ZFS на одном диске: имеет ли смысл

MAATRIX

Вы арендовали сервер с одним диском — SSD или NVMe, без второго для зеркала — и читаете про ZFS: снапшоты, сжатие, контрольные суммы, защита от битых данных. Возникает резонный вопрос: а есть ли смысл ставить ZFS, если избыточности всё равно нет и RAID-Z или зеркало тут не построить? Разберём честно: что ZFS даёт на одном диске без каких-либо оговорок, а что вам обещает только реклама файловой системы, но физически недостижимо без второго носителя.

Контрольные суммы: как ZFS ловит тихое повреждение данных

Начнём с главного отличия ZFS от ext4 или XFS, которое совсем не зависит от количества дисков. Каждый блок данных, который ZFS пишет на диск, получает контрольную сумму (по умолчанию — fletcher4, можно выставить sha256 через zfs set checksum=sha256 pool/dataset). Эта сумма хранится отдельно от самого блока — в родительском узле дерева метаданных, а не рядом с данными. При каждом чтении ZFS пересчитывает контрольную сумму блока и сверяет её с сохранённой.

Зачем это нужно? Диски иногда возвращают повреждённые данные без явной ошибки чтения — так называемое silent data corruption, тихое повреждение. Причины разные: битфлип в контроллере, баг прошивки SSD, деградация ячеек NAND, проблема на шине SATA/NVMe, ошибка в кэше RAID-контроллера. Диск при этом рапортует «чтение успешно», хотя данные уже не те, что записывались. Обычная файловая система (ext4, XFS, NTFS) в этот момент ничего не заметит: она доверяет диску и отдаёт приложению испорченные байты как есть. Если это конфиг — не страшно, максимум ошибка парсинга. Если это блок базы данных или файл в архиве, который вы не открывали полгода, — вы узнаете о проблеме в момент, когда данные уже нужны позарез, и окажется, что резервная копия давно перезаписана такой же тихой порчей.

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

zpool status -v tank

Если были ошибки чтения с несовпадением checksum, они покажутся в колонке CKSUM у соответствующего устройства, и это будет видно сразу — а не через полгода при попытке восстановиться из архива. Это работает совершенно одинаково что на массиве из 12 дисков, что на единственном NVMe в арендованном сервере: механизм проверки не требует избыточности, ему достаточно один раз посчитать хэш при записи и один раз при чтении.

Обнаружение — не значит исправление: что происходит без второго диска

Здесь начинается честная часть, которую часто замалчивают в статьях «10 причин перейти на ZFS». Контрольная сумма позволяет ZFS понять, что блок повреждён. Но чтобы исправить повреждение автоматически, файловой системе нужно откуда-то взять правильную копию этого же блока. В массиве с избыточностью (зеркало, RAID-Z1/Z2/Z3) вторая копия физически лежит на другом диске — ZFS читает её, проверяет контрольную сумму, убеждается, что она цела, и переписывает битый блок на первом диске корректными данными. Это называется self-healing, и это действительно работает автоматически при обычном чтении файла или при явном скрабе:

zpool scrub tank
zpool status tank   # дождаться завершения скраба и посмотреть на errors: 0

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

Частично ситуацию смягчает параметр copies. Если выставить zfs set copies=2 pool/dataset, ZFS начнёт хранить по две физические копии каждого блока метаданных и данных этого датасета — даже на одном диске, просто в разных местах диска. Это даёт шанс восстановиться при локальном повреждении сектора (диск жив, но конкретный участок побился), но не спасает при полном отказе самого диска — если умер контроллер SSD или пластина HDD, обе копии лежат на устройстве, которого больше нет. Плюс copies=2 удваивает расход места на этот датасет, так что это компромисс, а не бесплатная страховка.

Итог этого раздела предельно прост: без второго физического диска ZFS даёт вам обнаружение проблемы с высокой достоверностью, но не даёт автоматического исправления в общем случае. Это уже огромный шаг вперёд по сравнению с ext4, где вы вообще не узнаете о порче до тех пор, пока не откроете файл и не увидите, что он не читается или содержит мусор — но это не полная защита данных, которую иногда продают в рекламных статьях про ZFS.

Снапшоты на одном диске: полноценны без RAID

А вот здесь ситуация полностью противоположная — снапшоты ZFS никак не связаны с наличием избыточности между дисками, поэтому снапшоты в разных гипервизорах устроены по-разному, но принцип copy-on-write у самой ZFS работает одинаково на одном диске и на массиве. ZFS никогда не перезаписывает блок данных на месте — новая версия блока пишется в свободное место, а старые блоки остаются нетронутыми, пока на них ссылается снапшот. Создание снапшота — это просто фиксация текущего состояния указателей на блоки, без копирования самих данных:

zfs snapshot tank/data@2026-08-30
zfs list -t snapshot
zfs rollback tank/data@2026-08-30   # откат к состоянию снапшота

Снапшот создаётся почти мгновенно вне зависимости от объёма датасета — ведь физически ничего не копируется, только фиксируется ссылка на текущее дерево блоков. Место снапшот начинает занимать только тогда, когда исходные данные меняются: старый блок, на который ссылается снапшот, не освобождается, пока жив хотя бы один снапшот, который на него указывает. Это удобно для быстрого отката после неудачного обновления, миграции схемы БД или ошибки администратора — «откатить руками через 30 секунд» вместо «поднимать из бэкапа полчаса».

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

Сжатие данных: не зависит от количества дисков

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

zfs set compression=lz4 tank/data
zfs get compressratio tank/data

lz4 — разумный выбор по умолчанию: сжатие быстрое, накладные расходы на CPU минимальны, а на текстовых логах, конфигах, базах данных и виртуальных дисках часто даёт заметную экономию места. Для холодных архивов, где важнее плотность, чем скорость записи, можно взять zstd с более высоким уровнем компрессии за счёт CPU — zfs set compression=zstd-9 tank/archive.

Экономия места — не единственный эффект. Поскольку блок сжимается перед записью на диск, физически на носитель уходит меньше данных, чем логически записывает приложение — это снижает число реальных операций ввода-вывода на несжимаемую единицу полезных данных, что особенно заметно на медленных дисках или при высокой нагрузке по IOPS. На уже сжатых данных (видео, архивы, зашифрованные бэкапы) эффект от compression=lz4 минимален — ZFS достаточно умна, чтобы почти не тратить CPU на блоки, которые не сжимаются, но и выигрыша в месте здесь ждать не стоит.

Ни один из этих эффектов не требует второго диска. Компрессия — это преобразование данных перед записью на носитель, RAID и зеркала здесь вообще не участвуют в уравнении.

Управление датасетами, квотами и репликацией zfs send/receive

Третий пласт пользы от ZFS, независимый от избыточности, — удобство администрирования на уровне датасетов. Вместо одного большого раздела вы получаете иерархию логических датасетов внутри одного пула, у каждого — свои параметры:

zfs create tank/www
zfs create tank/db
zfs set quota=50G tank/www
zfs set quota=200G tank/db
zfs set recordsize=16K tank/db      # мельче блок под случайный доступ БД
zfs set atime=off tank/www          # меньше лишней записи метаданных

Квоты и резервации (reservation) позволяют держать несколько сервисов на одном пуле без риска, что один прожорливый датасет съест всё место и уронит остальные — привычная проблема на больших разделах ext4, где придётся резать LVM-тома заранее и негибко. Здесь границы датасетов меняются на лету одной командой, без остановки сервисов и без пересчёта разделов.

Отдельно стоит zfs send/zfs receive — механизм передачи снапшотов между пулами, в том числе на другой сервер по сети:

zfs snapshot tank/db@migrate
zfs send tank/db@migrate | ssh user@remote-host "zfs receive backup/db"

Это уже прямой мостик к резервному копированию: снапшот на одном диске сам по себе не бэкап, но переданный на другой сервер через zfs send — уже полноценная резервная копия, лежащая на физически другом носителе. Инкрементальная отправка (zfs send -i) передаёт только разницу между снапшотами, что для больших датасетов кратно экономит трафик и время по сравнению с полной синхронизацией файлов rsync-ом.

Чего ZFS не даёт на одном диске: отказ — значит потеря данных, как и везде

Теперь — то, что важно проговорить прямо, без реверансов в сторону маркетинга файловой системы. ZFS не создаёт избыточность из воздуха там, где физически есть только один диск. Если единственный накопитель в сервере полностью выходит из строя — умирает контроллер SSD, отказывает механика HDD, сгорает электроника — вы теряете все данные на этом диске целиком, включая пул ZFS со всеми его снапшотами, датасетами и настройками. Это ровно тот же исход, что и с ext4, XFS, NTFS или любой другой файловой системой на одном диске: RAID и файловые системы с избыточностью защищают от отказа диска только когда физически есть куда переключиться, а на одном носителе переключаться попросту не на что.

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

Отсюда практический вывод: если сервер с одним диском хранит что-то ценное, ZFS не отменяет необходимость резервного копирования на другой физический носитель — будь то другой сервер, объектное хранилище или внешний бэкап-сервис. zfs send в связке с удалённым хостом — удобный инструмент для этого, но сам факт «у меня ZFS» ничего не значит, если снапшоты некуда отправлять, кроме локального диска.

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