Restic + S3: автоматические зашифрованные бэкапы серверов на объектное хранилище

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет я восстанавливал клиентские системы из бэкапов десятки раз — после шифровальщика, неудачного апдейта, уволенного админа с правами root, пожара в серверной. И каждый раз вижу одно и то же: бэкап либо не делался, либо делался на соседний диск, либо делался, но прочитать его никто не пробовал. Restic закрывает все три беды сразу — он делает зашифрованный инкрементный бэкап на удалённое S3-хранилище с минимальными настройками. Покажу, как мы это ставим в рабочих инфраструктурах.

Почему restic, а не bacula и не borg

На рынке много решений. Я перебрал bacula (слишком тяжёлая), duplicity (медленный на больших репозиториях), borgbackup (нет нативного S3), Veeam (требует Windows и лицензии). Restic — это один Go-бинарник без зависимостей, который делает всё нужное:

• Дедупликация по content-defined chunking — повторяющиеся блоки хранятся один раз.
• Шифрование AES-256 ещё до отправки — хранилищу не нужно доверять.
• Нативная работа с S3, Azure Blob, B2, SFTP, rest-server, локальным путём.
• Снэпшоты с тегами и политиками retention (сколько хранить ежедневных, еженедельных, ежемесячных).
• Кросс-платформенно — одинаково работает на Linux, Windows и macOS.

Установка на Debian/Ubuntu

# Из стандартного репо (устаревшая версия):
sudo apt install restic

# Актуальная — скачиваем релиз с GitHub
RESTIC_VER=0.17.3
curl -LO https://github.com/restic/restic/releases/download/v$RESTIC_VER/restic_${RESTIC_VER}_linux_amd64.bz2
bunzip2 restic_${RESTIC_VER}_linux_amd64.bz2
sudo install -m 0755 restic_${RESTIC_VER}_linux_amd64 /usr/local/bin/restic
restic version

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

У нас на практике чаще всего Yandex Object Storage или MinIO на отдельном сервере в дата-центре МТС. Создаём bucket, получаем access-key и secret-key, готовим переменные окружения:

# /root/.restic-env — выставляем chmod 600
export AWS_ACCESS_KEY_ID="YCAJEabc123def456"
export AWS_SECRET_ACCESS_KEY="YCLsomestrongsecretkey"
export RESTIC_REPOSITORY="s3:https://storage.yandexcloud.net/itfresh-backups/srv01"
export RESTIC_PASSWORD="LongRandomPassword_64_symbols_generated_by_pwgen"

Пароль репозитория — это ключ шифрования. Храните его отдельно от бэкапов. Потеряете — никто, включая вас, не расшифрует. Я держу пароль в парольном менеджере клиента и в собственном Vaultwarden одновременно.

source /root/.restic-env
restic init
# repository ... opened successfully, password is correct

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

# Бэкап каталога с тегом и исключениями
restic backup /var/www /etc /home \
  --tag daily --tag webserver \
  --exclude /var/www/*/tmp \
  --exclude-caches \
  --exclude-if-present .nobackup

# Список снэпшотов
restic snapshots

# Просмотр содержимого
restic ls latest /etc/nginx

# Восстановление в /tmp/restore
restic restore latest --target /tmp/restore --include /etc/nginx

# Монтирование через FUSE
mkdir /mnt/restic && restic mount /mnt/restic

Политика retention: GFS через forget

Без прореживания репозиторий растёт бесконечно. Restic поддерживает гибкие политики forget, я всегда ставлю классику Grandfather-Father-Son:

restic forget \
  --keep-last 7 \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --keep-yearly 3 \
  --tag daily \
  --prune

Эта команда удаляет старые снэпшоты, кроме последних 7, 14 ежедневных, 8 еженедельных, 12 ежемесячных и 3 годовых. Prune физически вычищает неиспользуемые блоки из S3.

Автоматизация через systemd timers

Cron работает, но я предпочитаю systemd — нормальные логи, статус, зависимости. Создаём два unit-файла:

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

[Service]
Type=oneshot
EnvironmentFile=/root/.restic-env
ExecStart=/usr/local/bin/restic backup /var/www /etc /home --tag daily
ExecStart=/usr/local/bin/restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
ExecStart=/usr/local/bin/restic check
Nice=19
IOSchedulingClass=idle

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

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=30min
Persistent=true

[Install]
WantedBy=timers.target

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

Мониторинг и нотификации

Я всегда прикручиваю алерты в Telegram через вебхук и Healthchecks.io. Бэкап не завершился за ночь — утром будет сообщение.

Реальный кейс: сеть филиалов с 1С

В марте 2026 внедряли бэкапы у производственной компании. Семь филиалов в Центральной России, в каждом 1С-сервер с базой 40-80 ГБ, плюс файловые шары с документами по 200-500 ГБ. Раньше админы делали bat-файлы с robocopy на соседний жёсткий диск — и потеряли три базы после крипто-локера, зашифровавшего заодно и бэкап-диск.

Поставили restic на каждый сервер, S3-хранилище — на нашем ЦОД-кластере (Dell с Xeon Platinum 8280, 40G Mellanox, дедуп-ReFS 127 ТБ). Настроили:

• Ежедневный инкремент в 2:30 ночи через systemd timer.
• Retention 14 дней + 8 недель + 12 месяцев + 3 года.
• Telegram-алерты на канал «backup-ops».
• Еженедельный check --read-data-subset=10%.
• Ежеквартальный тестовый restore с проверкой контрольных сумм.

Объём бэкапов по всем 7 филиалам — 2.6 ТБ сырых данных сжались в 740 ГБ репозитория. Работы стоили 180 000 ₽ разовых + 14 000 ₽/мес за хранение. Через полгода восстанавливали базу 1С после сбоя RAID — 52 ГБ за 18 минут.

Типовые грабли

• Пароль нигде не сохранён. Теряется — данные навсегда утрачены.
• Бэкап на тот же сервер. Локер зашифрует и источник, и бэкап.
• Никто не тестировал restore. Бэкап без проверки — это надежда, а не гарантия.
• Без forget --prune. Репозиторий растёт бесконечно, счёт от облака тоже.
• Один бакет на всё. Скомпрометирован ключ — потерян весь парк. Разделяйте по серверам.

FAQ — частые вопросы по restic и S3

Чем restic лучше rsync и tar?

Дедупликация по блокам, AES-256 шифрование, снэпшоты с retention. Rsync даёт только актуальную копию, tar — без версионности.

Какое S3-совместимое хранилище выбрать?

Yandex Object Storage, VK Cloud, MTC Cloud. Локально — MinIO или Ceph RGW.

Как часто делать бэкапы?

Правило 3-2-1. Базы — раз в час, файлы — раз в сутки, конфиги при изменении.

Сколько места занимают бэкапы?

С дедупликацией — в 2-5 раз меньше сырого объёма.

Как проверить, что бэкап не битый?

restic check и периодически restic check --read-data.