Снапшоты и бэкапы: в чём разница и как не потерять данные

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

Что такое снапшот

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

Сильные стороны снапшотов:

• Быстро. Не нужно ничего устанавливать и настраивать на самом сервере.
• Целиком. Возвращается всё сразу, без ручной переустановки пакетов и настроек.
• Удобно перед рискованными изменениями: обновлением системы, переходом на новую версию дистрибутива, правкой сетевых настроек или миграцией базы данных.

Но у снапшотов есть и важные ограничения:

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

Что такое резервная копия

Бэкап — это копия ваших данных, сохранённая отдельно от сервера. Хорошая резервная копия отвечает на три вопроса:

1. Где лежит? Не на том же сервере и не на той же платформе. Если сервер удалён, взломан или недоступен, копия должна уцелеть.
2. Сколько версий? Не одна последняя, а несколько: за последние дни, недели и месяцы. Ошибку или заражение часто замечают не сразу.
3. Проверено ли восстановление? Копия, из которой ни разу не восстанавливались, — это надежда, а не бэкап.

Классический ориентир — правило 3-2-1: три копии данных, на двух разных носителях или в двух системах, одна из них — в другом месте.

Вывод простой: снапшоты и бэкапы не заменяют друг друга, а дополняют. Снапшот — быстрый способ отменить свою ошибку. Бэкап — страховка от всего остального.

Снапшоты в Verdian Cloud

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

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

Что нужно бэкапить на сервере

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

• базы данных — в виде дампов, а не копий файлов работающей СУБД;
• файлы приложения и загрузки пользователей — например, /var/www или каталоги с медиа;
• конфигурация — /etc, настройки веб-сервера, файлы .env, docker-compose.yml;
• тома Docker с данными, если проект работает в контейнерах;
• сертификаты и ключи, если их нельзя быстро выпустить заново.

Дампы баз данных

Копировать файлы работающей базы данных нельзя: на диске они почти никогда не находятся в согласованном состоянии. Вместо этого сделайте дамп штатными средствами.

PostgreSQL — в сжатом формате, из которого удобно восстанавливать отдельные таблицы:

sudo -u postgres pg_dump -Fc имя_базы > /var/backups/db/имя_базы.dump

MySQL и MariaDB — без блокировки таблиц InnoDB:

mysqldump --single-transaction --routines --triggers имя_базы | gzip > /var/backups/db/имя_базы.sql.gz

Восстанавливаются такие дампы командами pg_restore и mysql соответственно. Каталог /var/backups/db создайте заранее и ограничьте доступ к нему: в дампах лежат все данные проекта.

Простые бэкапы с restic

Для копирования файлов на внешнее хранилище удобен restic: он шифрует данные, хранит только изменения между версиями и умеет работать с другим сервером по SFTP или с S3-совместимым объектным хранилищем. Установка:

sudo apt install restic

Создайте файл с паролем репозитория и инициализируйте хранилище — в примере это каталог на другом сервере, доступном по SSH:

sudo install -m 600 /dev/null /root/.restic-pass
sudo nano /root/.restic-pass
sudo restic -r sftp:backup@адрес-хранилища:/srv/restic -p /root/.restic-pass init

Пароль из /root/.restic-pass сохраните ещё и в менеджере паролей: без него восстановить данные будет невозможно.

Сам бэкап и очистка старых версий — неделя ежедневных, месяц еженедельных и полгода ежемесячных копий:

sudo restic -r sftp:backup@адрес-хранилища:/srv/restic -p /root/.restic-pass \
    backup /etc /var/www /var/backups/db
sudo restic -r sftp:backup@адрес-хранилища:/srv/restic -p /root/.restic-pass \
    forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

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

Проверяйте восстановление

Раз в месяц-два восстанавливайте копию на тестовый каталог или отдельный сервер и проверяйте, что данные на месте:

sudo restic -r sftp:backup@адрес-хранилища:/srv/restic -p /root/.restic-pass check
sudo restic -r sftp:backup@адрес-хранилища:/srv/restic -p /root/.restic-pass \
    restore latest --target /tmp/restore-test

Команда check проверяет целостность хранилища, а restore показывает, что из копии действительно можно достать файлы. Для базы данных разверните дамп в отдельную тестовую базу и выполните пару запросов. Заодно засеките время: вы будете знать, сколько займёт восстановление в настоящей аварии.

Минимальный план защиты данных

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

Если вы только запускаете сервер, начните с базовой защиты по нашей инструкции «Первые 15 минут после покупки VPS», а снимок сделайте сразу после неё.