Определение простыми словами
Снапшот — это «фотография» состояния тома или виртуальной машины на конкретный момент времени. Современные снапшоты не копируют данные физически: пока исходные блоки не меняются, снимок и оригинал ссылаются на одни и те же сектора через механизм copy-on-write. Запись новых данных приводит к копированию только изменённых блоков, поэтому снимок занимает минимум места и создаётся за секунды.
Главное правило: снапшот — это не бэкап. Если умирает диск или том, на котором лежат и данные, и снимок, то теряется всё разом. Снимки полезны для быстрых откатов после миграций, обновлений и тестов, но для долговременной защиты данные нужно копировать на отдельное хранилище через rsync, restic или промышленные системы.
Сравнение с альтернативами
| Тип защиты | Скорость создания | Защита от отказа диска | Где живёт |
|---|---|---|---|
| Snapshot | Секунды | Нет | На том же томе |
| Backup | Минуты — часы | Да | Отдельное хранилище |
| Replication | Минуты задержки | Да | Другая площадка |
| Clone | Минуты | Зависит от носителя | Полная копия тома |
Кейсы использования
- Точка отката перед обновлением ядра, мажорной версией PostgreSQL или ноды Kubernetes.
- Быстрая выдача песочниц разработчикам — клонирование тома без копирования.
- Тестирование миграций базы данных на реальных данных без риска для прода.
- Снимок виртуальной машины в облаке перед экспериментом с прошивкой.
- Согласованный по времени источник для резервного копирования с последующей выгрузкой через rsync.
Негативный сценарий: на хосте с базой данных ZFS-снапшот висит две недели и съедает 80% свободного места, потому что DBA забыл про него. Запись на том упирается в нехватку места, база уходит в read-only, сервис падает. Снимки нужно держать под мониторингом и удалять по политике.
Технические детали
# LVM snapshot для бэкапа базы
sudo lvcreate -L 10G -s -n db_snap /dev/vg0/db
sudo mount -o ro /dev/vg0/db_snap /mnt/snap
sudo lvremove -f /dev/vg0/db_snap
# ZFS — мгновенный снимок и откат
sudo zfs snapshot tank/data@before-upgrade
sudo zfs rollback tank/data@before-upgrade
sudo zfs destroy tank/data@before-upgrade
# Btrfs subvolume snapshot
sudo btrfs subvolume snapshot /mnt/data /mnt/data-snap
# Облачный VPS API (пример Hetzner)
curl -X POST -H "Authorization: Bearer $TOKEN"
https://api.hetzner.cloud/v1/servers/123/actions/create_imageСнимки в LVM, ZFS и Btrfs работают на уровне блочного устройства и не понимают, что внутри живёт. Чтобы получить consistent-снимок СУБД, перед созданием делают FLUSH TABLES WITH READ LOCK, pg_start_backup или используют файловые системы с поддержкой fsfreeze. Иначе в снимке окажется набор «полузаписанных» страниц, и восстановление затянется надолго.
🔥 Где это применяется
Частые вопросы
Чем snapshot отличается от backup?
Снапшот хранится на том же томе и не защищает от его отказа. Бэкап — это полноценная копия на отдельном хранилище. Снимки удобны для быстрых откатов и source for backup, но не заменяют резервное копирование.
Сколько места занимает снапшот?
В момент создания почти ничего. Размер растёт пропорционально объёму изменённых блоков с момента снимка. Если активная база переписывает много данных, снимок может разрастись до объёма исходного тома за сутки.
Можно ли откатить только часть данных?
Полный rollback возвращает том к состоянию снимка целиком. Чтобы достать отдельные файлы, снимок монтируют read-only и копируют нужное наружу через cp или rsync. Для СУБД восстанавливают конкретные таблицы из дампа.