Снапшоты в Proxmox: как они устроены и когда опасны

MAATRIX

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

Что на самом деле происходит при создании снапшота

Когда вы жмёте «Take Snapshot» на виртуальной машине в Proxmox, гипервизор не копирует байты диска. Вместо этого происходит следующее: текущее состояние диска фиксируется как неизменяемая точка, а сам диск виртуальной машины продолжает работать, но все новые записи начинают уходить не поверх старых данных, а в отдельную область. Это классический механизм copy-on-write (COW) — «копирование при записи»: старый блок данных не трогается, пока в него не нужно что-то записать, а в момент записи система создаёт для изменившегося блока новое место, оставляя оригинал доступным через снапшот.

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

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

LVM-thin, ZFS и qcow2: один принцип, разная реализация

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

LVM-thin реализует COW на уровне блочного устройства. Каждый thin-volume делит пространство на чанки (обычно 64 МБ по умолчанию), и при первой записи в чанк после снапшота выделяется новый чанк, а старый остаётся привязан к снапшоту. Посмотреть состояние можно так:

lvs -a -o +lv_size,data_percent,metadata_percent vg_name

Здесь data_percent — заполненность thin-пула данными, а metadata_percent — отдельная метаданная область, которая тоже может кончиться (и тогда пул блокируется на запись, даже если данных вроде бы много не написали).

ZFS устроен нативно вокруг снапшотов — это его сильная сторона. ZFS изначально copy-on-write на уровне файловой системы, поэтому снапшот — это просто «заморозка» указателя на дерево блоков на момент времени, почти без накладных расходов на создание. Посмотреть, сколько реально «весит» снапшот:

zfs list -t snapshot -o name,used,refer rpool/data/vm-100-disk-0

Колонка used показывает объём, который занимает именно этот снапшот (то есть данные, уникальные для него и больше нигде не используемые), а refer — сколько данных вообще видно через этот снапшот. Разница между ними часто вводит в заблуждение: снапшот с used в 500 МБ может «отвечать» за куда больший refer, если данные разделяются с другими снапшотами в цепочке.

qcow2 (формат файлов-образов) реализует снапшоты через собственный внутренний механизм L1/L2-таблиц указателей на кластеры данных внутри одного файла. Здесь COW происходит на уровне самого файла образа: старые кластеры остаются в файле, новые дописываются, а таблицы указателей перестраиваются. Это самая гибкая по переносимости схема (снапшот живёт прямо внутри файла диска), но и самая медленная под нагрузкой — за счёт разрастания таблиц указателей и постоянных обращений к разным частям файла операции чтения/записи заметно тормозят при глубокой цепочке снапшотов. Мы разбирали это подробно в статье про то, почему qcow2-снапшоты тормозят диск — если ваши VM на qcow2 и снапшоты копятся, стоит прочитать отдельно.

Проверить состояние конкретной VM независимо от типа хранилища можно через сам Proxmox:

qm listsnapshot 100
qm status 100 --verbose

Опасность №1: длинная цепочка снапшотов и медленное удаление

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

На практике это проявляется так: вы удаляете снапшот недельной давности с активной базой данных внутри VM, и вместо мгновенного ответа Proxmox «зависает» на operation в статусе running на десятки минут, диск при этом загружен вводом-выводом под сто процентов, а сама VM ощутимо тормозит для пользователей. Это не баг — это неизбежная механика: слияние снапшота требует переписать ровно тот объём данных, который отличает его от соседних слоёв в цепочке.

Практический вывод: не превращайте снапшот в постоянную точку — если он создан для теста, удаляйте его сразу после проверки, а не «на всякий случай через месяц».

Опасность №2: снапшот растёт непредсказуемо, а не занимает фиксированный объём

Второе заблуждение — воспринимать снапшот как что-то с известным заранее размером. На деле снапшот занимает место пропорционально объёму изменений с момента его создания, а не какой-то фиксированный процент диска. Это значит, что для VM с низкой активностью записи (веб-сервер, который читает статику) снапшот месячной давности может весить копейки. А для VM с активной базой данных, логами с высокой частотой записи или очередью сообщений тот же снапшот за сутки может «съесть» десятки гигабайт — просто потому что база данных постоянно перезаписывает свои файлы, и каждая перезапись COW-блока добавляет вес снапшоту.

Реальный сценарий: администратор ставит снапшот перед обновлением PostgreSQL, тест проходит успешно, снапшот забывают удалить. База продолжает работать в обычном режиме — с checkpoint'ами, WAL-записью, вакуумом таблиц. Через две-три недели thin-пул или zpool внезапно упирается в потолок места, хотя «полезных» данных на диске не прибавилось — просто накопился вес забытого снапшота.

Мониторить это стоит явно, а не полагаться на то, что «места достаточно»:

# LVM-thin: смотреть заполненность пула, а не только отдельных volume
lvs -a -o +data_percent vg_name/pool_name

# ZFS: суммарный вес всех снапшотов датасета
zfs list -t snapshot -o name,used -r rpool/data

Если у вас уже есть настроенный мониторинг диска на сервере — стоит завести отдельный порог именно на заполненность thin-пула или zpool, а не только на общий df -h, потому что снапшоты не всегда видны через обычную файловую систему гостевой ОС.

Опасность №3: снапшот — это не резервная копия

Это самое опасное заблуждение из всех, и оно стоит того, чтобы проговорить его прямо: снапшот не защищает от отказа диска или хранилища. Снапшот живёт на том же физическом носителе (или в том же массиве, том же пуле), что и сама виртуальная машина. Если у вас NVMe/SSD под VM выходит из строя, RAID-массив теряет избыточность и сыпется, или thin-пул повреждается на уровне метаданных — вы теряете одновременно и рабочий диск VM, и все её снапшоты. Снапшот никак не увеличивает число физических копий данных — он лишь изменяет способ, которым эти данные организованы на одном и том же носителе.

Это тот же самый принцип, что и в мифе «RAID — это резервная копия»: избыточность и версионность внутри одного массива/пула не защищают от отказа самого массива/пула целиком, кражи сервера, ошибки администратора (rm -rf не по той VM) или атаки шифровальщика на весь датацентр. Мы разбирали эту логику подробнее применительно к RAID в статье про миф «RAID — это бэкап» — механика со снапшотами Proxmox та же самая: локальная избыточность ≠ резервная копия на отдельном носителе.

Снапшот отлично решает свою реальную задачу: короткая точка отката перед рискованным действием — обновлением ядра, миграцией схемы базы, экспериментом с конфигом. Если что-то пошло не так, qm rollback возвращает VM к состоянию снапшота за секунды. Но это совсем другая задача, чем защита от физической потери данных. Для последней нужна отдельная копия на другом носителе — в идеале на другом сервере или в другом дата-центре, регулярно и автоматически, что как раз и делает системы резервного копирования, а не снапшоты гипервизора.

Как использовать снапшоты правильно

Практический свод правил, который снимает 90% проблем:

• Снапшот — для минут и часов, не для недель. Создали перед рискованной операцией, проверили результат, удалили. Если тест провалился и нужен откат — откатились и удалили сразу после.
• Не накапливайте цепочки. Одна активная VM редко нуждается больше чем в 1-2 одновременных снапшотах. Если у вас в qm listsnapshot висит десяток записей за разные даты — это уже не технический долг, а прямой риск при следующем удалении.
• Мониторьте заполненность пула, а не диска гостя. Гостевая ОС внутри VM может показывать честные 20% занятого места, пока thin-пул или zpool на хосте уже трещит по швам от веса снапшотов.
• Для VM с активной записью (БД, очереди, логи) — короче окно жизни снапшота. Чем интенсивнее запись, тем быстрее растёт вес снапшота, и тем дороже станет его отложенное удаление.
• Снапшот перед обновлением — это гигиена, не стратегия защиты данных. Параллельно должен работать отдельный бэкап на внешнее хранилище: Proxmox Backup Server, либо любое из решений уровня VM/гостевой ОС.
• Планируйте задачи автоматизации снапшотов с автоудалением по TTL, а не полагайтесь на то, что кто-то не забудет прибраться руками.

Если вы разворачиваете новую инфраструктуру и думаете, сколько места закладывать под тома с учётом снапшотов — стоит сразу считать не только объём самих дисков VM, но и запас под временные снапшоты при активной записи, с хорошим запасом сверху.

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