В 2026 году «просто сделать архив» уже не считается бэкапом. Нормальный бэкап на Linux — это дедупликация, шифрование на клиенте, проверка целостности, понятная retention policy и регулярный restore test. А ещё — вывоз копий в удалённое хранилище (часто S3-совместимое), чтобы пережить не только случайное удаление, но и компрометацию сервера.
Ниже — практичный разбор BorgBackup vs Restic vs Kopia с фокусом на эксплуатацию: как выбрать инструмент под свой сценарий, как не «съесть» историю неправильной очисткой (prune/forget) и что реально нужно прописать в регламенте.
Критерии выбора в 2026: что важно именно админам
Перед сравнением — чеклист, который обычно решает исход «битвы тулов» сильнее, чем синтетические бенчмарки:
- Модель данных: файловый бэкап (/etc, /home, проекты) или «сначала снапшот тома/ФС, потом вывоз» (VM, базы, контейнеры).
- Дедупликация и компрессия: экономия места на длинной истории и при частых инкрементах.
- Шифрование: обязательно при выносе за пределы сервера; важно, чтобы оно происходило до сети.
- Бэкенды: локальный диск, SSH-репозиторий, S3-совместимое объектное хранилище.
- Retention policy: «сколько храним» плюс «как чистим», без сюрпризов.
- Проверяемость: команды check/verify и возможность регулярно делать restore test на отдельный каталог/VM.
- Защита от ransomware: минимальные права, иммутабельность на стороне хранилища, второй контур, мониторинг.
Короткая характеристика: BorgBackup, Restic, Kopia
Все три инструмента умеют шифрованные инкрементальные бэкапы с дедупликацией. Разница — в «родных» сценариях и удобстве эксплуатации.
BorgBackup
Borg — классика для Linux/Unix: зрелый, предсказуемый, обычно используется для репозитория на файловой системе (локально или на удалённом сервере по SSH). Сильные стороны — эффективность дедупликации/компрессии и понятное обслуживание репозитория.
Про S3: исторически это не основной сценарий Borg. Обычно добавляют промежуточный слой (например, «смонтировать объектное хранилище как ФС»), что усложняет схему и повышает риск проблем с консистентностью и производительностью. Если вам критичен именно S3, Borg обычно не первый кандидат.
Restic
Restic — один из самых «S3-friendly» инструментов: объектные репозитории — штатный режим. Он хорошо ложится на модель «одна команда — бэкап в S3», а управление историей делится на forget и prune.
Обратная сторона: на крупных репозиториях очистка и «листинги» могут быть дорогими по времени и по количеству операций в объектном хранилище. Это решается регламентом (как часто чистим) и наблюдаемостью (метрики времени/ошибок/роста).
Kopia
Kopia — более «политико-ориентированная» система: много настроек под разные пути/наборы данных, гибкие политики хранения, удобные команды. Как и Restic, нормально живёт с S3-совместимыми бэкендами, но часто выигрывает, когда хочется «разным данным — разные правила» без сложной обвязки.
Цена гибкости — дисциплина: нужно документировать политики и договориться в команде, как именно вы называете снапшоты, что исключаете и как проверяете восстановление.
Снапшот (snapshot) как часть стратегии бэкапа
Термин snapshot часто путают. В Linux-бэкапах важно разделять два слоя:
- Снапшот файловой системы/тома (LVM, Btrfs, ZFS): консистентный «срез» данных на момент времени. Отлично для БД/VM/контейнеров, но сам по себе не является offsite-бэкапом.
- Снапшот в смысле инструмента бэкапа (Borg/Restic/Kopia): точка восстановления как набор ссылок на зашифрованные дедуплицированные чанки.
Практичный паттерн для продакшена: сначала обеспечить консистентность (снапшот LVM/Btrfs/ZFS или прикладные хуки/дамп), затем вывозить уже «срез» в репозиторий. Так вы снижаете шанс получить «полубэкап».
Если вы бэкапите базы, полезно отдельно разобрать PITR-стратегию: для PostgreSQL — WAL, для MySQL/MariaDB — binlog. По теме пригодятся материалы: PITR PostgreSQL через WAL: бэкап и восстановление и PITR MySQL/MariaDB через binlog/GTID.
S3 backup: что меняется в эксплуатации по сравнению с SSH/диском
S3-совместимое хранилище — удобный offsite-контур, но у него своя специфика:
- Много мелких объектов: дедуплицированные репозитории — это тысячи/миллионы объектов. Это нормально, но влияет на листинг и очистку.
- Стоимость операций: платите не только за гигабайты, но и за запросы. Частые тяжёлые prune на больших репозиториях — типичный «скрытый счёт».
- Сеть и ретраи: важны докачка, устойчивость к временным ошибкам и корректные таймауты.
- Иммутабельность: если на стороне хранилища есть WORM/Object Lock — это сильный плюс против шифровальщиков. Если нет — компенсируйте правами доступа и вторым контуром.
В S3-сценарии чаще всего выбирают Restic или Kopia. Borg чаще берут, когда основной контур — SSH-репозиторий на отдельном сторидж-сервере, и S3 не является требованием.
Если вы планируете держать веб-проекты на сервере и выносить бэкапы в S3, заранее проверьте: есть ли отдельные ключи только на запись, можно ли включить версионирование/«корзину», и как вы будете мониторить рост репозитория. Для небольших сайтов/проектов иногда удобнее начинать с виртуального хостинга и выстроить бэкап-стратегию до переезда на выделенные ресурсы; для продовых задач чаще выбирают VDS, где проще контролировать агента, расписания и ключи.
Retention policy на практике: как не потерять нужные точки
Большинство инцидентов «бэкапы были, но восстановиться не смогли» упирается в две вещи: неверная политика хранения и отсутствие регулярного restore test.
Админский минимум для retention policy:
- Частые точки для быстрых откатов (например, почасовые или ежедневные).
- Средняя глубина на случай «тихой порчи» или позднего обнаружения (несколько недель).
- Длинная история для редких, но критичных сценариев (месяцы/кварталы).
Важно: retention — это не только «сколько храним», но и как чистим. В S3 очистка может быть тяжёлой по операциям, поэтому часто разумнее чистить реже, но предсказуемо (например, раз в неделю/месяц), и держать метрики: размер репозитория, время prune, количество ошибок.
Почему все путают forget и prune
В Restic (и концептуально в других инструментах) это две разные операции:
- forget — удалить точки восстановления согласно политике (логически «забыть» снапшоты).
- prune — физически удалить неиспользуемые данные (чанки) и реально освободить место.
Типичная ошибка — делать жёсткую очистку слишком часто и без мониторинга, а затем ловить долгие операции или рост затрат на S3. Другая крайность — делать только forget: история исчезла, а место не освобождается.
Пример «скелета» команд для Restic (адаптируйте под свой источник и расписание):
restic -r s3:s3.amazonaws.com/bucket/repo backup /etc /home
restic -r s3:s3.amazonaws.com/bucket/repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12
restic -r s3:s3.amazonaws.com/bucket/repo prune
restic -r s3:s3.amazonaws.com/bucket/repo checkОбратите внимание: адреса в примере приведены как шаблон. В реальной конфигурации используйте ваш S3-эндпоинт и способ аутентификации, принятый в инфраструктуре.
Проверка бэкапов: restore test — не опция
Если вы делаете бэкап и ни разу не делали restore test, вы не знаете, существует ли восстановление. Минимальный рабочий процесс теста:
- Выделить отдельный каталог или отдельную тестовую VM/контейнер.
- Восстановить выбранный снапшот (не только самый свежий, но и «недельной давности»).
- Проверить целостность: ожидаемые файлы, хэши, возможность запуска приложения или чтения дампа БД.
- Зафиксировать время восстановления (RTO) и потенциальную потерю данных (RPO).
Полезная практика: раз в месяц автоматизировать восстановление хотя бы критичных конфигов (/etc) и одного типового проекта в отдельный каталог, затем прогонять минимальные проверки (например, наличие ключевых файлов, успешный старт тестового контейнера).
Ransomware protection: что реально помогает, кроме «шифрования»
Шифрование репозитория обязательно, но от шифровальщика на сервере само по себе не спасает: вредонос может удалить бэкапы или испортить репозиторий, если имеет доступ.
Рабочие практики защиты, которые чаще всего дают реальный эффект:
- Раздельные учётные данные: ключи только на запись, без прав удаления, если бэкенд это позволяет.
- Иммутабельность: Object Lock/WORM на 7–30 дней (или хотя бы версионирование и «корзина» на стороне хранилища).
- Изоляция: бэкап-агент не должен иметь «админские» права на весь бакет/все репозитории.
- Второй контур: отдельный репозиторий, обновляемый реже (например, недельный), с другим ключом.
- Наблюдаемость: алерты на отсутствие свежих снапшотов, ошибки check/verify, резкое увеличение объёма или времени бэкапа.
Если вы хотите «попроще», начните с принципа: один репозиторий для частых бэкапов и второй «холодный» для редких контрольных копий. Это дисциплинирует и сильно повышает шанс пережить компрометацию.
Сравнение по сценариям: что выбрать в 2026
Сценарий 1: бэкап на отдельный сервер по SSH (классический offsite)
Если у вас есть выделенный сторидж-сервер (или отдельная машина в другом ДЦ) и нужен понятный поток по SSH — Borg исторически очень силён. Вы контролируете файловую систему репозитория, проще планировать обслуживание и прогнозировать поведение.
Если вы строите схему вокруг SSH и rsync-подхода (деплой, синхронизация, бэкапы), может пригодиться: практика rsync по SSH для деплоя и бэкапов.
Сценарий 2: S3 как основной удалённый репозиторий
Если ваш целевой бэкенд — S3-совместимое хранилище, чаще всего выбор между Restic и Kopia: они «родные» для объектной модели. Дальше решают детали: минимализм и простота Restic против более гибких политик Kopia.
Сценарий 3: много небольших проектов на одном хосте
Тут важны автоматизация, быстрый инкремент, понятная очистка и удобное восстановление по одному проекту. Restic часто выигрывает простотой команд, Kopia — удобством раздельных политик «из коробки».
Сценарий 4: акцент на «сначала снапшот, потом вывоз» (VM, БД, контейнеры)
В таких схемах инструмент бэкапа — второй слой. На первом слое вы обеспечиваете консистентность снапшотом LVM/Btrfs/ZFS или прикладными хуками/дампами. А потом Borg/Restic/Kopia вывозят данные в репозиторий. Важнее не «кто быстрее», а насколько удобно интегрировать в пайплайн, логировать, алертить и регулярно проверять восстановление.
Эксплуатационные нюансы: обслуживание репозитория
Что стоит заложить в регламент независимо от выбранного инструмента:
- Проверка целостности по расписанию (check/verify) и реакция на ошибки.
- Контроль роста: размер, время бэкапа, время очистки, число объектов (для S3).
- Ротация секретов: ключи доступа к бэкенду, пароль/ключ шифрования, место хранения секретов и процедуру восстановления доступа.
- Отдельные логи и алерты: «нет свежего бэкапа», «ошибка prune», «ошибка проверки».
И отдельно: не складывайте «снапшот провайдера» и «ваш независимый бэкап» в одну корзину. Снапшот диска полезен для быстрого отката после неудачного обновления, но как единственный контур хуже защищает от компрометации.
Быстрый вывод
- BorgBackup — отличный выбор, когда ваш основной сценарий: репозиторий на файловой системе (локально или по SSH), нужна зрелость и предсказуемость.
- Restic — часто лучший «первый выбор» для S3-бэкапов и простого управления репозиториями в объектном хранилище.
- Kopia — хороший вариант, когда хочется S3-ориентированности как у Restic, но с более гибкими политиками и настройками под разные данные.
Какой бы инструмент вы ни выбрали, два правила неизменны: задайте внятную retention policy (и понимайте разницу между forget и prune) и поставьте регулярный restore test на поток.
