Как установить и настроить restic на VPS

MAATRIX

Бэкапы через tar и rsync работают, пока архив не начинает весить больше самого сервера, а восстановление — занимать полдня. Restic решает эту проблему: он дедуплицирует данные на блочном уровне, шифрует всё перед отправкой и умеет писать хоть на локальный диск, хоть в SFTP, хоть в S3-совместимое хранилище — без плясок с GPG и cron-скриптами на tar. Ниже — как поставить его на VPS, инициализировать репозиторий и настроить бэкапы так, чтобы не вспоминать о них до момента, когда они реально понадобятся.

Что такое restic и чем он лучше самописных скриптов на tar

Restic — консольная утилита для резервного копирования с открытым исходным кодом, написана на Go, работает на Linux, macOS и Windows одним и тем же бинарником. Три вещи, которые отличают его от связки tar + cron + scp:

• Дедупликация на уровне чанков. Файл режется на куски переменного размера (content-defined chunking), и повторяющиеся куски между снапшотами не копируются заново. Если у вас 50 ГБ логов, из которых за сутки поменялось 200 МБ, следующий бэкап отправит именно эти 200 МБ, а не всё заново.
• Шифрование всегда включено. Репозиторий шифруется AES-256 ещё до того, как данные покидают сервер, включая метаданные и имена файлов. Ключ — это пароль, который вы задаёте при инициализации репозитория; без него данные бесполезны даже тому, кто получил полный доступ к бэкенду.
• Единый CLI под любой бэкенд. Один и тот же набор команд работает с локальной директорией, SFTP, Amazon S3, Backblaze B2, Azure, Google Cloud Storage и любым S3-совместимым хранилищем (MinIO, Selectel, Wasabi). Меняется только строка подключения к репозиторию.

Из ограничений: restic не заменяет репликацию базы данных и не годится для файлов, которые меняются побайтово каждую секунду (для СУБД лучше сначала снять логический дамп, а потом бэкапить его — об этом ниже). Также восстановление больших репозиториев с медленного бэкенда занимает время: дедупликация экономит трафик на запись, но не ускоряет чтение при полном восстановлении.

Установка restic на VPS

На Ubuntu/Debian и AlmaLinux/RHEL проще всего поставить restic из системного пакетного менеджера, но версия в репозиториях обычно отстаёт от актуальной на GitHub на несколько релизов. Для бэкапов это не критично, но если нужны свежие фичи (например, поддержка нового бэкенда), ставьте бинарник напрямую.

Через пакетный менеджер:

# Ubuntu / Debian
sudo apt update
sudo apt install restic -y

# AlmaLinux / RHEL (нужен EPEL)
sudo dnf install epel-release -y
sudo dnf install restic -y

Через официальный бинарник (актуальная версия — на странице релизов проекта на GitHub, restic/restic):

cd /tmp
curl -LO https://github.com/restic/restic/releases/latest/download/restic_linux_amd64.bz2
bunzip2 restic_linux_amd64.bz2
chmod +x restic_linux_amd64
sudo mv restic_linux_amd64 /usr/local/bin/restic
restic version

Если ставили через apt/dnf, дальше можно поддерживать бинарник встроенной командой:

sudo restic self-update

Она работает только для бинарника, скачанного напрямую — пакет из системного репозитория обновляется обычным apt upgrade.

Инициализация репозитория: локальный диск, SFTP, S3

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

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

sudo mkdir -p /etc/restic
sudo openssl rand -base64 32 > /etc/restic/password
sudo chmod 600 /etc/restic/password

Локальный диск или примонтированный сетевой том — самый простой вариант для старта или для второго диска на том же VPS:

restic -r /mnt/backup/restic-repo --password-file /etc/restic/password init

SFTP — если бэкапы улетают на отдельный сервер по SSH (например, на второй, дешёвый VPS, выделенный только под архивы):

restic -r sftp:backupuser@backup.example.com:/data/restic-repo \
  --password-file /etc/restic/password init

Для SFTP нужен настроенный доступ по SSH-ключу без пароля — restic не умеет вводить пароль SSH интерактивно в фоновых задачах. Если ключей ещё нет, сначала настройте SSH-ключи вместо пароля на обеих машинах.

S3 или S3-совместимое хранилище — вариант для продакшена, когда бэкапы должны жить физически отдельно от инфраструктуры и с версионированием на стороне бакета:

export AWS_ACCESS_KEY_ID=ваш_access_key
export AWS_SECRET_ACCESS_KEY=ваш_secret_key
restic -r s3:https://s3.amazonaws.com/имя-бакета/restic-repo \
  --password-file /etc/restic/password init

Для S3-совместимых хранилищ (MinIO, Selectel S3, Wasabi и подобных) меняется только эндпоинт:

restic -r s3:https://s3.selcdn.ru/имя-бакета/restic-repo \
  --password-file /etc/restic/password init

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

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

Базовая команда — restic backup с путями, которые нужно сохранить:

restic -r /mnt/backup/restic-repo --password-file /etc/restic/password \
  backup /etc /var/www /home --tag daily

Чтобы не таскать репозиторий и пароль в каждой команде, удобнее вынести их в переменные окружения — это же пригодится для автоматизации:

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

restic backup /etc /var/www /home --tag daily

Исключения задаются флагом --exclude или файлом со списком паттернов:

cat > /etc/restic/excludes.txt <<'EOF'
*.log
**/node_modules
**/.cache
/var/www/*/tmp
EOF

restic backup /etc /var/www /home --exclude-file=/etc/restic/excludes.txt

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

restic stats latest --mode raw-data
restic snapshots

Команда snapshots покажет список всех сохранённых точек с ID, датой и тегами — по этим ID потом восстанавливаете конкретную версию, а не только последнюю.

Восстановление данных

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

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

restic restore latest --target /restore

Восстановить конкретный снапшот по ID (ID берётся из restic snapshots):

restic restore a1b2c3d4 --target /restore

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

restic restore latest --target /restore --include /var/www/site1

Для точечного восстановления одного файла без разворачивания всего снапшота удобнее смонтировать репозиторий как файловую систему через FUSE и просто скопировать нужное:

mkdir /mnt/restic-browse
restic mount /mnt/restic-browse
# в другом терминале:
cp /mnt/restic-browse/snapshots/latest/var/www/site1/config.php /tmp/
# после работы отмонтировать:
fusermount -u /mnt/restic-browse

Это же удобно, чтобы визуально сравнить, что менялось между двумя снапшотами, не восстанавливая оба целиком.

Автоматизация через cron и ротация старых снапшотов

Без ротации репозиторий будет расти бесконечно — дедупликация экономит место на повторяющихся данных, но старые уникальные чанки никуда не деваются, пока их явно не удалить командой forget.

Файл с переменными окружения для cron, чтобы не хардкодить пароли и ключи в crontab:

# /etc/restic/env
RESTIC_REPOSITORY=s3:https://s3.selcdn.ru/имя-бакета/restic-repo
RESTIC_PASSWORD_FILE=/etc/restic/password
AWS_ACCESS_KEY_ID=ваш_access_key
AWS_SECRET_ACCESS_KEY=ваш_secret_key

sudo chmod 600 /etc/restic/env

Скрипт бэкапа с логированием и ротацией:

#!/bin/bash
# /usr/local/bin/restic-backup.sh
set -euo pipefail
set -a
source /etc/restic/env
set +a

LOG=/var/log/restic-backup.log

{
  echo "=== $(date -Is) start ==="
  restic backup /etc /var/www /home \
    --exclude-file=/etc/restic/excludes.txt \
    --tag daily
  restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
  echo "=== $(date -Is) done ==="
} >> "$LOG" 2>&1

sudo chmod +x /usr/local/bin/restic-backup.sh

Задача в cron — раз в сутки ночью:

sudo crontab -e

0 3 * * * /usr/local/bin/restic-backup.sh

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

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

Если бэкапите базу данных, восстановление файла с открытой БД на диске почти гарантированно даст битую копию — сначала сделайте логический дамп (mysqldump, pg_dump), а затем бэкапьте уже готовый файл дампа. Это отдельная тема, разобранная в статье про бэкап MySQL на VPS.

Мониторинг: проверка целостности и алерты о падении задачи

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

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

restic check --read-data-subset=10%

Добавьте это отдельной cron-задачей раз в неделю, с тем же /etc/restic/env.

Алерт, если задача не отработала. Проще всего подключить пинг на внешний сервис мониторинга cron-задач в конец скрипта — если скрипт не дошёл до последней строки (упал на ошибке, завис, сервер перезагрузился в момент бэкапа), пинг не придёт, и сервис пришлёт уведомление. Подробная настройка такого мониторинга — в статье про healthchecks.io для cron-задач. Если внешний сервис использовать не хочется, минимальный вариант — проверять код выхода скрипта и слать сообщение в Telegram при ошибке.

Также не забывайте проверять свободное место на бэкенде, где живёт репозиторий — растущий репозиторий на локальном диске без ротации способен внезапно заполнить весь том. Про диагностику этого — в статье про мониторинг диска на VPS.

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