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

Введение

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

Типичные причины повреждения файловых систем

Перед рассмотрением методов восстановления важно понять, почему файловые системы могут повреждаться:

• Аппаратные сбои: отказы жестких дисков, RAID-массивов или других компонентов хранения.
• Программные ошибки: некорректная работа приложений или системных утилит.
• Человеческий фактор: случайное удаление данных или неправильные действия администраторов.
• Вирусы и вредоносное ПО: атаки, приводящие к повреждению файловой системы.

Инструменты для восстановления файловых систем

fsck

fsck (File System Consistency Check) — основной инструмент для проверки и восстановления файловых систем в Linux. Он поддерживает различные типы файловых систем, включая ext2, ext3, ext4, XFS и Btrfs.

Использование:

sudo fsck /dev/sda1

e2fsck

Для файловых систем ext2, ext3 и ext4 используется специализированный инструмент e2fsck. Он предоставляет более детальные возможности по восстановлению.

Использование:

sudo e2fsck -f /dev/sda1

xfs_repair

Для файловой системы XFS используется xfs_repair. Этот инструмент предназначен для проверки и восстановления XFS-разделов.

Использование:

sudo xfs_repair /dev/sda1

btrfs check

Для файловой системы Btrfs используется btrfs check. Он позволяет проверять и восстанавливать Btrfs-разделы.

Использование:

sudo btrfs check /dev/sda1

Методы восстановления

1. Проверка файловой системы

Перед началом восстановления рекомендуется выполнить полную проверку файловой системы с помощью соответствующего инструмента (fsck, e2fsck, xfs_repair, btrfs check).

2. Создание резервной копии

Перед любыми действиями по восстановлению рекомендуется создать резервную копию поврежденного раздела. Это можно сделать с помощью dd:

sudo dd if=/dev/sda1 of=/path/to/backup.img bs=4M

3. Восстановление данных

Если проверка и восстановление с помощью стандартных инструментов не помогли, можно использовать специализированные утилиты для восстановления данных:

• testdisk: для восстановления разделов и файловых систем.
• photorec: для восстановления удаленных файлов.
• extundelete: для восстановления удаленных файлов на ext2/ext3/ext4.

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

Если данные хранятся на RAID-массиве или LVM, важно учитывать особенности восстановления:

• RAID: восстановление данных с помощью резервных копий или замены неисправных дисков.
• LVM: использование логических томов для восстановления данных.

Заключение

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

Рекомендуемые практики

1. Регулярно выполняйте резервное копирование данных.
2. Используйте RAID и LVM для повышения надежности хранения данных.
3. Периодически проверяйте целостность файловых систем с помощью fsck.
4. Обучайте администраторов методам восстановления и лучшим практикам.

Заключение

Восстановление файловых систем — это критически важная задача, требующая тщательного подхода и использования правильных инструментов. Следуя описанным методам и рекомендациям, системные администраторы могут значительно повысить надежность и доступность данных в 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.