Бэкап и восстановление restic

MAATRIX

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

Почему restic, а не rsync или tar

У каждого инструмента своя ниша, и смысл не в том, чтобы объявить один вариант плохим:

Ключевое отличие — content-defined chunking: restic режет файлы на блоки переменного размера по содержимому, а не по фиксированным границам. Если вы вставили байт в начало гигабайтного файла, tar пересохранит его целиком, а restic обнаружит, что почти все блоки не изменились, и допишет только разницу. На практике это означает, что ежедневный бэкап логов, баз или медиатеки занимает секунды и мегабайты — точная экономия зависит от характера данных, и на случайных бинарниках дедупликация даёт меньше, чем на текстах и БД-дампах.

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

Установка restic

Restic — один бинарник на Go без зависимостей, ставится за минуту.

На Debian/Ubuntu пакет есть в репозиториях, но часто отстаёт от актуальной версии:

apt update && apt install restic

Надёжнее взять свежий бинарник напрямую с GitHub Releases проекта restic/restic и встроенным self-update:

curl -L -o /usr/local/bin/restic.bz2 \
  https://github.com/restic/restic/releases/latest/download/restic_linux_amd64.bz2
bunzip2 /usr/local/bin/restic.bz2
chmod +x /usr/local/bin/restic
restic self-update    # подтягивает следующие релизы без переустановки
restic version

Для AlmaLinux/RHEL действует та же схема — бинарник статический, менеджер пакетов не нужен. Если сервер поднимаете с нуля, сначала пройдите базовую подготовку — она описана в статьях по Ubuntu 24.04 и Debian 12 с настройкой SSH-ключей.

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

Репозиторий restic — это каталог с зашифрованными блоками данных и метаданными. Пароль репозитория задаёт всё шифрование: потеряете его — данные не восстановить никак, бэкдоров и «сброса пароля» в дизайне restic нет намеренно.

Локальный диск или примонтированный внешний том — самый простой вариант, но не защищает от отказа самого сервера:

mkdir -p /mnt/backup-disk/restic-repo
export RESTIC_REPOSITORY=/mnt/backup-disk/restic-repo
export RESTIC_PASSWORD_FILE=/root/.restic-pass
echo 'сложный-пароль-минимум-20-символов' > /root/.restic-pass
chmod 600 /root/.restic-pass
restic init

SFTP на второй сервер — дёшево и просто, если у вас уже есть второй VPS под архив:

export RESTIC_REPOSITORY=sftp:backupuser@203.0.113.10:/home/backupuser/restic-repo
restic init

Ключевое требование — вход по SSH-ключу без пароля для пользователя backupuser, иначе автоматизация встанет на первом же запросе пароля.

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

export AWS_ACCESS_KEY_ID=ваш_access_key
export AWS_SECRET_ACCESS_KEY=ваш_secret_key
export RESTIC_REPOSITORY=s3:https://s3.example.com/bucket-name/restic-repo
restic init

Подходит любой S3-совместимый провайдер — достаточно указать нужный endpoint вместо s3.example.com. Если вы держите архивный бэкап на отдельном сервере или в облаке специально под такие задачи, посмотрите статью про подбор VPS под бэкапы и архив — там разбор требований к диску и сети именно для этого сценария.

Все три способа используют одни и те же команды backup/restore/snapshots — разница только в переменной RESTIC_REPOSITORY, что удобно, если позже решите сменить бэкенд.

Первый бэкап: что и как копировать

Базовый вызов:

restic backup /etc /home /var/www /var/lib/mysql \
  --exclude='*.tmp' \
  --exclude='/var/www/*/node_modules' \
  --exclude-caches \
  --tag daily

Разбор флагов:

• --exclude — паттерны исключений, можно перечислять несколько раз или вынести в файл --exclude-file=/etc/restic-excludes.txt;
• --exclude-caches — пропускает каталоги с файлом-маркером CACHEDIR.TAG (кеши npm, pip, браузеров);
• --tag daily — метка снапшота, пригодится при выборочном восстановлении и в политике хранения.

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

Проверить, что снапшот создался:

restic snapshots

ID        Time                 Host        Tags        Paths
a1b2c3d4  2026-08-28 03:00:11  web-01      daily       /etc, /home, /var/www, /var/lib/mysql

Шифрование и дедупликация: что происходит под капотом

Шифрование в restic не опциональная надстройка — оно встроено в формат репозитория, отключить его нельзя (это осознанное решение авторов). Каждый блок данных шифруется AES-256 в режиме CTR, целостность проверяется Poly1305-AES-MAC, ключ шифрования выводится из вашего пароля через scrypt и хранится в репозитории в зашифрованном виде отдельным файлом-ключом. Практический вывод: пароль репозитория и файл ключа — это единственное, что защищает бэкап, и единственное, что может привести к его полной потере.

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

Практические следствия для эксплуатации:

• Несколько ключей на один репозиторий. Можно выдать отдельный пароль другому серверу или человеку через restic key add, не раскрывая основной:

  restic key add
  restic key list

• Смена пароля не требует пересоздания репозитория: restic key passwd.
• Файл пароля должен быть за пределами репозитория и с правами 600 — хранить его рядом с данными на том же диске бессмысленно, если диск физически выйдет из строя.

Автоматизация и хранение снапшотов (retention)

Без политики хранения репозиторий будет расти бесконечно. Схема forget + prune решает это:

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

Это оставит 7 последних ежедневных снапшотов, 4 недельных и 6 месячных, остальные пометит на удаление, а --prune сразу освободит место, физически удалив блоки, на которые больше никто не ссылается. prune — операция с интенсивным чтением репозитория, на больших объёмах может занять время и нагрузить диск/сеть, поэтому на медленных бэкендах (SFTP на слабый канал) её иногда запускают реже, чем forget.

Собираем в systemd unit + timer — это надёжнее cron, потому что видно логи через journalctl и легко добавить зависимости:

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/local/bin/restic backup /etc /home /var/www /var/lib/mysql --tag daily
ExecStart=/usr/local/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Daily restic backup

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

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers | grep restic

Persistent=true гарантирует, что пропущенный из-за перезагрузки запуск выполнится сразу после старта системы, а не будет ждать следующего расписания. Уведомления об успехе или падении бэкапа стоит завести отдельно — если такой механизм ещё не настроен, посмотрите статью про алерты в Telegram на VPS (добавьте проверку ExecStartPost с отправкой статуса).

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

Ради чего всё это затевалось — проверенное восстановление. Полное восстановление снапшота в исходное расположение:

restic restore latest --target /

Восстановление конкретного снапшота по ID в отдельный каталог (правильная практика — никогда не восстанавливать поверх боевых данных без предварительной проверки):

restic restore a1b2c3d4 --target /tmp/restore-check

Восстановление одного файла или подкаталога без разворачивания всего снапшота:

restic restore latest --target /tmp/restore-check --include /var/www/site/wp-config.php

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

mkdir /mnt/restic-fuse
restic mount /mnt/restic-fuse
# в отдельном терминале: ls /mnt/restic-fuse/snapshots/
# Ctrl+C в терминале с mount отмонтирует репозиторий

Целостность репозитория стоит проверять регулярно, отдельно от самого бэкапа — повреждённые блоки на диске или в облаке обнаруживаются не при записи, а при чтении:

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

Полная проверка --read-data вычитывает весь репозиторий и на больших объёмах дорога по трафику (особенно на S3), поэтому на практике чаще гоняют выборочную проверку раз в неделю и полную — раз в месяц. Восстановление стоит делать по расписанию, а не полагаться на то, что раз backup не упал — значит, и restore сработает: общий принцип для любой схемы бэкапов, разобранный подробнее в статье про восстановление базы данных из бэкапа на практике.

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