Restic + S3: автоматический бэкап с дедупликацией

Restic — современный инструмент резервного копирования, написанный на Go, с тремя ключевыми особенностями: дедупликация на уровне блоков (одинаковые данные хранятся один раз), шифрование по умолчанию (AES-256-CTR + Poly1305-AES) и поддержка множества бэкендов — от локальных дисков до S3, SFTP, Azure Blob, Google Cloud Storage.

Для ИТ-отделов Restic выгоден по нескольким причинам: инкрементальные бэкапы занимают минимум места благодаря content-defined chunking (CDC), восстановление не требует всей цепочки инкрементов (каждый снапшот — полная копия с точки зрения восстановления), а S3-совместимое хранилище можно развернуть на своём MinIO или использовать Yandex Object Storage.

В этом руководстве настроим автоматическое резервное копирование серверов в S3 с ротацией, мониторингом и оповещениями.

Устанавливаем Restic из официального репозитория:

# Ubuntu/Debian
sudo apt install -y restic

# Или скачиваем последнюю версию
wget https://github.com/restic/restic/releases/download/v0.16.4/restic_0.16.4_linux_amd64.bz2
bunzip2 restic_0.16.4_linux_amd64.bz2
sudo mv restic_0.16.4_linux_amd64 /usr/local/bin/restic
sudo chmod +x /usr/local/bin/restic

# Проверяем
restic version

Настраиваем переменные окружения для доступа к S3:

# /etc/restic/env.sh
export RESTIC_REPOSITORY="s3:https://storage.yandexcloud.net/company-backups"
export RESTIC_PASSWORD="SuperSecretEncryptionKey2024"
export AWS_ACCESS_KEY_ID="YCAJExxxxxxxxxxxxxxxxx"
export AWS_SECRET_ACCESS_KEY="YCPxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Инициализируем репозиторий:

source /etc/restic/env.sh
restic init

Для MinIO используйте endpoint вида s3:http://minio.company.ru:9000/backups.

Базовая команда бэкапа:

# Бэкап директорий
restic backup /etc /home /var/www /opt/apps \
    --exclude="*.tmp" \
    --exclude="*.log" \
    --exclude=".cache" \
    --tag server=web-01 \
    --tag type=files

Для бэкапа баз данных предварительно создаём дамп:

# PostgreSQL
pg_dumpall -U postgres | restic backup --stdin --stdin-filename pg_dumpall.sql --tag type=database

# MySQL/MariaDB
mysqldump --all-databases --single-transaction | restic backup --stdin --stdin-filename mysql_all.sql --tag type=database

# Можно комбинировать в одном снапшоте
mkdir -p /tmp/db-dumps
pg_dumpall -U postgres > /tmp/db-dumps/postgres.sql
mongodump --out /tmp/db-dumps/mongo/
restic backup /tmp/db-dumps --tag type=database --tag server=db-01
rm -rf /tmp/db-dumps

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

Создаём systemd-сервис /etc/systemd/system/restic-backup.service:

[Unit]
Description=Restic Backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env.sh
ExecStartPre=/usr/local/bin/restic-pre-backup.sh
ExecStart=/usr/local/bin/restic backup /etc /home /var/www /opt --exclude-file=/etc/restic/excludes.txt --tag server=%H --tag type=files
ExecStartPost=/usr/local/bin/restic-post-backup.sh
Nice=19
IOSchedulingClass=idle

Таймер /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run Restic Backup daily

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

[Install]
WantedBy=timers.target

Включаем и запускаем:

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

Restic поддерживает гибкую политику хранения через команду forget:

# Оставляем: 7 ежедневных, 4 еженедельных, 12 ежемесячных, 2 годовых
restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 12 \
    --keep-yearly 2 \
    --prune \
    --tag server=web-01

Флаг --prune сразу удаляет данные, не привязанные ни к одному снапшоту. Без него forget только помечает снапшоты для удаления, но данные остаются.

Для автоматической ротации добавьте в systemd-сервис:

ExecStartPost=/usr/local/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2 --prune

Важно: команда prune нагружает сеть и CPU, так как перепаковывает pack-файлы. На больших репозиториях (десятки ТБ) используйте --max-repack-size 5G для ограничения объёма перепаковки за один запуск.

Просмотр доступных снапшотов:

# Все снапшоты
restic snapshots

# Фильтр по тегу
restic snapshots --tag server=web-01

# Фильтр по дате
restic snapshots --tag type=files | head -20

Восстановление:

# Полное восстановление в указанную директорию
restic restore latest --target /tmp/restore

# Восстановление конкретного снапшота
restic restore abc12345 --target /tmp/restore

# Восстановление отдельных файлов
restic restore latest --target /tmp/restore --include "/etc/nginx"

# Монтирование как FUSE-файловой системы
mkdir -p /mnt/restic
restic mount /mnt/restic &
# Снапшоты доступны как директории
ls /mnt/restic/snapshots/

FUSE-монтирование особенно удобно: вы видите все снапшоты как директории и можете скопировать нужные файлы обычным cp, не восстанавливая весь бэкап.

Restic имеет встроенную проверку целостности:

# Быстрая проверка метаданных
restic check

# Полная проверка с чтением данных
restic check --read-data

# Проверка части данных (для больших репозиториев)
restic check --read-data-subset=10%

Для мониторинга размера репозитория и успешности бэкапов создайте скрипт для Zabbix/Prometheus:

#!/bin/bash
# /usr/local/bin/restic-metrics.sh
source /etc/restic/env.sh

# Время последнего снапшота (Unix timestamp)
LAST_SNAP=$(restic snapshots --json --latest 1 | jq '.[0].time' -r)
LAST_TS=$(date -d "$LAST_SNAP" +%s)
NOW=$(date +%s)
AGE_HOURS=$(( (NOW - LAST_TS) / 3600 ))

# Статистика репозитория
STATS=$(restic stats --json)
TOTAL_SIZE=$(echo $STATS | jq '.total_size')
SNAP_COUNT=$(restic snapshots --json | jq 'length')

echo "restic_last_backup_age_hours $AGE_HOURS"
echo "restic_total_size_bytes $TOTAL_SIZE"
echo "restic_snapshot_count $SNAP_COUNT"

Настройте алерт: если restic_last_backup_age_hours > 26 — значит ночной бэкап не прошёл.