Перейти к содержанию

Restic: проверять восстановление, а не только бэкап

Бэкапы · VPS
Не изучено

Добавлено 2026-10-11. Пример рассчитан на Linux и установленный Restic.

Проблема

Cron завершился успешно, но после потери VPS выясняется, что в копию не попали конфиги, недоступен пароль репозитория или восстановленное приложение не запускается.

Решение

Хранить копию вне исходного VPS и регулярно восстанавливать выбранный снимок в отдельный каталог. restic check проверяет структуру репозитория; --read-data дополнительно читает все сохранённые данные. Ни одна из этих проверок не подтверждает работоспособность приложения после восстановления.

Пример

Предварительно создать удалённый репозиторий, настроить SSH-доступ и файл пароля с правами 0600. Пароль и SSH-ключ должны иметь отдельную резервную копию. Адрес и пути ниже заменить своими; restic init нужен только при создании нового репозитория.

export RESTIC_REPOSITORY='sftp:backup@backup.example.com:/srv/restic/devops-kb'
export RESTIC_PASSWORD_FILE='/etc/restic/devops-kb.password'

# Пользователь задания должен иметь доступ к этим каталогам.
restic backup /srv/devops-kb /etc/nginx --tag devops-kb
restic snapshots --tag devops-kb
restic check --read-data

Учение восстановления — отдельный скрипт. Выбрать ID снимка из списка выше, проверить его дату, пути и хост. Полное чтение репозитория требует времени и исходящего трафика.

#!/usr/bin/env bash
set -euo pipefail
: "${SNAPSHOT_ID:?Укажите ID нужного снимка Restic}"
: "${RESTIC_REPOSITORY:?Укажите репозиторий}"
: "${RESTIC_PASSWORD_FILE:?Укажите файл пароля}"

umask 077
restore_dir=$(mktemp -d /var/tmp/devops-kb-restore.XXXXXX)
started_at=$(date +%s)
restic restore "$SNAPSHOT_ID" --target "$restore_dir"
test -s "$restore_dir/srv/devops-kb/mkdocs.yml"
test -d "$restore_dir/etc/nginx"
printf 'Файлы восстановлены за %s с в %s\n' \
  "$(( $(date +%s) - started_at ))" "$restore_dir"

Это проверяет наличие файлов, но ещё не весь результат: собрать сайт из восстановленного проекта и проверить конфигурацию Nginx в изолированном окружении. Для БД сначала нужен согласованный дамп или подходящий способ резервирования; копирование файлов работающей БД само по себе этого не гарантирует. Каталог учения оставить до проверки результата, затем удалить вручную.

Когда применять

Для конфигурации VPS, исходников и данных, которые нельзя восстановить одним развёртыванием из Git. Для devops-kb отдельно определить, нужны ли копии .business/ и других файлов вне Git.

Источник

Как применить у себя

  1. Определить допустимую потерю данных (RPO) и время восстановления (RTO).
  2. Провести учение на другом хосте с доступом к резервной копии ключей.
  3. Записать ID и возраст снимка, время до работающего сайта, недостающие файлы.
  4. Отметить «Изучено» после успешного восстановления и назначения следующей проверки. Время копирования файлов из примера — только часть RTO.