Duplicacy на Ubuntu 24.04: пошаговая установка

MAATRIX

Если бэкапите сразу несколько серверов в одно и то же хранилище, restic и borg рано или поздно упрутся в блокировку репозитория: пока один клиент пишет или чистит старые снимки, второй ждёт или получает ошибку. Duplicacy решает это иначе — дедупликация построена на уровне отдельных chunks с алгоритмом, который не требует центральной блокировки, поэтому несколько машин могут спокойно писать в общее хранилище параллельно. Ниже — установка на Ubuntu 24.04 от бинарника до рабочего расписания в cron.

Установка Duplicacy

Duplicacy — бинарник на Go без зависимостей и без пакета в стандартных репозиториях Ubuntu, поэтому ставится вручную с GitHub-релизов проекта.

cd /tmp
curl -s https://api.github.com/repos/gilbertchen/duplicacy/releases/latest \
  | grep "browser_download_url.*linux_x64" \
  | cut -d '"' -f4 \
  | xargs curl -LO
chmod +x duplicacy_linux_x64_*
sudo mv duplicacy_linux_x64_* /usr/local/bin/duplicacy
duplicacy -version

Команда сама находит ссылку на актуальный linux_x64-релиз через GitHub API — не нужно подставлять номер версии руками и переписывать команду при каждом обновлении. Бинарник статический, обновление — это просто повторная загрузка и замена файла в /usr/local/bin, отдельного механизма самообновления, как у restic, здесь нет.

Важный момент по лицензии: CLI-версия Duplicacy бесплатна для личного некоммерческого использования. Для бизнеса разработчик (Acrosync) требует платную лицензию на каждый компьютер — актуальные условия и цену смотрите на официальном сайте проекта перед тем, как ставить инструмент на боевые сервера компании.

Инициализация репозитория и шифрование

Терминология Duplicacy отличается от restic и borg, и это первое, что путает при переходе: «репозиторий» здесь — это каталог с данными на сервере, который вы бэкапите, а не место назначения. Место назначения называется «storage». Инициализация выполняется прямо в каталоге с данными:

mkdir -p /var/www/myapp
cd /var/www/myapp
duplicacy init -e myserver-www /mnt/backup/duplicacy-storage

Флаг -e включает шифрование chunks паролем — без него Duplicacy пишет данные в storage открытым текстом, что приемлемо для локального доверенного диска, но не годится для SFTP или облака. Команда спросит пароль дважды и создаст в текущем каталоге скрытую папку .duplicacy/ с настройками (адрес storage, идентификатор снимка), сам пароль в открытом виде туда не попадает.

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

Для автоматических запусков из cron пароль удобнее не вводить интерактивно, а положить в переменную окружения:

export DUPLICACY_PASSWORD='ваш-пароль-от-storage'

Duplicacy читает переменные вида DUPLICACY_<ИМЯ>_PASSWORD, где <ИМЯ> — это имя storage из preferences (по умолчанию default для первого хранилища), так что при нескольких хранилищах у каждого будет своя переменная.

Хранилища: локальный диск, SFTP, S3 и B2

Duplicacy поддерживает больше десятка бэкендов, из них на практике для аренды VPS чаще всего используются локальный диск, SFTP на второй сервер и объектное S3-совместимое хранилище.

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

duplicacy init -e myserver-www /mnt/backup/duplicacy-storage

SFTP на отдельный сервер требует предварительно настроенного беспарольного SSH-доступа по ключу — без этого команда будет виснуть на запросе пароля в неинтерактивном режиме:

ssh-copy-id -i ~/.ssh/id_ed25519.pub backup@backup-host.example.com
ssh backup@backup-host.example.com "mkdir -p /home/backup/duplicacy-storage"
duplicacy init -e myserver-www sftp://backup@backup-host.example.com//home/backup/duplicacy-storage

Обратите внимание на двойной слэш после хоста — это способ Duplicacy указать абсолютный путь, одинарный слэш означает путь относительно домашней директории пользователя backup.

Для S3 и S3-совместимых хранилищ (Backblaze B2, Selectel Object Storage, Yandex Object Storage, MinIO на своём сервере) ключи задаются переменными окружения, а не флагами команды:

export DUPLICACY_S3_ID=ваш-access-key
export DUPLICACY_S3_KEY=ваш-secret-key
duplicacy init -e myserver-www s3://ru-central1@storage.example.com/bucket-name/duplicacy-storage

Для Backblaze B2 нативный бэкенд ещё проще — без ручного указания endpoint:

export DUPLICACY_B2_ID=keyID-из-b2
export DUPLICACY_B2_KEY=applicationKey-из-b2
duplicacy init -e myserver-www b2://bucket-name/duplicacy-storage

Бакет в обоих случаях должен существовать заранее — Duplicacy создаёт внутри него только структуру самого репозитория chunks, не сам бакет. Как и у любого инструмента с блочной дедупликацией, холодные классы хранения (Glacier-подобные) для storage Duplicacy не подходят: check и prune читают метаданные при каждом запуске, а не только при полном восстановлении.

Бэкап и восстановление

С инициализированным репозиторием сам бэкап — одна команда, запущенная из каталога с .duplicacy/:

cd /var/www/myapp
duplicacy backup -stats

Флаг -stats выводит статистику по загруженным и переиспользованным chunks — полезно, чтобы на глаз оценить, насколько эффективно работает дедупликация на конкретных данных. Список снимков (в терминологии Duplicacy — «revisions»):

duplicacy list

Восстановление устроено не так, как в restic: нельзя просто указать произвольную целевую папку флагом. Duplicacy восстанавливает либо на место, в тот же репозиторий, откуда бэкап делался, либо в новый каталог, который сначала нужно инициализировать той же парой «snapshot-id + storage»:

# восстановление на место, поверх текущих файлов
cd /var/www/myapp
duplicacy restore -r 5 -overwrite

# восстановление на другую машину или в новый каталог
mkdir -p /tmp/restore-myapp && cd /tmp/restore-myapp
duplicacy init myserver-www sftp://backup@backup-host.example.com//home/backup/duplicacy-storage
duplicacy restore -r 5

Без флага -overwrite команда в существующем репозитории только показывает, какие файлы отличаются от выбранной ревизии, но не трогает их — удобно для предварительной проверки перед реальным восстановлением. Эта двухшаговая логика (инициализация нового каталога как отдельного репозитория перед restore) — не самая интуитивная часть Duplicacy по сравнению с restic, но именно она даёт согласованность: восстанавливающий каталог всегда «знает», из какого storage и под каким snapshot-id он работает.

Ротация: prune и lock-free дедупликация

Здесь Duplicacy принципиально отличается от конкурентов. В restic и borg удаление старых снимков и связанной сборки мусора обычно предполагает эксклюзивный доступ к репозиторию — второй параллельный клиент может получить блокировку и отказ. Duplicacy вместо этого использует двухшаговую модель «fossil collection» на уровне chunks:

1. При prune chunks, на которые больше не ссылается ни один снимок, не удаляются сразу, а помечаются как «fossils».
2. При следующем запуске prune (обычно — следующим по расписанию) Duplicacy проверяет, не появились ли новые ссылки на эти chunks от других клиентов, писавших в то же время, и только тогда удаляет их физически.

Именно за счёт этого несколько серверов могут независимо бэкапиться в одно общее storage без центрального сервера блокировок — риск гонки исключён на уровне алгоритма, а не за счёт того, что клиенты «договариваются» друг с другом об очередности.

Политика хранения задаётся флагами -keep n:m — «начиная с ревизий старше m дней хранить одну версию на каждые n дней»:

duplicacy prune -keep 0:365 -keep 7:30 -keep 1:7

Это значит: снимки старше года удаляются полностью, от месяца до года остаётся один снимок в неделю, от недели до месяца — один в день, а всё, что младше недели, хранится целиком. Конкретные цифры подбирайте под свои требования к глубине истории и объёму storage — универсальной политики для всех проектов не существует.

Автоматизация: cron и мониторинг

Соберите переменные окружения и обе команды (backup и prune) в один скрипт — вручную забыть про ротацию проще, чем кажется.

sudo tee /usr/local/bin/duplicacy-backup.sh > /dev/null << 'EOF'
#!/bin/bash
set -euo pipefail

export DUPLICACY_PASSWORD='ваш-пароль-от-storage'

cd /var/www/myapp
/usr/local/bin/duplicacy backup -stats
/usr/local/bin/duplicacy prune -keep 0:365 -keep 7:30 -keep 1:7
EOF
sudo chmod 700 /usr/local/bin/duplicacy-backup.sh

Пароль в открытом виде внутри скрипта — компромисс ради простоты; если это неприемлемо для вашей модели угроз, храните его в файле с правами 600 и подставляйте через export DUPLICACY_PASSWORD=$(cat /etc/duplicacy/password). Дальше — обычная запись в crontab:

sudo crontab -e

0 3 * * * /usr/local/bin/duplicacy-backup.sh >> /var/log/duplicacy-backup.log 2>&1

Если формат расписания cron ещё не отработан на других задачах, посмотрите общий разбор настройки cron-задач на VPS — типичные ошибки там же: неверные права на скрипт и путаница с окружением пользователя, под которым выполняется задача. Сам по себе cron не сообщит, что бэкап упал с ошибкой посреди ночи — для этого нужен внешний контроль вроде мониторинга выполнения cron-задач через healthchecks.io, который поднимает тревогу, если ожидаемый сигнал не пришёл вовремя. Если для хранилища бэкапов нужен отдельный сервер, а не общий диск с продакшеном, стоит заранее прикинуть, какой VPS вообще брать под бэкапы и архив — по объёму диска и каналу это обычно другой профиль нагрузки, чем у боевого сервера.

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