Бэкапы сервера: правило 3-2-1 и восстановление

Правило 3-2-1 гласит: храните три копии важных данных (оригинал и две резервные), на двух разных видах носителей, и хотя бы одну копию держите в другом месте. На VPS это значит, что кроме данных на самом сервере должна быть хотя бы одна копия вне сервера.

Это же правило рекомендуется в документе Data Backup Options, подготовленном для US-CERT и опубликованном на сайте CISA. Его цель — чтобы один сбой, ошибка или атака не могли уничтожить все копии сразу.

Бэкап, снимок и избыточность дисков — не одно и то же

• Бэкап: отдельная копия ваших данных, обычно с более ранними версиями. Возвращает файл, удалённый или испорченный по ошибке.
• Снимок: фиксирует состояние сервера на данный момент. Удобен для быстрого отката перед крупным обновлением. Но он зависит от исходного диска, поэтому бэкап не заменяет.
• Избыточность дисков: одни и те же данные записываются сразу на два диска. Защищает при отказе одного диска. Удалённый вами файл удаляется с обоих дисков, а данные, зашифрованные вирусом-вымогателем, зашифрованы на обоих. Поэтому это не бэкап.

Как применить 3-2-1 на VPS

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

Что копировать

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

mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

sudo -u postgres pg_dumpall | gzip > /var/backups/pg-$(date +%F).sql.gz

Из файлов достаточно этого: /etc, файлы ваших сайтов, папка с данными приложения, тома Docker, если вы используете Docker, и файлы .env. Не копируйте то, что можно скачать заново, например пакеты и образы Docker. Если у приложения есть ключ шифрования, храните его тоже отдельно. Для некоторых приложений бэкап без ключа бесполезен.

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

Бэкап вне сервера с помощью restic

restic — это бэкап-инструмент с открытым кодом: он шифрует копии и хранит повторяющиеся данные один раз. В примере ниже копия записывается на другой сервер по SFTP. На целевом сервере нужен беспарольный вход по SSH-ключу, потому что автоматический бэкап не может ответить на запрос пароля. Создайте файл с паролем (/root/.restic-password) в текстовом редакторе и выполните для него chmod 600.

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:[email protected]:/backups/vps

export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

restic backup /etc /var/www /var/backups

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

Документация restic предупреждает: если потерять пароль, данные пропадут безвозвратно. Храните пароль и в менеджере паролей. Поместите обе строки export, дампы баз данных, restic backup и restic forget в скрипт, например /usr/local/bin/backup.sh, в таком порядке и сделайте его исполняемым командой chmod +x. Не забудьте добавить в конец строку, которая удаляет старые дампы, find /var/backups -name '*.sql.gz' -mtime +2 -delete, иначе файлы дампов заполнят диск. Затем запускайте скрипт каждую ночь, например из /etc/cron.d/backup с такой строкой:

30 3 * * * root /usr/local/bin/backup.sh

borg — похожий инструмент. Для простого копирования файлов подойдёт rsync, а для отправки данных в объектное хранилище — rclone.

Настоящая проверка: восстановление

Бэкап, который нельзя восстановить, бесполезен. Попробуйте сразу после настройки, а потом периодически:

• С restic распакуйте последнюю копию в пустую папку и проверьте файлы: restic restore latest --target /tmp/restore-test
• Загрузите дамп базы данных во временную базу и посмотрите таблицы.
• В панели нажмите значок Достать из него файлы рядом с бэкапом, найдите нужное внутри и скачайте один файл. Полное восстановление заменяет весь текущий диск, поэтому для проверки безопаснее достать один файл.

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

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

• Запись бэкапа на диск того же сервера. Если диск заполнится или сервер будет потерян, бэкап пропадёт вместе с ним.
• Хранение пароля или ключа от бэкапа там же, где сам бэкап.
• Незамеченные сбои скрипта. Добавьте в скрипт уведомление или время от времени проверяйте дату последнего бэкапа командой restic snapshots.
• Отсутствие контроля над заполнением места для бэкапов. Переполненное хранилище означает бэкапы, которые тихо перестают создаваться.