restic vs borg vs rsync — на чём строить бэкапы в 2026?

[qemukun]

Практическая связка которую держу для 15 серверов: restic + Backblaze B2 + healthchecks.io для мониторинга. Каждый сервер сам пушит бэкап, при успехе пингует healthchecks.io, при пропуске — алерт в Telegram. Хранение стоит копейки (B2 $6/ТБ в месяц, egress первые 3ТБ бесплатно). Дедупликация restic реально работает — 15 серверов с похожим окружением дают 40-60% экономии на хранении по сравнению с наивным tar.

[FpgaDev]

Добавлю момент, который в ветке не прозвучал: borg долго выигрывал по месту ещё и потому, что у restic не было компрессии вообще. С repo v2 (restic 0.14+) завезли zstd, и на моих данных разрыв с borg сократился с ~25% до 5-7%. Старый репозиторий апгрейдится через restic migrate upgrade_repo_v2, но учтите — компрессия применяется только к новым блобам, старые лежат несжатые, пока prune их не перепакует. Если репо создавали года три назад, проверьте версию: возможно, вы просто платите за лишние гигабайты в облаке.

[wasonga2]

@grumpylurker, про локи подтверждаю — ловил ровно это после OOM-kill посреди бэкапа. Коварство в том, что бэкапы при этом продолжают идти и мониторинг зелёный, а вот prune молча не проходит, и замечаешь через месяц по распухшему репозиторию. В resticprofile для этого есть force-inactive-lock: снимает только протухшие локи, не трогая активные — сильно безопаснее, чем тупой unlock по крону, который может выстрелить в ногу параллельному check.

[seniorwarlock]

@qemukun, схема хорошая, но пинг на успешный backup не ловит тихую деградацию репозитория: бэкап в битое репо тоже отчитается как успех. Я бы завёл в healthchecks отдельный чек под еженедельный restic check --read-data-subset=10% — читать всё каждый раз дорого по egress, а десятая часть по кругу за пару месяцев прощупывает весь репозиторий. И раз в квартал ручное восстановление случайного сервера на чистую виртуалку, иначе вся эта автоматика — вера, а не бэкапы.