Снапшоты и бэкапы VPS: в чём разница и зачем нужны оба

Коротко: снапшот — для отката, бэкап — для спасения

Снапшот (snapshot) — это снимок всего диска VPS в конкретный момент: система, настройки, код, данные. Его делают в панели провайдера за пару кликов, и из него можно быстро восстановить сервер целиком или создать копию.

Бэкап (backup) в строгом смысле — это независимая копия важных данных, которая хранится отдельно от сервера и провайдера и восстанавливается по проверенной процедуре.

Снапшот отвечает на вопрос «как быстро вернуться к вчерашнему состоянию». Бэкап — «как не потерять данные, если сервера больше нет».

Что именно захватывает снапшот и где он лежит

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

Отсюда главное: снапшот удобен, но привязан к одному аккаунту у одного провайдера.

Почему снапшот у того же провайдера — не настоящий бэкап

Снапшот не спасёт в сценариях, которые бьют по аккаунту или провайдеру целиком:

• Компрометация аккаунта. Злоумышленник с доступом к панели удалит и серверы, и снапшоты.
• Блокировка или неоплата. Аккаунт заморожен — доступа нет ни к чему.
• Удаление сервера. У некоторых провайдеров автоматические копии привязаны к серверу и исчезают вместе с ним.
• Ошибка в данных. Если повреждение или удаление записей заметили через неделю, а снапшоты хранятся три дня, откатываться некуда.
• Инцидент в дата-центре или регионе. Редко, но копии в том же регионе могут оказаться недоступны вместе с сервером.

Проблема консистентности с базами данных

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

• PostgreSQL и MySQL (InnoDB) обычно восстанавливаются по журналу, но это не гарантия, особенно если данные разнесены по нескольким дискам.
• Надёжнее делать логический дамп средствами самой СУБД или физический бэкап с журналом (WAL, binlog).
• Если нужен именно консистентный снапшот, кратко останавливают запись: останавливают сервис или замораживают файловую систему (fsfreeze) на время снимка.

# PostgreSQL: консистентный дамп без остановки базы
pg_dump -Fc -d app_db -f /backup/app_db.dump

# MySQL/InnoDB: дамп в одной транзакции
mysqldump --single-transaction --routines app_db > /backup/app_db.sql

Как совместить снапшоты и бэкапы

Рабочая схема для большинства проектов:

1. Автоматические снапшоты у провайдера — ежедневно, с хранением нескольких дней. Плюс ручной снапшот перед каждым крупным обновлением.
2. Дампы баз данных по расписанию — минимум раз в сутки, для важных данных чаще или с непрерывной архивацией журнала.
3. Файловый бэкап пользовательских загрузок, конфигов и секретов инструментами вроде restic или borg с шифрованием.
4. Внешнее хранилище — объектное хранилище у другого провайдера или в другом аккаунте с отдельными учётными данными. Сервер должен уметь только записывать туда, но не удалять.
5. Политика хранения: например, ежедневные копии за неделю, еженедельные за месяц, ежемесячные за год — под ваши требования.
6. Мониторинг: если бэкап не выполнился, вы узнаёте об этом сразу, а не в день аварии.

Тестовое восстановление — обязательная часть

Бэкап, из которого ни разу не восстанавливались, — это надежда, а не защита. Регулярно:

• поднимайте чистый сервер и разворачивайте на нём дамп базы и файлы;
• проверяйте, что приложение запускается и данные актуальны;
• засекайте время восстановления — это ваш реальный RTO;
• записывайте шаги в короткую инструкцию, чтобы восстановить мог не только один человек.

Частые ошибки

• Считать автоматические снапшоты провайдера единственной защитой.
• Хранить бэкапы на том же сервере, на отдельном разделе.
• Давать серверу права на удаление внешних копий.
• Не шифровать бэкапы, в которых лежат персональные данные и ключи.
• Ни разу не проверять восстановление.