Миф: снапшот виртуалки заменяет бэкап

MAATRIX

«У нас в Proxmox каждую ночь снимается снапшот по всем виртуалкам — бэкап настроен» — фраза звучит спокойно и по-хозяйски, а описывает при этом не бэкап, а совсем другой инструмент с другими гарантиями. Снапшот и полноценная резервная копия отвечают на разные вопросы: один — «как быстро откатить неудачное изменение», другой — «как пережить потерю всего хранилища целиком». Путать их удобно, потому что оба слова звучат как «у меня есть копия данных» — но в момент реального отказа диска или хоста разница между ними становится не терминологической, а буквально вопросом того, восстановитесь вы или нет.

Откуда берётся эта уверенность

Миф растёт из настоящего положительного опыта. Снапшот перед рискованным обновлением делают почти все, кто держит виртуалки: virsh snapshot-create-as или кнопка «Snapshot» в Proxmox отрабатывает за секунду, обновление идёт не так — откатываетесь одной командой, сервис поднимается в прежнем состоянии за минуты. Это работает, это проверено на практике десятки раз, и именно эта надёжность в узком сценарии откладывается в голове как «у меня есть рабочая система защиты данных».

Дальше происходит незаметное расширение вывода: человек, который несколько раз откатился снапшотом после неудачного апдейта пакета, начинает подсознательно считать, что то же самое спасёт его и при отказе диска, и при шифровальщике, и при случайном rm -rf в гостевой ОС. Проверить это предположение почти никогда не доводится — потому что диск в проде отказывает не каждую неделю, а снапшот перед обновлением делается регулярно и регулярно же «подтверждает» свою полезность. Ощущение защищённости накапливается быстрее, чем случаи, которые могли бы его опровергнуть.

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

Где физически лежит снапшот — и почему это не спасает от отказа хранилища

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

• LVM thin-снапшот живёт в том же thin-pool, на тех же физических дисках, что и боевой логический том.
• ZFS-снапшот — это набор указателей внутри того же пула (zpool), на тех же дисках.
• qcow2-снапшот (внутренний или в виде цепочки backing-файлов) лежит в том же каталоге, на той же файловой системе, физически на том же блочном устройстве.
• Снапшот в Proxmox — это надстройка над одним из перечисленных механизмов хранения, выбранным для конкретного датастора; сам снапшот никуда за пределы этого датастора не выходит.

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

• Диск (или несколько дисков RAID-массива) выходит из строя целиком — снапшот недоступен точно так же, как и боевой том, потому что технически они делят одни и те же блоки на нижнем уровне.
• Гипервизор-хост выходит из строя аппаратно (материнская плата, блок питания, контроллер) — недоступны все виртуалки на нём вместе со всеми их снапшотами разом.
• Шифровальщик или скомпрометированный процесс получает доступ на уровне гостевой ОС или самого гипервизора и шифрует датастор — под шифрование попадают и активные диски, и файлы снапшотов, если они физически достижимы с той же машины.
• Случайное удаление датастора или ошибка администратора на уровне управления хранилищем стирает всё, что на нём лежит, включая снапшоты.

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

Copy-on-write: почему снапшоты не рассчитаны на долгое хранение

Даже если забыть про физическое совпадение хранилища, у снапшотов есть вторая причина, по которой их нельзя растягивать в долгосрочный архив: механизм copy-on-write, на котором почти все они построены.

Снапшот в момент создания почти ничего не весит — он не копирует диск, а фиксирует точку отсчёта. Дальше каждая запись в уже зафиксированный блок требует прочитать старые данные, скопировать их в новое место и только потом применить изменение — это и есть copy-on-write, и это не бесплатная операция. Чем дольше живёт снапшот и чем активнее меняются данные под ним, тем больше накапливается таких скопированных блоков, тем сильнее растёт занятое место и тем ощутимее становится нагрузка на дисковую подсистему при каждой записи. Механику по шагам и с примерами команд virsh blockcommit разбирали в статье copy-on-write в qcow2: почему снапшот сначала бесплатный, а потом тормозит.

Практический вывод из этого простой: снапшот, оставленный «на всякий случай» на недели или месяцы, — это не бесплатная страховка, а растущая техническая задолженность. Он держит хранилище, тормозит запись, а если снапшотов накопилось несколько подряд — ещё и чтение старых данных, потому что каждое обращение к ним проходит по всей цепочке. Полноценные бэкап-инструменты вроде restic, borgbackup или Proxmox Backup Server устроены принципиально иначе: они делают дедупликацию и компрессию на уровне архива, рассчитанного жить месяцами и годами, а не разрастающуюся дельту поверх боевого тома.

Точка во времени, а не история версий

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

На практике это означает: если у вас есть только один действующий снапшот (перезаписанный вчерашним при следующем запуске скрипта или удалённый вручную после отката), а проблема в данных обнаружилась не сразу — восстанавливать уже нечем, актуальный снапшот уже содержит ту же порчу, а предыдущего просто не существует. Похожий сценарий подробно разобран в постмортеме восстановление из снапшота откатило сервер на две недели назад — там ротация снапшотов держала только определённую глубину истории, и когда потребовалась точка старше этой глубины, оказалось, что её просто не сохранили.

Полноценные системы резервного копирования решают эту задачу иначе — версионированием с явной политикой хранения (retention): ежедневные копии за последние недели, еженедельные за пару месяцев, ежемесячные за год и так далее, при этом каждая версия — самостоятельная точка восстановления, а не звено единой цепочки CoW-дельт, зависимой от целостности всех предыдущих звеньев. Если у снапшота испорчена цепочка (например, повреждён backing-файл посередине), рушится доступ ко всем более старым точкам сразу — у независимо хранимых версий в бэкапе такой связанности нет.

Что снапшот действительно даёт — и это по-настоящему полезно

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

Типичный правильный сценарий:

# перед рискованным обновлением — снапшот
virsh snapshot-create-as myvm pre-update-2026-08 \
  --description "before apt upgrade + app migration"

# выполняем обновление, миграцию БД, смену конфигурации
# ...

# если что-то пошло не так — откат за секунды
virsh snapshot-revert myvm pre-update-2026-08

# если всё в порядке — снапшот больше не нужен, схлопываем
virsh blockcommit myvm vda --active --pivot --wait

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

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

Как выглядит правильная связка: снапшот плюс отдельный бэкап

На практике снапшот и бэкап не конкурируют, а закрывают разные оси риска и должны стоять рядом. Сравнение по ключевым параметрам:

Практическая схема для виртуалки на своём сервере: снапшот гипервизора остаётся инструментом на время рискованной операции, а параллельно, независимо от того, есть сейчас активный снапшот или нет, идёт настоящий бэкап на отдельное хранилище — вручную через vzdump в Proxmox с удалённым storage, через restic/borgbackup изнутри гостевой ОС, либо образом диска, скопированным на внешний сервер. Например, план бэкапа виртуалки целиком по расписанию через Proxmox Backup Server или аналог, плюс дамп базы данных внутри неё отдельным заданием — если нужно определиться, копировать образ целиком или файлы изнутри гостевой ОС, это отдельно разобрано в статье резервное копирование виртуалок: образ целиком или файлы внутри. А сама схема разделения копий во времени и в пространстве описана в разборе правила 3-2-1 для бэкапов — снапшот в этой схеме не заменяет ни одну из трёх копий, потому что физически он не отделён от оригинала ни во времени, ни в пространстве.

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

• снапшот — только на время активного изменения (обновление, миграция, эксперимент), с явным сроком удаления;
• настоящий бэкап — по расписанию, на отдельное хранилище, с проверенным восстановлением хотя бы раз в квартал;
• если снапшотов накопилось больше одного «долгоживущего» — это сигнал остановиться и разобраться, зачем они там висят;
• бэкап настраивается вне зависимости от того, есть снапшоты или нет — это два параллельных, а не последовательных процесса.

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