Резервная копия VPS Ubuntu: проверьте восстановление
Резервная копия VPS Ubuntu полезна, когда её можно получить вне сервера и восстановить ожидаемые файлы. В этом упражнении архивируются статическая страница и конфигурация Nginx, копируются на другой компьютер и проверяются без изменения работающего сайта.
Содержание
Определите границы упражнения
Нужны Bash, GNU tar, sha256sum и OpenSSH на Ubuntu либо клиенте Linux/WSL. Держите открытыми два терминала: один на сервере, второй на отдельном компьютере. Переменные сохраняются только в своей сессии. После ошибки команды остановитесь.
Пример использует два временных файла в домашнем каталоге. Он не меняет Nginx, firewall или действующий сайт; распаковка не выполняется от root. Начните с тестовых файлов. Необязательная замена ниже использует только файлы из инструкции статического HTTPS-сайта.
Для реального проекта отдельно перечислите ресурсы сайта, перенаправления, подключаемые конфигурации, DNS и зависимости. Два файла не являются полной копией машины или приложения.
Подготовьте файлы без изменения сайта
В серверном терминале создайте закрытый каталог упражнения. Конфигурация ниже — файл для архива, её не нужно включать в Nginx.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="ru"><title>Проверка восстановления</title><h1>Восстановленная статическая страница</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Каталог для упражнения: %s\n' "$backup_lab"Необязательно: вместо тестовых файлов можно взять страницу и server block из первого руководства. Исходники должны читаться вашей учётной записью. Проверьте конфигурацию на секреты и приостановите публикацию, чтобы собрать одно согласованное состояние. Для упражнения с тестовыми файлами пропустите этот блок.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"Команды читают оригиналы и заменяют только временные копии. Они не забирают закрытые ключи сертификатов или целые системные каталоги. Дополнительные файлы реального сайта нужно осознанно добавить в перечень и манифест контрольных сумм.
Создайте архив и два уровня проверки
В той же серверной сессии создайте суммы выбранных файлов, архив с относительными путями и сумму самого архива. Не меняйте содержимое во время этого шага.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Каталог экспорта на сервере: %s\n' "$backup_lab/export"В списке ожидаются site/, nginx/, два файла и SHA256SUMS. Запишите выведенный каталог экспорта. Сумма архива выявляет изменение переданных байтов; внутренний манифест проверяет файлы после распаковки.
Контрольные суммы не удостоверяют источник копии, если кто-то может подменить и данные, и ожидаемую сумму. Защищайте источник, доступ и место хранения.
Перенесите архив на отдельный компьютер
В локальном терминале задайте remote_backup точным каталогом, который вывел сервер. Замените адрес, пользователя и ключ своими данными SSH. 203.0.113.10 — адрес для документации, REPLACE — место для реального суффикса, а не результат mktemp.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Перед первым соединением подтвердите отпечаток хоста доверенным способом. При проблемах следуйте диагностике SSH, не отключая проверку ключа.
SCP защищает передачу через SSH. Сам tar.gz сжат, но не зашифрован. Защитите аккаунт и хранилище назначения, при необходимости примените шифрование хранения. Второй каталог на той же VM не является копией вне сервера.
Проверьте архив и восстановите в пустой каталог
В той же локальной сессии сначала проверьте архив. Продолжайте только после OK от sha256sum.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"При несовпадении разберите причину или повторите передачу. Не заменяйте ожидаемую сумму новой, чтобы скрыть сбой. Доверенный архив распакуйте в новый пустой каталог.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"keep-old-files отказывается заменять существующие файлы, no-same-owner не восстанавливает архивного владельца. Не меняйте назначение на / и не используйте sudo.
Ожидаются OK для site/index.html и nginx/first-site.conf, затем заголовок восстановленной страницы. Это проверка содержимого, не производственных прав, ACL, доступности службы или всех зависимостей.
Отделите возврат файлов от возврата услуги
Восстановленная конфигурация пока остаётся неактивным текстовым файлом. На отдельном сервере для восстановления проверьте пути, include, модули, права и сертификаты. Там проверьте собранную конфигурацию Nginx до reload и выполните внешний запрос HTTP/HTTPS. Проверка неизменённого старого сервера не проверяет новую копию.
Архив намеренно не содержит закрытых ключей TLS. Запланируйте перевыпуск сертификатов или их отдельную защищённую копию. Для действующей базы используйте поддерживаемый согласованный метод резервного копирования и восстановления, а не tar её активных файлов.
Снимки провайдера могут помочь, но проверьте срок хранения, зависимость от инфраструктуры и процедуру восстановления. Наличие snapshot не доказывает, что экспортированные файлы можно поднять на другой машине.
Запишите цели и результат восстановления
RPO — допустимая потеря данных, выраженная временем; RTO — целевое время возвращения услуги. Для небольшого информационного сайта можно выбрать RPO 24 часа и RTO 60 минут. Это условные цели, не измеренный результат упражнения. Ежедневное задание имеет смысл только при успешных и восстанавливаемых копиях.
Прокрутите таблицу, чтобы увидеть остальные столбцы →
| Что записать | Что это показывает |
|---|---|
| Время копии и версия проекта | Какое состояние можно восстановить |
| Независимое место и срок хранения | Где и как долго доступна копия |
| Суммы архива и файлов | Совпали ли выбранные байты |
| Начало и завершение попытки | Время выполненных шагов |
| Недостающие файлы, права и зависимости | Что ещё нужно для запуска |
| Внешняя проверка HTTPS на новом сервере | Вернулась ли работа сайта |
Измерьте всю замену: доступ, создание VM, конфигурацию, файлы, сертификаты и DNS. Быстрая локальная распаковка не равна сроку устранения аварии. Сохраняйте нужные точки восстановления и реагируйте на ошибки заданий. Расходы на хранение и помощь с возвратом данных учитывайте в стоимости хостинга.
Вопросы и ответы
Архив этих файлов восстанавливает весь VPS?
Нет. Упражнение проверяет два файла статического сайта. ОС, базы, службы, права, DNS и сертификаты требуют отдельного плана.
tar.gz защищает секретные данные?
Нет. Сжатие не является шифрованием. SCP защищает передачу, но файлам на дисках по обе стороны нужны контроль доступа и подходящая защита.
Когда повторять проверку восстановления?
По графику, согласованному с риском и сроками хранения, а также после важных изменений приложения, данных или способа копирования.