Снапшот это не бэкап: почему «точка восстановления» не спасает
О разнице снапшота и бэкапа начинающие сисадмины узнают в самый неподходящий момент. Например, когда аккаунт уже заблокирован или база уже не поднимается. Под катом разберу, почему опасно заменять резервное копирование на 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 часов. Длинные цепочки могут ухудшать производительность и раздувать расход хранилища, плюс для длительного хранения логичнее бэкапы.
До кучи, восстановление из снапшота — это операция над всем диском целиком. Если пользователь случайно удалил один каталог или одну таблицу, вам для восстановления придётся откатывать весь сервер, теряя всё, что изменилось с момента снимка, или разворачивать копию и ковырять нужное руками.
Снапшот вас привязывает
Снапшот существует только внутри экосистемы конкретного хостера и конкретного гипервизора. Домой на внешний диск его не скачаешь, к другому провайдеру не унесёшь и через пять лет из архива не поднимешь.
А нужны ли вообще снапшоты?
Нужны… Перед обновлением ядра, перед миграцией базы, перед экспериментом с «щас я вот это переключу», потому что откат занимает минуты. Сделал снимок, сломал, откатился, выдохнул, сделал снимок и пошёл ломать дальше.
Также на 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 и подобные им инструменты с шифрованием и дедупликацией.
Ну и чек как минимум раз в месяц. О том, как проверить, что бэкап можно восстановить, писал тут. По действиям:
Если администрируете сами, найдите все снапшоты старше 72 часов и разберитесь — если они нужны, значит, пора делать бэкап. Если берете снапшоты у хостера, посмотрите, как именно он их реализует, сколько они хранятся и можно ли восстановить из них отдельный сервер.
Проверьте, чтобы бэкапы физически лежали отдельно от прода.
Для важных данных сделайте хотя бы одну копию неизменяемой или доступной по другим учётным данным.
Поднимите бэкап в тестовой среде и проверьте реальное восстановление.
А у вас снапшоты и бэкапы разведены по разным местам или всё лежит в одной панели? Делитесь в комментариях.
© 2026 ООО «МТ ФИНАНС»
Mentions
Снапшот это не бэкап: почему «точка восстановления» не спасает О разнице снапшота и бэкапа начинающие сисадмины узнают в самый неподходящий момент. Например, когда аккаунт уже заблокирован или база уже не поднимается. Под катом разберу, почему опасно заменять резервное копирование на 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 часов. Длинные цепочки могут ухудшать производительность и раздувать расход хранилища, плюс для длительного хранения логичнее бэкапы. До кучи, восстановление из снапшота — это операция над всем диском целиком. Если пользователь случайно удалил один каталог или одну таблицу, вам для восстановления придётся откатывать весь сервер, теряя всё, что изменилось с момента снимка, или разворачивать копию и ковырять нужное руками. Снапшот вас привязывает Снапшот существует только внутри экосистемы конкретного хостера и конкретного гипервизора. Домой на внешний диск его не скачаешь, к другому провайдеру не унесёшь и через пять лет из архива не поднимешь. А нужны ли вообще снапшоты? Нужны… Перед обновлением ядра, перед миграцией базы, перед экспериментом с «щас я вот это переключу», потому что откат занимает минуты. Сделал снимок, сломал, откатился, выдохнул, сделал снимок и пошёл ломать дальше. Также на 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 и подобные им инструменты с шифрованием и дедупликацией. Ну и чек как минимум раз в месяц. О том, как проверить, что бэкап можно восстановить, писал тут. По действиям: Если администрируете сами, найдите все снапшоты старше 72 часов и разберитесь — если они нужны, значит, пора делать бэкап. Если берете снапшоты у хостера, посмотрите, как именно он их реализует, сколько они хранятся и можно ли восстановить из них отдельный сервер. Проверьте, чтобы бэкапы физически лежали отдельно от прода. Для важных данных сделайте хотя бы одну копию неизменяемой или доступной по другим учётным данным. Поднимите бэкап в тестовой среде и проверьте реальное восстановление. А у вас снапшоты и бэкапы разведены по разным местам или всё лежит в одной панели? Делитесь в комментариях. © 2026 ООО «МТ ФИНАНС»
VCF Readiness VCF Readiness - vmware/vcf-readiness Report overview video - youtube.com As a lot of people are preparing to reuse hardware for VVF/VCF 9.1, I've put out tool that scrapes the hardware configurations, checks the HCLs, assess's health, security posture, endurance, and more. A few things: 1. This doesn't require ESXi be installed (Can be any OS or hypervisor). It speaks Redfish straight to the metal (out of band management, so iDRAC/CIMC/iLO/etc). 2. The output are HTML reporting, or everyone's favorite database excel. 3. The only real dependency is python. So you can run it from source with a simple 4. "chmod +x vcfr_web.py" followed by 5. "python vcfr_web.py" (windows) 6. python3 vcfr_web.py" (Mac linux) 7. This runs with ReadOnly credentials (it's all GET commands) 8. No Phone home, but it does by default download a copy of the HCL JSON file (you can also build a darksite bundle of this to carry in). 9. It inventories switch connections from servers, identifies single switch homed servers, identifies likely "racks" of common servers with similar upstream pairs (LLDP over redfish is a thing!) I've tested this on ~600 different servers, across 8 OEMs, and 5 generations of CPUs, but am always looking to expand test coverage. If anyone run into any weird Pokemon send me a message and I'll expand coverage. (Still trying to collect a Synergy capture) Here's a Video of the scanner workflow. - youtube.com Also.
My love, hate, hate relationship with Redfish has come together and shipped something. * Inventory and cable match bare metal servers/Switches running any OS. * HCL check server chassis, CPU, NICs, firmware for 9.x upgrades. * a lot more... vmware/vcf-readiness
そもそも、VMware vSphere使ってます！みたいに書いてるからね。 その辺から狙い撃ちしやすくなってるのもあるよ。 github.com/vmware/vcf-security-and-compliance-gui…