TrueNAS ZFS snapshots: как настроить снимки и расписание

Что именно сохраняет ZFS snapshot

Снимок фиксирует ссылки на блоки dataset в конкретный момент времени и остаётся только для чтения. Сразу после создания он почти не требует дополнительного места, потому что не копирует весь набор данных. Когда активный dataset изменяется, старые блоки нельзя освободить, пока на них ссылается хотя бы один snapshot; именно поэтому занятие места растёт по мере изменений. Это важная деталь для медиатеки с редкими правками и для VM/базы данных с интенсивной записью: одинаковая частота снимков даёт совершенно разный расход. TrueNAS позволяет делать снимки отдельного dataset, zvol и при необходимости дочерних datasets рекурсивно.

Важно: Snapshot — это не второй экземпляр данных. Он защищает от логических ошибок, но не от потери всего пула.

Как создать первый ручной snapshot

1. Откройте Datasets и выберите dataset, состояние которого хотите зафиксировать.
2. В блоке Data Protection нажмите Create Snapshot или перейдите к списку snapshots через раздел Data Protection.
3. Выберите dataset/zvol и задайте понятное имя. Если снимок должен участвовать в существующей репликации, используйте совместимую naming schema.
4. Включайте Recursive только если осознанно хотите захватить дочерние datasets; рекурсивный снимок увеличивает область управления и последующего удаления.
5. Сохраните snapshot и убедитесь, что он появился в списке. Для теста восстановите один безопасный файл через clone/copy, а не делайте rollback рабочего dataset.

Совет: Первую проверку восстановления делайте на некритичном файле или клоне. Наличие snapshot в списке ещё не доказывает, что ваша процедура восстановления понятна и отработана.

Периодические снимки: частота и срок хранения

Для домашнего файлового сервера разумнее связать частоту с ценой потери данных. Рабочие документы можно снимать каждые 15–60 минут и хранить частые точки несколько дней, фотоархив — реже, но дольше, а каталог загрузок часто вообще не нуждается в длинной истории. В Periodic Snapshot Tasks задайте dataset, расписание и lifetime, после чего TrueNAS будет создавать и очищать снимки автоматически. Не выбирайте максимально частое расписание «на всякий случай»: большое число снимков усложняет обзор и может удерживать много изменённых блоков. Полезная схема — много коротких точек восстановления плюс более редкие дневные/недельные копии.

Пример политики для домашнего сервера

• [object Object]
• [object Object]
• [object Object]
• [object Object]
• [object Object]

Предупреждение: Для баз данных и виртуальных машин файловый snapshot не гарантирует консистентность приложения. Если нужна транзакционная точка, используйте механизм приложения/гипервизора или согласованный quiesce.

Rollback, clone и восстановление файла — не одно и то же

Rollback возвращает весь dataset к состоянию снимка и может отбросить более новые изменения, поэтому это самый рискованный вариант для живого хранилища. Clone создаёт записываемый dataset на основе snapshot и удобен для проверки состояния без уничтожения текущих данных. Для отдельного удалённого файла лучше извлечь нужную версию из snapshot или клона и скопировать обратно. Перед rollback обязательно перечислите, какие изменения после снимка будут потеряны, и сделайте актуальную копию того, что ещё нужно. Такая осторожность особенно важна, если snapshot охватывает множество дочерних datasets рекурсивно.

Как контролировать занимаемое место

В ZFS место освобождается только тогда, когда ни активный dataset, ни snapshot больше не ссылаются на блок. Поэтому удаление большого файла может почти не увеличить свободное пространство, если этот файл присутствует в старых снимках. Смотрите Used/Referenced у snapshots и динамику пула, а не только количество объектов. Если пул приближается к критическому заполнению, сначала выясните, какие снимки удерживают больше всего блоков, и удаляйте по политике retention, а не хаотично самый новый. Слишком заполненный пул ухудшает эксплуатацию, поэтому срок хранения должен соответствовать фактической скорости изменений.

Репликация превращает снимки в защиту от отказа пула

Сам по себе локальный snapshot разделяет судьбу исходного пула. Если важные снимки реплицируются на другой TrueNAS, другой ZFS-пул или физически отдельную систему, вы получаете уже другой уровень защиты: можно пережить отказ исходного сервера и восстановить состояние до последней репликации. Расписание snapshot и replication должно быть согласовано, иначе слишком короткий retention может удалить нужную точку раньше копирования. Для off-site копии учитывайте пропускную способность сети и объём ежедневных изменений. Проверяйте не только успешный статус задачи, но и фактическое наличие последних снимков на стороне приёмника.

Как выбрать retention без накопления лишних снимков

Срок хранения стоит выбирать по тому, как быстро меняется dataset и насколько далеко назад реально приходится возвращаться. Snapshot почти ничего не добавляет в момент создания, но по мере изменений удерживает старые блоки, поэтому одинаковое расписание по-разному влияет на медиатеку, рабочие документы и активно меняющийся zvol. Сначала задайте короткую понятную политику, затем несколько дней наблюдайте за числом снимков и занимаемым ими пространством. Если история не используется, сокращайте срок хранения, а не отключайте snapshots полностью. Для действительно ценных данных сочетайте локальные точки восстановления с репликацией или отдельной резервной копией на другом носителе.

Минимальная схема, которую стоит считать рабочей

• Periodic Snapshot Task создан для каждого важного dataset с подходящей частотой.
• Retention ограничен и соответствует доступной ёмкости.
• Есть отдельная репликация или backup вне того же пула для критичных данных.
• Процедура восстановления отдельного файла проверена на практике.
• Rollback не используется как первая кнопка при любой ошибке.
• Уведомления TrueNAS о состоянии пула и задач не игнорируются.

Что учитывать

Условия меняются. Страница отражает состояние на 2026-09-21; при расхождении с официальной документацией приоритет у первоисточника.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Creating Snapshots). Пример и формулировки — редакция N1RO на 2026-09-21.

• Creating Snapshots