Що таке 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 — рівень надмірності:
| Тип vdev | Мін. дисків | Втрата дисків без даних |
|---|---|---|
| mirror | 2 | 1 з 2 |
| RAIDZ1 | 3 | 1 |
| RAIDZ2 | 4 | 2 |
| RAIDZ3 | 5 | 3 |
Створення дзеркального пулу з двох дисків:
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 tankScrub читає кожен блок, звіряє контрольну суму і, якщо надмірність дозволяє, лагодить знайдені помилки на льоту. Для продакшн-серверів scrub ставлять за розкладом раз на 1-2 тижні через cron, а стан пулу перевіряють на предмет рядка state: DEGRADED — він означає, що один із дисків уже недоступний і пул працює без запасу з надмірності.
Чек-лист: коли ZFS виправдана на виділеному сервері
- Потрібні снапшоти і швидкий відкат без зупинки сервісу — у ZFS це вбудована функція, а не окремий інструмент.
- Важливий захист від тихого пошкодження даних — контрольні суми блоків ZFS перевіряє під час кожного читання.
- На сервері достатньо RAM: під ARC варто планувати не менше 4-8 ГБ понад потреби застосунків.
- Є ECC-пам'ять — інакше переваги від контрольних сум ZFS частково втрачаються на етапі кешу в оперативній пам'яті.
- Розширення пулу планується заздалегідь цілими vdev, а не окремими дисками «за потреби».
ZFS не панацея: для простих веб-серверів з одним диском її можливості надмірні, а от для файлових сховищ і серверів баз даних із частими снапшотами вона знімає частину завдань, які інакше вирішувалися б окремими утилітами поверх ext4 і mdadm.