Настройка Restic для резервного копирования VPS

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

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

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

Restic в четырех тезисах

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

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

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

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

Установка 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 поддерживает все описанные функции. Если вам требуется новейший релиз ради повышения производительности, скачайте официальный бинарный файл со страницы релизов проекта restic на GitHub, распакуйте его с помощью 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-совместимый бакет работает аналогично; меняются только адрес и две переменные с учетными данными:

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

Каждый снимок содержит 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 показывает, когда произойдет следующий запуск. Вы также можете сгенерировать пару файлов юнитов вместо того, чтобы вводить их вручную:

Полное описание шаблона для этих двух файлов, включая синтаксис календаря и директивы безопасности, которые может содержать сервис, приведено в запуск программы как 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 shell, как описано выше, восстановите один реальный каталог из последнего снимка во временное место и сравните его с рабочими файлами:

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

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

Хранение: forget и prune

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

Команда forget сама по себе лишь удаляет записи о снимках; блоки данных остаются в репозитории, пока их что-то не удалит. Именно это делает --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. Режима без шифрования не существует, и для выполнения любой команды требуется пароль от репозитория. Машина или провайдер, где хранится репозиторий, получают только зашифрованные блоки данных, поэтому взлом сервера резервного копирования не приведет к утечке ваших файлов. У этого есть обратная сторона: без пароля данные невозможно восстановить, поэтому храните его копию отдельно от сервера.

Выполняет ли restic инкрементальное резервное копирование?

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

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

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

Как часто нужно запускать резервное копирование restic?

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

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

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