Резервное копирование VPS: rsync, restic и правило 3-2-1

Зачем свои резервные копии, если сервер надёжный

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

Что такое правило 3-2-1

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

Шаг 1. Решите, что копировать

• /etc - конфиги nginx, systemd, SSH, файрвола: на их повторную настройку уходят часы;
• данные приложений - /home, /opt, /srv, /var/www или где лежат ваши проекты, включая файлы .env;
• дампы баз данных - PostgreSQL, MySQL, SQLite, а не файлы работающей базы;
• тома Docker (/var/lib/docker/volumes), если данные живут в контейнерах, - лучше тоже через дамп базы;
• не нужно копировать систему целиком: /usr, /var/cache, /proc, /tmp и node_modules восстанавливаются установкой ОС и пакетов.

Шаг 2. Делайте дампы баз перед копированием

Файлы базы данных, скопированные на ходу, почти наверняка окажутся несогласованными, и база из них не поднимется. Дамп снимается с работающей базы без остановки и всегда согласован. Пример для PostgreSQL - подробнее в статье про PostgreSQL на VPS:

sudo mkdir -p /var/backups/db
sudo -u postgres pg_dump -Fc myapp | sudo tee /var/backups/db/myapp.dump > /dev/null
sudo ls -lh /var/backups/db

Шаг 3. Настройте вход на сервер копий по SSH-ключу

Копирование по расписанию работает без пароля, поэтому для него нужен отдельный SSH-ключ root. ssh-copy-id один раз попросит пароль пользователя backup на втором сервере, а запись в /root/.ssh/config даёт ему короткое имя backup-server. О ключах подробнее - в статье про подключение по SSH:

sudo ssh-keygen -t ed25519 -N "" -f /root/.ssh/backup_key
sudo ssh-copy-id -i /root/.ssh/backup_key.pub backup@203.0.113.20
sudo tee -a /root/.ssh/config > /dev/null <<'EOF'
Host backup-server
    HostName 203.0.113.20
    User backup
    IdentityFile /root/.ssh/backup_key
EOF

Шаг 4. Простой вариант: rsync на другой сервер

rsync копирует только изменившиеся файлы, поэтому повторный запуск занимает секунды. -a сохраняет права и даты, --delete удаляет на копии файлы, которых больше нет на сервере. rsync должен быть установлен на обоих серверах:

sudo apt install -y rsync
sudo rsync -a --delete /etc /home /opt /var/backups backup-server:/srv/backup/myvps/

Шаг 5. restic: шифрование, дедупликация и история

restic хранит копии снимками (snapshot): каждый снимок - полное состояние на момент запуска, но одинаковые части файлов хранятся один раз (дедупликация), поэтому 30 ежедневных снимков редко меняющихся данных занимают немногим больше одного. Всё шифруется на вашем сервере, и сервер копий видит только зашифрованные блоки. Репозиторий по SFTP использует ключ из шага 3:

sudo apt install -y restic
sudo sh -c 'openssl rand -base64 32 > /root/.restic-password && chmod 600 /root/.restic-password'
sudo -i
export RESTIC_REPOSITORY=sftp:backup-server:/srv/restic/myvps
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init

Первый снимок, список снимков, чистка по политике хранения и проверка целостности репозитория. forget --prune оставляет 7 последних дневных, 4 недельных и 6 месячных снимков и удаляет данные, на которые больше не ссылается ни один снимок:

restic backup /etc /home /opt /var/backups --exclude-caches
restic snapshots
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

Кроме SFTP restic умеет писать в S3-совместимые хранилища - так удобно сделать вторую резервную копию по правилу 3-2-1. Список поддерживаемых хранилищ - в документации на restic.net.

Шаг 6. Запускайте копирование по расписанию

Соберите дамп и restic в один скрипт: set -eu остановит его на первой ошибке, и битый дамп не уйдёт в копию как удачный:

sudo tee /usr/local/sbin/backup.sh > /dev/null <<'EOF'
#!/bin/sh
set -eu
export RESTIC_REPOSITORY=sftp:backup-server:/srv/restic/myvps
export RESTIC_PASSWORD_FILE=/root/.restic-password

# дамп базы - если на сервере есть PostgreSQL
mkdir -p /var/backups/db
runuser -u postgres -- pg_dump -Fc myapp > /var/backups/db/myapp.dump

restic backup /etc /home /opt /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF
sudo chmod 700 /usr/local/sbin/backup.sh

systemd timer запускает скрипт каждую ночь в 03:30 со случайной задержкой до 15 минут, а Persistent=true выполнит пропущенный запуск, если сервер в это время был выключен. Результат каждого запуска виден в journalctl -u backup:

sudo tee /etc/systemd/system/backup.service > /dev/null <<'EOF'
[Unit]
Description=Restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup.sh
EOF
sudo tee /etc/systemd/system/backup.timer > /dev/null <<'EOF'
[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer

Если привычнее cron, та же задача - одна строка в sudo crontab -e:

30 3 * * * /usr/local/sbin/backup.sh >> /var/log/backup.log 2>&1

Шаг 7. Проверьте восстановление

Резервная копия, из которой ни разу не восстанавливали, - это надежда, а не бэкап. Раз в месяц восстановите несколько файлов во временный каталог и сравните с оригиналом, а дамп базы разверните в отдельную базу через pg_restore:

restic snapshots
restic restore latest --target /root/restore-test --include /etc/nginx
diff -r /etc/nginx /root/restore-test/etc/nginx && echo OK

Заодно засеките время: сколько займёт поднять всё на чистом сервере - установить ОС, пакеты, вернуть /etc, данные и базу. Этот план восстановления стоит записать до аварии, а не во время неё.

Куда складывать копии

У Tihost три локации - Германия, Финляндия и Польша, поэтому сервер для копий удобно взять в другой стране, чем основной: авария одного дата-центра не затронет обе копии. Как выбрать локацию - в статье о выборе локации VPS. Для хранилища копий подходят конфигурации Starter - в старшей из них диск больше всего: