Backup • Linux • VPS • Восстановление • restic

Проверка и восстановление backup Linux VPS: практическая тренировка

Опубликовано 15 июля 2026 7 мин чтения Урок 5 из 6

Успешное сообщение «backup completed» доказывает только запись данных. Оно не подтверждает наличие нужных файлов, правильность дампа базы, сохранность ключа шифрования и способность команды вернуть сервис в работу. Резервная копия становится надёжной только после регулярной проверки и восстановления в изолированную среду.

Определите критерии успеха

До теста запишите:

какие сайты, базы и службы должны восстановиться;
целевой RPO — насколько свежей должна быть точка;
целевой RTO — сколько времени есть до запуска;
какие внешние зависимости нужны: DNS, object storage, SMTP, API-ключи;
кто принимает решение о переключении трафика.

Без критериев тест превращается в проверку нескольких случайных файлов.

Проверьте доступ к репозиторию и ключу

Для restic:

sudo sh -c '. /etc/restic/vps.env; restic snapshots'
sudo sh -c '. /etc/restic/vps.env; restic check'

Тест выполняйте тем же способом, который будет доступен при аварии. Если пароль существует только в файле на исходном VPS, удаление сервера сделает удалённый репозиторий бесполезным.

Отдельно подтвердите наличие:

пароля или ключа шифрования в защищённом хранилище;
учётных данных SFTP/S3;
инструкции установки restic совместимой версии;
данных MFA и аварийных кодов.

Проверьте структуру и данные restic

restic check проверяет внутреннюю согласованность репозитория. Для периодической глубокой проверки используйте доступные в вашей версии параметры чтения данных, учитывая стоимость трафика и объём:

sudo sh -c '. /etc/restic/vps.env; restic check --read-data-subset=10%'

Раз в более длительный период полезно прочитать все данные, если объём и backend позволяют. Проверка должна выполняться не одновременно с тяжёлой нагрузкой без оценки влияния на диск и сеть.

Восстановите снимок в отдельный каталог

Никогда не начинайте тест с перезаписи рабочего /etc или /var/www.

sudo install -d -m 700 /srv/restore-test
sudo sh -c '. /etc/restic/vps.env; restic restore latest \
  --target /srv/restore-test'

Посмотрите восстановленную структуру:

sudo find /srv/restore-test -maxdepth 3 -type d | sort | head -100
sudo du -sh /srv/restore-test
sudo find /srv/restore-test -xdev -type f | wc -l

Сверьте критичные файлы

Сравнение конфигурации:

sudo diff -ruN \
  /etc/nginx \
  /srv/restore-test/etc/nginx | less

Контрольные суммы отдельного файла:

sudo sha256sum \
  /etc/nginx/nginx.conf \
  /srv/restore-test/etc/nginx/nginx.conf

Различие не всегда ошибка: backup может быть старше текущей конфигурации. Важно понимать, какой снимок выбран и какие изменения после него будут потеряны.

Проверьте права и владельцев

sudo stat \
  /srv/restore-test/etc/ssh/sshd_config \
  /srv/restore-test/var/www \
  /srv/restore-test/root

Некоторые способы копирования не сохраняют ACL, extended attributes, capabilities или sparse-файлы. Для сервисов проверьте:

sudo getfacl -p /srv/restore-test/var/www 2>/dev/null | head
sudo getcap -r /srv/restore-test 2>/dev/null | head
sudo getfattr -R -d /srv/restore-test/etc 2>/dev/null | head

Проверьте конфигурации без запуска

Не все программы умеют тестировать конфигурацию с альтернативным корнем, но основные файлы можно скопировать во временную VM или контейнер. На отдельном тестовом VPS:

sudo nginx -t
sudo sshd -t
sudo php-fpm8.5 -t 2>/dev/null || true
sudo systemd-analyze verify \
  /etc/systemd/system/*.service 2>/dev/null

Для Docker Compose:

docker compose -f /srv/app/compose.yml config --quiet

Проверка синтаксиса не доказывает доступность секретов, DNS и внешних API, но быстро выявляет неполную копию.

Тест восстановления MariaDB

Создайте отдельную тестовую базу. Не импортируйте дамп поверх production.

sudo mariadb -e \
"DROP DATABASE IF EXISTS restore_test;
 CREATE DATABASE restore_test CHARACTER SET utf8mb4;"

Если дамп содержит одну базу без CREATE DATABASE:

zcat /srv/restore-test/var/backups/vps/databases/appdb.sql.gz \
  | sudo mariadb restore_test

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

Проверка:

sudo mariadb restore_test -e 'SHOW TABLES;'
sudo mariadb restore_test -e \
"SELECT table_name, table_rows
 FROM information_schema.tables
 WHERE table_schema='restore_test'
 ORDER BY table_name;"

Выполните прикладную проверку: найдите известную запись, создайте тестовую транзакцию, запустите миграции в режиме проверки.

Тест восстановления PostgreSQL

sudo -u postgres dropdb --if-exists restore_test
sudo -u postgres createdb restore_test
sudo -u postgres pg_restore \
  --exit-on-error \
  --no-owner \
  --dbname=restore_test \
  /srv/restore-test/var/backups/vps/databases/postgresql-appdb.dump

Проверка:

sudo -u postgres psql restore_test -c '\dt'
sudo -u postgres psql restore_test -c \
"SELECT schemaname, relname, n_live_tup
 FROM pg_stat_user_tables
 ORDER BY relname;"

Custom dump может содержать код, созданный владельцем исходной базы. Восстанавливайте данные только из доверенного источника и в изолированном окружении.

Проверьте приложение, а не только таблицы

Для тестового сайта:

Создайте временное доменное имя или запись в локальном hosts.
Запустите копию приложения с восстановленной базой.
Отключите реальную отправку почты, платежи и внешние webhooks.
Проверьте вход, чтение и запись данных, загрузку файлов и фоновые задания.
Сравните число ключевых объектов с production.

Именно прикладной тест выявляет отсутствующий volume, секрет, ключ шифрования или отдельную таблицу.

Полная тренировка восстановления на новом VPS

Не реже нескольких раз в год проведите полный сценарий:

Создайте чистый VPS у того же или другого провайдера.
Установите поддерживаемую ОС и минимальные пакеты.
Получите доступ к удалённому backup без исходного сервера.
Восстановите конфигурацию, файлы и базы.
Исправьте сетевые адреса и секреты окружения.
Проверьте конфигурации до запуска.
Запустите службы в правильном порядке.
Выполните внешний health-check.
Зафиксируйте реальное время восстановления.

Не переключайте публичный DNS во время учебного теста. Используйте временное имя, локальный hosts или закрытую сеть.

Порядок запуска служб

Типовая последовательность:

Сеть, DNS и точное время.
Хранилища и volumes.
MariaDB/PostgreSQL.
Очереди и cache.
Приложение и фоновые workers.
Nginx/reverse proxy.
Timers, cron и мониторинг.

Не включайте все cron-задачи до проверки базы: они могут отправить письма, удалить данные по retention или повторно обработать старую очередь.

Проверка сертификатов и DNS

В backup могут находиться старые ACME-сертификаты. На тестовом сервере не запускайте массовое получение сертификатов для production-доменов. Сначала проверьте конфигурацию с временным сертификатом или staging ACME.

Перед реальным переключением:

dig A example.net +short
dig AAAA example.net +short
curl -I --resolve example.net:443:NEW_IP \
  https://example.net/

--resolve позволяет проверить новый сервер до изменения DNS.

Сформируйте отчёт теста

После каждой тренировки сохраните:

ID и дату восстановленного snapshot;
контрольные суммы и результат repository check;
время каждого этапа;
отсутствующие файлы и секреты;
ошибки дампов и миграций;
фактический RPO/RTO;
изменения в инструкции и backup-скриптах;
дату следующего теста.

Безопасная очистка теста

Восстановленная копия содержит production-данные и секреты. После проверки:

sudo rm -rf --one-file-system /srv/restore-test
sudo -u postgres dropdb --if-exists restore_test
sudo mariadb -e 'DROP DATABASE IF EXISTS restore_test;'

Удалите временные VPS, object-storage credentials, DNS-записи и локальные копии дампов. Если данные персональные, соблюдайте внутреннюю политику доступа и уничтожения.

Итоговый критерий

Backup считается рабочим, если независимый администратор может получить к нему доступ без исходного сервера, восстановить выбранную точку, запустить приложение и уложиться в заявленные RPO/RTO. Всё остальное — лишь предположение о наличии резервной копии.