Снапшоты VPS и резервные копии на внешней площадке

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

Снапшоты и резервные копии

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

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

Снапшоты в тарифах

Если все слоты заняты, укажите в запросе, какой снапшот заменить.

Создание, восстановление и удаление снапшотов

Создать

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

Восстановить

В разделе Действия с сервером выберите Восстановить из снапшота и укажите имя снапшота. VPS вернётся в состояние на момент снапшота, а запрос будет отмечен как выполненный, когда сервер снова будет в сети. Проверьте, что ваши сервисы запустились, а задания по расписанию и сертификаты в порядке.

Удалить

Отправьте запрос Удалить снапшот в разделе Действия с сервером, указав имя снапшота. Удаление снапшота необратимо. Храните хотя бы один заведомо рабочий снапшот, например сделанный после первоначальной настройки, а снапшоты, сделанные перед изменениями, удаляйте, когда изменения несколько дней проработают без проблем.

Как делать согласованные снапшоты

Снапшот работающего сервера согласован на уровне сбоя (crash-consistent): диск выглядит так, будто в этот момент отключили питание. Журналируемые файловые системы хорошо с этим справляются. Базы данных обычно тоже восстанавливаются, но могут потерять последние транзакции, а таблица, в которую в этот момент шла запись, может оказаться повреждённой. Прежде чем запрашивать снапшот сервера с базой данных, воспользуйтесь одним из двух способов ниже.

Кратковременная остановка базы данных

Самый простой вариант. Остановите службу (для PostgreSQL она называется postgresql):

systemctl stop mariadb

Запросите снапшот и снова запустите службу, когда запрос будет отмечен как выполненный (до этого момента база данных недоступна):

systemctl start mariadb

Предварительный дамп баз данных

Лучший вариант, если база данных должна оставаться доступной: дамп, сделанный непосредственно перед запросом снапшота, согласован, даже если рабочие файлы базы данных — нет, и его можно повторно использовать для резервного копирования на внешнюю площадку. Между созданием дампа и моментом, когда запрос будет отмечен как выполненный, не записывайте ничего важного. Для MariaDB (в MySQL команда называется mysqldump):

mkdir -p /root/db-dumps
chmod 700 /root/db-dumps
mariadb-dump --all-databases --single-transaction --routines --events > /root/db-dumps/mariadb.sql

Для PostgreSQL:

runuser -u postgres -- pg_dumpall > /root/db-dumps/postgresql.sql

Резервное копирование на внешнюю площадку с restic или Borg

И restic, и Borg шифруют данные на вашем сервере до того, как что-либо его покинет, выполняют дедупликацию и экономно хранят множество версий. Место назначения видит только зашифрованные данные, поэтому им может быть любая машина, доступная по SSH: второй VPS, сервер для хранения данных в другой нашей локации или домашний компьютер. Копируйте /etc, /home, /root, корневые каталоги сайтов и данные приложений, а также дампы баз данных вместо рабочих файлов баз данных. Скорректируйте пути в примерах под свой сервер.

restic

На VPS установите restic, создайте SSH-ключ для root и скопируйте его на хост для резервных копий. Затем сгенерируйте случайный пароль репозитория, инициализируйте репозиторий и запустите первое резервное копирование:

apt install -y restic
ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519
ssh-copy-id backup@BACKUP_HOST
install -m 600 /dev/null /root/.restic-pass
openssl rand -base64 32 > /root/.restic-pass
export RESTIC_REPOSITORY=sftp:backup@BACKUP_HOST:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /root /var/www --exclude-caches
restic snapshots

Borg

Borg должен быть установлен и на хосте для резервных копий, поскольку он работает там через SSH. Настройте SSH-ключ, как в примере с restic. Эти команды рассчитаны на Borg 1.2 и 1.4 — версии, которые входят в пакеты текущих выпусков Debian и Ubuntu:

apt install -y borgbackup
install -m 600 /dev/null /root/.borg-pass
openssl rand -base64 32 > /root/.borg-pass
export BORG_REPO=ssh://backup@BACKUP_HOST/./borg/web1
export BORG_PASSCOMMAND="cat /root/.borg-pass"
borg init --encryption=repokey-blake2
borg create --stats --compression zstd '::{hostname}-{now}' /etc /home /root /var/www
borg list
borg key export "$BORG_REPO" /root/borg-key.txt

Сохраните borg-key.txt и парольную фразу в надёжном месте вне сервера, затем удалите экспортированный файл с VPS.

Автоматизация, очистка и проверка

Поместите обе строки export, команды для дампа баз данных и команду резервного копирования в скрипт, например /usr/local/sbin/offsite-backup, и сделайте его доступным для чтения только root:

chmod 700 /usr/local/sbin/offsite-backup
crontab -e

Добавьте в crontab пользователя root строку, которая будет запускать скрипт каждую ночь в 03:30:

30 3 * * * /usr/local/sbin/offsite-backup

Завершите скрипт правилом хранения, чтобы старые версии удалялись. Приведённые правила сохраняют ежедневные копии за неделю, еженедельные — за месяц и ежемесячные — за шесть месяцев. Для restic:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Для Borg:

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compact

Непроверенная резервная копия может не восстановиться, когда она понадобится. Раз в месяц проверяйте репозиторий и восстанавливайте данные во временный каталог. С restic:

restic check
restic restore latest --target /root/restore-test

С Borg выведите список архивов, затем извлеките один из них в пустой каталог:

borg check
mkdir -p /root/restore-test
cd /root/restore-test
borg extract '::ARCHIVE_NAME' etc

Сервер, который сам отправляет свои резервные копии, может их и удалить, если злоумышленник получит права root. Чтобы этого не случилось, сделайте репозиторий на хосте для резервных копий доступным только для добавления: у rest-server для restic есть режим --append-only, а Borg можно ограничить с помощью borg serve --append-only в файле authorized_keys пользователя, от имени которого выполняется резервное копирование. Руководство по усилению защиты поможет вообще не допустить злоумышленников на сервер.