Duplicacy vs Restic vs Borg: какой инструмент резервного копирования выбрать в 2025

Если ты хоть раз настраивал сервер или ковырялся в облачной инфраструктуре, то точно сталкивался с вопросом: чем делать резервные копии? В 2025 году набор инструментов огромен, но три имени мелькают чаще других — Duplicacy, Restic и Borg. В этом посте разберёмся, какой из них выбрать, как быстро поднять бэкапы на боевом сервере, и почему один инструмент может быть лучше другого именно для твоих задач.

О чём эта статья и зачем она нужна?

Здесь не будет занудной теории или маркетинговых лозунгов. Только практика, реальные кейсы, примеры команд и разбор граблей, на которые наступал каждый, кто пытался автоматизировать бэкапы на VPS, в Docker или на выделенном сервере. Если ты ищешь решение “настроил и забыл” — читай дальше. Обсудим:

• Как устроены Duplicacy, Restic и Borg внутри
• Что проще и быстрее поднять с нуля
• В чём их плюсы, минусы и подводные камни
• Как не облажаться на старте и не потерять данные
• Кому какой инструмент подойдёт лучше всего

Почему резервное копирование — это не скучно и не банально?

Потому что однажды оно спасёт тебе нервы, деньги и репутацию. Любой сервер — это набор файлов, которые могут исчезнуть из-за бага, кривого обновления, аппаратного сбоя или злого админа. А если сервер — это твой бизнес или клиентский проект, то бэкап — твой единственный шанс откатить всё за 5 минут, а не собирать по кусочкам.

В 2025 году облачные провайдеры и хостинги предлагают свои решения, но часто они либо дорогие, либо неудобные, либо не дают гибкости. Поэтому open-source инструменты типа Duplicacy, Restic и Borg остаются топовым выбором для тех, кто хочет контролировать процесс и не платить за каждый гигабайт.

Как это работает? Алгоритмы, структура, подходы

Давай разбираться без маркетинга. Все три инструмента — это CLI-утилиты, которые умеют делать инкрементальные бэкапы, шифровать данные и отправлять их в облако, на локальный диск или на другой сервер. Но у каждого свой подход.

Duplicacy

• Структура: Каждый бэкап — снапшот, данные делятся на чанки (блоки), дедупликация на уровне чанков по всему хранилищу.
• Особенности: Поддержка параллельных бэкапов, облачные сториджи (S3, Backblaze, Dropbox, Google Drive и др.), шифрование, дедупликация между разными хостами (!).
• Алгоритмы: Использует rolling hash для определения границ чанков, хранит метаданные отдельно, поддерживает репозитории с несколькими ключами и пользователями.

Restic

• Структура: Снапшоты, данные разбиваются на чанки, дедупликация по всему репозиторию.
• Особенности: Простота, кроссплатформенность, поддержка SFTP, S3, Backblaze, Azure, Google Cloud, OpenStack Swift, WebDAV.
• Алгоритмы: Использует chunking с variable-size chunks, быстрый индекс, шифрует всё на лету (AES-GCM), метаданные и данные лежат в одном репозитории.

Borg

• Структура: Архивы внутри репозитория, chunking, дедупликация по репозиторию, поддержка append-only режима.
• Особенности: Отлично работает по SSH, шифрует на стороне клиента, поддержка компрессии (lz4, zstd, lzma), быстрый restore.
• Алгоритмы: Использует rolling hash (Buzhash) для чанков, блочная дедупликация, сжатие, шифрование (AES-CTR + HMAC).

Как быстро всё настроить? Практика и примеры

Вот что важно: все три инструмента CLI-шные, поэтому их можно воткнуть в любой скрипт, systemd unit, cron или Docker контейнер. Но у них разная философия и нюансы.

Duplicacy: быстрая настройка в Docker и не только


# 1. Установка (на Linux)
curl -L https://github.com/gilbertchen/duplicacy/releases/latest/download/duplicacy_linux_x64 -o /usr/local/bin/duplicacy
chmod +x /usr/local/bin/duplicacy

# 2. Инициализация репозитория
duplicacy init mybackup sftp://user@host//path/to/backup

# 3. Первый бэкап
duplicacy backup

# 4. Restore
duplicacy restore -r 1

# 5. Для облака (например, S3)
duplicacy init mybackup s3://bucketname/path

Duplicacy отлично работает в Docker — есть официальный контейнер. Можно монтировать volume, хранить config в переменных окружения, и запускать бэкапы по расписанию.

Фишка: дедупликация между машинами — если у тебя 10 серверов, одинаковые файлы не будут храниться 10 раз.

Restic: минимализм и скорость


# 1. Установка (Linux)
curl -L https://github.com/restic/restic/releases/latest/download/restic_$(uname -s)_$(uname -m).bz2 | bunzip2 > /usr/local/bin/restic
chmod +x /usr/local/bin/restic

# 2. Инициализация репозитория
restic init -r /mnt/backup

# 3. Первый бэкап
restic -r /mnt/backup backup /home/user

# 4. Restore
restic -r /mnt/backup restore latest –target /tmp/restore

# 5. S3, Backblaze, etc.
export AWS_ACCESS_KEY_ID=…
export AWS_SECRET_ACCESS_KEY=…
restic -r s3:s3.amazonaws.com/bucketname backup /srv/data

Restic прост, как три рубля. Не требует root, не пишет ничего в систему, всё в одном бинарнике. Работает в Docker, но чаще его просто запускают из cron или systemd.

Фишка: нативная поддержка кучи облаков и простота скриптов.

Borg: скорость и надёжность


# 1. Установка (Linux)
apt install borgbackup

# 2. Инициализация репозитория
borg init –encryption=repokey /mnt/backup

# 3. Первый бэкап
borg create /mnt/backup::my-archive-$(date +%Y-%m-%d) /srv/data

# 4. Restore
borg extract /mnt/backup::my-archive-2025-01-01

# 5. По SSH
borg init –encryption=repokey user@backupserver:/path/to/repo
borg create user@backupserver:/path/to/repo::my-archive-$(date +%Y-%m-%d) /srv/data

Borg — классика для Linux-админов. Работает молниеносно по SSH, хорошо сжимает данные, но чуть сложнее в настройке, если нужен облачный storage (S3, GCS — только через rclone или webdav).

Фишка: append-only режим — никто не сможет удалить старые бэкапы даже с доступом к репозиторию.

Реальные кейсы: плюсы, минусы, подводные камни

Ошибки новичков и мифы

• Миф: “Duplicacy — только платный”.
  Реальность: CLI-версия бесплатна для персонального использования, лицензия нужна для коммерции и GUI.
• Ошибка: “Restic не поддерживает дедупликацию между машинами”.
  Реальность: Да, но только если все бэкапят в один репозиторий. Duplicacy это делает лучше.
• Ошибка: “Borg не умеет в облако”.
  Реальность: Через rclone/webdav можно, но не нативно.
• Миф: “Все эти инструменты сложные”.
  Реальность: Самое сложное — первый раз прописать команды и автоматизировать запуск. Дальше — проще некуда.
• Ошибка: “Можно не тестировать restore”.
  Реальность: Всегда делай тестовый restore, иначе бэкап может оказаться бесполезным.

Похожие решения и альтернативы

• rsync — дедушка всех бэкапов, но без дедупликации и шифрования.
• Duplicity — старше Duplicacy, но медленнее, не так удобен.
• Kopia — свежий игрок, быстрый, но пока не так популярен.
• rclone — для копирования в облако, но не полноценный бэкап-менеджер.

Статистика, производительность, сравнение

• Duplicacy — самый быстрый из тройки при большом количестве серверов (за счёт дедупликации между машинами), минимальный размер хранилища.
• Restic — оптимален для небольших и средних проектов, прост в автоматизации, хорошая производительность на дешёвых VPS.
• Borg — лидер по скорости и надёжности на локальных и SSH-репозиториях, минимальное время восстановления.

В 2025 году все три инструмента поддерживают современные алгоритмы шифрования, chunking и сжатие. Duplicacy и Restic легко интегрируются с облаками, Borg — с локальными и SSH-хранилищами.

Креатив и нестандартные сценарии

• Использовать Duplicacy для бэкапа Docker volumes прямо из контейнера — удобно для CI/CD пайплайнов.
• Restic можно запускать из systemd-timer с автоматическим прунингом старых снапшотов.
• Borg идеально подходит для “air-gapped” серверов: можно физически переносить репозиторий на USB/NAS, используя append-only режим.
• Все три инструмента отлично работают в cron-джобах и bash-скриптах. Можно строить свои системы мониторинга бэкапов на базе их exit-кодов.
• Duplicacy поддерживает web-based GUI (но это уже платно), что удобно для тех, кто не любит консоль.

Автоматизация и новые возможности в 2025

Всё больше людей используют infrastructure-as-code, поэтому важно, чтобы бэкап-утилита была скриптуемой и легко интегрировалась в DevOps пайплайны. Все три инструмента CLI-шные, поддерживают переменные окружения, не требуют root-доступа и легко деплоятся через Ansible, Terraform, Kubernetes Jobs и т.д.

• Duplicacy и Restic поддерживают environment variables для паролей, ключей и путей — удобно для CI/CD.
• Borg можно запускать через systemd, ограничив права пользователя и доступ к репозиторию.
• Все три инструмента поддерживают автоматический прунинг старых бэкапов (retention policy).
• Можно строить централизованные системы мониторинга: логировать результаты, отправлять алерты в Slack/Telegram при ошибках.

Выводы и рекомендации

В 2025 году Duplicacy, Restic и Borg — это три кита современного резервного копирования для серверов любого типа: VPS, облако, Docker, bare-metal. Какой выбрать?

• Duplicacy — если у тебя много серверов, нужен бэкап в облако и максимальная экономия места за счёт дедупликации между машинами. Идеален для DevOps/CI/CD, Docker, облачных проектов.
• Restic — для простых, быстрых и надёжных бэкапов на одном сервере или в облаке, если не хочется заморачиваться с настройкой. Отлично подходит для cron-джоб, скриптов, малых и средних проектов.
• Borg — если нужен максимальный контроль, скорость и надёжность на локальных и SSH-хранилищах. Для хранения на NAS, физических серверах, air-gapped инфраструктуры, архивирования на годы вперёд.

Совет: протестируй restore на отдельной машине или в Docker перед тем, как доверить инструменту свои данные. Не ленись автоматизировать бэкапы: cron, systemd, Ansible — всё это твои друзья.

Если нужен VPS для бэкапов — вот ссылка на проверенный сервис. Для выделенного сервера — сюда.

Официальные ссылки:

• Duplicacy
• Restic
• Borg

Пробуй, экспериментируй, не доверяй только одному решению — и пусть твои бэкапы никогда не понадобятся, но всегда будут под рукой!