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

Правило 3-2-1 без буквоедства

Три копии данных, на двух разных носителях, одна — вне площадки. На практике для VPS это значит: рабочие данные на сервере, зашифрованный бэкап в S3-совместимом хранилище другого провайдера — и всё. Бэкап на том же сервере (или у того же провайдера в том же ДЦ) — это не копия, а иллюзия: сгорел аккаунт — сгорело всё.

restic: шифрование и дедупликация из коробки

restic шифрует всё на клиенте, хранит снапшоты инкрементально и умеет любой S3. Один бинарник, никаких демонов.

$ export RESTIC_REPOSITORY=s3:s3.storage.example.com/backup-bucket
$ export RESTIC_PASSWORD_FILE=/root/.restic-pass
$ restic init                        # один раз
$ restic backup /srv/app/data /etc \
    --exclude='*.tmp'
$ restic forget --keep-daily 7 --keep-weekly 4 \
    --keep-monthly 6 --prune

Базы данных не копируйте файлами на живую — сначала дамп, потом бэкап дампа:

$ docker exec db pg_dump -U app -Fc app > /srv/backup/app.dump
$ restic backup /srv/backup

Бэкап не существует, пока не восстановлен

Главный пункт, который пропускают все: восстановление надо репетировать. Не «однажды, когда припрёт», а по расписанию. Минимум — еженедельный restic check --read-data-subset плюс восстановление дампа во временную базу с проверкой, что она открывается.

# в cron раз в неделю:
restic check --read-data-subset=10%
restic restore latest --target /tmp/restore-test \
    --include /srv/backup/app.dump
pg_restore --list /tmp/restore-test/srv/backup/app.dump

Чек-лист