Як розгорнути Duplicati на власному сервері у 2026 році: зашифровані резервні копії, монтування та тести відновлення

Якщо ви вже намагалися розгорнути Duplicati на власному сервері, вам, імовірно, знайомий цей неприємний стан: UI відкривається, але контейнер бачить порожній шлях, оскільки вихідні каталоги хоста було змонтовано в іншому місці. Повторне створення контейнера рідко вирішує розбіжність між URL, станом і залежностями.

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

Порти, процеси та приватні сервіси

Корисна схема Duplicati показує публічний маршрут, приватний порт 8200, межу стану та всі необхідні залежності. Позначте, які стрілки передають облікові дані, а які — звичайний користувацький трафік. Мережева модель Duplicati передбачає монтування вихідних даних лише для читання та доступне сховище призначення резервних копій. Залишайте приватні endpoints у внутрішньому DNS, дозволяйте лише необхідні вихідні з’єднання та надайте Duplicati service credential з обмеженими правами.

Підтвердьте схему реальною дією: створіть резервну копію тестового каталогу у вибране сховище, видаліть вихідний файл і відновіть його в чистий альтернативний шлях. Найімовірніше навантаження визначатиметься кількістю вихідних файлів, compression, encryption, затримкою сховища призначення та перетином запланованих завдань; моніторте саме цей шлях, а не сприймайте всі HTTP-запити як однакові.

Діагностика Duplicati, який виглядає справним

Побудуйте dashboards навколо кількості вихідних файлів, compression, encryption, затримки сховища призначення та перетину запланованих завдань. Графік CPU без контексту цього навантаження не пояснить, чому Duplicati працює повільно. Додайте synthetic або заплановану перевірку, яка намагається створити резервну копію тестового каталогу у вибране сховище, видалити вихідний файл і відновити його в чистий альтернативний шлях, використовуючи безпечні тестові дані.

Перед оновленням врахуйте специфічний для цього застосунку ризик: зміни в configuration database і backup format Duplicati потрібно тестувати, не перезаписуючи єдиний віддалений набір резервних копій. Відновіть недавню резервну копію в ізольованому розгортанні, виконайте там міграції та порівняйте поведінку. Якщо контейнер бачить порожній шлях, оскільки вихідні каталоги хоста було змонтовано в іншому місці, перевірте відповідну межу — public origin, сховище або залежність — перш ніж змінювати сторонні налаштування.

Що має пройти до появи реальних даних Duplicati

У release record для Duplicati потрібні факти, а не висновок «виглядає добре». Збережіть digest вибраного image, checksum конфігурації, публічне ім’я хоста та результат із часовою позначкою для такої перевірки: створити резервну копію тестового каталогу у вибране сховище, видалити вихідний файл і відновити його в чистий альтернативний шлях. Використовуйте невиробничі тестові дані, щоб перевірку можна було запускати після кожного deployment.

Підтвердьте окремо дві події життєвого циклу. Заміна контейнера має зберігати нормальну роботу; повне відновлення має показати, що новий екземпляр Duplicati може імпортувати конфігурацію та відновити вибрані файли з перевіреними hash. Поки виконуються перевірки, вимірюйте кількість вихідних файлів, compression, encryption, затримку сховища призначення та перетин запланованих завдань і зберігайте результат як очікуваний envelope для цієї версії.

Також перевірте заборонений або некоректний сценарій: тимчасово забороніть тестовій identity доступ до монтувань вихідних даних лише для читання та доступного сховища призначення резервних копій. Duplicati має завершитися з помилкою, яку можна діагностувати, і не повинен перезаписувати справний стан. Відновіть коректні умови, повторно запустіть тест і додайте відповідні redacted logs. Ці артефакти дадуть майбутньому рішенню про rollback конкретні докази.

Перетворіть локальну команду на сервіс, який можна перевіряти

Наведена нижче команда робить межу контейнера видимою, не створюючи вигляду, ніби всі зовнішні сервіси вже налаштовані.

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, монтування та listener. Додайте перевірені connection settings для монтувань вихідних даних лише для читання та доступного сховища призначення резервних копій; для приватних сервісів використовуйте приватні імена. Успішний запуск завершується не тоді, коли docker ps виводить Up, а коли ви можете створити резервну копію тестового каталогу у вибране сховище, видалити вихідний файл і відновити його в чистий альтернативний шлях.

Зробіть відновлення Duplicati вимірюваним

Зафіксуйте стан до створення першого реального запису: configuration database Duplicati та окремо перевірені backup sets. Змонтуйте /config до bootstrap, запишіть безпечні тестові дані та замініть контейнер, щоб довести, що цей шлях справді є постійним. Перевірте монтування, записавши безпечні дані, замінивши Duplicati та прочитавши їх назад.

Snapshots цінні для швидкого rollback, але коли хост або volume зникає, потрібна незалежна резервна копія. Відновіть дані в порожньому середовищі з pinned image і переконайтеся, що новий екземпляр Duplicati може імпортувати конфігурацію та відновити вибрані файли з перевіреними hash. Використовуйте persistent volumes and snapshots, щоб розділяти ці два механізми відновлення.

TLS — це просто, а згенеровані URL — ні

Відкрийте для Duplicati один HTTPS hostname, а raw port 8200 залиште приватним. Залишайте management UI приватним або захищеним надійною автентифікацією за HTTPS. Це не дозволить браузерам і API-клієнтам дізнатися про дві адреси, що конкурують між собою.

На чистому клієнті виконайте відому успішну транзакцію та перевірте перший запит, який завершився помилкою. Скористайтеся custom-domain guide, якщо проблема пов’язана з DNS або TLS. Сприймайте ситуацію «контейнер бачить порожній шлях, оскільки вихідні каталоги хоста було змонтовано в іншому місці» як окрему діагностику застосунку після підтвердження маршруту.

Посильте захист Duplicati після bootstrap

Bootstrap credentials є тимчасовими, а trust model — постійною. У випадку Duplicati звертайте увагу на монтування backup sources з правом запису та втрату encryption passphrase; монтуйте sources лише для читання, залишайте management UI приватним і зберігайте backup passphrase за межами сервера.

Згенеруйте SETTINGS_ENCRYPTION_KEY один раз, не додавайте його до Git і збережіть разом із recovery manifest, оскільки його зміна може зробити недійсним зашифрований або підписаний application state. Запускайте image без непотрібних Linux capabilities і відкривайте лише публічний application route. Забезпечте видимість дій адміністраторів, не записуючи secret values.

Використовуйте Dockup для platform layer

Для Duplicati Dockup може створити route і TLS certificate, зберегти mounts, доставити secrets і розмістити монтування вихідних даних лише для читання та доступне сховище призначення резервних копій у приватній мережі під час deployment у Dockup або на під’єднаних серверах.

Release gate усе одно визначається конкретною транзакцією Duplicati: створити резервну копію тестового каталогу у вибране сховище, видалити вихідний файл і відновити його в чистий альтернативний шлях. Також перевірте умову відновлення — новий екземпляр Duplicati може імпортувати конфігурацію та відновити вибрані файли з перевіреними hash. Ці дві перевірки показують, чи працює deployment і чи можна його відновити.

Поширені запитання

Що потрібно Duplicati для deployment у production?

Прокладіть маршрут від контейнера Duplicati на порту 8200 через один HTTPS origin. Мережева вимога для залежностей — монтування вихідних даних лише для читання та доступне сховище призначення резервних копій. Не вважайте Duplicati готовим, доки не зможете створити резервну копію тестового каталогу у вибране сховище, видалити вихідний файл і відновити його в чистий альтернативний шлях.

Які дані Duplicati потрібно включити до резервної копії?

Забезпечте постійне зберігання /config і додайте configuration database Duplicati та окремо перевірені backup sets до того самого recovery manifest. Відновлення Duplicati у чистому середовищі вважається успішним лише тоді, коли новий екземпляр Duplicati може імпортувати конфігурацію та відновити вибрані файли з перевіреними hash.

Чи потрібен Duplicati HTTPS за reverse proxy?

Використовуйте HTTPS для публічного Duplicati origin, а порт 8200 залишайте у внутрішньому маршруті. Правильно застосуйте налаштування Duplicati: management UI має бути приватним або захищеним надійною автентифікацією за HTTPS. Для Duplicati HTTPS захищає облікові дані або користувацький контент під час передавання та забезпечує узгоджену поведінку клієнтів, чутливу до origin.

Як тестувати оновлення Duplicati?

Відновіть поточний стан Duplicati в ізольованому deployment, застосуйте candidate version і повторіть acceptance transaction. Будьте особливо уважні, оскільки зміни в configuration database і backup format Duplicati потрібно тестувати, не перезаписуючи єдиний віддалений набір резервних копій. Зберігайте попередній Duplicati image, доки не буде зрозумілою межа міграції даних і rollback.