Как настроить Restic для бэкапов VPS

Почему резервное копирование на тот же сервер не является резервным копированием

Restic — это бесплатный инструмент с открытым исходным кодом для резервного копирования. Он отправляет зашифрованные снимки файлов с дедупликацией в удаленное хранилище: на второй VPS, домашний компьютер или S3-совместимое объектное хранилище. В данном руководстве описан процесс настройки на Ubuntu 24.04: от установки до создания репозитория через SFTP, выполнения первого резервного копирования, настройки ежедневного таймера systemd, политики хранения данных и проверки восстановления для подтверждения работоспособности системы. Местом назначения должен быть другой компьютер, так как копия на том же сервере будет утеряна вместе с сервером.

Директория backup/ на том же хосте, который вы копируете, защищает только от одного: случайного удаления файла. Она не поможет при выходе диска из строя, так как копия находится на этом диске. Она не поможет при взломе с правами root, так как злоумышленник сначала удалит копии. Она не поможет при ошибке в управлении аккаунтом, при которой удаляется сам VPS. Самый неэффективный дата-центр в мире шутит о tar-архиве backup_final_v2_REAL, расположенном на том же массиве, что и данные; эта шутка актуальна, так как многие из нас совершали именно это. Правило гласит: храните копии на другом устройстве, и restic — самый простой способ следовать этому правилу.

Restic в четырех понятиях

Repository. Место, куда restic записывает данные. Это директория в собственном формате restic, содержащая зашифрованные blobs; прочитать ее может только restic. Не редактируйте ее вручную; взаимодействие происходит через команды restic и адрес -r.

Snapshot. Снимок состояния файлов на определенный момент времени. Каждый запуск резервного копирования создает snapshot. Каждый snapshot можно восстановить отдельно; каждый снимок ведет себя как полная копия ваших данных на тот момент.

Deduplication. Restic разделяет файлы на чанки с определением по содержимому и загружает только те чанки, которые еще не встречаются в репозитории. Первый запуск загружает все данные; каждый последующий загружает только изменившиеся части. Ночной snapshot объемом 20 GB, в котором изменилось 50 MB, требует около 50 MB трафика. Это позволяет дешево хранить десятки снимков.

Encryption by default. Репозиторий restic всегда зашифрован (AES-256), для каждой команды требуется пароль от репозитория. Хост резервного копирования или провайдер хранилища видят только зашифрованные blobs. Прямое следствие: если вы потеряете пароль, данные будут безвозвратно утеряны, так как это предусмотрено архитектурой. Храните копию пароля вне этого сервера. Это важно, поэтому данное утверждение встречается ниже еще дважды.

Установка restic на Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

В Ubuntu 24.04 устанавливается restic версии 0.16.4, тогда как актуальная версия upstream — 0.19.1. Разница в версиях обусловлена тем, что LTS (long term support) релизы фиксируют версии пакетов. В данном случае это не имеет значения: версии 0.16.4 достаточно для выполнения всех действий из этого руководства. Если вам нужна последняя версия для повышения производительности, скачайте официальный бинарный файл со страницы GitHub releases проекта restic, распакуйте его с помощью bunzip2 и установите в /usr/local/bin/restic; установка restic не требует дополнительных действий.

Создание репозитория на другом сервере через SFTP

Вам потребуется целевая машина: обычно используют второй небольшой VPS, но подойдет любой сервер с SSH-сервером и свободным дисковым пространством. Restic поддерживает протокол SFTP (передача файлов через SSH), поэтому на хосте резервного копирования не нужно устанавливать дополнительное ПО. В данном руководстве хостом резервного копирования является 10.0.0.12 с пользователем restic. Не называйте пользователя backup: в каждой установке Ubuntu и Debian есть зарезервированная системная учетная запись backup (uid 34, без оболочки входа), поэтому adduser backup завершится ошибкой, а ssh backup@... попадет в nologin.

Ежедневная задача будет запускаться от имени root на сервере, с которого выполняется резервное копирование, поэтому пользователю root необходим вход по ключу на хост резервного копирования. Создайте отдельный ключ без пароля, так как в 3 часа ночи человек не сможет ввести пароль, и скопируйте его:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Если вы не знакомы с ключами, основы управления SSH-ключами объясняют принцип работы, права доступа и процесс отзыва ключа.

Далее — пароль репозитория. Сгенерируйте надежный пароль в файл, доступный только пользователю root:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Прежде чем продолжать, скопируйте этот пароль в ваш менеджер паролей. Если этот VPS выйдет из строя, репозиторий и этот пароль позволят восстановить все данные; без пароля репозиторий бесполезен.

Инициализируйте репозиторий:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

Альтернативным вариантом является S3-совместимое объектное хранилище. Это подходящий выбор, если вы не хотите использовать второй сервер. Любой S3-совместимый bucket работает одинаково; меняются только адрес и две переменные учетных данных:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Все параметры после init идентичны для обоих вариантов назначения. В остальной части данного руководства указан адрес SFTP; замените его на свой.

Первый резервный копирование с исключениями

Создавайте резервные копии данных, которые нельзя восстановить переустановкой системы, а не всей файловой системы. Операционную систему можно восстановить путем переустановки; ваши конфигурации и данные — нет. Для типичного VPS это означает /etc, /home и директории, где приложения хранят состояние, такие как /srv или /var/www. Исключайте кэши, так как они занимают много места, постоянно изменяются и восстанавливаются автоматически:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

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

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Каждый снимок (snapshot) содержит ID, время и пути к содержимому. Эти ID используются для восстановления данных.

Ежедневный запуск по расписанию с помощью systemd timer

Ввод адреса репозитория в каждой команде неудобен, а ручной запуск резервного копирования часто забывается уже через месяц. Обе проблемы решаются с помощью одного скрипта и одного таймера. Скрипт устанавливает две переменные окружения, которые использует restic, RESTIC_REPOSITORY и RESTIC_PASSWORD_FILE. Это позволяет сократить команды внутри скрипта:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

Строки forget и check описаны в следующих двух разделах. Теперь настройка расписания: сервис oneshot, который запускает скрипт, и таймер, который запускает его в 03:00 каждую ночь. Использование таймера предпочтительнее cron, так как логи запуска записываются в journal, а Persistent=true запускает пропущенное резервное копирование сразу после возобновления работы сервера после простоя.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

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

[Install]
WantedBy=timers.target

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

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

Команда systemctl list-timers покажет время следующего запуска. Вы также можете сгенерировать пару unit-файлов вместо их ручного ввода:

Полное описание структуры этих двух файлов, включая синтаксис календаря и директивы безопасности для сервисов, приведено в запуске программы как сервиса systemd на VPS.

Резервная копия — это лишь слух, пока вы не выполнили восстановление

Относитесь к этому утверждению как к правилу. Успешное выполнение задания резервного копирования каждую ночь доказывает только то, что процесс прошел; это не гарантирует возврат данных. Чтобы устранить неопределенность, необходимо выполнить две проверки.

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

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

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

Во-вторых, проверка процесса восстановления. Находясь в оболочке root из предыдущего шага, восстановите одну реальную директорию из последнего snapshot в временную папку и сравните её с рабочими файлами:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

Если diff ничего не выводит, значит, каждый байт восстановился идентично. Это единственное значимое доказательство. После этого удалите /srv/restore-drill. Проводите эту проверку ежемесячно, а один или два раза в год выполняйте полную версию: восстановите весь последний snapshot на временный VPS и убедитесь, что приложение успешно запускается из него. В критической ситуации вы должны полагаться на процедуру, которую уже многократно отрабатывали.

Retention: forget и prune

Без настроенной политики снимки (snapshots) накапливаются бесконечно, и объем репозитория постоянно растет. Скрипт применяет политику каждую ночь в строке forget: --keep-daily 7 сохраняет по одному снимку за каждый день в течение последних семи дней, --keep-weekly 4 — по одному снимку за неделю в течение четырех недель, а --keep-monthly 6 — по одному снимку за месяц в течение шести месяцев. Все данные, не защищенные правилами, удаляются.

Команда forget сама по себе только удаляет записи о снимках; сами блоки данных (chunks) остаются в репозитории, пока их не удалит другая команда. Именно это делает --prune: она находит блоки, на которые больше не ссылается ни один снимок, и удаляет их. Только после этого освобождается место на диске. Команда prune выполняет ресурсоемкие операции с репозиторием, поэтому на больших репозиториях некоторые пользователи запускают forget каждую ночь, а --prune — раз в неделю; для типичных VPS достаточно ежедневного запуска.

Базы данных: сначала выполните дамп, затем создайте резервную копию дампа

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

Для PostgreSQL добавьте команду дампа в начало restic-backup.sh перед командой restic backup и включите директорию с дампом в пути резервного копирования:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump выполняет ту же роль для MariaDB и MySQL. В качестве примера реализации всего процесса раздел резервного копирования Nextcloud переводит систему в режим обслуживания, выполняет дамп Postgres и копирует файлы как единый согласованный набор. Именно этот набор должен передаваться через restic каждую ночь. Для SQLite используется аналогичный подход, но более простой: руководство по Vaultwarden останавливает контейнер на несколько секунд для создания холодной копии db.sqlite3, и именно этот архив передается через restic с сервера.

FAQ

Шифруются ли резервные копии restic?

Да, всегда. Каждый репозиторий restic зашифрован с помощью AES-256. Нешифрованного режима не существует, и каждая команда требует пароль репозитория. Машина или провайдер, хранящий репозиторий, содержит только зашифрованные блоки данных (blobs). Если хост резервного копирования будет взломан, ваши файлы не будут раскрыты. Это неизменное условие: без пароля данные не сможет восстановить никто, поэтому храните его копию отдельно от сервера.

Поддерживает ли restic инкрементальное резервное копирование?

Каждый snapshot в restic работает как полный бэкап, но при этом потребляет инкрементальный объем хранилища. Restic разделяет файлы на чанки (chunks) и загружает только те чанки, которых еще нет в репозитории. Таким образом, при ежедневном запуске передается только объем данных, изменившийся за день. В отличие от традиционных инкрементальных схем, здесь нет цепочки для воспроизведения: любой snapshot восстанавливается напрямую, и удаление старого snapshot никогда не нарушает целостность более новых.

Как восстановить файлы из резервной копии restic?

Выполните restic snapshots, чтобы найти ID snapshot, затем выполните restic restore <id> --target /some/empty/dir для его восстановления. Используйте --include /path, чтобы восстановить только часть данных. Вместо ID можно использовать latest. Restic воссоздает исходную структуру каталогов в целевой директории, поэтому восстановление /etc/ssh попадет в /some/empty/dir/etc/ssh. Отработайте этот процесс заранее, так как непроверенный бэкап — это лишь слух.

Как часто нужно запускать restic backup?

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

Что произойдет, если я потеряю пароль от репозитория restic?

Резервные копии невозможно будет восстановить. В шифровании restic нет «черного хода» или функции сброса, поэтому пароль так же важен, как и сами данные. Храните его копию в менеджере паролей или в любом другом надежном месте, отличном от сервера с бэкапами. Пока у вас есть доступ, вы можете использовать restic key add, чтобы зарегистрировать второй пароль для того же репозитория — это создаст резервный вариант.