Как настроить автоматическое резервное копирование на VPS с Ubuntu и проверить восстановление данных

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

Краткий ответ: для Ubuntu удобно использовать Restic, хранить репозиторий за пределами VPS - например, в S3-совместимом хранилище, - и запускать резервирование через systemd timer. Минимальная рабочая схема включает дамп базы данных, копирование нужных каталогов, автоматическую очистку старых снимков и обязательный тест восстановления.

Перед настройкой следует определить, что именно нужно сохранить. Для сайта это обычно каталог приложения, конфигурация веб-сервера, сертификаты, файлы загрузок и база данных. Папки /proc, /sys, /dev, временные файлы и кэш в резервную копию не включают: они либо виртуальные, либо восстанавливаются заново. Отдельно стоит зафиксировать допустимый простой и объём потери данных. Если допустима потеря информации максимум за час, ежедневного запуска будет недостаточно.

Сам VPS не должен быть единственным местом хранения. Даже если используется виртуальный сервер на ubuntu, локальный архив на том же диске не спасёт при удалении сервера или повреждении файловой системы. Практичный вариант - держать оперативный архив локально для быстрого отката, а полноценные зашифрованные снимки отправлять в независимое S3-хранилище или на отдельный сервер.

Почему для этой задачи подходит Restic

Restic работает не как обычный архиватор, который каждый раз заново пакует весь каталог. Он создаёт дедуплицированные снимки: одинаковые блоки не дублируются, а данные шифруются до отправки в удалённое хранилище. Это снижает расход места и не требует передавать по сети весь сайт при каждом запуске.

Инструмент	Сильная сторона	Ограничение	Подходящий сценарий
Restic	Шифрование, дедупликация, удобное восстановление	Нужно отдельно настроить дампы баз данных	Файлы VPS и смешанные данные
rsync	Быстрое зеркалирование каталогов	Сам по себе не хранит историю изменений	Синхронизация с резервным сервером
tar и cron	Простота и доступность	Нет дедупликации, шифрование нужно организовать отдельно	Небольшие разовые архивы

Ниже используется Restic с S3-бэкендом. Названия переменных подходят и для Amazon S3, и для совместимых сервисов, но адрес конечной точки и регион зависят от конкретного провайдера. Пароль репозитория Restic нельзя путать с ключом доступа S3: это два разных секрета, и потеря пароля Restic делает зашифрованные данные непригодными для расшифровки.

Подготовка Ubuntu и секретов

Сначала установите необходимые пакеты. В актуальных версиях Ubuntu Restic обычно доступен в стандартном репозитории, однако перед рабочим внедрением желательно проверить версию в документации проекта и выбрать поддерживаемый выпуск.

sudo apt update
sudo apt install -y restic mariadb-client postgresql-client
sudo install -d -m 700 /etc/restic /var/backups/vps

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

sudo nano /etc/restic/backup.env

RESTIC_REPOSITORY=s3:https://s3.example.net/my-vps-backups
RESTIC_PASSWORD=сложная-длинная-фраза-для-restic
AWS_ACCESS_KEY_ID=идентификатор-доступа
AWS_SECRET_ACCESS_KEY=секретный-ключ
AWS_DEFAULT_REGION=eu-central-1

sudo chown root:root /etc/restic/backup.env
sudo chmod 600 /etc/restic/backup.env

Критически важно: сохраните пароль Restic в отдельном менеджере секретов или офлайн-хранилище. Резервная копия без пароля не восстанавливается. Файл с переменными не должен попадать в Git, веб-каталог или архив самого себя.

Инициализируйте репозиторий один раз. Если используется S3-совместимый сервис, проверьте корректность endpoint, bucket и прав ключа: достаточно разрешений на чтение, запись и удаление объектов внутри выделенного хранилища.

sudo bash -c 'source /etc/restic/backup.env && restic init'

После инициализации полезно проверить доступ к репозиторию:

sudo bash -c 'source /etc/restic/backup.env && restic snapshots'

Сначала - согласованные дампы баз данных

Копировать файлы работающей базы данных обычным архиватором рискованно: в момент чтения часть таблиц может измениться, а полученный набор файлов окажется логически несогласованным. Для MariaDB или MySQL применяют mysqldump, для PostgreSQL - pg_dump. Дамп складывают во временный каталог, после чего Restic включает его в снимок.

sudo install -d -m 700 /var/backups/vps/db

sudo mysqldump --single-transaction --routines --events \
  --all-databases | sudo gzip -c > /var/backups/vps/db/mysql.sql.gz

sudo -u postgres pg_dumpall | gzip -c \
  | sudo tee /var/backups/vps/db/postgresql.sql.gz > /dev/null

На сервере без одной из этих СУБД соответствующую команду нужно убрать. Для крупной PostgreSQL-базы логичнее применять собственную стратегию: отдельный pg_dump по базам, физическое резервирование или архивирование WAL. Важно также учитывать права: запуск дампа от имени root не всегда позволяет подключиться к базе, если авторизация настроена через peer или отдельного системного пользователя.

Скрипт резервного копирования

Создайте скрипт, который сначала формирует дампы, затем отправляет в репозиторий только нужные пути. В примере сохраняются конфигурации, сайт и каталог с дампами. Список необходимо адаптировать под фактическую структуру сервера.

sudo nano /usr/local/sbin/vps-backup.sh

#!/usr/bin/env bash
set -Eeuo pipefail

source /etc/restic/backup.env

/usr/local/sbin/create-db-dumps

restic backup \
  /etc/nginx \
  /etc/letsencrypt \
  /srv/www \
  /var/backups/vps/db \
  --exclude-caches \
  --tag automatic

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

restic check

Отдельный скрипт /usr/local/sbin/create-db-dumps должен содержать команды дампа и иметь режим доступа 700. Такой разнос удобен: основная процедура отвечает за отправку и политику хранения, а логика конкретной СУБД меняется независимо.

sudo chmod 700 /usr/local/sbin/vps-backup.sh
sudo chmod 700 /usr/local/sbin/create-db-dumps

Практическая рекомендация: не запускайте restic check --read-data после каждого ежедневного архива на большом репозитории. Такая проверка читает все данные и создаёт лишнюю нагрузку. Ежедневно достаточно проверки структуры, а полное чтение можно выполнять раз в неделю или по расписанию с низким приоритетом.

Автоматический запуск через systemd timer

Systemd timer удобнее традиционного cron для серверных задач: результат виден в журнале, можно задать задержку после загрузки, ограничить время выполнения и запускать пропущенную задачу после перезапуска. Создайте сервис:

sudo nano /etc/systemd/system/vps-backup.service

[Unit]
Description=Encrypted VPS backup with Restic
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/vps-backup.sh
Nice=10
IOSchedulingClass=best-effort

Теперь добавьте таймер. Вариант ниже запускает резервирование каждый день в 03:15 с допустимым случайным отклонением до 20 минут. Это снижает вероятность одновременного старта задач на нескольких серверах.

sudo nano /etc/systemd/system/vps-backup.timer

[Unit]
Description=Daily VPS backup timer

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

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now vps-backup.timer
sudo systemctl start vps-backup.service
sudo systemctl status vps-backup.service
journalctl -u vps-backup.service --no-pager

После первого запуска проверьте наличие снимка командой restic snapshots. В рабочей эксплуатации полезно настроить уведомления о ненулевом коде завершения сервиса: без мониторинга резервное копирование может перестать работать из-за заполненного bucket, истёкшего ключа или изменившегося пароля базы.

Как проверить восстановление

Проверка должна проходить не на рабочем каталоге, а во временной директории или на отдельном тестовом VPS. Сначала получите список снимков и выберите нужный идентификатор:

sudo bash -c 'source /etc/restic/backup.env && restic snapshots'

Восстановите последний снимок в отдельную папку:

sudo mkdir -p /restore-test
sudo bash -c 'source /etc/restic/backup.env && restic restore latest --target /restore-test'

Затем проверьте не только наличие файлов, но и их пригодность. Для сайта сравните количество файлов, владельцев и права доступа. Для базы распакуйте дамп в отдельный экземпляр MariaDB или PostgreSQL и выполните контрольный запрос. Например, после восстановления SQL-архива можно проверить список таблиц и наличие последних записей. Если в конфигурации есть сертификаты, убедитесь, что закрытые ключи имеют ожидаемые права, обычно 600 или более строгие ограничения.

Что проверять	Команда или действие	Признак успеха
Снимок создан	restic snapshots	Есть новый снимок с актуальной датой
Репозиторий не повреждён	restic check	Команда завершилась без ошибок
Файлы читаются	restic restore latest --target /restore-test	Каталоги и файлы открываются
База пригодна	Импорт в тестовую СУБД	Таблицы и контрольные записи доступны
Права сохранены	stat, проверка владельцев	Сервис запускается с ожидаемыми разрешениями

Памятка перед вводом в эксплуатацию

Перед тем как считать схему законченной, проверьте несколько вещей: удалённое хранилище находится в другом месте и желательно в другой зоне доступности; пароль Restic сохранён отдельно; в резервную копию попадают конфигурации и дампы, а не только пользовательские файлы; политика forget соответствует объёму диска и требованиям к сроку хранения; systemd timer действительно активен; ошибки видны в журнале или системе мониторинга; восстановление проходило на чистой тестовой среде.

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

Итог

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

Понравилась запись? Поделись с друзьями и поддержи сайт: