Резервна копія без перевірки відновлення — це просто файл, який займає місце на диску. restic і BorgBackup вирішують задачу бекапів інакше, ніж tar чи rsync: вони ріжуть дані на блоки змінної довжини, зберігають у репозиторії тільки унікальні блоки і шифрують архів ще на клієнті. На VPS з обмеженим диском це знижує обсяг зберігання щоденних копій у 3-5 разів порівняно зі звичайним tar.gz.

Навіщо потрібна дедуплікація в резервних копіях

Звичайний tar.gz при щоденному бекапі створює новий архів цілком, навіть якщо за добу змінилося 200 МБ із 50 ГБ. За місяць накопичується терабайт копій одних і тих самих файлів. restic і BorgBackup під час кожного запуску порівнюють блоки даних з уже збереженими в репозиторії і дописують тільки те, що реально змінилося.

На практиці це означає: перший бекап каталогу на 50 ГБ займе майже стільки ж місця в репозиторії. Другий і всі наступні — зазвичай 100-500 МБ, якщо змінюються логи, конфіги і частина файлів сайту. Зберігати 30 щоденних копій стає реальним завданням навіть на VPS із диском 80 ГБ.

Чим restic відрізняється від BorgBackup

Архітектура репозиторію і клієнт

restic написаний на Go, поширюється одним бінарником без залежностей і однаково працює на Linux, FreeBSD і Windows. BorgBackup написаний на Python із C-розширеннями для швидкості, вимагає встановлення через пакетний менеджер чи pip і на практиці частіше використовується як клієнт, а не як сервер.

Шифрування і віддалені бекенди

restic шифрує репозиторій алгоритмом AES-256 завжди, без можливості вимкнути. BorgBackup дає вибір: репозиторій можна створити взагалі без шифрування, що прискорює запис на довірений локальний диск. У restic помітно ширший список нативних бекендів — він вміє писати напряму в S3, Backblaze B2 і Azure Blob Storage, а через rclone serve — у десятки інших хмар.

Параметр	restic	BorgBackup
Мова реалізації	Go, один бінарник	Python і C
Шифрування	AES-256, завжди увімкнено	AES-256, за бажанням
Нативні бекенди	SFTP, S3, B2, Azure, rclone	SFTP, локальний диск
Дедуплікація між машинами	Так, у спільному репозиторії	Так, у спільному репозиторії
Монтування через FUSE	Є, restic mount	Є, borg mount

Встановлення restic і BorgBackup на VPS

Обидва інструменти є в репозиторіях Debian і Ubuntu, починаючи з версій, де пакети не сильно застарілі. Для свіжої версії restic простіше завантажити бінарник з GitHub Releases і замінити пакетний.

apt update && apt install -y restic borgbackup
restic version
borg --version
# якщо версія restic у репозиторії стара — самооновлення:
restic self-update

Обидва клієнти не вимагають серверної частини: репозиторій — це просто каталог на диску, по SFTP чи в об'єктному сховищі, доступ до якого йде напряму від клієнта.

Перший бекап і відновлення файлу

Репозиторій ініціалізується один раз, пароль від нього варто зберегти окремо від сервера — без нього дані не відновити, навіть маючи root-доступ до VPS.

export RESTIC_REPOSITORY=/mnt/backup/restic-repo
export RESTIC_PASSWORD='пароль-не-коротше-20-символів-збережіть-його'
restic init
restic backup /etc /var/www /home
restic restore latest --target /tmp/restore --include /etc/nginx

Команда restic snapshots показує перелік усіх точок відновлення з датою і розміром нових даних. Відновити можна як увесь знімок, так і один файл через --include, не розгортаючи архів цілком.

Куди складати репозиторій: диск, SFTP, S3

Зберігати репозиторій на тому самому диску, що і дані, немає сенсу: при відмові диска чи видаленні VPS зникнуть і дані, і бекапи. Практичні варіанти:

Другий диск чи блочне сховище, змонтоване окремо від системного розділу — найшвидший варіант для відновлення, але не захищає від втрати всього сервера.
SFTP на другий VPS в іншому дата-центрі — restic і borg підключаються до нього напряму, без проміжного ПЗ.
S3-сумісне сховище, зокрема власний сервер MinIO — repository можна створити прямо за протоколом s3, вказавши ключі доступу в змінних середовища.

Коли потрібно синхронізувати вже готовий репозиторій у хмару без вбудованої підтримки протоколу, між клієнтом і сховищем ставлять rclone — він вміє працювати як serve-прошарок для restic і як окремий інструмент копіювання для borg.

Автоматизація через cron і перевірка цілісності

Бекап без ротації швидко з'їсть весь диск сховища. Політика зберігання задається прапорами forget: скільки щоденних, щотижневих і щомісячних копій залишити, решта відновлюється за ланцюгом дедуплікації і фізично видаляється командою prune.

0 2 * * * restic backup /etc /var/www --tag daily && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Раз на місяць варто запускати повну перевірку цілісності репозиторію, а не тільки перегляд переліку знімків — пошкоджені блоки в об'єктному сховищі інакше виявляться тільки в момент реального відновлення.

restic check --read-data — читає всі блоки репозиторію і звіряє контрольні суми, а не тільки метадані.
borg check --verify-data — аналог для BorgBackup, запускати рідше через навантаження на диск.
Раз на квартал — тестове відновлення знімка на окремий сервер, а не тільки команда restore одного файлу.
Пароль репозиторію зберігати в менеджері паролів окремо від VPS, а не в змінній середовища в .bashrc.

restic і BorgBackup: дедуплікація бекапів VPS