ZFS на выделенном сервере: пулы, ARC, снапшоты

Что такое ZFS и чем он отличается от mdadm и ext4

ZFS — это файловая система и одновременно менеджер томов: она объединяет диски в пул, отвечает за RAID, кеширование в памяти и контрольные суммы данных в одном слое, без отдельного RAID-контроллера или mdadm. Каждый блок данных ZFS хранит вместе с контрольной суммой и при чтении сверяет её, поэтому тихое повреждение данных (bit rot) обнаруживается сразу, а не через месяцы.

На выделенном сервере ZFS чаще ставят на Linux через модуль OpenZFS или на FreeBSD, где она входит в базовую систему. Для входа с нуля пригодится опыт работы с RAID и понимание, как устроена дисковая подсистема сервера: ZFS не отменяет разницу между HDD, SATA SSD и NVMe, она лишь управляет ими по-другому.

Структура пула: vdev, RAIDZ1/2/3 и зеркало

Пул ZFS (zpool) состоит из одного или нескольких vdev. Данные пишутся по vdev параллельно (как RAID 0), а внутри каждого vdev — уровень избыточности:

Создание зеркального пула из двух дисков:

zpool create tank mirror /dev/sda /dev/sdb
zpool status tank

Расширить пул можно, только добавив новый vdev целиком — увеличить существующий RAIDZ на один диск без пересоздания пула нельзя, это нужно учитывать при планировании места заранее.

ARC и L2ARC: как ZFS использует память под кеш

ZFS держит основной кеш чтения (ARC, Adaptive Replacement Cache) в оперативной памяти сервера и по умолчанию может забирать под него до половины всей RAM. Это нормальное поведение, а не утечка памяти: ARC отдаёт память другим процессам по запросу. На серверах с большим объёмом холодных данных для второго уровня кеша используют L2ARC на NVMe-диске — он не хранит данные постоянно, а кеширует то, что уже вытеснено из ARC.

Поскольку ARC хранит данные без такой же строгой проверки на лету, как контрольные суммы на диске, для ZFS особенно важна ECC-память: без коррекции ошибок повреждённый бит в кеше ARC может записаться на диск как «правильные» данные ещё до проверки.

Снапшоты и send/receive для бэкапов

Снапшот ZFS создаётся мгновенно и почти не занимает места, пока данные не изменятся:

zfs snapshot tank/data@2026-09-29
zfs list -t snapshot

Разницу между снапшотами можно передать на другой сервер потоком, без промежуточных файлов:

zfs send -i tank/data@2026-09-01 tank/data@2026-09-29 | \
  ssh backup-host zfs receive tank/data

Это удобный способ инкрементального переноса данных для резервного копирования: передаётся только изменённый объём, а не весь массив заново, и на приёмнике всегда есть консистентный снимок на момент снапшота.

Проверка целостности: scrub и мониторинг

Плановая проверка контрольных сумм всего пула запускается командой:

zpool scrub tank
zpool status -v tank

Scrub читает каждый блок, сверяет контрольную сумму и, если избыточность позволяет, чинит найденные ошибки на лету. Для продакшн-серверов scrub ставят по расписанию раз в 1-2 недели через cron, а состояние пула проверяют на предмет строки state: DEGRADED — она означает, что один из дисков уже недоступен и пул работает без запаса по избыточности.

Чек-лист: когда ZFS оправдана на выделенном сервере

• Нужны снапшоты и быстрый откат без остановки сервиса — у ZFS это встроенная функция, а не отдельный инструмент.
• Важна защита от тихого повреждения данных — контрольные суммы блоков ZFS проверяет на каждом чтении.
• На сервере достаточно RAM: под ARC стоит планировать не меньше 4-8 ГБ сверх потребностей приложений.
• Стоит ECC-память — иначе плюсы от контрольных сумм ZFS частично теряются на этапе кеша в оперативной памяти.
• Расширение пула планируется заранее целыми vdev, а не отдельными дисками «по мере необходимости».

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