Объединенная статья: Методы восстановления файловых систем в Linux: от диагностики до полного восстановления и eBPF для наблюдаемости Linux: архитектура, production-ready примеры и типовые ошибки

Введение

Файловые системы являются критически важной частью любой операционной системы, особенно в Linux-среде, где разнообразие файловых систем (ext4, XFS, Btrfs и др.) предоставляет широкие возможности для хранения и управления данными. Однако, как и любое сложное программное обеспечение, файловые системы подвержены сбоям, ошибкам и повреждениям, что может привести к потере данных или недоступности системы. В данной статье мы рассмотрим методы диагностики и восстановления файловых систем в Linux, от базовых инструментов до продвинутых техник.

Диагностика проблем файловой системы

Перед началом восстановления важно правильно диагностировать проблему. Вот основные шаги диагностики:

1. Проверка целостности файловой системы с помощью fsck:

   sudo fsck /dev/sda1
   

   Этот инструмент проверяет и пытается исправить ошибки в файловой системе.

2. Использование smartctl для проверки состояния диска:

   sudo smartctl -a /dev/sda
   

   Этот инструмент позволяет оценить физическое состояние диска, что может быть важно для понимания причины повреждения файловой системы.

3. Анализ логов системы:

   sudo journalctl -xe
   

   Логи могут содержать важную информацию о сбоях и ошибках файловой системы.

Восстановление файловых систем

1. Восстановление ext4

Для файловой системы ext4 основной инструмент восстановления — e2fsck. Вот как его использовать:

sudo umount /dev/sda1
sudo e2fsck -f /dev/sda1

2. Восстановление XFS

Для XFS используется инструмент xfs_repair:

sudo umount /dev/sda1
sudo xfs_repair /dev/sda1

3. Восстановление Btrfs

Btrfs имеет встроенные инструменты для восстановления:

sudo btrfs check --repair /dev/sda1

Продвинутые техники восстановления

1. Использование LVM

Если файловая система находится на логическом томе (LVM), восстановление может быть более сложным. Вот основные шаги:

1. Проверка состояния LVM:

   sudo vgdisplay
   sudo lvdisplay
   

2. Восстановление логического тома:

   sudo lvchange -ay /dev/vg0/lv0
   

2. Восстановление RAID

Для RAID-массивов используется инструмент mdadm:

sudo mdadm --assemble --scan

Заключение

Восстановление файловых систем в Linux — это процесс, требующий внимательного подхода и использования правильных инструментов. Правильная диагностика и выбор метода восстановления могут значительно сократить время простоя и предотвратить потерю данных. Важно регулярно создавать резервные копии и следить за состоянием дисков и файловых систем для предотвращения серьезных проблем.

eBPF для наблюдаемости Linux: архитектура, production-ready примеры и типовые ошибки

Аннотация

Практическое руководство по применению eBPF в production: архитектура подсистемы, безопасная загрузка программ, observability-стек (метрики, трейсы, логи), типовые ошибки и чек-лист внедрения. Подходит для SRE и platform-инженеров.

1. Архитектура и безопасность

Компоненты:

• Ядро: verifier, JIT, maps, helpers, tail calls, BTF.
• Пользовательское пространство: libbpf/libbpfgo, bpftool, bpftrace.
• Безопасность: privilege model (CAP_BPF/CAP_PERFMON/CAP_SYS_ADMIN), signed programs, LSM/BPF, ограничение bpf() через sysctl.

Ключевые свойства:

• Нулевая или минимальная задержка instrumentation.
• Программируемость без перезагрузки сервисов.
• Изоляция через верификатор и BTF типов.

2. Production-ready стек

2.1 Метрики: трассировка системных вызовов и latency

Пример на bpftrace для latency fsync:

bpftrace -e 'tracepoint:syscalls:sys_enter_fsync { @start[tid] = nsecs; } tracepoint:syscalls:sys_exit_fsync /@start[tid]/ { @lat = hist(nsecs - @start[tid]); delete(@start[tid]); }'

Экспорт в Prometheus через exporter (например, bcc/parca-agent или кастомный на libbpf):

• Карты BPF: HISTOGRAM, COUNTER.
• Скрейпинг каждые 10–15 секунд.

2.2 Трейсы: распределённая трассировка через BPF/USDT

• USDT в приложениях (PostgreSQL, Nginx, Java): tracepoints без перекомпиляции.
• Корреляция через сквозные идентификаторы (trace_id) в maps.
• Агрегация в коллекторе (OpenTelemetry Collector с BPF receiver или vendor-решения).

2.3 Логирование и безопасность

• Мониторинг аномалий: частые OOM/execve, необычные сетевые соединения.
• LSM-BPF политики: ограничение file_create/socket_connect по меткам.
• Audit-совместимость: экспорт в journald/syslog-ng/rsyslog с structured-data.

3. Практические примеры

3.1 Контейнерный observability

• Отслеживание cgroup переходов, latency планировщика, ошибок cgroup BPF.
• Изоляция per-namespace: отдельный maps namespace, mount namespace для BPF FS.

3.2 Сетевая наблюдаемость

• XDP для ранней отбраковки DDoS, учёт по 5-tuple, latency TCP handshake.
• TC-BPF для маркировки и rate-limit без изменения приложения.

3.3 Профилирование CPU/IO

n

• perf/perf-tools замена на BPF: on-CPU flamegraphs через stack traces и maps.
• IO latency по устройствам, выявление «шумных соседей».

4. Типовые ошибки

• Игнорирование verifier: сложные циклы, недоступные пути, рост стека > 512.
• Несогласованность BTF: ядро vs user-space, разные версии пакетов.
• Утечки maps: отсутствие gc, лимиты rlimit_memlock.
• Отсутствие fallback: программа не загрузилась — сервис без наблюдаемости.
• Неправильные права: избыточный CAP_SYS_ADMIN вместо CAP_BPF/CAP_PERFMON.

5. Чек-лист внедрения

• Ядро с CONFIG_BPF, CONFIG_BPF_JIT, BTF включён.
• Привилегии минимальны: CAP_BPF/CAP_PERFMON.
• CI проверяет verifier на CI-образе ядра.
• Maps с лимитами и GC; мониторинг rlimit_memlock.
• Экспорт метрик в Prometheus; алерты на drop/verifier errors.
• Runbooks: загрузка/откат BPF-программы, диагностика verifier.
• Тест восстановления: отключение BPF не ломает SLO.

6. Инструментарий

• libbpf/bpftool/bpftrace; Cilium/ebpf_exporter/parca-agent.
• BTF: pahole, kernel-devel-btf, синхронизация с prod-ядром.
• CI: github actions с matrix по ядрам, signed BPF.

Заключение

eBPF — зрелый production-инструмент при соблюдении дисциплины: минимизация привилегий, BTF-совместимость, наблюдаемость самого eBPF и чёткие runbooks.