Для надежного резервного копирования VPS недостаточно хранить единственные архивы на том же сервере: при сбое диска, удалении VPS или компрометации системы можно потерять одновременно и рабочие данные, и локальные бэкапы. Поэтому копии будем отправлять во внешнее S3-совместимое Object Storage через Restic.
В руководстве настроим:
- Отдельный S3-бакет для резервных копий;
- Безопасное хранение ключей доступа и пароля Restic;
- Шифрование бэкапов средствами Restic;
- Резервное копирование файлов VPS и дампа базы данных;
- Автоматический запуск по расписанию;
- Retention policy и удаление устаревших snapshots;
- Проверку целостности репозитория;
- Обязательное тестовое восстановление файлов и базы данных из внешнего хранилища.
В результате резервные копии будут храниться независимо от VPS, а их пригодность к восстановлению будет проверена на практике.
Как устроено резервное копирование VPS через Restic
Резервная копия данных с VPS должна пережить не только случайное удаление файла, но и более серьезные сценарии: повреждение диска, ошибочное удаление виртуальной машины, сбой инфраструктуры или компрометацию самого сервера. Поэтому в этой схеме резервные данные будем хранить не рядом с оригиналом, а во внешнем S3-совместимом Object Storage.
Для работы с удаленным хранилищем используем Restic — утилиту резервного копирования, которая поддерживает S3 и S3-совместимые сервисы, дедупликацию и шифрование данных. Restic передает в репозиторий только необходимые данные и шифрует содержимое резервных копий до отправки в хранилище.
Почему резервная копия должна храниться вне VPS
Если создать архив сайта или базы данных, например, в /backup на том же VPS, это защитит только от части пользовательских ошибок, хотя это и удобно использовать для оперативного восстановления информации. Но при потере самой виртуальной машины исчезнет и оригинал, и размещенный рядом архив.
Внешняя копия решает эту проблему:
- Рабочие данные остаются на VPS;
- Резервные копии отправляются в отдельное Object Storage;
- Удаление или повреждение VPS не уничтожает S3-репозиторий;
- Восстановление можно выполнить уже на другой виртуальной машине.
Такой подход также удобен при миграции: новый сервер не обязан иметь доступ к дискам старого VPS — ему достаточно получить доступ к резервному репозиторию.
При этом Object Storage не заменяет саму политику резервного копирования. Помимо внешнего расположения копий необходимо настроить расписание, retention policy и регулярно проверять возможность восстановления.
Как Restic работает с S3-совместимым Object Storage
Restic создает внутри бакета собственный репозиторий. Пользователь работает не с отдельными .tar.gz-архивами, а со snapshots — состояниями выбранных файлов на момент выполнения резервного копирования.
Для подключения используются:
- Адрес S3 endpoint;
- Имя бакета;
- Access Key;
- Secret Key;
- Пароль репозитория Restic.
Для S3-совместимого сервиса репозиторий задается в формате: s3:https://s3.example.com/vps-backups
Конкретный endpoint зависит от используемого Object Storage.
Учетные данные S3 передаются через стандартные переменные:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
Restic официально поддерживает Amazon S3 и S3-совместимые хранилища и использует соответствующие учетные данные для доступа к бакету.
Важная особенность Restic — встроенное шифрование. При создании репозитория задается отдельный пароль, необходимый для расшифровки резервных данных. Даже если кто-либо получит доступ к содержимому бакета, сами файлы нельзя будет прочитать без ключевой информации Restic. Потеря пароля, наоборот, означает потерю возможности восстановить данные, поэтому его необходимо хранить отдельно и надежно.
Что будем копировать: файлы и базу данных
В примере будем резервировать два типа данных:
/var/www/example
/var/backups/database
Первый каталог представляет файлы приложения или сайта.
База данных требует отдельного подхода. Вместо простого копирования файлов PostgreSQL или MySQL непосредственно из рабочего каталога СУБД сначала создается логический дамп: /var/backups/database/app.sql
Затем Restic включает этот файл в общий snapshot.
Сценарий будет выглядеть так:
После успешного резервного копирования временный SQL-дамп можно удалить с VPS. Постоянная резервная копия останется во внешнем Object Storage.
Подготовка S3-совместимого хранилища
Перед установкой Restic необходимо подготовить место назначения. Создадим отдельный бакет и отдельные учетные данные специально для резервного копирования.
Не стоит использовать для backup те же ключи, которыми управляются другие бакеты или вся инфраструктура Object Storage: в случае утечки последствия будут значительно шире.
Создание отдельного бакета для резервных копий
В панели используемого S3-совместимого Object Storage создайте новый бакет, например: vps-restic-backups
Бакет предназначен исключительно для Restic. Размещать в нем файлы сайта, пользовательские загрузки или другие данные приложения не требуется.
Если провайдер позволяет выбрать регион, желательно использовать регион, подходящий по требованиям к географическому размещению и стоимости хранения.
Для действительно внешней резервной копии желательно, чтобы бакет не зависел от диска или файловой системы того же VPS, хорошей практикой будет использовать S3 в другом облачном провайдере, чтобы не зависеть от единственного поставщика. Amazon S3 и совместимые объектные хранилища предназначены в том числе для сценариев backup и restore.
После создания запишите:
Bucket: vps-restic-backups
S3 endpoint: https://s3.example.com
Endpoint у разных провайдеров отличается, поэтому в дальнейших командах необходимо использовать адрес своего Object Storage.
Создание ключей доступа к Object Storage
Следующий шаг — создать отдельную пару учетных данных для Restic.
Обычно S3-совместимый API использует два значения:
- Access Key
- Secret Key
Access Key идентифицирует пользователя или сервисную учетную запись, а Secret Key используется для подписания запросов.
Эти данные понадобятся Restic на VPS:
AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
Secret Key следует сохранить сразу после создания: некоторые панели показывают его только один раз.
Для резервного копирования лучше создавать отдельную сервисную учетную запись, например: restic-backup
В таком случае ключ можно заменить или отозвать независимо от других приложений.
Ограничение доступа ключей только нужным бакетом
Учетным данным Restic не нужен доступ ко всему Object Storage. Им достаточно работать только с бакетом резервных копий.
Если используемый сервис поддерживает IAM-подобные политики, разрешения следует ограничить ресурсами:
vps-restic-backups
vps-restic-backups/*
Например, для AWS S3 политика ограниченного доступа может включать операции с конкретным бакетом и объектами внутри него. AWS отдельно рекомендует применять принцип least privilege — предоставлять только те действия и ресурсы, которые действительно необходимы задаче.
Упрощенно политика может выглядеть следующим образом:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::vps-restic-backups"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::vps-restic-backups/*"
]
}
]
}
Для конкретного S3-совместимого провайдера набор разрешений и интерфейс создания политики могут отличаться, но принцип остается тем же: backup-ключ должен работать только с выделенным бакетом.
После настройки убедитесь, что бакет создан и доступен в панели Object Storage.
Установка и подготовка Restic на VPS
После создания внешнего хранилища можно переходить к VPS. Здесь установим Restic и подготовим конфигурацию так, чтобы S3-ключи и пароль репозитория не приходилось указывать непосредственно в командах резервного копирования.
Установка Restic
На Ubuntu сначала обновите список пакетов: sudo apt update
Установите Restic: sudo apt install -y restic
Проверьте версию: restic version
После установки Restic не требует отдельного постоянно работающего сервера или демона: резервное копирование запускается отдельными командами и позднее будет автоматизировано через systemd.
Настройка переменных для подключения к S3
Чтобы не указывать endpoint и ключи в каждой команде вручную, создадим отдельный конфигурационный файл: sudo nano /etc/restic.env
Добавьте:
AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
RESTIC_REPOSITORY=s3:https://s3.example.com/vps-restic-backups
RESTIC_PASSWORD_FILE=/etc/restic-password
Замените:
YOUR_ACCESS_KEY
YOUR_SECRET_KEY
на параметры своего Object Storage.
Переменная RESTIC_REPOSITORY позволяет не передавать параметр -r при каждом запуске Restic. Для автоматизированной работы Restic также поддерживает получение пароля через файл, указанный в RESTIC_PASSWORD_FILE.
Для загрузки конфигурации в текущую shell-сессию позже можно использовать:
set -a
source /etc/restic.env
set +a
После этого команды restic будут использовать указанный удаленный репозиторий и учетные данные.
Безопасное хранение S3-ключей и пароля Restic
S3 Secret Key и пароль шифрования не стоит размещать непосредственно в backup-скрипте. Если скрипт попадет в Git-репозиторий или будет доступен другим пользователям VPS, вместе с ним утекут учетные данные, и как следствие - доступ к резервным копиям с чувствительной информацией.
Поэтому конфигурацию храним отдельно: /etc/restic.env
А пароль Restic — еще в одном файле: sudo nano /etc/restic-password
В него добавьте длинный случайный пароль одной строкой, например: CHANGE_THIS_TO_A_LONG_RANDOM_PASSWORD
Этот пароль используется для шифрования репозитория и потребуется для восстановления данных. Его копию следует сохранить за пределами VPS — например, в менеджере паролей или другом защищенном хранилище. Потеря единственной копии пароля сделает резервные данные недоступными.
Теперь ограничьте доступ к обоим файлам:
sudo chown root:root /etc/restic.env /etc/restic-password
sudo chmod 600 /etc/restic.env /etc/restic-password
Проверить права можно командой: sudo ls -l /etc/restic.env /etc/restic-password
Результат должен выглядеть примерно так:
-rw------- 1 root root ... /etc/restic-password
-rw------- 1 root root ... /etc/restic.env
Создание репозитория Restic в Object Storage
После установки Restic и подготовки переменных окружения можно создать удаленный backup-репозиторий внутри S3-бакета. Именно туда Restic будет записывать snapshots, служебные индексы и зашифрованные блоки данных.
Инициализация удаленного репозитория
Сначала загрузите переменные из файла конфигурации:
set -a
source /etc/restic.env
set +a
Теперь инициализируйте репозиторий: sudo -E restic init
Restic создаст необходимую структуру внутри указанного в RESTIC_REPOSITORY бакета. Пароль будет прочитан из файла, заданного через RESTIC_PASSWORD_FILE.
При успешной инициализации появится сообщение о создании нового репозитория.
Повторно выполнять restic init для того же репозитория не требуется. После инициализации все последующие команды работают уже с существующим хранилищем.
Проверка подключения к S3-хранилищу
Проверить доступность репозитория можно командой: sudo -E restic snapshots
Сразу после создания список snapshots будет пустым, но Restic должен успешно подключиться к бакету и прочитать структуру репозитория.
Дополнительно можно выполнить: sudo -E restic check
Команда проверяет внутреннюю структуру репозитория и позволяет убедиться, что Restic действительно может обращаться к данным в Object Storage.
После этого удаленное хранилище готово к работе. Теперь можно переходить к созданию первой резервной копии с самого VPS.
Резервное копирование файлов VPS
Копировать всю файловую систему сервера целиком обычно не требуется. В backup имеет смысл включать данные, которые действительно понадобятся при восстановлении: файлы приложений, пользовательские загрузки, конфигурацию сервисов и другие важные каталоги.
Выбор каталогов для резервного копирования
Для примера предположим, что приложение находится в: /var/www/example
Создадим тестовый каталог и несколько файлов:
sudo mkdir -p /var/www/example
echo "Application data" | sudo tee /var/www/example/index.txt
echo "Important configuration" | sudo tee /var/www/example/config.txt
Перед созданием backup полезно проверить содержимое: sudo find /var/www/example -maxdepth 2 -type f
В реальном проекте можно резервировать сразу несколько каталогов, например:
/var/www/example
/etc/nginx
/etc/systemd/system
При этом следует учитывать, что резервная копия должна содержать именно полезные для восстановления данные, а не весь набор временных файлов ОС.
Исключение временных и ненужных файлов
Кэши, журналы разработки, временные архивы и другие легко восстанавливаемые данные лучше исключить. Это уменьшает размер snapshots и количество ненужных изменений между резервными копиями.
Создадим файл исключений: sudo nano /etc/restic-excludes
Например:
*.tmp
*.cache
__pycache__
node_modules
.cache
После сохранения ограничим его обычными системными правами:
sudo chown root:root /etc/restic-excludes
sudo chmod 644 /etc/restic-excludes
Restic позволяет передавать такой файл через параметр --exclude-file. Исключения применяются до отправки файлов в backup.
Создание первой резервной копии
Убедитесь, что переменные Restic загружены:
set -a
source /etc/restic.env
set +a
Создайте backup:
sudo -E restic backup /var/www/example \
--exclude-file=/etc/restic-excludes \
--tag files
Restic просканирует каталог, определит новые данные, зашифрует их и передаст в удаленный S3-репозиторий.
После завершения будет показана статистика: количество обработанных файлов, объем добавленных данных и идентификатор snapshot.
Проверим список: sudo -E restic snapshots
В нем должна появиться первая запись с тегом files.
При необходимости можно посмотреть содержимое последнего snapshot: sudo -E restic ls latest
Повторные резервные копии того же каталога обычно выполняются быстрее и занимают меньше дополнительного места, поскольку Restic использует дедупликацию и не хранит повторно идентичные блоки данных.
Резервное копирование базы данных
Файлы приложения — только часть данных. Если сервис использует базы данных, например PostgreSQL или MySQL, то необходимо отдельно позаботиться и о них.
Прямое копирование файлов работающей СУБД может привести к неконсистентной копии. Для небольших и средних проектов проще сначала создать логический дамп средствами самой базы данных, а затем отправить этот файл в Restic.
Создание дампа PostgreSQL или MySQL
Для PostgreSQL используется pg_dump.
Например:
sudo mkdir -p /var/backups/database
sudo chmod 700 /var/backups/database
Создание дампа: sudo -u postgres pg_dump app_db > /var/backups/database/app.sql
Если используется отдельный пользователь PostgreSQL: pg_dump -h 127.0.0.1 -U app_user app_db > /var/backups/database/app.sql
Для MySQL или MariaDB аналогичная операция выполняется через mysqldump: mysqldump -u app_user -p app_db > /var/backups/database/app.sql
В обоих случаях результатом становится обычный SQL-файл, который затем можно резервировать вместе с другими данными.
Проверить его наличие можно командой: sudo ls -lh /var/backups/database/app.sql
Добавление дампа базы данных в резервную копию
После создания дампа снова загружаем окружение Restic:
set -a
source /etc/restic.env
set +a
Добавляем каталог с дампом в удаленный репозиторий:
sudo -E restic backup /var/backups/database \
--tag database
После успешного завершения проверим snapshots: sudo -E restic snapshots
Теперь в списке будут как минимум две резервные копии с разными тегами:
files
database
Можно также проверить содержимое последнего snapshot базы данных: sudo -E restic ls latest
В списке должен присутствовать: /var/backups/database/app.sql
Удаление временного локального дампа после backup
После того как Restic успешно передал дамп в удаленный S3-репозиторий, локальный файл больше не обязан постоянно храниться на VPS.
Удалите его: sudo rm -f /var/backups/database/app.sql
Проверить каталог можно командой: sudo ls -la /var/backups/database
Это особенно важно, если дампы создаются регулярно: без очистки они будут накапливаться на локальном диске и постепенно занимать свободное место.
В автоматизированной схеме удаление лучше выполнять только после успешной команды restic backup. Если отправка данных завершилась ошибкой, дамп стоит оставить до следующей попытки, чтобы не потерять подготовленную резервную копию.
Автоматизация резервного копирования
Ручной запуск подходит для первой проверки, но регулярные резервные копии должны создаваться автоматически. Для этого вынесем последовательность действий в отдельный скрипт и будем запускать его по расписанию через systemd timer.
В скрипт включим создание дампа базы данных, резервное копирование файлов и дампа через Restic, а также удаление временного SQL-файла только после успешной отправки данных в Object Storage.
Создание backup-скрипта
Создайте файл: sudo nano /usr/local/sbin/restic-backup.sh
Добавьте:
#!/bin/bash
set -euo pipefail
set -a
source /etc/restic.env
set +a
BACKUP_DIR="/var/backups/database"
DUMP_FILE="$BACKUP_DIR/app.sql"
mkdir -p "$BACKUP_DIR"
chmod 700 "$BACKUP_DIR"
echo "Creating database dump..."
sudo -u postgres pg_dump app_db > "$DUMP_FILE"
echo "Backing up application files..."
restic backup /var/www/example \
--exclude-file=/etc/restic-excludes \
--tag files
echo "Backing up database dump..."
restic backup "$BACKUP_DIR" \
--tag database
echo "Removing local database dump..."
rm -f "$DUMP_FILE"
echo "Backup completed successfully"
Конструкция: set -euo pipefail
заставляет скрипт завершиться при ошибке команды, обращении к неопределенной переменной или ошибке внутри pipeline. Это важно для резервного копирования: если, например, pg_dump или Restic завершатся неуспешно, скрипт не должен продолжать выполнение так, будто backup создан.
Сделайте файл исполняемым: sudo chmod 700 /usr/local/sbin/restic-backup.sh
Перед автоматизацией обязательно проверьте его вручную: sudo /usr/local/sbin/restic-backup.sh
При нормальной работе в конце появится: Backup completed successfully
Так мы сначала подтверждаем саму логику резервного копирования и только затем передаем управление systemd.
Настройка запуска по расписанию через systemd timer
Для запуска по расписанию можно использовать crontab,но мы сделаем через systemd. Нам понадобятся два unit-файла: service описывает команду резервного копирования, а timer определяет, когда ее выполнять.
Создайте сервис: sudo nano /etc/systemd/system/restic-backup.service
Добавьте:
[Unit]
Description=Restic VPS backup to S3-compatible storage
After=network-online.target postgresql.service
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-backup.sh
Type=oneshot подходит для задач, которые запускаются, выполняют набор действий и завершаются. Постоянно работающий процесс для Restic не требуется.
Теперь создайте timer: sudo nano /etc/systemd/system/restic-backup.timer
Например, для ежедневного запуска в 03:00:
[Unit]
Description=Daily Restic backup
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=restic-backup.service
[Install]
WantedBy=timers.target
Параметр Persistent=true полезен, если VPS был выключен в запланированный момент. После следующего запуска systemd сможет выполнить пропущенную задачу.
Перечитайте конфигурацию: sudo systemctl daemon-reload
Активируйте timer: sudo systemctl enable --now restic-backup.timer
Проверить расписание можно командой: systemctl list-timers --all | grep restic-backup
В выводе будет указано время следующего и предыдущего запуска.
Проверка выполнения резервного копирования по расписанию
Ждать наступления 03:00 для проверки необязательно. Service можно запустить вручную тем же способом, которым его будет вызывать timer: sudo systemctl start restic-backup.service
После завершения проверьте статус: sudo systemctl status restic-backup.service --no-pager
Для oneshot-сервиса после успешного выполнения нормально увидеть состояние вроде:
Active: inactive (dead)
при наличии:
status=0/SUCCESS
Более подробно результат можно посмотреть в журнале: sudo journalctl -u restic-backup.service -n 50 --no-pager
Затем убедитесь, что появились новые snapshots:
set -a
source /etc/restic.env
set +a
sudo -E restic snapshots
Таким образом дальнейшее создание копий уже не требует ручного входа на VPS: systemd будет запускать тот же проверенный скрипт по установленному расписанию.
Настройка retention policy
Регулярный backup быстро создаст десятки или сотни snapshots. Хранить каждую копию бесконечно обычно нет смысла, поэтому Restic позволяет определить политику хранения и автоматически удалять устаревшие snapshots.
Retention policy отвечает не за создание копий, а за то, какие из уже созданных версий должны оставаться доступными для восстановления.
Сколько ежедневных, еженедельных и ежемесячных копий хранить
Конкретная схема зависит от частоты изменений и требований проекта. Для небольшого VPS можно использовать, например:
7 ежедневных копий
4 еженедельные копии
6 ежемесячных копий
Такой вариант дает подробную историю за последнюю неделю и одновременно сохраняет несколько более старых точек восстановления.
Для Restic это выражается параметрами:
--keep-daily 7
--keep-weekly 4
--keep-monthly 6
Важно учитывать, что Restic использует дедупликацию, поэтому каждый snapshot не обязательно занимает объем, равный полному размеру исходных данных. Неизменившиеся блоки повторно не сохраняются.
Удаление старых snapshots через forget
Сначала полезно посмотреть, какие snapshots Restic удалил бы согласно политике, не выполняя реального удаления:
sudo -E restic forget \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
--dry-run
--dry-run позволяет проверить результат политики без изменения репозитория.
Если список выглядит корректно, выполните команду без этого параметра:
sudo -E restic forget \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6
forget удаляет ссылки на snapshots, которые больше не соответствуют политике хранения.
Само место в Object Storage при этом может освободиться не сразу: неиспользуемые блоки данных еще остаются внутри репозитория.
Освобождение места через prune
Для физического удаления данных, которые больше не принадлежат ни одному сохраненному snapshot, используется: sudo -E restic prune
Restic анализирует содержимое репозитория и удаляет ненужные блоки.
Часто обе операции объединяют:
sudo -E restic forget \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
--prune
Для небольшого репозитория такой вариант удобен, однако prune может создавать дополнительную нагрузку и выполнять значительное количество операций в Object Storage. Поэтому на крупных хранилищах его можно запускать реже, например раз в неделю или месяц.
После применения политики снова выведите список: sudo -E restic snapshots
В нем останутся только snapshots, которые соответствуют заданным правилам хранения. Оптимально это использовать вместе с политиками самого S3-бакета, чтоб получить неизменяемые резервные копии (например неделю можно только добавлять файлы, но не удалять) - если злодей получит доступ к кредам Restic, он всё равно не сможет удалить актуальные данные. Но эта настройка зависит от S3-провайдера и останется за рамками этого руководства.
Retention policy можно добавить в тот же backup-скрипт или вынести в отдельный systemd timer. Второй вариант удобнее, если резервные копии создаются ежедневно, а prune требуется выполнять значительно реже.
Проверка резервных копий
Наличие файлов в S3-бакете еще не гарантирует, что из них действительно получится восстановить данные. Поэтому резервный репозиторий необходимо периодически проверять средствами самого Restic.
Такая проверка дополняет тестовое восстановление, которое выполним на следующем этапе.
Просмотр доступных snapshots
Для вывода всех сохраненных точек восстановления выполните:
set -a
source /etc/restic.env
set +a
sudo -E restic snapshots
Для каждого snapshot Restic показывает идентификатор, время создания, hostname, теги и сохраненные пути.
Например, по тегам можно отдельно просмотреть файловые копии: sudo -E restic snapshots --tag files
И snapshots базы данных: sudo -E restic snapshots --tag database
Такая маркировка упрощает поиск нужной точки восстановления, особенно если один репозиторий используется для нескольких типов данных.
Содержимое конкретного snapshot можно посмотреть командой: sudo -E restic ls latest
Проверка целостности репозитория через restic check
Для проверки структуры репозитория используется: sudo -E restic check
Restic проверяет метаданные, ссылки между объектами и корректность структуры репозитория.
Для более глубокой проверки можно дополнительно читать данные из хранилища: sudo -E restic check --read-data
Такая проверка требует больше времени и трафика, поскольку Restic фактически считывает сохраненные данные из Object Storage.
На крупных репозиториях можно проверять только часть данных: sudo -E restic check --read-data-subset=10%
Это позволяет регулярно контролировать состояние хранилища без полного чтения всего backup-набора при каждом запуске.
Успешный restic check подтверждает целостность структуры репозитория, но окончательной проверкой остается реальное восстановление. Именно поэтому в следующем разделе файлы будут извлечены из S3 в отдельный каталог и проверены независимо от оригиналов на VPS.
Тестовое восстановление из S3
Успешное создание snapshots и даже команда restic check еще не доказывают, что резервная копия пригодна для практического восстановления. Поэтому backup-процесс необходимо хотя бы периодически проверять полным циклом: получить данные обратно из внешнего S3-хранилища, открыть восстановленные файлы и убедиться, что дамп базы данных также доступен.
Проверку лучше проводить в отдельном каталоге. Так восстановленные данные не будут перезаписывать рабочие файлы на VPS, а результат можно будет сравнить с оригиналом.
Создание отдельного каталога для восстановления
Создайте тестовый каталог: sudo mkdir -p /var/restore-test
Ограничьте доступ к нему: sudo chmod 700 /var/restore-test
Перед восстановлением загрузите конфигурацию Restic:
set -a
source /etc/restic.env
set +a
Посмотрите доступные snapshots: sudo -E restic snapshots
Для восстановления файлов приложения можно выбрать последний snapshot с соответствующим тегом: sudo -E restic snapshots --tag files
Это позволяет восстановить именно файловую резервную копию, не ориентируясь только на время создания остальных snapshots.
Восстановление файлов из последнего snapshot
Восстановим последний snapshot с тегом files в тестовый каталог:
sudo -E restic restore latest \
--tag files \
--target /var/restore-test
Restic воссоздаст внутри target исходную структуру каталогов. Если в snapshot находился путь /var/www/example восстановленные файлы появятся здесь: /var/restore-test/var/www/example
Исходные файлы приложения при этом не изменяются. Это позволяет безопасно проверить резервную копию даже на работающем VPS.
Проверка восстановленных файлов
Посмотрите содержимое восстановленного каталога: sudo find /var/restore-test/var/www/example -maxdepth 2 -type f
Для тестовых файлов можно проверить и содержимое: sudo cat /var/restore-test/var/www/example/index.txt
Например, созданный ранее файл должен содержать: Application data
При необходимости оригинал и восстановленную копию можно сравнить:
sudo diff -r \
/var/www/example \
/var/restore-test/var/www/example
Если различий нет, diff не выведет ничего.
Таким образом проверяется не просто наличие snapshot в репозитории, а возможность действительно получить из внешнего Object Storage исходные данные.
Восстановление дампа базы данных
Отдельно восстановим snapshot с дампом базы данных: sudo mkdir -p /var/restore-database
Запустите:
sudo -E restic restore latest \
--tag database \
--target /var/restore-database
После восстановления дамп будет находиться по исходному пути внутри каталога target: /var/restore-database/var/backups/database/app.sql
Проверьте его: sudo ls -lh /var/restore-database/var/backups/database/app.sql
Для PostgreSQL SQL-дамп можно дополнительно просмотреть: sudo head -n 20 /var/restore-database/var/backups/database/app.sql
В полноценной проверке disaster recovery дамп следует загрузить в отдельную тестовую базу данных. Например: sudo -u postgres createdb app_restore_test
Затем:
sudo -u postgres psql app_restore_test \
< /var/restore-database/var/backups/database/app.sql
После восстановления можно проверить наличие таблиц: sudo -u postgres psql -d app_restore_test -c "\dt"
Такой тест подтверждает сразу две вещи: SQL-файл действительно сохранился в удаленном репозитории и СУБД способна использовать его для восстановления данных.
После проверки временную тестовую базу можно удалить: sudo -u postgres dropdb app_restore_test
А каталоги восстановления очистить: sudo rm -rf /var/restore-test /var/restore-database
На этом полный цикл резервного копирования проверен: данные были созданы на VPS, отправлены во внешнее S3-хранилище, удалены из локального временного каталога и затем успешно получены обратно.
Обслуживание резервного копирования
После настройки автоматического backup основная работа сводится к контролю выполнения задач, периодической проверке репозитория и управлению учетными данными. Особое внимание стоит уделять ошибкам доступа к Object Storage: если их не заметить, расписание может продолжать запускаться, но актуальных внешних копий при этом не будет.
Оптимально, настроить оповещение на наличие ошибок в логах и отсутствие резервной копии (если по какой-то причине копирование вообще не запускалось), в минимальном варианте - отправлять на почту результаты работы резервного копирования.
Просмотр логов backup-сервиса
Поскольку резервное копирование запускается через systemd, журнал последнего выполнения можно посмотреть командой: sudo journalctl -u restic-backup.service -n 100 --no-pager
Для просмотра записей за текущие сутки: sudo journalctl -u restic-backup.service --since today
Отдельно можно проверить сам timer: systemctl status restic-backup.timer --no-pager
И расписание следующих запусков: systemctl list-timers --all | grep restic-backup
В логах следует обращать внимание не только на завершение сервиса, но и на сообщения самого Restic: ошибки подключения, отказ в доступе, невозможность открыть репозиторий или создать snapshot.
После устранения проблемы резервное копирование можно запустить вручную: sudo systemctl start restic-backup.service
А затем проверить появление нового snapshot:
set -a
source /etc/restic.env
set +a
sudo -E restic snapshots
Что делать при ошибке доступа к Object Storage
Если Restic перестал подключаться к удаленному репозиторию, сначала следует определить, относится ли проблема к сети, endpoint или учетным данным.
Проверьте, что конфигурационные файлы существуют и имеют корректные права: sudo ls -l /etc/restic.env /etc/restic-password
Затем загрузите окружение:
set -a
source /etc/restic.env
set +a
И попробуйте получить список snapshots: sudo -E restic snapshots
Ошибки вида Access Denied обычно указывают на проблему с Access Key, Secret Key или политикой доступа к бакету. Ошибка подключения или разрешения имени может быть связана с неправильным S3 endpoint либо сетевой доступностью Object Storage.
Если ключ был отозван или заменен, необходимо обновить значения:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
в /etc/restic.env.
После изменения конфигурации снова запустите: sudo -E restic snapshots
Важно не создавать новый репозиторий командой restic init, если существующий временно недоступен. Сначала необходимо восстановить доступ именно к исходному репозиторию с резервными копиями.
Ротация S3-ключей и пароля Restic
S3-ключи рекомендуется периодически заменять, особенно если есть подозрение на компрометацию учетных данных.
Безопасная последовательность выглядит так:
- Создать новую пару Access Key и Secret Key с теми же ограниченными правами на backup-бакет.
- Обновить /etc/restic.env.
- Проверить доступ командой restic snapshots.
- Создать тестовую резервную копию.
- Только после успешной проверки отозвать старый S3-ключ.
Так backup не останется без доступа к Object Storage во время ротации.
Пароль Restic выполняет другую функцию: он защищает содержимое репозитория шифрованием и не является S3-учетной записью. Для управления паролями репозитория Restic предоставляет команду key.
Посмотреть существующие ключи можно так: sudo -E restic key list
Для добавления нового пароля используется: sudo -E restic key add
После проверки нового пароля старый ключ можно удалить с помощью: sudo -E restic key remove ID
При ротации важно не удалять последний рабочий ключ до того, как подтвержден доступ с новым паролем.
Новый пароль также необходимо сохранить за пределами VPS. Сам S3-бакет без пароля Restic недостаточен для восстановления зашифрованных данных.
Заключение
В результате резервные копии VPS хранятся независимо от самого сервера в S3-совместимом Object Storage. Restic шифрует данные перед отправкой, создает snapshots и использует дедупликацию, а отдельные S3-ключи с ограниченными правами уменьшают последствия возможной компрометации учетных данных.
В backup включены как файлы приложения, так и логический дамп базы данных. Создание копий автоматизировано через systemd timer, retention policy ограничивает количество старых snapshots, а forget и prune позволяют удалять устаревшие данные из репозитория.
Главная проверка резервного копирования — не факт успешного выполнения команды, а возможность восстановить данные. Поэтому завершающим этапом стало тестовое получение файлов и дампа базы данных обратно из S3. Только после такого восстановления резервную схему можно считать практически проверенной.
FAQ
Почему нельзя хранить резервную копию только на том же VPS?
Локальная копия помогает при случайном удалении отдельных файлов, но не защищает от потери самой виртуальной машины, повреждения диска или компрометации сервера. Поэтому основной backup в этой схеме хранится во внешнем S3-совместимом Object Storage.
Шифрует ли Restic данные перед отправкой в S3?
Да. Restic шифрует содержимое репозитория на стороне клиента до передачи в backend. Для доступа к резервным копиям используется пароль репозитория, поэтому его необходимо хранить отдельно от VPS и S3-ключей.
Нужно ли копировать каталог PostgreSQL или MySQL напрямую?
Для обычного логического резервного копирования лучше сначала создать дамп средствами самой СУБД, например через pg_dump или mysqldump, а затем добавить полученный файл в Restic. Это снижает риск получить неконсистентную копию файлов работающей базы.
Чем отличаются restic forget и restic prune?
forget удаляет snapshots из списка доступных точек восстановления согласно заданной retention policy. prune дополнительно удаляет из репозитория блоки данных, которые больше не используются ни одним сохраненным snapshot.
Поэтому после forget объем Object Storage может сразу не уменьшиться.
Как часто выполнять restic check?
Частота зависит от объема репозитория и требований к резервному копированию. Обычный restic check можно запускать регулярно, а более ресурсоемкую проверку с --read-data или --read-data-subset — реже.
При этом restic check не заменяет тестовое восстановление.
Можно ли восстановить backup на другой VPS?
Да. В этом и заключается одно из преимуществ внешнего репозитория. На новой машине достаточно установить Restic, получить доступ к тому же S3-бакету, указать правильный пароль репозитория и выполнить restic restore.
Что произойдет, если потерять пароль Restic?
Доступ к зашифрованным данным может быть утрачен. Поэтому пароль или дополнительный ключ Restic необходимо хранить отдельно от резервируемого VPS, например в защищенном менеджере секретов или другом надежном хранилище.
Нужно ли постоянно хранить SQL-дамп на VPS?
Нет. Дамп можно использовать как временный файл: создать перед backup, отправить через Restic и удалить после успешного завершения резервного копирования. Постоянная копия останется во внешнем репозитории.
