Как установить и настроить Duplicacy на VPS

MAATRIX

Если вы уже пробовали restic или borgbackup, знаете главную боль: пока идёт prune, бэкап с другого сервера в то же хранилище лучше не запускать — есть риск гонки и повреждённого репозитория. Duplicacy решает это иначе — за счёт дедупликации на уровне chunks с двухшаговым удалением "мёртвых" данных, несколько машин могут писать в одно и то же хранилище параллельно, не мешая друг другу. Ниже — установка, инициализация хранилища, бэкап, восстановление и автоматизация на VPS с нуля.

Что такое Duplicacy и чем он отличается от restic и borgbackup

Duplicacy — кросс-платформенная консольная утилита для дедуплицирующего бэкапа (Linux, macOS, Windows, один и тот же бинарник для всех). Как и restic, она режет файлы на чанки переменного размера (content-defined chunking, в среднем около 4 МБ — это ориентир, у вас будет отличаться в зависимости от данных) и хранит только уникальные блоки, адресуемые по хешу содержимого.

Ключевое отличие — в механизме удаления устаревших данных. У restic и borgbackup prune требует эксклюзивного лока на весь репозиторий: пока идёт очистка, писать в хранилище больше никому нельзя, иначе есть риск повредить метаданные. Duplicacy вместо этого помечает чанки-кандидаты на удаление как "fossils" и физически стирает их только вторым проходом, если ни один клиент за это время их не затронул. Это и есть блокировка на уровне chunks, а не всего репозитория — несколько VPS с разными snapshot ID могут одновременно бэкапиться и чиститься в одно общее хранилище без централизованного лок-сервера.

Если сомневаетесь, какой из трёх инструментов брать под конкретный сценарий — есть отдельный разбор restic против borgbackup с плюсами и минусами каждого. Практический вывод по Duplicacy: если у вас несколько серверов (веб, база, файловое хранилище) и вы хотите слать бэкапы в одно S3-совместимое или SFTP-хранилище без танцев с блокировками — Duplicacy закрывает этот сценарий из коробки.

Важная оговорка по лицензии: сам CLI-бинарник Duplicacy бесплатен, включая коммерческое использование command-line версии — платной является только их GUI-обёртка (Duplicacy Web Edition / Vertical Backup). Для скриптов и cron на VPS это не имеет значения, но если захотите веб-интерфейс — проверьте актуальные условия лицензии на сайте разработчика перед внедрением.

Установка Duplicacy на VPS

Официальный способ — скачать статический бинарник с GitHub-релизов проекта (gilbertchen/duplicacy). Пакетов в стандартных репозиториях Ubuntu/Debian/AlmaLinux нет, поэтому ставим руками:

cd /tmp
# посмотрите актуальную версию на странице релизов и подставьте её в URL
curl -LO https://github.com/gilbertchen/duplicacy/releases/download/v3.2.3/duplicacy_linux_x64_3.2.3
chmod +x duplicacy_linux_x64_3.2.3
sudo mv duplicacy_linux_x64_3.2.3 /usr/local/bin/duplicacy
duplicacy -version

Версию из примера не копируйте вслепую — на странице релизов может быть более свежая сборка, номер стоит сверить перед загрузкой. Бинарник статически слинкован, зависимостей вроде Go-рантайма на сервере не требует.

Для восстановления на другой машине (например, локально на ноутбуке для сверки бэкапа) ставится точно так же — просто скачайте сборку под нужную ОС.

Инициализация репозитория и выбор хранилища

Duplicacy привязывает бэкап к конкретной директории — репозиторию. Заходите в папку, которую хотите бэкапить (или создаёте символическую точку, если бэкапите несколько несвязанных путей), и инициализируете:

mkdir -p /opt/backup-src && cd /opt/backup-src
# локальное хранилище на отдельном диске/разделе
duplicacy init -e myvps-web /mnt/backup-storage

# или SFTP на другой сервер (двойной слэш перед абсолютным путём)
duplicacy init -e myvps-web sftp://backupuser@backup.example.com//home/backupuser/duplicacy

# или S3-совместимое хранилище (MinIO, Backblaze B2, Wasabi и т.п. через S3 API)
duplicacy init -e myvps-web s3://eu-central-1@s3.example.com/my-backup-bucket/web

Флаг -e включает клиентское шифрование AES-256 — Duplicacy спросит пароль хранилища и попросит подтвердить его повторно. Этот пароль нигде не хранится на сервере в открытом виде и не восстанавливается — потеряете его, потеряете доступ ко всем данным в хранилище. Сохраните его в менеджере паролей сразу же, отдельно от сервера.

myvps-web — это snapshot ID, имя, под которым бэкапы этого репозитория будут видны в общем хранилище. Если бэкапите несколько серверов в одно хранилище — каждому дайте уникальный ID (myvps-db, myvps-files и т.д.), это и есть основа для параллельной работы без блокировок.

Для S3-совместимых и B2-хранилищ ключи доступа можно не прописывать в конфиге, а передавать через переменные окружения перед командой:

export DUPLICACY_S3_ID=ваш_access_key
export DUPLICACY_S3_SECRET=ваш_secret_key
duplicacy backup

Так секреты не попадут в .duplicacy/preferences в открытом виде и не утекут при случайном коммите конфигов в git.

Первый бэкап и фильтры исключений

После init в директории появляется скрытая папка .duplicacy/ с файлом preferences. Прежде чем гнать первый полный бэкап, настройте исключения — файл .duplicacy/filters:

# .duplicacy/filters
-*.log
-*.tmp
-node_modules/
-.cache/
-*/tmp/*
+/etc/nginx/*.conf

Синтаксис простой: строка с - исключает по маске (относительно корня репозитория), + — явно включает (полезно, когда общее правило слишком широкое, а конкретный путь нужен). Порядок правил важен — они применяются сверху вниз.

Запуск бэкапа:

duplicacy backup -stats

Флаг -stats покажет, сколько данных прочитано, сколько реально ушло в хранилище (после дедупликации) и сколько чанков переиспользовано из предыдущих снапшотов. На первом запуске переиспользовать нечего, зато сразу видно скорость upload — если она вас не устраивает, смотрите -threads N для параллельной загрузки чанков (по умолчанию используется несколько потоков, но на медленном аплинке лучше подобрать значение под свой канал вручную).

Список снапшотов проверяется так:

duplicacy list

Если бэкапите несколько путей на одном сервере в одно хранилище через разные snapshot ID — добавить второе хранилище к тому же репозиторию можно командой duplicacy add, не переинициализируя всё заново.

Восстановление данных и просмотр ревизий

Каждый успешный backup создаёт новую ревизию (номер по порядку). Посмотреть, что менялось между ревизиями, и найти нужную точку восстановления:

duplicacy list -a          # снапшоты всех репозиториев в хранилище
duplicacy diff -r 5 -r 8   # что изменилось между ревизией 5 и 8
duplicacy history путь/к/файлу.conf   # история изменений конкретного файла

Восстановление — в отдельную пустую директорию, чтобы не перезаписать текущее состояние вслепую:

mkdir -p /opt/restore-test && cd /opt/restore-test
duplicacy init -e myvps-web s3://eu-central-1@s3.example.com/my-backup-bucket/web
duplicacy restore -r 8

Можно восстановить не всё, а конкретные файлы по маске:

duplicacy restore -r 8 etc/nginx/nginx.conf var/www/site/wp-config.php

Для перезаписи файлов прямо в рабочей директории добавляется -overwrite — делайте так только осознанно, а не когда просто проверяете содержимое бэкапа. Хорошая практика — раз в месяц реально поднимать восстановление на тестовом VPS и проверять, что сервис с этими файлами стартует, а не полагаться на то, что бэкап "наверное рабочий".

Автоматизация: cron, retention policy и несколько источников

Ручной запуск не масштабируется — настраиваем cron-задачу и политику хранения (prune), чтобы старые ревизии не копились бесконечно и не раздували хранилище:

#!/bin/bash
# /usr/local/bin/duplicacy-backup.sh
cd /opt/backup-src || exit 1

/usr/local/bin/duplicacy backup -stats >> /var/log/duplicacy-backup.log 2>&1

# храним: все ревизии за последние 7 дней,
# 1 ревизию в неделю за последние 30 дней,
# 1 ревизию в месяц за последний год
/usr/local/bin/duplicacy prune -keep 0:365 -keep 7:30 -keep 1:7 >> /var/log/duplicacy-backup.log 2>&1

chmod +x /usr/local/bin/duplicacy-backup.sh
crontab -e

# бэкап каждую ночь в 2:30
30 2 * * * /usr/local/bin/duplicacy-backup.sh

Формат -keep N:M читается так: "начиная с M дней назад храни не чаще одной ревизии в N дней" (0:365 — вообще ничего не удалять младше суток, 7:30 — не чаще раза в неделю для ревизий старше 30 дней, 1:7 — не чаще раза в день для последней недели). Порядок правил и логика на старте путают почти всех — проверьте duplicacy prune -dry-run -keep ... перед первым реальным запуском на проде, чтобы увидеть, что именно будет удалено, не удаляя ничего на самом деле.

Для нескольких серверов в одно хранилище схема та же: на каждом VPS свой snapshot ID, свой cron с тем же расписанием (или со сдвигом на 5-10 минут, чтобы не толпиться в одну секунду), и общий prune можно запускать хоть с каждого сервера, хоть с выделенной машины через -a (по всем репозиториям сразу) — благодаря блокировке на уровне chunks они не будут ломать данные друг друга.

Раз в неделю стоит гонять duplicacy check, который сверяет целостность метаданных и наличие всех чанков в хранилище без полного скачивания данных — это дешевле по трафику, чем реальное восстановление, но покрывает не всё: битые чанки, которые check не затронул на диске хранилища напрямую, вылезут только при реальном restore.

Наблюдение за бэкапами и типичные проблемы

Сам Duplicacy не шлёт уведомления — он просто пишет в stdout/лог-файл и возвращает код выхода. Минимальная обвязка для проверки, что бэкап прошёл, а не тихо упал:

#!/bin/bash
cd /opt/backup-src || exit 1
if /usr/local/bin/duplicacy backup -stats >> /var/log/duplicacy-backup.log 2>&1; then
    echo "OK: $(date)" >> /var/log/duplicacy-status.log
else
    echo "FAIL: $(date)" >> /var/log/duplicacy-status.log
    # здесь можно дёрнуть webhook, telegram-бота или пинг из статьи про [мониторинг cron-задач через healthchecks.io](/blog/healthchecks-io-monitoring-cron-zadach/)
fi

Частые проблемы на практике:

• storage password incorrect — либо реально не тот пароль, либо переменная DUPLICACY_PASSWORD (если используете её вместо интерактивного ввода) обрезана в cron-окружении из-за кавычек. Проверяйте env внутри самого cron-джоба, а не в интерактивной сессии — окружения различаются.
• Бэкап "висит" на большом количестве мелких файлов — типично для node_modules, кэшей фреймворков, почтовых очередей. Разбирайтесь через -stats (сколько файлов просканировано) и добавляйте исключения в filters, а не увеличивайте таймауты вслепую.
• Хранилище растёт быстрее, чем ожидалось — обычно означает, что prune не запускается по расписанию (упал по ошибке до backup, exit code не проверялся) или retention-политика слишком щедрая для объёма изменяемых данных.

Частые вопросы