ZFS за 15 минут: пул, датасет, снапшот

MAATRIX

Если вы впервые открываете man по ZFS, там за десять минут можно утонуть в терминах вроде vdev, ARC, RAID-Z и dedup — и так и не понять, с чего вообще начать работать руками. На самом деле для старта достаточно трёх понятий: пул, датасет и снапшот. Разберём их по порядку на реальных командах — этого хватит, чтобы за 15 минут создать рабочее хранилище и сделать первую точку отката.

Zpool: объединяем диски в один пул

Пул (zpool) — это фундамент ZFS. Вместо того чтобы форматировать каждый диск отдельно и городить LVM поверх, ZFS объединяет один или несколько физических дисков в единое пространство хранения, из которого потом нарезаются логические разделы. Пул — это то, с чем работает менеджер тома, а не файловая система в привычном смысле: сам по себе он ничего не хранит, но управляет дисками и их избыточностью.

Самый простой вариант — пул из одного диска:

zpool create tank /dev/sdb

Здесь tank — произвольное имя пула (можно назвать как угодно, tank — просто общепринятое в документации), а /dev/sdb — целый диск, который вы отдаёте под ZFS целиком. Важно: ZFS сам размечает диск под себя, вручную создавать разделы фдиском не нужно и обычно вредно.

Если дисков несколько и вы хотите избыточность, есть готовые схемы:

# зеркало из двух дисков (аналог RAID 1)
zpool create tank mirror /dev/sdb /dev/sdc

# raidz1 из трёх дисков (аналог RAID 5, один диск на чётность)
zpool create tank raidz1 /dev/sdb /dev/sdc /dev/sdd

Разбор классических уровней RAID и когда какой выбирать мы уже разбирали отдельно в статье про RAID на сервере: уровни и как выбирать — логика избыточности в ZFS похожа, но именно raidz устроен иначе на уровне записи данных, это тема отдельного разбора, а не этой статьи.

Проверить, что пул создался и жив, можно командой:

zpool status

Она покажет состояние (ONLINE, DEGRADED, FAULTED), список дисков в пуле и есть ли ошибки чтения/записи/чексумм. Это первая команда, которую стоит выучить наизусть — именно её вы будете гонять при подозрении на проблемы с диском.

Посмотреть, сколько места свободно и занято на уровне пула:

zpool list

Удалить пул целиком (осторожно, необратимо, если нет снапшотов и бэкапов):

zpool destroy tank

На этом этапе у вас уже есть работающий пул — но напрямую писать файлы в него вы не будете. Для этого нужен датасет.

Dataset: логический раздел внутри пула

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

Создание датасета:

zfs create tank/data

После этой команды ZFS сам смонтирует его — по умолчанию в /tank/data. Проверить список датасетов и куда они смонтированы:

zfs list

Вывод покажет колонки NAME, USED, AVAIL, REFER, MOUNTPOINT — сколько занято реально этим датасетом, сколько свободно во всём пуле (место общее для всех датасетов пула, если не выставлены квоты) и куда он смонтирован.

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

zfs create tank/data/photos
zfs create tank/data/backups

Каждый получит свою точку монтирования (/tank/data/photos, /tank/data/backups) и может настраиваться отдельно. Например, ограничить датасет по объёму:

zfs set quota=50G tank/data/photos

Или изменить точку монтирования на что-то более осмысленное:

zfs set mountpoint=/mnt/photos tank/data/photos

Датасеты поддерживают сжатие «из коробки» (обычно lz4, включается свойством compression), но это уже следующий уровень разбора — здесь просто держите в уме, что оно есть и включается одной командой, а глубину темы (когда оно того стоит, а когда нет) разберём отдельно.

Удалить датасет:

zfs destroy tank/data/backups

Если внутри датасета есть снапшоты — команда откажется его удалять, пока вы явно не скажете -r (рекурсивно, вместе со снапшотами) — это защита от случайной потери истории, и это подводит к следующей части.

Snapshot: мгновенная копия состояния без остановки

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

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

Создать снапшот:

zfs snapshot tank/data@before-update

Формат имени всегда такой: пул/датасет@имя_снапшота. Имя после @ — произвольное, но разумно называть его так, чтобы через месяц было понятно, зачем он сделан (before-update, 2026-08-30, pre-migration).

Посмотреть список снапшотов:

zfs list -t snapshot

Если что-то пошло не так и нужно откатиться к состоянию на момент снапшота:

zfs rollback tank/data@before-update

Важный нюанс, который стоит проговорить сразу, а не узнавать на практике: rollback откатывает датасет к состоянию снапшота и удаляет все более поздние снапшоты, если они были сделаны после того, к которому вы откатываетесь (без флага -r команда откажется выполняться, если такие снапшоты есть — это защита, а не забытая мелочь). Если вам нужно не терять текущее состояние, а просто посмотреть на старые данные — не откатывайте датасет целиком, а склонируйте снапшот или обратитесь к нему напрямую через скрытую директорию .zfs/snapshot/ внутри точки монтирования датасета:

ls /tank/data/.zfs/snapshot/before-update/

Так можно скопировать один нужный файл из прошлого, не трогая текущее состояние всего датасета.

Удалить снапшот, когда он больше не нужен:

zfs destroy tank/data@before-update

Полный пример: от нуля до отката снапшота

Соберём всё вместе — вот минимальная последовательность команд, которая проведёт вас от голого диска до отработанного отката, ровно то, что стоит один раз руками прогнать на тестовом сервере, чтобы концепции улеглись в голове:

# 1. создаём пул на диске /dev/sdb
zpool create tank /dev/sdb

# 2. проверяем, что пул жив
zpool status

# 3. создаём датасет внутри пула
zfs create tank/data

# 4. кладём туда что-нибудь, для примера
echo "версия 1" > /tank/data/file.txt

# 5. делаем снапшот текущего состояния
zfs snapshot tank/data@v1

# 6. меняем файл — как будто накатили обновление
echo "версия 2, всё сломалось" > /tank/data/file.txt
cat /tank/data/file.txt

# 7. откатываемся к снапшоту
zfs rollback tank/data@v1

# 8. проверяем — файл вернулся к версии 1
cat /tank/data/file.txt

После шага 8 в файле снова будет «версия 1» — откат отработал мгновенно, без остановки датасета и без копирования гигабайтов данных туда-обратно. Именно эта связка — пул как физический уровень, датасет как логический раздел с собственными настройками, снапшот как бесплатная (по времени создания) точка отката — и есть тот минимум ZFS, с которым уже можно работать на реальном сервере: перед рискованным обновлением конфига, перед миграцией базы, перед экспериментом с новым пакетом.

Практические ограничения на старте

Несколько вещей, о которых честно стоит сказцать сразу, чтобы не набить на них шишки:

• Снапшот — не бэкап на другой физический носитель. Если умер весь пул (например, накрылся диск в конфигурации без избыточности), снапшоты умрут вместе с ним — они живут внутри того же пула. Снапшот защищает от «сам сломал», а не от отказа железа.
• Снапшоты постепенно съедают место. Если данные активно меняются, а старые снапшоты не удаляются, свободное место в пуле будет уменьшаться быстрее, чем кажется на первый взгляд — стоит время от времени смотреть zfs list -t snapshot и убирать то, что больше не нужно.
• zpool create без раздумий стирает данные на диске. Команда не спрашивает подтверждения так же настойчиво, как, скажем, mkfs — дважды проверьте, что указали правильное блочное устройство, прежде чем нажать Enter.
• Пул нельзя просто «уменьшить», убрав диск. В отличие от добавления диска в пул, удаление диска из уже созданного vdev в классической конфигурации не поддерживается — планируйте состав дисков заранее, а не «докупим потом уберём».

Что дальше — темы для отдельного изучения

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

• репликацией через zfs send / zfs receive — как переносить снапшоты между серверами для бэкапов и миграций, инкрементально и без остановки сервиса;
• сжатием (compression=lz4/zstd) — когда оно почти бесплатно по CPU и ощутимо экономит место, а когда не стоит того;
• дедупликацией — мощная функция, но с реальной ценой по оперативной памяти, которую часто недооценивают на старте;
• требованиями к памяти под ARC-кэш — ZFS активно использует RAM для кэширования, и это стоит учитывать при выборе конфигурации сервера, особенно на VPS с ограниченным объёмом памяти.

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

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

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