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

> restic і BorgBackup стискають резервні копії VPS за рахунок дедуплікації: порівняння, встановлення, автоматизація через cron і перевірка цілісності.

Резервна копія без перевірки відновлення — це просто файл, який займає місце на диску. 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](https://www.zevshost.net/uk/kb/minio-s3-nastroika-vps/) — repository можна створити прямо за протоколом s3, вказавши ключі доступу в змінних середовища.

Коли потрібно синхронізувати вже готовий репозиторій у хмару без вбудованої підтримки протоколу, між клієнтом і сховищем ставлять [rclone](https://www.zevshost.net/uk/kb/rclone-oblachnye-bekap/) — він вміє працювати як 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.

---

Джерело: https://www.zevshost.net/uk/kb/restic-borg-bekapy/