Налаштування резервного копіювання серверів через 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?
| Сховище | Протокол | Особливості |
|---|---|---|
| AWS S3 | s3:// | Стандарт, підтримка IAM ролей |
| MinIO | s3:// | Self-hosted, сумісність з S3 API |
| SFTP-сервер | sftp:// | Простота, потрібен лише SSH-доступ |
| REST-сервер | rest:// | Власний протокол, висока швидкість |
| rclone | rclone:// | Google Drive, Dropbox, FTP та 50+ |
Ми допомагаємо обрати сховище під ваш бюджет: від дешевого 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 | rsync + cron |
|---|---|---|
| Дедуплікація | Вбудована (чанки 512 КБ) | Немає (повні копії) |
| Шифрування | На клієнті (AES-256-GCM) | Потребує gpg/openssl |
| Інкрементальні бекапи | Автоматично | Через hardlink (складно) |
| Простота ротації | Одна команда forget |
Скрипти, ручне видалення |
| Відновлення файлів | restic restore --include |
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
- Слабкий пароль: використовуйте довгий пароль (20+ символів) — він єдиний ключ до даних.
- Відсутність exclude-правил: не виключайте тимчасові файли (node_modules, .git), інакше репозиторій роздується.
-
Неправильна політика retention: без
--pruneневикористовувані чанки не видаляються, що веде до зростання сховища. - Ігнорування моніторингу: бекап може мовчки не виконуватися (помилка доступу до S3). Налаштовуйте алерти.
- Відсутність тестового відновлення: перевіряйте процес restore хоча б раз на місяць.
Наші інженери мають досвід відновлення сотень серверів — ми гарантуємо, що ваші дані будуть доступні в будь-який момент. Замовте налаштування Restic під ключ і отримайте безпечне резервне копіювання без сюрпризів.
