Как разместить Duplicati на собственном сервере в 2026 году: зашифрованные резервные копии, монтирование и тесты восстановления
Практическое руководство по самостоятельному размещению Duplicati: Docker, порты, постоянное хранение данных, TLS, безопасность, резервное копирование и проблемы, которые мешают использовать сервис в production. Актуально для 2026 года.
Если вы уже пытались разместить Duplicati на собственном сервере, вам наверняка знакома эта раздражающая ситуация: UI открывается, но контейнер видит пустой путь, потому что исходные каталоги на хосте были смонтированы в другом месте. Пересоздание контейнера редко устраняет несоответствие между URL, состоянием и зависимостями.
В этом руководстве используется один конкретный критерий готовности — создать резервную копию тестового каталога в выбранное хранилище, удалить исходный файл и восстановить его в чистый альтернативный путь. Каждое решение по конфигурации оценивается по этому критерию, а не по зелёному статусу контейнера.
Порты, процессы и приватные сервисы
Полезная схема Duplicati показывает публичный маршрут, приватный порт 8200, границу состояния и все необходимые вспомогательные компоненты. Отметьте, какие стрелки передают учётные данные, а какие обозначают обычный пользовательский трафик. Сетевой контракт Duplicati — это монтирование исходных каталогов только для чтения и доступное сетевое хранилище резервных копий. Держите приватные endpoints во внутреннем DNS, разрешайте только необходимые исходящие вызовы и выдайте Duplicati сервисные учётные данные с ограниченной областью доступа.
Проверьте схему реальным действием: создайте резервную копию тестового каталога в выбранное хранилище, удалите исходный файл и восстановите его в чистый альтернативный путь. На производительность, скорее всего, будут влиять количество исходных файлов, compression, encryption, задержка хранилища назначения и пересечение запланированных заданий; отслеживайте именно этот путь, а не считайте все HTTP-запросы одинаковыми.
Диагностика Duplicati, который выглядит исправным
Стройте dashboards вокруг количества исходных файлов, compression, encryption, задержки хранилища назначения и пересечения запланированных заданий. График CPU без контекста нагрузки не объяснит, почему Duplicati работает медленно. Добавьте synthetic или scheduled check, который пытается создать резервную копию тестового каталога в выбранное хранилище, удалить исходный файл и восстановить его в чистый альтернативный путь, используя безопасные тестовые данные.
Перед обновлением учтите специфический для приложения риск: изменения в configuration database и формате резервных копий Duplicati нужно тестировать, не перезаписывая единственный удалённый набор резервных копий. Восстановите недавнюю резервную копию в изолированном deployment, выполните там migrations и сравните поведение. Если контейнер видит пустой путь, потому что исходные каталоги на хосте были смонтированы в другом месте, сначала проверьте соответствующую границу — публичный origin, хранилище или dependency, — и только потом изменяйте настройки, не связанные с проблемой.
Что должно пройти до появления реальных данных Duplicati
В release record для Duplicati нужны факты, а не формулировка «вроде работает». Сохраните digest выбранного image, checksum конфигурации, публичный hostname и результат с timestamp для следующей проверки: создать резервную копию тестового каталога в выбранное хранилище, удалить исходный файл и восстановить его в чистый альтернативный путь. Используйте непроизводственные тестовые данные, чтобы проверку можно было выполнять после каждого deployment.
Проверьте два lifecycle-события отдельно. Замена контейнера должна сохранять штатную работу; чистое восстановление должно показать, что новый экземпляр Duplicati может импортировать конфигурацию и восстановить выбранные файлы с проверенными hashes. Пока выполняются проверки, измеряйте количество исходных файлов, compression, encryption, задержку хранилища назначения и пересечение запланированных заданий, а результат сохраняйте как ожидаемый envelope для этой версии.
Проверьте и запрещённое или некорректное условие: временно запретите тестовой identity доступ к монтированию исходных каталогов только для чтения и доступному сетевому хранилищу резервных копий. Duplicati должен завершиться с диагностируемой ошибкой и не перезаписать корректное состояние. Верните рабочее условие, повторно запустите проверку на тестовых данных и приложите соответствующие redacted logs. Эти артефакты дадут будущему решению об откате конкретные подтверждения.
Превратите локальную команду в сервис, состояние которого можно проверять
Следующая команда делает границу контейнера видимой, не создавая видимость полного provisioning всех внешних сервисов.
docker run -d \
--name duplicati \
--restart unless-stopped \
-p 127.0.0.1:8200:8200 \
-v duplicati-data:/config \
-v /srv/data:/source:ro \
-e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
lscr.io/linuxserver/duplicati:latest
До открытия ingress проверьте resolved environment, mounts и listener. Добавьте проверенные connection settings для монтирования исходных каталогов только для чтения и доступного сетевого хранилища резервных копий; для приватных сервисов используйте приватные имена. Успешный запуск считается завершённым, когда вы можете создать резервную копию тестового каталога в выбранное хранилище, удалить исходный файл и восстановить его в чистый альтернативный путь, а не когда docker ps выводит Up.
Сделайте восстановление Duplicati измеримым
До создания первой реальной записи перечислите состояние: configuration database Duplicati и отдельно проверенные backup sets. Смонтируйте /config до bootstrap, запишите безопасные тестовые данные и замените контейнер, чтобы доказать фактическую постоянность этого пути. Подтвердите монтирование: запишите безопасные данные, замените Duplicati и прочитайте их обратно.
Snapshots полезны для быстрого отката, но при исчезновении хоста или volume нужна независимая резервная копия. Выполните восстановление в пустом окружении с pinned image и проверьте, что новый экземпляр Duplicati может импортировать конфигурацию и восстановить выбранные файлы с проверенными hashes. Используйте persistent volumes and snapshots, чтобы разделять эти два механизма восстановления.
TLS прост, а сгенерированные URL — нет
Опубликуйте один HTTPS hostname для Duplicati, а исходный порт 8200 оставьте приватным. Держите management UI приватным или используйте строгую authentication за HTTPS. Это не позволит браузерам и API-клиентам узнавать два конкурирующих адреса.
На чистом клиенте выполните проверенную транзакцию и изучите первый запрос, завершившийся ошибкой. Если проблема связана с DNS или TLS, воспользуйтесь руководством по custom domain. Считайте ситуацию «контейнер видит пустой путь, потому что исходные каталоги на хосте были смонтированы в другом месте» отдельной диагностикой приложения после того, как маршрут подтверждён.
Защитите Duplicati после bootstrap
Учётные данные bootstrap временные, а trust model постоянна. В Duplicati следите за тем, чтобы исходные каталоги резервного копирования не монтировались с правами на запись и чтобы не была утрачена passphrase шифрования; монтируйте исходные каталоги только для чтения, держите management UI приватным и храните passphrase резервных копий за пределами сервера.
Сгенерируйте SETTINGS_ENCRYPTION_KEY один раз, не добавляйте его в Git и сохраните вместе с recovery manifest, поскольку его изменение может сделать недействительным зашифрованное или подписанное состояние приложения. Запускайте image без ненужных Linux capabilities и публикуйте только публичный application route. Сохраняйте информацию об активности администраторов, не записывая секретные значения.
Используйте Dockup для platform layer
Для Duplicati Dockup может создать route и TLS certificate, сохранить mounts, передать secrets и разместить монтирование исходных каталогов только для чтения и доступное сетевое хранилище резервных копий в приватной сети, выполняя deployment либо в Dockup, либо на подключённых серверах.
Release gate по-прежнему определяется конкретной транзакцией Duplicati: создать резервную копию тестового каталога в выбранное хранилище, удалить исходный файл и восстановить его в чистый альтернативный путь. Также проверьте условие восстановления — новый экземпляр Duplicati может импортировать конфигурацию и восстановить выбранные файлы с проверенными hashes. Эти две проверки показывают, работает ли deployment и можно ли его восстановить.
Часто задаваемые вопросы
Что нужно Duplicati для deployment в production?
Направьте контейнер Duplicati на порту 8200 через один HTTPS origin. Требование к поддерживающей сети — монтирование исходных каталогов только для чтения и доступное сетевое хранилище резервных копий. Не объявляйте Duplicati готовым, пока не сможете создать резервную копию тестового каталога в выбранное хранилище, удалить исходный файл и восстановить его в чистый альтернативный путь.
Какие данные Duplicati должны входить в резервную копию?
Сохраняйте /config и включайте configuration database Duplicati и отдельно проверенные backup sets в один recovery manifest. Восстановление Duplicati в чистом окружении считается успешным только тогда, когда новый экземпляр Duplicati может импортировать конфигурацию и восстановить выбранные файлы с проверенными hashes.
Требуется ли Duplicati HTTPS за reverse proxy?
Используйте HTTPS для публичного Duplicati origin, а порт 8200 оставьте во внутреннем маршруте. Корректно примените настройку Duplicati: держите management UI приватным или используйте строгую authentication за HTTPS. Для Duplicati HTTPS защищает учётные данные или пользовательский контент при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.
Как тестировать обновление Duplicati?
Восстановите текущее состояние Duplicati в изолированном deployment, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание: изменения в configuration database и формате резервных копий Duplicati нужно тестировать, не перезаписывая единственный удалённый набор резервных копий. Сохраняйте предыдущий Duplicati image, пока не будут понятны границы миграции данных и rollback.