Резервні копії сервера: правило 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.
• Відсутність контролю над заповненням цілі резервного копіювання. Переповнена ціль означає копії, що мовчки не створюються.