restic на Ubuntu 24.04: пошаговая установка

MAATRIX

Стандартный tar для бэкапов работает, пока архив не разрастается до десятков гигабайт и каждая ночная копия не начинает съедать половину диска и канала. restic решает это дедупликацией на уровне блоков: копирует только изменившиеся данные, шифрует всё перед отправкой и умеет писать хоть на соседний диск, хоть на S3-хранилище в другой стране. Ниже — пошаговая установка на Ubuntu 24.04, от пакета до рабочего cron-задания с ротацией.

Установка restic

Ubuntu 24.04 (noble) держит restic в стандартных репозиториях, это самый простой путь для большинства серверов.

sudo apt update
sudo apt install -y restic
restic version

Версия из apt может заметно отставать от актуального релиза на GitHub — для бэкапов это обычно не критично, restic обратно совместим с форматом репозитория уже много лет, но если нужны свежие фичи (например, недавние оптимизации бэкенда S3), проще поставить бинарник напрямую с страницы релизов.

cd /tmp
curl -s https://api.github.com/repos/restic/restic/releases/latest \
  | grep "browser_download_url.*linux_amd64.bz2" \
  | cut -d '"' -f4 \
  | xargs curl -LO
bunzip2 restic_*_linux_amd64.bz2
chmod +x restic_*_linux_amd64
sudo mv restic_*_linux_amd64 /usr/local/bin/restic
restic version

Команда сама вытаскивает ссылку на последний linux_amd64-релиз через GitHub API, так что не придётся подставлять номер версии руками. У бинарника из релиза есть встроенное самообновление:

sudo restic self-update

Оно перезаписывает сам исполняемый файл — удобно, но требует прав записи в /usr/local/bin. Если restic ставился через apt, self-update работать не будет и корректнее обновлять его штатным apt upgrade.

Для продакшена достаточно apt-версии, если она не старше пары мажорных релизов — проверьте restic version сразу после установки и сверьтесь со страницей релизов, стоит ли обновляться.

Инициализация репозитория

Репозиторий — это каталог (локальный, по SSH или в объектном хранилище), где restic хранит зашифрованные и дедуплицированные данные. Прежде чем инициализировать его, задайте пароль шифрования — без него никто, включая вас, данные не расшифрует.

sudo mkdir -p /etc/restic
sudo bash -c 'head -c 32 /dev/urandom | base64 > /etc/restic/password'
sudo chmod 600 /etc/restic/password

Файл с паролем должен читаться только root'ом и храниться отдельно от самого бэкапа — если оба лежат на одном сервере и сервер погибает целиком, восстанавливать будет нечего и нечем. Скопируйте пароль в менеджер паролей сразу же, до первого restic init.

Дальше задаём переменные окружения, которые restic понимает во всех командах — это избавляет от повторения флагов -r и --password-file в каждом вызове.

export RESTIC_REPOSITORY=/mnt/backup/restic-repo
export RESTIC_PASSWORD_FILE=/etc/restic/password
restic init

Команда создаёт структуру каталогов репозитория и записывает в него зашифрованный ключ. Проверить, что всё встало на место:

restic snapshots

Пустой список без ошибок — репозиторий готов принимать бэкапы. Дальше остаётся выбрать, куда именно он будет писать: на локальный диск, по SFTP на другой сервер или в объектное хранилище.

Бэкенд: локальный диск и SFTP

Локальный каталог (как в примере выше) годится только как временное или тестовое хранилище — если это тот же диск, что и данные, при отказе диска вы теряете и оригинал, и копию. Для продакшена локальный бэкенд имеет смысл лишь как первая ступень перед отправкой на удалённый сервер, либо на отдельном физическом диске.

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

ssh-copy-id -i ~/.ssh/id_ed25519.pub backup@backup-host.example.com
ssh backup@backup-host.example.com "mkdir -p /home/backup/restic-repo"

Затем инициализируем репозиторий уже с SFTP-адресом:

export RESTIC_REPOSITORY=sftp:backup@backup-host.example.com:/home/backup/restic-repo
export RESTIC_PASSWORD_FILE=/etc/restic/password
restic init

Если SSH слушает нестандартный порт или нужен конкретный ключ, пропишите их в ~/.ssh/config для этого хоста — restic сам параметров порта и ключа не принимает, полагаясь на настройки SSH-клиента. Для второй площадки под такое хранилище удобно взять отдельный VPS в другой локации у MAATRIX — оплата картой, СБП или криптой из России проходит без проблем, а разнос бэкапа и оригинала на разные серверы и провайдеров — база правила «3-2-1» для резервных копий.

Бэкенд: S3 и совместимые хранилища

Для больших объёмов или когда нужен бэкенд без отдельного сервера под хранилище, restic нативно работает с S3 и S3-совместимыми API — Amazon S3, Backblaze B2, MinIO, Selectel Object Storage, Yandex Object Storage и другие с совместимым протоколом.

export AWS_ACCESS_KEY_ID=ваш-access-key
export AWS_SECRET_ACCESS_KEY=ваш-secret-key
export RESTIC_REPOSITORY=s3:https://s3.example-provider.com/имя-бакета/restic-repo
export RESTIC_PASSWORD_FILE=/etc/restic/password
restic init

Ключевые моменты по S3-бэкенду:

• Бакет создаётся заранее через консоль или CLI провайдера — restic его сам не создаёт, только каталог-репозиторий внутри.
• Для AWS S3 можно не указывать URL и обойтись s3:s3.amazonaws.com/бакет/путь, для остальных провайдеров нужен полный endpoint из их документации.
• Права доступа: ключу достаточно read/write на конкретный бакет, не давайте ему полный доступ к аккаунту.
• Данные, которые видит S3-хранилище, уже зашифрованы на стороне restic — провайдеру не нужно доверять содержимое, только доступность сервиса.

Если провайдер поддерживает классы хранения с холодным доступом (Glacier и аналоги), для restic они не подходят: репозиторий читается при каждой операции check, forget и prune, а не только при полном восстановлении, и холодное хранилище либо не даст это сделать, либо станет платить за каждое обращение.

Первый бэкап и восстановление

С инициализированным репозиторием (неважно, локальным, SFTP или S3 — команды идентичны) можно делать первый бэкап.

restic backup /etc /var/www /home --exclude /var/www/*/cache

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

Проверить список созданных снимков и статистику репозитория:

restic snapshots
restic stats

Восстановление — обратная операция, полное или выборочное:

# полное восстановление последнего снимка
restic restore latest --target /tmp/restore

# только один каталог
restic restore latest --target /tmp/restore --include /etc/nginx

Восстанавливайте в отдельный каталог, а не поверх рабочих данных — так вы сначала проверяете, что именно восстановилось, и только потом переносите нужное на место. Регулярное тестовое восстановление — единственный способ убедиться, что бэкап реально рабочий, а не просто существует.

Автоматизация: cron и ротация копий

Ручные запуски restic полезны для проверки, но реальную ценность бэкап даёт только по расписанию. Соберите переменные окружения и команду в отдельный скрипт.

sudo tee /usr/local/bin/restic-backup.sh > /dev/null << 'EOF'
#!/bin/bash
set -euo pipefail

export RESTIC_REPOSITORY=sftp:backup@backup-host.example.com:/home/backup/restic-repo
export RESTIC_PASSWORD_FILE=/etc/restic/password

restic backup /etc /var/www /home --exclude /var/www/*/cache
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF
sudo chmod 700 /usr/local/bin/restic-backup.sh

forget с флагом --prune — обязательная часть скрипта, а не опция «на будущее»: без ротации репозиторий растёт бесконечно даже с учётом дедупликации, потому что старые снимки продолжают ссылаться на исторические блоки данных. Политика --keep-daily 7 --keep-weekly 4 --keep-monthly 6 — лишь стартовая точка, подберите цифры под свои требования к глубине истории.

Добавляем в cron под тем пользователем, у которого настроен SSH-доступ к хранилищу (обычно root, если бэкапятся системные каталоги):

sudo crontab -e

0 3 * * * /usr/local/bin/restic-backup.sh >> /var/log/restic-backup.log 2>&1

Если раньше не приходилось настраивать cron-задачи на сервере, обратите внимание на формат расписания и права на выполнение скрипта — типичная причина «бэкап не запускается» именно в них. Дальше стоит убедиться, что сам факт запуска контролируется отдельно — сам cron не сообщит, что задача упала с ошибкой или зависла, для этого нужен внешний мониторинг вроде проверки статуса выполнения по расписанию. Общий подход к тому, какой сервер вообще брать под бэкапы и архив, стоит продумать ещё до того, как заводить репозиторий на постоянной основе.

Частые вопросы