Снапшоты, которые копятся годами: сколько они стоят за год

MAATRIX

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

Зачем снапшоты множатся молча

Снапшот диска почти никогда не создаётся один раз осознанно и не удаляется тем же движением руки. Обычно накопление происходит по одному из трёх сценариев.

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

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

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

Итог во всех трёх случаях один: через год-два на аккаунте оказывается несколько десятков снапшотов, из которых актуальны в лучшем случае два-три последних, а остальные — цифровой мусор, за который продолжает капать счёт.

Почему снапшот стоит денег, даже когда диска-оригинала уже нет

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

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

Отсюда два важных следствия, которые почти никогда не учитывают при планировании бюджета:

• Размер снапшота растёт со временем, даже если размер исходного диска не меняется. Чем активнее меняются данные на диске, тем быстрее толстеет снапшот — он накапливает всё больше версий изменённых блоков.
• Уменьшение или удаление исходного диска снапшот не освобождает. Если вы урезали том, пересоздали диск с нуля или вообще удалили виртуальную машину, а снапшот при этом остался — он продолжает хранить полный набор блоков на момент создания и продолжает тарифицироваться так, будто исходный диск всё ещё существует в прежнем размере.

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

Как устроено хранение: copy-on-write, инкрементальность, цепочки

Технически подавляющее большинство систем снапшотирования — будь то LVM, ZFS, QCOW2 в связке с QEMU или блочное хранилище виртуализации — работает по одной из двух похожих моделей: copy-on-write (COW) или redirect-on-write.

При copy-on-write перед изменением блока на диске старая версия этого блока копируется в область снапшота, а затем блок на диске перезаписывается. Снапшот в этой модели хранит только изменённые с момента создания блоки — но каждое новое изменение исходного диска порождает новую копию в снапшоте, и его объём растёт пропорционально объёму реально изменённых данных, а не пропорционально размеру диска.

При redirect-on-write (характерно для ZFS и Btrfs) новые данные пишутся в новое место, а старые блоки просто продолжают на них ссылаться из снапшота — снапшот в этом случае не «догоняет» диск копированием, а просто удерживает от освобождения старые блоки, которые иначе были бы переиспользованы.

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

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

Методика: как посчитать, сколько стоят забытые снапшоты за год

Чтобы получить честную оценку, а не прикидку на глаз, стоимость нужно считать не «на сегодня», а как накопленную сумму за весь срок жизни каждого снапшота. Формула для одного снапшота выглядит так:

стоимость_снапшота_за_год = размер_ГБ × цена_за_ГБ_в_месяц × месяцев_хранения

Где размер_ГБ — это не размер исходного диска, а фактически занятое снапшотом место (см. команды инвентаризации ниже), а месяцев_хранения — сколько месяцев снапшот фактически пролежал за отчётный период (если снапшоту два года, а вы считаете за последний год — берите 12 месяцев, а не 24).

Суммарная стоимость архива — это сумма по всем найденным снапшотам:

итого_за_год = Σ (размер_ГБ_i × цена_за_ГБ_в_месяц × месяцев_хранения_i)

Цена за ГБ в месяц сильно различается между провайдерами и типами хранилища (SSD-снапшоты обычно дороже, архивные — дешевле), поэтому здесь принципиально не приводить универсальное число: берите цену снапшота из своего тарифного плана.

Для наглядности методики — условный пример с произвольными цифрами (не тарифом конкретного провайдера, а иллюстрацией порядка расчёта):

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

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

Аудит: команды для инвентаризации снапшотов в реальной инфраструктуре

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

ZFS — снапшоты видны напрямую, used показывает уникальные данные, которые освободятся при удалении именно этого снапшота:

zfs list -t snapshot -o name,used,refer,creation -s creation

LVM — сведения о снапшотах и их происхождении:

lvs -a -o lv_name,lv_size,origin,data_percent,time

Растущий data_percent у thin-снапшота — сигнал, что он копит изменения и приближается к переполнению; подробнее о рисках переполнения — в уже упомянутой статье про LVM-снапшоты.

QCOW2 / QEMU — цепочка backing-файлов и реальный занятый объём:

qemu-img info --backing-chain /var/lib/vz/images/101/vm-101-disk-0.qcow2

Proxmox VE — список снапшотов виртуальной машины через API или консоль:

pvesh get /nodes/<node>/qemu/<vmid>/snapshot
qm listsnapshot <vmid>

Обобщённый скрипт-инвентаризация — если снапшотов много и разбросаны по нескольким машинам, полезно свести их в один отчёт с возрастом в днях:

zfs list -t snapshot -H -o name,used,creation -p | \
awk -v now="$(date +%s)" '{
  age_days = int((now - $3) / 86400)
  printf "%-50s %10s  age=%d days\n", $1, $2, age_days
}' | sort -k3 -n -r

Такой отчёт стоит гонять раз в квартал и сверять с реальной потребностью: если снапшоту больше 90 дней и он не помечен как «нужен для отката», это кандидат на удаление.

Ротация и политика хранения: как не допустить накопления заново

Разовая чистка снимает симптом, но без политики хранения архив соберётся заново за следующий год. Рабочий подход — принять явную схему ротации и автоматизировать её, а не полагаться на память.

Классическая схема — grandfather-father-son (GFS): ежедневные снапшоты хранятся неделю, еженедельные — месяц, ежемесячные — год. Она же применима и к снапшотам дисков, не только к бэкапам; общие принципы схем хранения разобраны в статье про то, сколько хранить бэкапы и какая ротация нужна — логика переносится на снапшоты почти без изменений.

Практические шаги для внедрения:

1. Тегируйте снапшоты датой истечения в момент создания, а не постфактум. Если инструмент поддерживает произвольные метаданные — пишите туда expires=2026-10-01, а не полагайтесь на дату создания как единственный источник истины (некоторые снапшоты действительно нужно держать дольше стандартного срока — годовой архив перед крупной миграцией, например).
2. Автоматизируйте удаление по расписанию, а не создание. Обычно автоматизируют именно создание снапшотов (это очевидная задача), а удаление остаётся ручным — именно поэтому архив и растёт. Скрипт очистки должен запускаться так же регулярно, как скрипт создания:

# псевдокод логики очистки: удалять снапшоты старше 30 дней без тега keep
for snap in $(list_snapshots); do
  age=$(snapshot_age_days "$snap")
  if [ "$age" -gt 30 ] && ! has_tag "$snap" "keep"; then
    delete_snapshot "$snap"
  fi
done

1. Разделяйте снапшоты «для отката» и снапшоты «для бэкапа». Первые живут часы-дни и удаляются автоматически после подтверждения успешного изменения. Вторые — это не задача снапшотов вообще: для полноценного резервного копирования с независимым хранением и версионированием нужны отдельные инструменты. О том, почему снапшот — не замена бэкапу, подробно написано в статье про ZFS-снапшоты против бэкапа.
2. Мониторьте суммарный объём снапшотов как отдельную метрику, а не только занятость диска. Рост этой метрики без соответствующего роста активности — первый признак забытого архива, который стоит заметить до того, как он попадёт в счёт за квартал. Похожий сценарий тихого роста счёта без роста нагрузки разобран в статье про то, как счёт за облако вырос вдвое без роста нагрузки.
3. Перед удалением старого снапшота в цепочке проверяйте зависимости. Как разобрано выше, в COW-цепочках нельзя просто выбросить средний снапшот — нужна операция слияния. Автоматика очистки должна это учитывать, иначе вместо экономии вы получите долгую операцию merge на проде в неудобный момент.

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

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