Снимки виртуальных машин (snapshots): когда применять и подводные камни

Конец рабочей недели, критическое обновление на рабочем сервере. После перезагрузки сервис не стартует, настройки слетели, а откатить изменения вручную - это часы работы. Если перед обновлением вы сделали снапшот, откат займёт минуты. Если нет - готовьтесь к долгой ночи. Но есть нюанс: неправильное использование снимков ВМ создаёт больше проблем, чем решает.

Что вообще такое эти snapshots

Снапшот (snapshot, снимок) - это сохранённое состояние виртуальной машины на определённый момент: её дисков, настроек и, по желанию, содержимого оперативной памяти. К этому состоянию можно вернуться одной командой, отменив всё, что произошло после.

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

Реализаций две. При redirect-on-write новые записи сразу идут в дельту, исходный диск не трогается: так работают VMware, Hyper-V и внешние снимки qcow2. При copy-on-write перед перезаписью блока его старая версия копируется в область снимка: так устроены классические снимки LVM. ZFS и Ceph делают снимки средствами самого хранилища, почти мгновенно и без отдельного файла. Снимок и шаблон часто путают, хотя задачи у них не совпадают - разбираем в статье про шаблоны и образы виртуальных машин.

Когда снапшоты - это спасение

Снимки ВМ незаменимы там, где нужна быстрая точка возврата на часы или пару дней. Долговременное хранение в этот список не входит.

Первый сценарий - перед обновлениями. Неважно, патчите ли вы операционную систему, обновляете 1С или меняете конфигурацию: снапшот даст откатиться за считанные минуты. Особенно ценно, когда вендор уверяет, что «обновление займёт 5 минут и точно ничего не сломает».

Тестирование новых конфигураций - ещё одна сильная сторона снимков. Нужно проверить, как поведёт себя система с новыми правилами межсетевого экрана, - сделайте снимок, экспериментируйте, а потом откатитесь к исходному состоянию.

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

Почему снапшот - это не бэкап

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

Он есть, и не один.

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

Вторая - рост. При активной записи дельта увеличивается каждый час, и через неделю-другую снимок базы данных может догнать по размеру сам диск. Место на хранилище заканчивается внезапно, и останавливаются разом все машины на нём.

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

Забавно, что бэкап без снапшота тоже почти не обходится. Системы резервного копирования для vSphere сами создают снимок на время копирования, чтобы забрать диск в согласованном состоянии, и удаляют его сразу после. Proxmox в режиме snapshot делает похожую фиксацию средствами QEMU. Полноценный бэкап виртуальных машин на отдельный сервер разобран в статье о настройке Proxmox Backup Server.

Цепочки снапшотов и их коварство

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

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

Рекомендуемая длина цепочки - не больше 2-3 снимков. Это не цифра с потолка: VMware в базе знаний пишет, что технически поддерживается до 32 снимков в цепочке, но для нормальной производительности советует держать 2-3 и не хранить один снимок дольше 72 часов. До 32 в рабочей среде лучше не доходить.

Технические особенности разных платформ

Каждая система виртуализации реализует снапшоты по-своему, и от этого зависит, что можно, а чего нельзя.

VMware vSphere складывает изменения в отдельные файлы дисков рядом с файлами машины. На хранилищах VMFS6 по умолчанию используется формат SEsparse (файлы -sesparse.vmdk), на старых VMFS5 для небольших дисков - -delta.vmdk. Перенос ВМ между хранилищами (Storage vMotion) со снимками работает, а вот увеличить виртуальный диск, пока есть снапшоты, нельзя: сначала их придётся удалить.

Proxmox VE делает снимки средствами хранилища, поэтому всё зависит от того, где лежат диски:

Если снимки нужны регулярно, хранилище под Proxmox лучше выбирать с этим расчётом. Подробнее о том, почему администраторы любят ZFS именно за снимки и репликацию, - в отдельной статье, а для кластеров на нескольких хостах тот же подход даёт Ceph.

KVM с libvirt умеет внутренние снимки в формате qcow2 и внешние, когда поверх диска создаётся новый файл-дельта. Формат raw работает чуть быстрее, но внутренних снимков не поддерживает: выбирать приходится между удобством и скоростью.

Hyper-V называет снимки контрольными точками (checkpoints) и хранит изменения в файлах .avhdx. С Windows Server 2016 по умолчанию создаются рабочие (production) контрольные точки: перед снимком Hyper-V через службу VSS внутри гостевой Windows сбрасывает данные приложений на диск. Лимит - 50 контрольных точек на машину. Это потолок, проблемы с производительностью начинаются задолго до него.

zVirt и РОСА Виртуализация построены на oVirt и работают со снимками похоже: их создают и удаляют из портала администрирования. Удалить снимок можно и у выключенной машины, и у работающей. Во втором случае идёт слияние дисков на лету, и оно нагружает хранилище. Сравнение российских платформ - в обзоре zVirt, РОСА и Альт.

Как сделать снапшот: VMware, Proxmox, Hyper-V, KVM

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

VMware vSphere (PowerCLI). Создать снимок с согласованием файловой системы через VMware Tools, посмотреть список и удалить:

Proxmox VE. Номер машины (100) и имя снимка; ключ --vmstate 1 добавляет в снимок оперативную память:

Hyper-V (PowerShell). Создать контрольную точку, откатиться к ней и удалить:

KVM (virsh). Внутренний снимок машины с диском qcow2:

Подробнее о форматах дисков и управлении машинами из консоли - в руководстве по KVM-виртуализации.

Снапшот с памятью и согласованность данных

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

Надёжнее согласованный снимок (application-consistent). Перед ним гостевой агент просит систему и приложения сбросить данные на диск и на мгновение заморозить запись. В Windows это делает служба VSS, в Linux - VMware Tools или qemu-guest-agent, который надо установить в гостевую систему и включить в настройках ВМ. В VMware за это отвечает галочка «Quiesce guest file system», в Hyper-V - рабочие контрольные точки.

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

Лучшие практики работы со снимками

После всех страшилок - о том, как работать со снапшотами, чтобы они приносили пользу.

Первое и главное правило - снапшот должен жить недолго. Создали перед обновлением, обновились, убедились, что всё работает, - удалили. Не дольше 72 часов, а лучше в пределах суток.

Подписывайте снапшоты. Когда через месяц вы найдёте забытый снимок с именем «test», вы не вспомните, что тестировали и можно ли его удалить. Имя «before-update-apache-2.4.62» и описание с вашей фамилией говорят сами за себя.

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

Следите за местом на хранилищах. Снапшоты растут непредсказуемо: сегодня свободно 100 ГБ, а завтра утром хранилище переполнено, и все машины на нём встали. Предупреждение на 80% заполнения даёт время среагировать.

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

Когда снапшоты становятся проблемой

Типичные сценарии, когда снимок из помощника превращается в источник аварии:

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

Снапшоты баз данных требуют особого внимания. Базы постоянно пишут: перестраиваются индексы, растут журналы, создаются и удаляются временные таблицы. Снимок от этого быстро растёт. Для защиты баз лучше подходят средства самой СУБД - дампы, журналы транзакций, репликация, специализированные бэкап-решения.

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

Автоматизация управления снапшотами

Ручное управление снимками рано или поздно подводит: кто-то забудет удалить снапшот, и он будет расти, пока не съест всё место.

Простейшая автоматизация - скрипты на PowerShell для VMware и Hyper-V или bash для Proxmox. Например, поиск всех снимков в vSphere старше трёх дней:

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

Для сложных сценариев подходят системы оркестрации - Ansible, Terraform - или средства самой платформы. С ними строится цепочка: создать снимок, выполнить изменения, проверить работоспособность, удалить снимок при успехе или откатиться при проблемах.

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

Вопросы и ответы

Где лежат снапшоты в vSphere?

По умолчанию - в той же папке на хранилище, что и файлы машины: файлы дельты -00000N-sesparse.vmdk (или -delta.vmdk), состояние .vmsn и описание дерева снимков .vmsd. Руками эти файлы не удаляют: только через интерфейс или PowerCLI, иначе можно потерять данные.

Почему не расширяется диск ВМ в VMware?

Чаще всего из-за снапшотов: пока у машины есть снимки, увеличить её виртуальный диск нельзя. Удалите снимки (или выполните консолидацию, если vSphere о ней просит) и повторите.

Можно ли удалить снапшот у выключенной машины?

Да, во всех распространённых платформах - VMware, Hyper-V, Proxmox, zVirt и РОСА Виртуализации. У выключенной машины удаление даже проще: слиянию дисков не мешает работающая ВМ.

Сколько места займёт снапшот?

Сразу после создания - почти нисколько, если не сохранять память. Дальше столько, сколько данных машина изменит, вплоть до размера исходного диска. Снимок с памятью сразу добавляет объём оперативной памяти ВМ.

Реальность против ожиданий

Снимки ВМ - мощный инструмент, но не серебряная пуля. Они отлично подходят для краткосрочной защиты от ошибок, тестирования изменений и быстрого отката после неудачных обновлений. Полноценное резервное копирование они не заменяют и для архива не годятся.

Главное правило: создавайте снимок с конкретной целью, используйте по назначению и удаляйте, как только необходимость отпала. И всегда держите план Б в виде настоящего бэкапа - хранилище, а заодно и пользователи скажут спасибо.

По теме: Сравнение гипервизоров 2026