Снапшот фиксирует состояние блоков на том же массиве и возвращает данные к нужной точке за секунды. Резервная копия лежит на отдельном носителе и остаётся доступной, если пул, контроллер, стойка или вся площадка потеряны. Механизмы решают разные задачи: снапшот ускоряет откат, копия спасает от катастрофы.
Дальше разберём, чем снапшот отличается от резервной копии, почему снапшоты не спасают при потере массива, как настроить политики на ZFS и TrueNAS, посчитать частоту и глубину хранения под RPO и RTO и собрать чек-лист ошибок, из-за которых восстановление срывается в самый неподходящий момент.
Снапшот и резервная копия: в чём разница и почему это важно
Снапшот - зафиксированный набор метаданных о блоках данных на конкретный момент времени. Сами данные физически не копируются: файловая система запоминает, какие блоки принадлежали файлам, и держит их неизменными, пока снапшот существует. Резервная копия - независимый набор данных на другом носителе, который читается и восстанавливается даже после полной гибели исходного массива.
Ключевое отличие в точке отказа. Снапшот живёт внутри того же пула, тома или LUN, что и рабочие данные. Потеря массива уничтожает данные и все снапшоты одновременно, потому что второго экземпляра не существует. Резервная копия находится вне этой точки отказа: другой сервер, ленточная библиотека, облачный бакет, offline-диск в сейфе.
Второе отличие в назначении. Снапшот отвечает на вопрос «как быстро вернуть файл, который удалили или испортили час назад». Копия отвечает на вопрос «как поднять сервис, если массива больше нет». Смешение этих задач даёт ложное чувство защищённости: администратор видит десятки снапшотов, считает данные защищёнными и узнаёт о проблеме только в момент аварии.
Как работают снапшоты на уровне файловой системы
ZFS и btrfs используют механизм Copy-on-Write. Когда приложение меняет блок, новые данные записываются в свободное место, а старый блок остаётся на диске и продолжает принадлежать снапшоту. Метаданные перестраиваются так, чтобы текущая версия файла указывала на новые блоки, а снапшот - на прежние. Никакого копирования терабайтов при создании снапшота не происходит: операция занимает миллисекунды и не зависит от объёма данных.
Место снапшот начинает занимать только тогда, когда блоки, на которые он ссылается, изменяются или удаляются в рабочем наборе. Удаление самого снапшота освобождает все блоки, на которые больше никто не ссылается. Отсюда практическое правило: снапшоты не «съедают» место заранее, но при интенсивной записи пул заполняется быстро, и ZFS начинает отказывать в новых операциях.
Проверить состояние просто. Команда zfs list -t snapshot -o name,used показывает, сколько занимает каждый снапшот, а zfs list -o space,name -t filesystem добавляет колонки usedbysnapshots и usedbydataset. Создание вручную: zfs snapshot tank/data@2026-09-13-1200. В TrueNAS снапшот делается через Datasets, затем Snapshots и кнопку Add, либо автоматически задачей Periodic Snapshot Tasks.
NetApp ONTAP работает по схеме Redirect-on-Write поверх файловой системы WAFL: новые данные пишутся в новые блоки, а прежние остаются зафиксированными для снапшота. Производительность записи почти не страдает, зато растёт фрагментация и потребление места под снапшоты. Политика снапшотов в ONTAP задаётся парой «расписание плюс количество копий»: например, 12 ежечасных, 7 ежедневных, 4 еженедельных.
Любой механизм снапшотов решает одну задачу: быстрый откат к точке во времени внутри той же системы хранения. Защита от отказа пула в него не входит по конструкции.
Почему снапшоты не заменяют резервное копирование
Список ситуаций, где снапшоты бесполезны, закрывает почти весь перечень реальных аварий. Физический отказ дисков сверх уровня избыточности: в RAID-Z2 потеря третьего диска делает пул недоступным вместе со всеми снапшотами. Выход из строя контроллера, backplane, блока питания или всей полки расширения. Логическое повреждение: разрушение метаданных ZFS, повреждение таблицы разделов, сбой при обновлении прошивки. Шифровальщик, который получает доступ к хосту с примонтированным пулом, удаляет снапшоты и шифрует данные. Ошибочное действие администратора: zfs destroy по пулу, mkfs по не тому устройству, неверный параметр в скрипте. Пожар, затопление, кража оборудования.
Во всех этих сценариях данные и снапшоты исчезают одним событием, потому что лежат на одном носителе. Вот почему снапшоты не заменяют бэкап: у них нет независимой физической копии.
Риски потери массива: когда снапшоты не спасут
Оценить бюджет на внешние копии помогает простая таблица отказов. Она же снимает основной спор с руководством: RAID защищает от отказа диска, а не от потери массива.
| Механизм | Где хранятся данные | От чего защищает | От чего не защищает |
|---|---|---|---|
| RAID / RAID-Z | Диски внутри одного массива | Отказа одного или двух дисков | Отказа массива, контроллера, шифровальщика, ошибок админа |
| Снапшот | Тот же пул или том | Ошибочного изменения и удаления файлов, неудачного обновления | Отказа массива, ransomware с удалением снапшотов, потери площадки |
| Реплика | Второй массив, обычно в той же сети | Отказа основного массива | Синхронного шифрования обоих массивов, мгновенно реплицируемых ошибок админа |
| Резервная копия | Отдельный носитель, offline или immutable | Потери массива, ransomware, ошибок админа, катастрофы на площадке | Ничего из перечисленного не покрывает только неверно составленный набор данных |
Отказ оборудования и логические повреждения
Отказ дисков сверх избыточности - самый частый сценарий потери пула. Практика показывает, что второй диск в RAID-Z1 выходит из строя во время ребилда заметно чаще, чем в обычном режиме: массив часами читает все оставшиеся диски на полной скорости. Для пулов от 6 дисков разумный минимум избыточности - RAID-Z2, для холодных архивов с медленным восстановлением - RAID-Z3.
Контроллер и backplane отказывают реже дисков, зато забирают с собой весь пул сразу. Если контроллер пишет повреждённые метаданные, ZFS может уйти в состояние, когда часть блоков не читается. Снапшоты здесь не помогают: они ссылаются на те же физические блоки. Ошибки в метаданных ZFS, сбои при обновлении пула (zpool upgrade), обрыв питания во время записи метаданных дают логические повреждения, которые лечатся только восстановлением из независимой копии.
Ransomware и человеческий фактор
Современные шифровальщики первым делом ищут и удаляют теневые копии и снапшоты. Если хост с Windows или Linux имеет примонтированный сетевой том с СХД, вредоносный процесс получает те же права, что и пользователь: он выполняет удаление снапшотов через API хранилища или через проброс команд на сам массив, а затем шифрует данные. Снапшоты, которые не защищены holds, удаляются одной командой.
Защита от такого сценария строится на трёх вещах. Первая - holds на снапшотах: команда zfs hold keep tank/data@replica-weekly запрещает удаление, пока hold не снят через zfs release. Вторая - отдельные учётные данные для задач бэкапа, у которых нет прав на удаление копий (в S3 это Object Lock в режиме compliance). Третья - offline или air gap копия: лента, вынутая из библиотеки, или диск, физически отключённый от сети после записи.
Человеческий фактор даёт не меньше инцидентов, чем вредоносное ПО. Типовые случаи: удаление тома вместо снапшота, запуск скрипта инициализации не на том устройстве, восстановление поверх рабочего набора данных, удаление каталога с копиями ради освобождения места. Снапшот спасает при случайном изменении или удалении отдельных файлов, но не при удалении всего пула или тома.
Репликация тоже не универсальное решение. При синхронной репликации шифровальщик, работающий на основном массиве, шифрует данные, и они уходят на второй массив в том же виде. При асинхронной остаётся окно в несколько минут или часов, за которое повреждение успевает реплицироваться. Реплика ускоряет восстановление сервиса после отказа оборудования, но не заменяет копию на изолированном носителе.
Как настроить снапшоты на СХД: практические рекомендации
Рабочая политика снапшотов строится от двух чисел: RPO (сколько данных допустимо потерять) и RTO (за сколько нужно поднять сервис). Если RPO равен часу, снапшоты каждые 30 минут дают запас и не создают избыточной нагрузки. Если данные меняются редко, ежечасных снапшотов достаточно.
Политики снапшотов: частота и глубина хранения
Частота определяется скоростью изменения данных и допустимой потерей. Глубина определяется тем, как далеко в прошлое администратору нужно заглянуть при разборе инцидента, и сколько места пул может отдать под снапшоты.
| Тип снапшота | Частота | Типичная глубина | Для чего нужен |
|---|---|---|---|
| Частые | Каждые 15 минут | 4-8 часов | Базы данных, виртуальные машины с высокой скоростью записи |
| Часовые | Каждый час | 24-48 часов | Файловые серверы, рабочие каталоги |
| Ежедневные | Раз в сутки ночью | 30 дней | Разбор ошибок недельной давности |
| Еженедельные | Раз в неделю | 12 недель | Отчётные периоды, медленные изменения конфигураций |
| Ежемесячные | 1-е число месяца | 12 месяцев | Архивные точки, требования аудита |
Расчёт места делается по скорости изменения. Набор данных 1 ТБ с изменением 5% в час даёт около 50 ГБ новых блоков ежечасно. Двадцать четыре часовых снапшота удержат примерно 1,2 ТБ, то есть больше самого набора данных. Если тот же набор защищён ежедневными снапшотами с изменением 20% в сутки, тридцать копий займут около 6 ТБ. Цифры стоит проверять на своём профиле нагрузки: zfs get -o property,value written и наблюдение за usedbysnapshots в течение недели дают реальную картину.
В TrueNAS политики задаются в разделе Data Protection, затем Periodic Snapshot Tasks. Доступны рекурсивные снапшоты для наборов с дочерними датасетами, расписание в стиле cron и настройка хранения: например, «оставлять 24 часовых, 30 ежедневных, 12 еженедельных». NetApp ONTAP использует объекты snapshot policy с расписанием и счётчиком копий, а также SnapMirror и SnapVault для переноса и долгого хранения. Подробный разбор сравнения ZFS, btrfs и инструментов уровня приложений есть в материале о снапшотах и качестве хранения данных.
Отдельно стоит продумать влияние на производительность. Массовое удаление старых снапшотов на ZFS создаёт всплеск нагрузки на диски, потому что освобождаются миллионы блоков. Такие операции планируют на ночные окна. Рекурсивный снапшот по 200 датасетам тоже создаёт поток метаданных, который чувствуется на слабых контроллерах.
Репликация снапшотов на другой массив
ZFS умеет передавать снапшоты потоком: zfs send отправляет блоки в stdout, zfs receive применяет их на втором пуле. Инкрементная передача делается флагом -i с указанием промежуточного снапшота, что переносит только изменившиеся блоки. Схема tank/data@snap1 и tank/data@snap2 превращается в поток, который принимающая сторона применяет поверх предыдущего состояния.
В TrueNAS периодическая репликация настраивается через Data Protection, затем Replication Tasks: выбирается источник, приёмник, расписание и способ шифрования канала. В ONTAP аналогичную роль выполняет SnapMirror: он переносит снапшоты и позволяет быстро активировать вторичный том.
Репликация бывает синхронной и асинхронной. Синхронная гарантирует нулевой RPO, но при шифровании данных на основном массиве повреждение мгновенно уходит на второй. Асинхронная даёт окно, за которое часть повреждений можно остановить, но теряет данные за последний интервал. Если реплика живёт в той же инфраструктуре с теми же учётными данными, шифровальщик доберётся и до неё. Реплика повышает отказоустойчивость, а не защищает от логических атак и ошибок администратора.
Стратегия резервного копирования: от снапшотов к внешним копиям
Рабочая схема распределяет роли между механизмами. Снапшоты дают быстрый откат на минуты и часы. Репликация закрывает отказ основного массива. Резервная копия на внешнем носителе защищает от всего остального, включая потерю площадки и сознательное удаление копий.
Формальное правило 3-2-1: три копии данных, два разных типа носителей, одна копия вне основной площадки. В 2026 году к нему добавляют два требования: одна копия должна быть offline или immutable, и восстановление должно быть проверено (ноль ошибок). Отсюда вариант 3-2-1-1-0. Практическая реализация этой схемы на ZFS, rsync, restic и borg с готовыми расписаниями и retention policy разобрана в статье про стратегии 3-2-1 и 3-2-1-1-0.
Выгрузка копий на внешние носители и в облако
Способы выгрузки делятся на три группы по типу приёмника. Файловые: rsync на удалённый сервер или NAS, работает поверх любого монтирования, поддерживает инкременты и жёсткие ссылки через --link-dest для экономии места. Блочные: zfs send в файл или в поток на другой пул, переносит снапшоты со всей структурой датасетов и свойствами. Объектные: restic и borgbackup в S3-совместимое хранилище, дают шифрование на клиенте, дедупликацию и версионирование без доверия к провайдеру.
В TrueNAS выгрузка настраивается через Data Protection, затем Rsync Tasks и Cloud Sync Tasks. Для облака важны две вещи: шифрование на стороне клиента до отправки и включённая неизменяемость объектов. Без Object Lock шифровальщик с ключами из локальной системы удалит и облачные копии.
Облако подходит не для всех объёмов. Холодный архив на 50 ТБ дешевле держать на ленте или на внешних дисках, а вот оперативные копии небольших наборов и конфигураций удобно отправлять в S3-совместимое хранилище: скорость восстановления выше, чем с ленты, а стоимость предсказуема. Для небольших инфраструктур подходит размещение копий на арендованном сервере или в объектном хранилище: например, Timeweb Cloud даёт облачные серверы и хранилище, куда можно выгружать инкременты и держать отдельный стенд для проверки восстановления.
Выбор между rsync, ZFS send/recv, Restic и BorgBackup зависит от того, нужна ли версионность на уровне файлов, поддерживается ли нативная дедупликация и насколько критично шифрование на клиенте. Разбор сильных и слабых сторон этих связок с примерами скриптов есть в руководстве по практическим связкам rsync, ZFS, Restic и BorgBackup.
Целостность копий проверяется сразу после записи. Для restic это restic check, а раз в квартал - restic check --read-data-subset=10% с чтением части данных с носителя. Для borg аналог - borg check с флагом --verify-data. Для ZFS-потоков проверка сводится к попытке приёма в тестовый пул: если поток читается и применяется без ошибок, копия рабочая.
Расчёт частоты и глубины хранения для бэкапов
RPO задаёт частоту копий, RTO задаёт требования к скорости восстановления и, косвенно, к типу носителя. При RPO в один час нужны ежечасные инкрементальные копии, а полные копии могут создаваться раз в сутки или раз в неделю. При RTO в четыре часа восстановление не может идти с ленты со скоростью 100 МБ/с, если данных десятки терабайт: понадобится дисковый или облачный приёмник.
Типовая схема для большинства инфраструктур выглядит так: ежечасные инкременты с хранением 24-48 часов, ежедневные копии с хранением 30 дней, еженедельные с хранением 6 месяцев, ежемесячные с хранением 12 месяцев. Глубина определяется требованиями отрасли и внутренними регламентами: финансовые и медицинские данные держат дольше.
Дедупликация и сжатие меняют расчёт места в разы. restic и borg на наборе из виртуальных машин с общими системными образами легко дают экономию в 5-10 раз, потому что одинаковые блоки хранятся один раз. ZFS-потоки сжимаются по-разному в зависимости от типа данных: текстовые логи и конфигурации сжимаются хорошо, уже сжатые архивы и медиафайлы почти не дают выигрыша. Окно бэкапа планируют так, чтобы полная копия не пересекалась с пиковой нагрузкой: полный бэкап раз в неделю в выходные, инкременты в рабочие часы.
Типичные ошибки при настройке резервного копирования и как их избежать
Бэкап существует формально, но восстановить из него нечего: так выглядит большинство разборов аварий. Ниже список ошибок, которые встречаются чаще всего, и способ проверки для каждой.
- Копия лежит на том же массиве или на том же LUN, что и рабочие данные. Проверка: обойти конфигурацию заданий и убедиться, что путь приёмника не совпадает с источником ни на уровне пула, ни на уровне физических дисков.
- Снапшоты считаются бэкапом. Проверка: ответить на вопрос, что произойдёт при потере пула целиком.
- Исключения в политике бэкапа вычистили нужные каталоги. Проверка: сравнить список исключений с перечнем критичных данных и восстановить один файл из каждого крупного каталога.
- Восстановление никогда не тестировалось. Проверка: раз в квартал восстанавливать случайный набор данных на отдельный стенд и замерять время.
- Ключи шифрования или пароли хранятся рядом с копиями. Проверка: убедиться, что без доступа к продакшену копия не расшифровывается, и что ключ есть у дежурного сотрудника.
- Задания падают молча, потому что код возврата cron никто не проверяет. Проверка: алерт на отсутствие свежей копии, а не только на ненулевой код.
- Одна учётная запись используется и для продакшена, и для бэкапа. Проверка: у задачи бэкапа нет прав на удаление копий в хранилище.
- Нет документации: неизвестно, что, когда и куда копируется. Проверка: новый дежурный по документу восстанавливает сервис без подсказок коллег.
Непроверенные бэкапы и отсутствие тестового восстановления
Копия считается рабочей только после успешного восстановления. Типовой сценарий из практики: архивы исправно создавались годами, а при аварии выяснилось, что часть архивов повреждена из-за ошибки на диске приёмника, а часть содержит не те данные. Обнаружить это заранее можно только тестами.
Порядок проверки: выбрать один случайный набор данных или том, восстановить его на отдельный стенд, сравнить контрольные суммы критичных файлов, замерить время восстановления и сравнить с заявленным RTO. Для наборов, которые не помещаются полностью, восстанавливают подмножество: например, одну виртуальную машину или одну базу. Проверки автоматизируют: скрипт разворачивает копию в изолированной сети, прогоняет проверки и отправляет отчёт.
Отдельно проверяют восстановление после потери массива целиком, а не отдельного файла. Это разные процедуры: в первом случае нужен план развёртывания нового пула, установки системы и порядка применения инкрементов, во втором достаточно достать файл из снапшота.
Мониторинг и документирование стратегии
Мониторинг закрывает главный риск: незаметный отказ задания. В Zabbix контролируются статус заданий, свободное место на приёмнике и возраст последней копии. Прометеевский стек получает метрики через node_exporter с коллектором zfs, а также через экспортёры систем резервного копирования. Триггеры строятся на понятных числах: если последний снапшот старше двух часов, если свободное место на пуле ниже 20%, если задание завершилось ошибкой, если размер инкремента вырос в пять раз (возможный признак шифрования).
Полезны проверки состояния пула: zpool status с контролем статуса DEGRADED и наличием ошибок чтения и записи, zfs list -t snapshot -o name,creation с проверкой свежести. TrueNAS показывает состояние заданий и снапшотов в веб-интерфейсе, но полагаться только на ручной просмотр не стоит: нужен внешний алерт, который сработает, даже если сам интерфейс недоступен.
Документация включает схему потоков данных, расписание, сроки хранения, ответственных, порядок действий при восстановлении и результаты последних проверок. Без неё передача дел превращается в археологию, а аудит показывает дырки в процедурах. Хороший минимум: одна страница со схемой, одна таблица с расписанием и ретенцией, один раздел с пошаговой процедурой восстановления и датой последнего теста.
Восстановление данных из снапшотов и бэкапов: пошаговые сценарии
Скорость восстановления зависит от того, насколько заранее продуман сценарий. Ниже рабочие процедуры для ZFS и TrueNAS, которые закрывают большинство инцидентов.
Восстановление из снапшота: rollback и клонирование
Rollback возвращает набор данных к состоянию снапшота и уничтожает все изменения после него, включая промежуточные снапшоты. Команда zfs rollback tank/data@snap применима, когда нужно вернуть весь том целиком. Требование: на наборе не должно быть открытых файлов и активных процессов, иначе ядро откажет в операции. Поэтому том сначала отмонтируют или останавливают сервис.
Безопаснее клонирование. Команда zfs clone tank/data@snap tank/data_restore создаёт новый набор данных, который сначала делит блоки со снапшотом, а затем расходится с ним. Рабочий том продолжает жить, клон монтируется в отдельную точку, и нужные файлы просто копируются оттуда. В TrueNAS клон делается через Datasets, затем Snapshots, выбор снапшота и команду Clone to New Dataset. Дальше новый датасет монтируется, файлы копируются, после чего клон удаляется. Такой путь занимает минуты и не требует простоя.
Для защиты от случайного удаления снапшотов используют holds. Команда zfs hold keep tank/data@weekly-monthly не даст удалить снапшот, пока hold активен, а снять его можно через zfs release. Это простая мера, которая останавливает часть сценариев шифровальщика и скриптов очистки.
Полезно помнить про время: у ZFS снапшоты монтируются в скрытый каталог .zfs/snapshot внутри самого датасета. Скопировать файл из снапшота можно обычным cp из этого каталога, без клонирования и отката. Для отдельного файла это самый быстрый путь.
Восстановление из резервной копии
Полное восстановление разбивается на этапы. Сначала выбирается подходящая точка восстановления с учётом RPO и характера сбоя: если проблема в логической порче данных, последняя копия может содержать ту же порчу, и нужна более ранняя. Затем готовится целевое хранилище, на котором должно быть достаточно места и правильные права. После восстановления данные проверяются, сервисы включаются, и только потом исходная копия помечается как использованная.
Для ZFS-потока процедура выглядит так: создаётся новый пул, применяется последний полный поток, затем последовательно накатываются инкременты вплоть до выбранной точки. Для файловой копии rsync данные синхронизируются обратно с флагом --delete только после того, как проверено содержимое, иначе ошибка в источнике уничтожит остатки. Для restic выполняется restic restore с указанием снапшота и целевого каталога, после чего проверяется целостность восстановленных данных.
RTO измеряют по факту: с момента аварии до момента, когда сервис отвечает на запросы. Практическое руководство с расчётом реального RTO и схемами для разных типов данных собрано в статье про схемы резервного копирования и проверку восстановления.
Минимизировать простой помогает подготовленная инфраструктура: заранее созданный пул, известные права, тестовый стенд и понятный порядок запуска сервисов. Если восстановление идёт с облака или удалённого сервера, заранее считают пропускную способность канала: 10 ТБ при 200 Мбит/с займут больше двух суток, что для многих сервисов означает выход за пределы RTO.
Начните с одного действия: проверьте, что последняя копия лежит вне массива с рабочими данными, и восстановите из неё один произвольный каталог на отдельный стенд. Этот тест показывает больше о реальной защите данных, чем любая схема на бумаге.