Duplicati на сервере: частые ошибки и решения

MAATRIX

Duplicati — один из немногих бэкап-инструментов с полноценным веб-интерфейсом, поэтому его часто ставят те, кто не хочет разбираться с флагами restic или borg в консоли. Но у него своя коллекция граблей: SQLite-база, которая расходится с реальным состоянием хранилища, веб-панель, которая вдруг перестаёт открываться после смены домена, зависающие на часы задания при первом полном бэкапе. Ниже — конкретные ошибки, с которыми вы, скорее всего, столкнётесь на сервере, и что с ними делать.

Установка на сервере: Docker vs пакет

На VPS проще всего запускать Duplicati в Docker — так вы не тащите Mono-зависимости в систему и легко переносите контейнер целиком при миграции. Рабочий docker-compose.yml:

services:
  duplicati:
    image: linuxserver/duplicati:latest
    container_name: duplicati
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Moscow
      - CLI_ARGS=--webservice-interface=any
    volumes:
      - ./config:/config
      - ./backups:/backups
      - /home:/source/home:ro
      - /etc:/source/etc:ro
    ports:
      - "8200:8200"
    restart: unless-stopped

Ключевые моменты:

• PUID/PGID должны совпадать с владельцем каталогов, которые вы бэкапите изнутри контейнера — иначе Duplicati увидит файлы, но не сможет их прочитать, и в логе будет тихая ошибка доступа без явного объяснения.
• Источники монтируйте :ro — Duplicati не должен иметь возможность что-либо менять в бэкапируемых данных.
• Если ставите пакетом (.deb/.rpm) на голое железо — учтите, что классическая ветка Duplicati требует Mono, а более новая — .NET runtime. Смешивать версии на одной машине не стоит: обновление пакета поверх старой конфигурации — частая причина «база не открывается» после апгрейда.

Перед тем как городить Duplicati вручную, оцените, тянет ли ваш тариф компактинг и дедупликацию — это разбирали в статье про то, сколько ресурсов нужно VPS для бэкапов и архива.

Веб-интерфейс не открывается или ругается на пароль

Три сценария, которые встречаются чаще всего.

«Connection refused» на 8200. По умолчанию Duplicati слушает только 127.0.0.1. Если ставили не через Docker, а нативно как сервис, добавьте флаг:

--webservice-interface=any
--webservice-port=8200

В systemd-юните это правится в ExecStart= или через /etc/default/duplicati (путь зависит от дистрибутива — проверьте systemctl cat duplicati перед правкой).

«Host check failed» / «Invalid hostname» при заходе через домен или reverse proxy. Duplicati сверяет заголовок Host с внутренним списком разрешённых имён и по умолчанию пускает только localhost и IP-адреса. Если вы проксируете через nginx на backup.example.com, нужно явно разрешить хост:

--webservice-allowed-hostnames=backup.example.com,localhost,127.0.0.1

Для nginx-проксирования не забудьте прокинуть заголовки:

location / {
    proxy_pass http://127.0.0.1:8200;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Забыт пароль веб-интерфейса. Пароль хранится в конфиге, а не в отдельной БД, поэтому сброс — это правка Duplicati-server.sqlite (в Docker — /config/Duplicati/Duplicati-server.sqlite). Проще всего временно снять пароль через CLI на остановленном контейнере:

sqlite3 ./config/Duplicati/Duplicati-server.sqlite \
  "DELETE FROM Option WHERE Name='server-passphrase' OR Name='server-passphrase-salt';"

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

Ошибки базы данных: «unexpected difference», repair, recreate

Это самая частая категория проблем в Duplicati, и почти все они сводятся к рассинхрону между локальной SQLite-базой (она хранит индекс блоков) и файлами на удалённом хранилище.

Типичные сообщения в логе:

• Found N files that are missing from the remote storage
• Unexpected difference in fileset version
• The database was attempted repaired, but the repair did not complete

Порядок действий:

1. Сначала diagnose, не чините вслепую. Запустите проверку:

   duplicati-cli test <backup-id> all --dbpath=/config/Duplicati/xxxx.sqlite

1. Repair восстанавливает базу из данных на удалённом хранилище — это безопасная операция, ничего не удаляет:

   duplicati-cli repair "<remote-url>" \
     --dbpath=/config/Duplicati/xxxx.sqlite \
     --passphrase=<ваша-парольная-фраза>

1. Если repair не помог и база настолько разошлась, что чинить нечего — пересоздайте её с нуля из удалённого хранилища (это займёт время, пропорциональное числу файлов в бэкапе, БД строится заново из метаданных на сторадже):

   duplicati-cli repair "<remote-url>" \
     --dbpath=/config/Duplicati/xxxx_new.sqlite \
     --passphrase=<ваша-парольная-фраза> \
     --rebuild-missing-dblock-files

1. Если часть удалённых файлов реально повреждена или потеряна (например, объект в S3 удалили руками), используйте purge-broken-files — он уберёт из истории версии, которые физически восстановить нельзя, чтобы бэкап снова стал консистентным:

   duplicati-cli purge-broken-files "<remote-url>" \
     --dbpath=/config/Duplicati/xxxx.sqlite \
     --passphrase=<ваша-парольная-фраза>

Отдельно встречается database is locked — это SQLite, а не Duplicati, и почти всегда означает, что два процесса (например, ручной запуск CLI и фоновый сервис) одновременно лезут в один файл базы. Проверьте ps aux | grep duplicati и убедитесь, что работает ровно один процесс на задание.

Ошибки подключения к хранилищу: SFTP, S3, WebDAV

Duplicati поддерживает десяток бэкендов, и у каждого свой набор типичных ошибок.

Для SFTP и S3 полезно один раз прогнать duplicati-cli test-connection, прежде чем создавать задание в веб-интерфейсе — это отсекает половину проблем сразу:

duplicati-cli test-connection "s3://your-bucket/backups?s3-endpoint=s3.example.com&auth-username=KEY&auth-password=SECRET"

Если храните бэкапы на собственном сервере по SFTP, логично взять под это отдельный тариф — как выбрать его, разбирали в материале про VPS для бэкапов и архива.

Backup зависает или идёт мучительно долго

Первый полный бэкап большого объёма данных в Duplicati — самое медленное, что вы сделаете за всё время использования программы, и это не баг. Дедупликация построена на разбиении файлов на блоки (по умолчанию блок 100 КБ, а dblock — архив из блоков размером 50 МБ), и на первом проходе движок вычисляет хэши для всего массива данных, прежде чем что-либо загрузить.

Что реально помогает:

• Увеличьте размер блока для больших файлов (базы данных, видео, образы дисков) — --blocksize=1MB вместо дефолтных 100КБ резко снижает число записей в индексе и ускоряет и бэкап, и последующие проверки.
• Ограничьте параллелизм, если сервер и так под нагрузкой:

  --asynchronous-concurrent-upload-limit=2
  --throttle-upload=10MB

Без throttle Duplicati может забрать всю исходящую полосу VPS, что заметно на инстансах с ограниченным каналом.

• Отключите авто-компактинг на время первого бэкапа (--no-auto-compact=true), а запускайте его отдельным заданием по ночам — компактинг перезаписывает удалённые архивы и на медленном хранилище может занимать сравнимое с самим бэкапом время.
• Не бэкапьте миллионы мелких файлов одним заданием. Если у вас node_modules, кэши сборки или почтовые maildir-ящики с десятками тысяч файлов — вынесите их в отдельное задание или явно исключите через --exclude, они не нужны в бэкапе и только замедляют сканирование.

Учтите: приведённые цифры (10MB/2 потока и т.п.) — стартовая точка, а не универсальное значение. Реальные оптимальные параметры зависят от канала вашего VPS и загрузки хранилища — подбирайте по факту через несколько прогонов.

Шифрование, восстановление и перенос на другой сервер

Duplicati шифрует данные на клиенте (AES-256 по умолчанию, либо GPG) до того, как они уходят на хранилище. Это значит одну критичную вещь: если вы потеряете парольную фразу, данные не восстановит никто, включая разработчиков Duplicati — на сервере хранятся только зашифрованные блоки. Это не баг и не то, что можно «починить» через repair.

Что сделать заранее, чтобы не попасть в эту ситуацию:

• Экспортируйте конфигурацию задания через веб-интерфейс: *Задания → меню (⋮) → Экспорт → As Command-line*. Файл экспорта содержит и путь назначения, и парольную фразу — храните его отдельно от сервера, который бэкапите (в менеджере паролей, в сейфе, но не рядом с исходными данными).
• Если принципиально не хотите держать пароль в открытом виде на сервере — используйте GPG-шифрование с публичным ключом вместо симметричного AES: тогда для восстановления нужен приватный ключ, который можно вообще не хранить на сервере. Общие принципы такого подхода разбирали в статье про бэкап с шифрованием на сервере.

Перенос Duplicati на новый сервер делается одним из двух способов:

1. Перенос конфига целиком — скопируйте директорию /config/Duplicati (в Docker) или ~/.config/Duplicati на новую машину, поднимите тот же образ. Задания, история версий и расписание переедут как есть, менять ничего не нужно, если пути к источникам совпадают.
2. Без переноса конфига — создайте новое задание на новом сервере, укажите тот же URL хранилища и ту же парольную фразу, и в первый раз выполните не бэкап, а repair — Duplicati восстановит локальную базу из уже существующих данных в облаке, и вы продолжите бэкапиться в тот же набор версий без повторной полной заливки.

Второй способ особенно удобен, если вы меняете VPS целиком — подробный план такого переезда есть в статье про полный бэкап сервера.

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