Настройка бэкапирования серверов через Restic под ключ

Настройка бэкапирования серверов через Restic под ключ

Настраиваем бэкапы серверов с Restic — дедупликация на уровне чанков и шифрование на клиенте. Restic одинаково хорошо работает с S3, SFTP и любыми хранилищами через rclone, что даёт гибкость в выборе бэкенда. Наши инженеры имеют более 5 лет опыта эксплуатации Restic в продакшене, включая кластеры на 100+ серверов. В этой статье разберём, как Restic решает ключевые проблемы бэкапов, и покажем реальную конфигурацию с systemd timer.

Как Restic решает проблему дедупликации и шифрования?

Restic разбивает данные на чанки по 512 КБ и вычисляет их хеши. При повторных бэкапах передаются только новые или изменённые чанки — это сокращает трафик в 10–20 раз по сравнению с rsync. Шифрование выполняется на клиенте до отправки: пароль генерирует ключ AES-256, и даже при компрометации хранилища данные остаются недоступными. Для критичных баз данных (PostgreSQL, MySQL) мы дополнительно настраиваем бэкапы через pg_dump перед отправкой в Restic. Для Docker-контейнеров используем sidecar-контейнер с restic, монтируя volumes.

Какие хранилища поддерживает Restic?

Мы помогаем выбрать хранилище под ваш бюджет: от дешёвого S3-совместимого объектного хранилища до корпоративного SFTP. Restic репозиторий одинаково читается независимо от бэкенда.

Пример конфигурации с systemd timer

# Установка
apt-get install restic
# или
wget https://github.com/restic/restic/releases/download/v0.17.3/restic_0.17.3_linux_amd64.bz2
bunzip2 restic_*.bz2 && chmod +x restic_* && mv restic_* /usr/local/bin/restic

# Инициализация репозитория в S3
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=secret
export RESTIC_REPOSITORY=s3:https://s3.eu-central-1.amazonaws.com/my-backups/server1
export RESTIC_PASSWORD=strong-encryption-password
restic init

Первый бэкап:

restic backup /etc /home /var/www /var/lib/postgresql \
    --exclude="/var/lib/postgresql/*/pg_wal" \
    --exclude="/var/www/*/node_modules" \
    --tag server1 \
    --tag prod

Дедупликация работает на уровне контент-адресуемых чанков по 512 КБ — при повторном бэкапе передаются только изменённые блоки. Для типичного сервера второй и последующие бэкапы занимают 5-15% времени первого.

/etc/restic/env:

AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=secret RESTIC_REPOSITORY=s3:https://s3.eu-central-1.amazonaws.com/my-backups/server1 RESTIC_PASSWORD=strong-encryption-password 

Права 0600, владелец root.

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

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=restic backup /etc /home /var/www --exclude-file=/etc/restic/excludes
ExecStartPost=restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
StandardOutput=journal
StandardError=journal

# /etc/systemd/system/restic-backup.timer
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
[Install]
WantedBy=timers.target

--keep-daily 7 --keep-weekly 4 --keep-monthly 6 — стандартная ротация: 7 ежедневных, 4 еженедельных, 6 ежемесячных снапшотов. --prune удаляет неиспользуемые данные после применения политики. Для мониторинга можно добавить restic_exporter, который отдаёт метрики в Prometheus — время выполнения, объём данных, статус.

Почему Restic лучше традиционных rsync-бэкапов?

Restic сокращает время повторного бэкапа в 10–15 раз по сравнению с rsync, а экономия места на хранилище за счёт дедупликации достигает 80%. Особенно это заметно на серверах с базами данных или большими логами. Реальный кейс: клиент с 50 серверами перешёл с rsync на Restic и сократил время бэкапа с 3 часов до 15 минут.

Что входит в настройку Restic под ключ?

Мы предоставляем комплексную услугу:

• Аудит ваших данных: определяем, что бэкапить и как часто
• Установка и конфигурация Restic с учётом вашего стека (Linux, Docker, Kubernetes)
• Настройка systemd timer или интеграция с существующим CI/CD
• Выбор и подключение хранилища (S3, SFTP, REST)
• Политика ротации и автоматический forget/prune
• Мониторинг бэкапов: алерты в Telegram/Slack при сбоях, метрики в Prometheus
• Тестовое восстановление (restore dry-run) — проверяем, что данные читаются
• Документация и обучение ваших инженеров
• Гарантия восстановления данных — если не сможем восстановить, доработаем бесплатно

Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальную конфигурацию и сроки.

Частые ошибки при настройке Restic

1. Слабый пароль: используйте длинный пароль (20+ символов) — он единственный ключ к данным.
2. Отсутствие exclude-правил: не исключайте временные файлы (node_modules, .git), иначе репозиторий раздуется.
3. Неправильная политика retention: без --prune неиспользуемые чанки не удаляются, что ведёт к росту хранилища.
4. Игнорирование мониторинга: бэкап может молча не выполняться (ошибка доступа к S3). Настраивайте алерты.
5. Отсутствие тестового восстановления: проверяйте процесс restore хотя бы раз в месяц.

Наши инженеры имеют опыт восстановления сотен серверов — мы гарантируем, что ваши данные будут доступны в любой момент. Закажите настройку Restic под ключ и получите безопасное резервное копирование без сюрпризов.