btrfs сегодня: где он хорош, а где до сих пор рискован

MAATRIX

Если вы гуглите «btrfs надёжен или нет», то попадёте либо на статьи 2015 года про потерю данных на RAID 5, либо на свежие посты «у меня всё летает пятый год». Обе крайности честны, но обе — про разные вещи внутри одной файловой системы. Разберём btrfs не единым вердиктом «хорош/плох», а по конкретным возможностям — потому что именно так и нужно принимать это решение.

Почему нельзя оценивать btrfs одной фразой

btrfs — это не одна функция, а набор довольно независимых друг от друга подсистем: copy-on-write и снапшоты, встроенное сжатие, контрольные суммы данных и метаданных, и отдельно — код многодисковой избыточности (RAID-профили). Исторически проблемы возникали именно в последней части, а не во всей файловой системе целиком. Но репутация «btrfs ест данные» приклеилась ко всей системе сразу, включая сценарии, которые никогда не были проблемными.

Это важно, потому что решения принимаются здесь и сейчас, а статьи в интернете фиксируют состояние на момент публикации. Ядро Linux и btrfs-progs продолжают развиваться, и single-diск-сценарий 2026 года — не то же самое, что RAID6 2016 года, хотя формально это «одна и та же файловая система». Дальше — по пунктам, и в каждом честно скажем, где уверенность высокая, а где нужно проверять самостоятельно.

Один диск: снапшоты, сжатие, контрольные суммы — зрелая часть

Здесь оценка спокойная: базовый набор возможностей btrfs на одном диске (или на нескольких дисках без parity-RAID, то есть без RAID 5/6) на сегодня — зрелая и стабильная функциональность. Это не голословное утверждение: btrfs уже много лет является файловой системой по умолчанию в openSUSE (Leap и Tumbleweed), используется как опция в Fedora Workstation (default с Fedora 33), и годами эксплуатируется на десктопах и серверах именно в этом режиме — один или несколько дисков без сложной parity-избыточности.

Copy-on-write здесь работает предсказуемо. Снапшот подтома создаётся мгновенно и почти без накладных расходов, потому что физически не копирует данные — он лишь фиксирует состояние дерева экстентов на момент вызова:

# создать снапшот подтома @home перед обновлением системы
btrfs subvolume snapshot /mnt/@home /mnt/@home_snap_2026-09-05

# посмотреть список снапшотов
btrfs subvolume list -s /mnt

Сжатие включается на уровне точки монтирования или конкретного подтома, и алгоритм zstd (доступен начиная с ядра 4.14, но по-настоящему обкатан именно в последние годы) даёт разумный баланс между экономией места и нагрузкой на CPU:

# в /etc/fstab
UUID=xxxx  /data  btrfs  defaults,compress=zstd:3,ssd,noatime  0  0

Контрольные суммы данных и метаданных считаются на лету (по умолчанию crc32c, можно выбрать xxhash, sha256 или blake2 при создании файловой системы) и проверяются при каждом чтении. Если диск начал незаметно портить биты — а такое случается на любом накопителе, — вы узнаете об этом при обращении к файлу, а не через полгода при попытке восстановить бэкап:

# внеплановая проверка контрольных сумм всего раздела
btrfs scrub start /data
btrfs scrub status /data

Это ключевое отличие от ext4/XFS, где контрольные суммы данных вообще не считаются (у XFS есть контрольные суммы метаданных, у ext4 — тоже частично, но не данных). Если для вас принципиально знать, что прочитанный файл — это ровно то, что было записано, а не тихо повреждённый бит, btrfs в single-диск-режиме даёт это «из коробки» без танцев с dm-integrity. Про альтернативы без этой возможности можно почитать в статье про выбор между ext4 и XFS — там контрольных сумм данных нет ни у одной из двух систем.

Специфика, о которой стоит знать заранее: btrfs не любит, когда диск заполняется под завязку (аллокатору сложнее находить свободные экстенты, отсюда иногда встречающиеся ошибки ENOSPC при формально свободном месте) и периодически требует btrfs balance для перераспределения блочных групп на активно меняющихся томах. Это не баг, а особенность архитектуры — с ней нужно жить, а не бояться.

RAID 5/6 в btrfs: что было не так и что нужно проверить сейчас

Здесь придётся быть предельно честным, потому что это ровно та часть, из-за которой у btrfs плохая репутация в целом. RAID 5 и RAID 6 профили btrfs (распределение данных с чётностью по нескольким дискам) годами имели задокументированную и серьёзную проблему — так называемый «write hole»: при отказе диска или неожиданном отключении питания во время записи чётность могла оказаться рассинхронизирована с данными, что в худшем случае вело к невосстановимой потере части данных при ребилде массива. Это не слухи — статус этой конкретной возможности как «нестабильной, не рекомендованной для продакшена» годами официально фиксировался в вики проекта btrfs, и именно поэтому в профессиональной среде сложилось устойчивое правило: RAID 5/6 в btrfs — нет, если данные важны.

Что здесь честно нужно сказать про конец 2026 года: мы не можем и не будем утверждать, что проблема окончательно решена или всё ещё актуальна в это же самой степени — ситуация зависит от конкретной версии ядра и от того, какие именно исправления попали в мейнлайн к моменту, когда вы это читаете. За несколько лет в код parity-RAID вносились точечные исправления, но принципиальная архитектурная переработка (устраняющая write hole на уровне дизайна, а не заплаткой) — это отдельный вопрос, ответ на который меняется быстрее, чем живут статьи в интернете.

Поэтому если вы рассматриваете btrfs RAID 5/6 для реального продакшена в 2026 году, сделайте буквально следующее перед тем, как принимать решение:

1. Откройте актуальную страницу статуса возможностей на wiki проекта btrfs (раздел Status, где по каждому RAID-профилю отдельно указана степень стабильности) — не полагайтесь на скриншоты и пересказы трёхлетней давности.
2. Проверьте changelog ядра, которое реально будет стоять на сервере, на предмет упоминаний исправлений в raid56-коде btrfs за последние 1-2 года.
3. Поищите свежие (не старше нескольких месяцев на момент проверки) отчёты пользователей о ребилде RAID5/6-массива после реального отказа диска — а не только синтетические тесты в лаборатории.
4. Если после этой проверки остаются сомнения — их не нужно снимать «на слово» ни в одну, ни в другую сторону. Не эксплуатируйте на продакшен-данных возможность, чей текущий статус вы не смогли подтвердить.

Не менее важный нюанс: даже когда run-time поведение стабилизируется, отдельно стоит вопрос производительности записи при parity-RAID — она структурно медленнее, чем при простом зеркалировании, независимо от статуса надёжности. Общее устройство RAID-уровней и то, почему parity дороже по вычислениям, разобрано в статье про уровни RAID и как выбирать между ними.

RAID 1 и простые схемы: более спокойный сценарий

Профиль RAID 1 в btrfs (полное зеркалирование данных и метаданных на двух и более дисках, без чётности) архитектурно проще, чем RAID 5/6, и именно поэтому считается в сообществе заметно более стабильным сценарием. Здесь нет write hole в том виде, в котором он существует у parity-RAID: при записи каждый блок просто дублируется на второй (или третий) диск, и рассинхронизации чётности физически быть не может — её здесь просто нет как понятия.

# создать btrfs-том с зеркалированием данных и метаданных на двух дисках
mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc

# посмотреть распределение по дискам и заполненность
btrfs filesystem usage /mnt/data

Это не значит «RAID 1 в btrfs гарантированно надёжен при любых условиях» — здесь та же общая рекомендация, что и для всей темы: если решение критично для бизнеса, стоит свериться с актуальным статусом конкретно этого профиля перед продакшен-нагрузкой, а не полагаться на репутацию «раз это не RAID5/6, значит всё хорошо». Но по совокупности признаков (архитектурная простота, многолетняя эксплуатация именно в этом режиме, отсутствие открытых громких инцидентов последних лет именно с raid1-профилем) — это заметно более консервативный выбор внутри самой экосистемы btrfs, чем parity-уровни.

Отдельно стоит помнить: RAID любого уровня — это защита от отказа диска, а не резервная копия. Если ошибка приложения или человек случайно удалит данные, зеркало добросовестно продублирует и удаление тоже. Это не специфика btrfs, это общее свойство любого RAID — подробно разобрано в статье про миф о том, что RAID заменяет бэкап, и снапшоты btrfs здесь дополняют RAID, а не заменяют его: снапшот спасает от случайного rm -rf, RAID — от физического отказа диска, а от полной потери сервера спасает только копия данных в другом месте.

btrfs против ZFS и mdadm+ext4/XFS: когда что выбирать

Для честного выбора полезно сравнить btrfs не абстрактно, а по тем же осям — снапшоты, сжатие, контрольные суммы, многодисковая избыточность:

Если вам нужны снапшоты и сжатие на одном диске или в простом зеркале — btrfs и ZFS в 2026 году это разумные, сопоставимые варианты, выбор между ними скорее вопрос экосистемы (ZFS исторически теснее связан с Proxmox/TrueNAS и лицензионно не входит в мейнлайн ядра Linux, что для кого-то плюс, для кого-то минус). Про базовые понятия ZFS — пул, датасет, снапшот — есть отдельный разбор в статье ZFS за 15 минут.

Если же нужна многодисковая конфигурация с parity и высокими требованиями к сохранности данных (продакшен-база, единственная копия важных файлов), а не просто «побольше места», честная рекомендация на 2026 год такая: mdadm RAID5/6 поверх ext4 или XFS — это консервативный, десятилетиями проверенный путь, у которого нет истории с write hole в том виде, что была у btrfs (mdadm использует собственные, давно отработанные механизмы защиты от рассинхронизации, включая write-intent bitmap), пусть и без встроенных снапшотов и контрольных сумм данных на уровне файловой системы. ZFS RAID-Z — более функциональный вариант с той же надёжностью на этом уровне избыточности, если ваша инфраструктура готова его нести. btrfs RAID5/6 в этом сравнении — тот вариант, чей статус нужно проверить лично перед принятием решения, а не тот, который можно взять по умолчанию просто потому, что «это же одна файловая система, где уже всё остальное хорошо».

Практический чеклист: как снизить риск при выборе

Собираем сказанное выше в последовательность действий:

• Один диск или простое зеркало, снапшоты и сжатие важны — берите btrfs (или ZFS) без колебаний, это зрелый сценарий на конец 2026 года, широко эксплуатируемый как значениями по умолчанию в дистрибутивах, так и на реальных серверах годами.
• Нужен parity-RAID (5/6) и данные критичны — не принимайте решение по этой статье или любой другой статье «на слово». Проверьте актуальный статус на wiki проекта btrfs, changelog используемого ядра и свежие пользовательские отчёты о реальных ребилдах после отказа диска. Если после проверки остаются сомнения — используйте mdadm+ext4/XFS или ZFS RAID-Z как более консервативную и дольше проверенную альтернативу именно на этом уровне избыточности.
• Не путайте RAID со снапшотами и с бэкапом — снапшот в btrfs защищает от логической ошибки (случайное удаление, неудачное обновление), RAID любого уровня — от физического отказа диска, а от потери всего сервера целиком защищает только копия за пределами этого сервера.
• Мониторьте scrub регулярно, а не только при подозрении на проблему — btrfs scrub находит битые контрольные суммы, пока у вас ещё есть избыточность (вторая копия или resilvering-источник), чтобы их исправить; после отказа диска возможности для исправления уже может не быть.
• Делайте резервные копии независимо от выбранной файловой системы — ни btrfs, ни ZFS, ни mdadm-массив не отменяют необходимость копии данных в другом месте. Это правило работает вне зависимости от того, насколько зрелой окажется конкретная возможность к моменту, когда вы читаете эту статью.

Частые вопросы