Btrfs против ext4: как выбрать файловую систему для надёжного RAID и не потерять данные

Когда сервер с критически важными данными падает в три часа ночи, а телефон разрывается от звонков, меньше всего хочется думать о том, что файловая система была выбрана неправильно. За пятнадцать лет работы с Linux-инфраструктурой я видел достаточно подобных ситуаций, чтобы понять простую истину: выбор между Btrfs и ext4 - это не вопрос моды или личных предпочтений. Это стратегическое решение, которое определяет, насколько спокойно вы будете спать.

Фундаментальные различия: два подхода к хранению

Ext4 - это проверенный временем инструмент. Надёжный, предсказуемый, понятный. Файловая система появилась в 2008 году как эволюция ext3 и с тех пор стала стандартом де-факто для большинства Linux-дистрибутивов. Она поддерживает журналирование, работает стабильно под нагрузкой и редко преподносит сюрпризы.

Btrfs представляет собой совершенно иную философию. Здесь реализован механизм Copy-on-Write (CoW), который меняет саму парадигму записи данных. При любой модификации файла система не перезаписывает исходные блоки, а создаёт новую копию изменённых данных в свободном пространстве. Старые блоки остаются нетронутыми до тех пор, пока новые данные не будут полностью записаны. Честно говоря, когда я впервые разобрался в этом механизме, то понял - это именно то, чего не хватало для по-настоящему отказоустойчивых систем.

Что это даёт на практике? Если питание отключится в момент записи, ext4 может потерять данные или оставить файл в повреждённом состоянии. Журнал поможет восстановить метаданные, но содержимое файла - под вопросом. В случае с Btrfs старые данные остаются целыми, поскольку новые ещё не были полностью записаны и ссылки на них не обновились.

Snapshots: страховка, которая работает

Снимки состояния файловой системы в Btrfs - это не просто удобная функция. Это фундаментальный инструмент для enterprise-окружений. Благодаря CoW создание snapshot занимает доли секунды независимо от объёма данных, потому что копируются только метаданные, а не сами файлы.

Для создания снимка достаточно выполнить:

btrfs subvolume snapshot /mnt/data /mnt/data/.snapshots/daily-2025-01-15

Для автоматизации многие используют snapper или btrbk. Вот пример конфигурации btrbk для ежечасных снимков с автоматической ротацией:

snapshot_preserve_min   2d
snapshot_preserve       14d

volume /mnt/data
  snapshot_dir .snapshots
  subvolume home
  subvolume databases

В ext4 подобная функциональность требует использования LVM snapshots, которые работают на уровне блочного устройства и потребляют значительно больше ресурсов. Кроме того, LVM-снимки деградируют по производительности по мере накопления изменений - эффект, который мне приходилось наблюдать неоднократно на продакшн-серверах.

RAID: встроенная защита против внешних костылей

Здесь разница между двумя файловыми системами становится особенно заметной. Ext4 полностью полагается на внешний RAID - будь то аппаратный контроллер или mdadm. Файловая система просто видит одно блочное устройство и не знает ничего о физической структуре массива.

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

Для создания массива RAID1 с Btrfs:

mkfs.btrfs -m raid1 -d raid1 /dev/sda /dev/sdb /dev/sdc

При чтении данных файловая система сверяет контрольные суммы. Если обнаруживается несоответствие, Btrfs автоматически читает правильную копию с другого диска и восстанавливает повреждённые данные. Это происходит прозрачно для приложений. Ext4 в связке с mdadm такой возможности лишена - она просто не знает, что данные повреждены, пока не станет слишком поздно.

Однако справедливости ради отмечу: RAID5 и RAID6 в Btrfs до сих пор имеют статус экспериментальных. Для продакшн-систем с этими уровнями RAID я по-прежнему рекомендую связку mdadm плюс ext4. Иногда старые решения оказываются надёжнее новых.

Миграция данных: пошаговый алгоритм без потерь

Переход с ext4 на Btrfs требует тщательной подготовки. Теоретически существует утилита btrfs-convert для конвертации на месте, но в enterprise-среде я категорически не советую этот путь. Слишком много переменных, слишком высоки риски.

Проверенный алгоритм миграции выглядит следующим образом. Первым делом нужно создать полный бэкап данных на отдельное хранилище - это аксиома, которую нельзя игнорировать. Затем подготавливаем новый раздел с Btrfs и настраиваем структуру подтомов:

mkfs.btrfs -L data_new /dev/sdc1
mount /dev/sdc1 /mnt/btrfs_new
btrfs subvolume create /mnt/btrfs_new/@data
btrfs subvolume create /mnt/btrfs_new/@databases

Для переноса данных с сохранением всех атрибутов использую rsync с правильными флагами:

rsync -aHAXxv --progress /mnt/ext4_old/ /mnt/btrfs_new/@data/

После переноса обязательно проверяем целостность:

btrfs scrub start /mnt/btrfs_new
btrfs scrub status /mnt/btrfs_new

Весь процесс для терабайтных массивов может занять несколько часов. Планируйте maintenance window заранее и предупреждайте пользователей. Спешка на этом этапе - прямой путь к проблемам.

Восстановление после сбоев: когда теория встречается с практикой

Каждый системный администратор рано или поздно сталкивается с отказом диска или повреждением данных. Вопрос не в том, случится ли это, а когда именно.

Для ext4 стандартным инструментом восстановления служит fsck:

umount /dev/sda1
e2fsck -f -y /dev/sda1

Процедура проверяет журнал, метаданные и при необходимости восстанавливает структуру каталогов. Работает надёжно, но возможности ограничены - если данные перезаписаны, восстановить их не получится.

Btrfs предлагает более богатый инструментарий:

btrfs check /dev/sda1
btrfs check --repair /dev/sda1  # использовать с осторожностью
btrfs restore /dev/sda1 /mnt/recovery  # извлечение данных

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

mv /mnt/data/@home /mnt/data/@home.broken
btrfs subvolume snapshot /mnt/data/.snapshots/yesterday/@home /mnt/data/@home

Помню случай, когда скрипт обновления базы данных отработал некорректно и повредил индексы. Благодаря снимку, созданному автоматически за пять минут до обновления, сервис восстановили за считанные минуты, а не часы.

Оптимизация под SSD: тонкости настройки

Твердотельные накопители требуют особого подхода к настройке файловой системы. Ключевые моменты, которые следует учитывать, включают поддержку TRIM, выравнивание разделов и минимизацию избыточных операций записи.

Для ext4 на SSD рекомендуемые опции монтирования:

/dev/nvme0n1p1 /data ext4 defaults,noatime,discard=async 0 2

Опция noatime отключает обновление времени доступа при чтении файлов, что существенно снижает количество записей. Discard=async включает фоновый TRIM.

Для Btrfs настройка несколько сложнее из-за CoW:

/dev/nvme0n1p1 /data btrfs defaults,noatime,compress=zstd:3,ssd,discard=async 0 0

Параметр ssd активирует оптимизации для твердотельных накопителей. Сжатие zstd уменьшает объём записываемых данных, что продлевает ресурс SSD и часто улучшает производительность за счёт снижения нагрузки на шину.

Для баз данных и виртуальных машин на Btrfs критически важно отключить CoW для файлов данных:

chattr +C /var/lib/mysql/
chattr +C /var/lib/libvirt/images/

Без этой настройки производительность случайной записи может упасть катастрофически. Многие пропускают этот шаг и потом удивляются тормозам - типичная ошибка при переходе на Btrfs.

Какую систему выбрать: матрица решений

После всего сказанного закономерен вопрос: что же использовать? Универсального ответа не существует, но могу предложить ориентиры на основе собственного опыта.

Ext4 остаётся лучшим выбором для простых файловых серверов без критичных требований к снимкам, для систем с аппаратным RAID-контроллером, для баз данных с интенсивной случайной записью и для окружений, где стабильность важнее функциональности.

Btrfs предпочтительнее для систем, требующих регулярных снимков состояния, для программных RAID1 и RAID10 массивов, для контейнерных платформ и виртуализации, для сценариев, где важна проверка целостности данных.

По сути, выбор сводится к балансу между проверенной надёжностью и современными возможностями. Ext4 - это как надёжный внедорожник: доедет везде, не подведёт, но без изысков. Btrfs - современный электромобиль с кучей функций, однако требующий более внимательного обращения.

В своей практике я использую обе системы в зависимости от задачи. Серверы баз данных работают на ext4 поверх аппаратного RAID. Файловые хранилища и системы резервного копирования используют Btrfs с её снимками и встроенной проверкой целостности. Такой гибридный подход позволяет извлечь максимум из обеих технологий.

Главное помнить: никакая файловая система не заменит грамотную стратегию резервного копирования. Снимки Btrfs защищают от логических ошибок и случайного удаления, но не спасут при физическом отказе всех дисков массива. Правило 3-2-1 никто не отменял - три копии данных, на двух разных типах носителей, одна копия вне площадки.