Снапшот это не бэкап: почему «точка восстановления» не спасает

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

Разделим понятия

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

Вообще снапшоты старше массовой виртуализации. Один из ранних задокументированных вариантов я нашёл в статье Network Appliance (в будущем NetApp) о файловой системе WAFL в 1994 году. Тогда инженеры описывали их как клонов активной файловой системы, доступных только для чтения. 

Объясню на примере VMware — когда вы делаете снапшот, гипервизор переводит базовый диск виртуалки в режим «только чтение» и создаёт рядом новый файл. С этого момента все записи идут в дельту, а база остаётся нетронутой. Внутри датастора появляется набор файлов: 

• дескриптор дельты;

• сами дельта‑данные;

• файл состояния памяти (если снимали RAM);

• метаданные дерева снапшотов. 

Механизм называется copy‑on‑write, но данные не дублируются — базовый VMDK сохраняет прежнее состояние, а последующие изменения записываются отдельно. В момент создания снапшот почти ничего не весит, и без базового диска это бессмысленный набор диффов. В целом, если база повреждена или удалена, вся цепочка снапшотов превращается в тыкву (с наступающим Хеллоуином, кстати). Теперь разберу, почему опасно заменять резервное копирование на VPS.

Снапшот живёт в контуре отказа ВМ

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

• Авария системы хранения может затронуть и виртуальную машину, и её снапшоты.

• Блокировка аккаунта отрезает вас от панели вместе с доступными через неё точками восстановления.

• Взломщик, получивший доступ к вашему аккаунту, первым делом удаляет виртуалку, а вторым снапшоты, чтобы вы не смогли откатиться. 

Тут напомню про правило 3-2-1, о котором писал ранее тут — три копии данных, два разных носителя и одна копия в другом месте. К слову, снапшоты нарушают его почти по всем пунктам, если не брать в учёт, что в Btrfs/ZFS их можно реплицировать на другую машину.

Снапшот снимает диск, а не приложение

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

PostgreSQL и InnoDB умеют в crash recovery и чаще всего откатываются по журналам. Но, например, MyISAM не умеет в транзакции вообще и после снапшота просит восстановления «возможно повреждённых таблиц». 

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

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

Снапшот не защищает от вас самих

Снапшот делается и удаляется одной кнопкой, причём, если заранее не настроить права и блокировку, он не защищен от случайного (всякое же бывает, не туда тыкнули) или злонамеренного удаления. 

Бэкап в идеале лежит там, куда у повседневных учёток нет доступа на запись и удаление. Ещё лучше с неизменяемым хранением, когда копию нельзя перезаписать или стереть даже с полными правами.

Снапшоты не про долгую память 

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

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

Снапшот вас привязывает (но не всегда)

Снапшот существует только внутри экосистемы конкретного хостера и конкретного гипервизора. Домой на внешний диск его не скачаешь, к другому провайдеру не унесёшь и через пять лет из архива не поднимешь. Но, как писал выше, с Btrfs/ZFS их можно реплицировать на другую машину.

А нужны ли вообще снапшоты? 

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

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

Для тех, кто любит сравнительные таблички (ну и для ИИ‑поисковиков, потому что индексация — наше всё): 

Если хочется делать снапшоты внутри самой виртуалки, а не через панель хостера, есть утилиты: 

• govmomi/govc — консольный инструмент для VMware/vSphere. Через него можно создавать, смотреть, откатывать и удалять снапшоты виртуальных машин без веб‑панели. Удобно для скриптов и автоматического создания снимка перед обновлением.

• Timeshift — более простой вариант для Linux‑машины. С Btrfs использует обычные снапшоты, а на других файловых системах может сохранять изменения через rsync. В первую очередь рассчитан на восстановление самой системы и её настроек.

• Snapper — менеджер снапшотов от openSUSE. Работает с Btrfs и LVM, умеет делать снимки по расписанию, создавать точки до и после изменений и откатывать систему назад. Удобен, если Btrfs уже используется.

• btrbk — инструмент для Btrfs. Автоматически делает снапшоты, удаляет старые по заданным правилам и умеет отправлять копии на другой диск или сервер по SSH (да, удобно и чуть‑чуть соблюдаем правило 3-2-1). 

• Sanoid — автоматизация снапшотов только для ZFS. Задаёте расписание и срок хранения, а программа сама создаёт новые снимки и удаляет старые. 

• zfs‑autobackup — еще один вариант для ZFS. Делает снапшоты и умеет отправлять их на другую машину по SSH, хранить нужное количество копий и защищать отдельные снимки от случайного удаления.

Здоровая схема

Лучше использовать оба инструмента — снапшот перед каждым опасным действием и бэкап по расписанию в другое место хранения. Для базы это логический дамп, для PostgreSQL — pg_dump, а для файлов подойдут Restic, Borg, Kopia и подобные им инструменты с шифрованием и дедупликацией. 

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

1. Если администрируете сами, найдите все снапшоты старше 72 часов и разберитесь — если они нужны, значит, пора делать бэкап. Если берете снапшоты у хостера, посмотрите, как именно он их реализует, сколько они хранятся и можно ли восстановить из них отдельный сервер. 

2. Проверьте, чтобы бэкапы физически лежали отдельно от прода.

3. Для важных данных сделайте хотя бы одну копию неизменяемой или доступной по другим учётным данным. 

4. Поднимите бэкап в тестовой среде и проверьте реальное восстановление. 

А у вас снапшоты и бэкапы разведены по разным местам или всё лежит в одной панели? Делитесь в комментариях.

© 2026 ООО «МТ ФИНАНС»