Разбор упавших файловых систем, потерянных баз данных и умирающих дисков съедает время, особенно когда всё это приходится восстанавливать консольными утилитами или самописными скриптами. Однако настройку бэкапов можно упростить с помощью утилит — под катом я собрал топ-10 опенсорс-инструментов и рассказал, на основе чего выбирать. 

1. Restic

Для чего: инкрементальные бэкапы файлов, дедупликация, шифрование и хранение копий на другом сервере или в объектном сторадже.

Restic — консольная утилита для резервного копирования, которая хорошо ложится на обычные VDS, где нет сложной инфраструктуры. Она делает снапшоты выбранных директорий и сохраняет их в репозитории, а при следующих запусках не копирует одни и те же данные заново, потому что использует дедупликацию.  

Для пользователей российских VDS Restic удобна тем, что она не привязана к конкретному облаку или зарубежному сервису. Копии можно хранить на другом сервере по SFTP, локально, в MinIO или в S3-совместимом хранилище (конкретные называть не буду, но на рынке их много). Важно, данные шифруются на стороне клиента, поэтому внешний сервер или хранилище видит только закрытый репозиторий.

Из полезного у Restic есть хранение нескольких версий, правила очистки старых снапшотов и возможность смонтировать репозиторий как файловую систему. Это спасает в ситуациях, когда нужно достать один nginx-конфиг или старую версию файла сайта.

Минусы — встроенного планировщика нет (запуск придётся настраивать через cron или systemd-таймеры), для баз данных нужен отдельный сценарий с дампом или остановкой записи, а при больших репозиториях очистка старых снапшотов может грузить диск.

2. BorgBackup

Для чего: инкрементальные бэкапы с дедупликацией на уровне блоков, сжатие и хранение копий на удалённом сервере по SSH.

Это уже более тяжёлый инструмент по сравнению с Restic, но и более эффективный на больших объёмах. Он разбивает данные на чанки, считает хэши и сохраняет только уникальные блоки. За счёт этого повторные бэкапы занимают минимум места, даже если вы регулярно копируете одни и те же каталоги или базы.

Для VDS Borg чаще всего используют в схеме «сервер → сервер», где основная машина отправляет копии на отдельный сервер по SSH. Привязки к внешним облакам здесь нет, всё держится на обычном SSH, ключах и понятной файловой модели. 

Из полезного есть сжатие, шифрование, хранение версий и предсказуемое восстановление. Также в плюсы — есть большое сообщество с ресурсами. 

Минусы — порог входа выше, команд больше, логика репозиториев и prune-политик требует внимания, также для объектных хранилищ понадобятся дополнительные обвязки. 

3. Duplicati

Для чего: бэкапы с веб-интерфейсом, расписанием и хранением версий в локальных и объектных хранилищах.

Duplicati — вариант для тех, кто не хочет собирать бэкап из CLI-утилит и cron. Это полноценный сервис с веб-интерфейсом, где можно настроить задания, выбрать директории, задать расписание и политику хранения без постоянной работы в терминале.

Инструмент поддерживает локальные диски, SFTP, WebDAV и объектные хранилища, поэтому без проблем работает с российскими VDS и объектными стораджами. К слову, бэкапы делаются инкрементально, с дедупликацией и шифрованием на стороне клиента, так что данные не утекают в открытом виде.

Удобно и то, что всё управление в одном месте. В интерфейсе видно историю запусков, ошибки и объёмы данных. Также можно быстро проверить, когда последний раз выполнялся бэкап. Ну и сообщество также большое, активное. 

Минусы — при больших объёмах и длинной истории бэкапов может заметно тормозить (особенно на слабых VDS), а также иногда всплывают проблемы с консистентностью базы метаданных.

4. Kopia

Для чего: инкрементальные бэкапы с дедупликацией, шифрование и хранение в локальных и объектных стораджах.

Kopia называют альтернативой Restic. По сути, это тот же класс инструментов (файловые снапшоты, дедупликация, репозиторий), но с упором на удобное управление.

Инструмент хорошо подходит для тех, кому важно быстро настроить бэкап и не завязываться на конкретного провайдера. Kopia поддерживает локальные диски, SFTP и работает с российскими стораджами и хостингами. Также важно, что данные шифруются на клиенте, а снапшоты можно монтировать и просматривать как обычную файловую систему. Отдельный плюс — есть не только CLI, но и простой веб-интерфейс. Там можно посмотреть статус, запуски и историю. 

Минусы — документация местами менее подробная, а при нестандартных сценариях приходится разбираться самостоятельно. 

5. rclone

Для чего: синхронизация и перенос данных между VDS и внешними хранилищами, выгрузка бэкапов и архивов.

Rclone — не совсем классический инструмент для бэкапов, а консольная программа для работы со стораджами. Чаще всего его часто используют как способ быстро и без лишней инфраструктуры вынести данные с VDS в другое место. 

Инструмент поддерживает десятки хранилищ, включая S3-совместимые сервисы, WebDAV, FTP, SFTP, локальные диски и самописные стораджи (выделил их отдельно). В нём можно настроить регулярную синхронизацию директорий, заливку архивов или дампов баз, а также использовать шифрование через rclone crypt.

В целом rclone вам подойдёт, если нужно просто иметь актуальную копию данных вне сервера. Например, выгрузить бэкапы сайта или базы в объектное хранилище.

Минусы — из коробки нет нормальной дедупликации и полноценного версионирования, поэтому это именно синхронизация, а не система бэкапов. Кроме того, если случайно удалить файл на сервере, он может исчезнуть и в копии. 

6. rsnapshot

Для чего: простые бэкапы через rsync с хранением версий на отдельном сервере или диске.

Старый, но до сих пор работающий инструмент. В rsnapshot есть только rsync и файловая система. Он делает копии директорий и использует жёсткие ссылки, чтобы одинаковые файлы не дублировались. Версии полноценные, а место расходуется минимально. 

Между двумя серверами данные копируются по SSH, а rsnapshot раскладывает их по каталогам вроде hourly, daily, weekly. На выходе получается обычная файловая структура, в которую можно зайти через ls и сразу увидеть нужную версию файла или каталога без восстановления и распаковки.

Для наших реалий это почти идеальный минимализм — не нужно никаких облаков, API и внешних зависимостей, только SSH и диск. Если что-то ломается, достаточно зайти на сервер с бэкапами и забрать файл.

Минусы — нет шифрования из коробки, эффективность зависит от окружения и нет дедупликации на уровне блоков (зато экономия за счёт хардлинков).

7. UrBackup

Для чего: централизованные бэкапы с веб-интерфейсом, инкрементальные копии и хранение версий.

UrBackup — это уже полноценная система резервного копирования. Вместо отдельных скриптов и cron тут нужен отдельный сервер, к которому подключаются клиенты. Сам инструмент работает по сети, поддерживает файловые и образные бэкапы, умеет делать инкременты и хранить историю. 

Кроме того, в нём можно настроить расписание, политики хранения и отслеживать, когда бэкап прошёл, а не просто был запланирован. А в интерфейсе можно поглядеть состояние клиентов, объёмы данных, ошибки и статус последних копий. 

Минусы — требует отдельного сервера и чуть больше ресурсов, чем CLI-инструменты, настройка сложнее, и при плохом канале между VDS и сервером бэкапов возможны просадки по скорости.

8. Bacula

Для чего: бэкапы с управлением заданиями, хранением версий и разграничением ролей.

Bacula состоит из нескольких компонентов — директор управляет заданиями, сторедж хранит данные, а клиенты отправляют бэкапы. Система поддерживает инкрементальные и дифференциальные бэкапы, хранение версий, расписание, контроль выполнения заданий и восстановление на уровне файлов или целых систем. 

Работает Bacula по сети, поэтому можно собирать бэкапы с разных VDS. Это значит, что инструмент больше подойдёт тем, у кого несколько проектов и разные политики хранения. Также есть неплохая мобильная версия. 

Минусы — сложная архитектура, настройка занимает время, и документацию тут точно придётся читать, а также требует отдельного сервера и ресурсов под инфраструктуру.

9. Bareos

Для чего: бэкапы с управлением заданиями, хранением версий и веб-интерфейсом.

Bareos — это форк Bacula, который со временем ушёл в сторону более активной разработки и удобства эксплуатации. Архитектура та же, но сюда добавили более понятный веб-интерфейс.

Подходит для тех же сценариев, что и Bacula — несколько VDS, разные проекты, централизованное управление и контроль бэкапов. Можно настраивать задания, хранение версий, расписание, отслеживать статус и восстанавливать данные из одной точки. Работает также по сети. 

Минусы — такая же сложная система, требует отдельного сервера, ресурсов и времени на настройку. 

10. borgmatic

Для чего: автоматизация бэкапов на базе Borg с конфигами, расписанием и хуками.

Ну и заключительный игрок нашей подборки — borgmatic — это обвязка вокруг Borg, которая превращает набор команд в нормальный процесс. По сути, вы один раз описываете, что и куда бэкапить, а дальше запускаете всё одной командой или по расписанию. Пример базового конфигурационного файла:

source_directories:

- /home

- /etc

repositories:

- path: ssh://user@backup.server/repo

label: remote

keep_daily: 7

keep_weekly: 4

postgresql_databases:

- name: app_db

Хорошо подходит для VDS, где уже выбран Borg, но не хочется каждый раз писать длинные команды или держать всё в shell-скриптах. Конфигурация хранится в YAML, можно задать директории, исключения, политику хранения, а также хуки до и после бэкапа. Например, перед запуском сделать дамп базы, а после — отправить уведомление.

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

Что важно учесть при выборе 

Все инструменты из подборки можно использовать на любом российском VPS/VDS. Им не нужен доступ к инфраструктуре провайдера, ведь они работают внутри вашей ОС, читают файлы, делают копии и отправляют их туда, куда вы сами укажете.

Но есть несколько важных моментов:

• Если будете лить бэкапы во внешние хранилища или на другой сервер, смотрите на исходящую скорость и трафик. Нагрузку даёт не только первый бэкап, но и копии, особенно если на сервере много медиа, логов или дампов баз. 

• Бэкап лучше запускать в спокойные часы. На недорогих VDS проблемы часто возникают из-за диска. Если во время очистки старых снапшотов, сжатия и больших инкрементальных копий есть лаги — дело в I/O. 

• Копия должна храниться на другом VDS, сервере или в хранилище. Это надёжнее, потому что при сбое страдают все директории, включая /backup.

В целом, как обычно, советую не ограничиваться одним инструментом. Делитесь в комментариях, чем вы бэкапите свои VDS.

© 2026 ООО «МТ ФИНАНС»