Резервная копия без проверки восстановления — это просто файл, который занимает место на диске. 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