Как да хоствате Duplicati самостоятелно през 2026 г.: криптирани архиви, монтирания и тестове за възстановяване

Ако вече сте опитвали да хоствате Duplicati самостоятелно, вероятно познавате това неприятно състояние: интерфейсът се показва, но container-ът вижда празен path, защото source-овете от host-а са монтирани на друго място. Създаването на container-а наново рядко решава несъответствие между URL адреси, state и зависимости.

Това ръководство използва един конкретен критерий за успешно завършване — архивирайте тестова директория в избраната дестинация, изтрийте source файл и го възстановете в чист alternate path. Всяко конфигурационно решение се оценява спрямо този критерий, а не спрямо зеления badge на container-а.

Портове, процеси и частни услуги

Полезната диаграма на Duplicati показва публичния route, частния порт 8200, границата на state-а и всяко необходимо supporting изискване. Отбележете кои стрелки пренасят credentials и кои представляват обикновен user traffic. Мрежовият contract за Duplicati е read-only source mounts плюс достъпно storage за backup destination. Дръжте private endpoint-ите във вътрешен DNS, разрешете само необходимите outbound calls и дайте на Duplicati service credential с ограничен обхват.

Докажете диаграмата с едно реално действие: архивирайте тестова директория в избраната дестинация, изтрийте source файл и го възстановете в чист alternate path. Вероятният натиск идва от броя source файлове, compression, encryption, latency на дестинацията и припокриването между scheduled jobs; наблюдавайте този path, вместо да третирате всички HTTP заявки като равностойни.

Диагностициране на Duplicati, който изглежда здрав

Изградете dashboards около броя source файлове, compression, encryption, latency на дестинацията и припокриването между scheduled jobs. CPU графика без този workload context не може да обясни защо Duplicati е бавен. Добавете synthetic или scheduled check, който се опитва да архивира тестова директория в избраната дестинация, да изтрие source файл и да го възстанови в чист alternate path, използвайки безопасни тестови данни.

Преди upgrade отчетете следния специфичен за приложението риск: промените в configuration database и backup format на Duplicati трябва да се тестват, без да се презаписва единственият remote backup set. Възстановете скорошен backup в изолирана deployment среда, изпълнете migrations там и сравнете поведението. Ако container-ът вижда празен path, защото source-овете от host-а са монтирани на друго място, проверете съответната граница — public origin, storage или dependency — преди да променяте несвързани настройки.

Какво трябва да премине, преди да постъпят реални данни в Duplicati

Release record-ът за Duplicati се нуждае от факти, а не от „изглежда добре“. Съхранете избрания image digest, checksum-а на конфигурацията, публичния hostname и резултат с timestamp за следното: архивирайте тестова директория в избраната дестинация, изтрийте source файл и го възстановете в чист alternate path. Използвайте примерни данни, които не са production, за да може проверката да се изпълнява след всяка deployment операция.

Докажете поотделно два lifecycle event-а. Подмяната на container трябва да запази нормалната работа; clean recovery трябва да покаже, че нова Duplicati instance може да импортира конфигурацията и да възстанови избрани файлове с проверени hash-ове. Докато проверките се изпълняват, измервайте броя source файлове, compression, encryption, latency на дестинацията и припокриването между scheduled jobs и запазете резултата като очаквания envelope за тази версия.

Тествайте и отказ или невалидно състояние: временно забранете на test identity да получава достъп до read-only source mounts плюс достъпно storage за backup destination. Duplicati трябва да се провали по начин, който позволява диагностика, и не трябва да презаписва здравия state. Върнете валидното състояние, изпълнете отново sample-а и прикрепете съответните redacted logs. Тези artifacts дават конкретни доказателства за бъдещо решение за rollback.

Превърнете локалната команда в inspectable service

Следващата команда прави границата на container-а видима, без да претендира, че 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 за read-only source mounts плюс достъпно storage за backup destination; използвайте private names за private services. Успешният launch приключва, когато можете да архивирате тестова директория в избраната дестинация, да изтриете source файл и да го възстановите в чист alternate path, а не когато docker ps изведе Up.

Направете възстановяването на Duplicati измеримо

Опишете state-а, преди да бъде създаден първият реален record: configuration database на Duplicati и отделно проверените backup sets. Монтирайте /config преди bootstrap, запишете безопасни примерни данни и подменете container-а, за да докажете, че path-ът действително е persistent. Потвърдете mount-а, като запишете безопасни данни, подмените Duplicati и ги прочетете обратно.

Snapshots са ценни за бърз rollback, но е необходим независим backup, когато host-ът или volume-ът изчезне. Възстановете в празна среда с pinned image и проверете, че нова Duplicati instance може да импортира конфигурацията и да възстанови избрани файлове с проверени hash-ове. Използвайте persistent volumes and snapshots, за да запазите тези два recovery механизма разграничени.

TLS е лесен; генерираните URL адреси — не

Изложете един HTTPS hostname за Duplicati; дръжте raw порт 8200 private. Дръжте management UI private или силно authenticated зад HTTPS. Така не позволявате на browsers и API clients да научат за два конкуриращи се адреса.

От clean client изпълнете познатата good транзакция и проверете първата failing request. Използвайте ръководството за custom domain, когато DNS или TLS са неправилно конфигурирани. Третирайте „container-ът вижда празен path, защото source-овете от host-а са монтирани на друго място“ като отделна application diagnosis, след като route-ът е доказано работещ.

Затегнете защитата на Duplicati след bootstrap

Bootstrap credentials са временни; trust model-ът е постоянен. При Duplicati следете за монтиране на backup source-ове с read-write достъп или загуба на encryption passphrase, монтирайте source-овете read-only, дръжте management UI private и съхранявайте backup passphrase извън server-а.

Генерирайте SETTINGS_ENCRYPTION_KEY еднократно, не го съхранявайте в Git и го запазете с recovery manifest-а, защото промяната му може да направи encrypted или signed application state невалиден. Стартирайте image-а без ненужни Linux capabilities и изложете само public application route-а. Поддържайте видимост върху administrator activity, без да записвате secret values.

Използвайте Dockup за platform layer-а

За Duplicati Dockup може да създаде route и TLS certificate, да запази mounts, да достави secrets и да постави read-only source mounts плюс достъпно storage за backup destination в private networking, като deployment-ва към Dockup или към attached servers.

Release gate-ът все още е конкретната Duplicati транзакция: архивирайте тестова директория в избраната дестинация, изтрийте source файл и го възстановете в чист alternate path. Проверете и recovery condition-а — нова Duplicati instance може да импортира конфигурацията и да възстанови избрани файлове с проверени hash-ове. Тези две проверки показват дали deployment-ът работи и дали може да бъде възстановен.

Често задавани въпроси

Какво е необходимо на Duplicati за production deployment?

Насочете Duplicati container-а на порт 8200 през един HTTPS origin. Поддържащото мрежово изискване е read-only source mounts плюс достъпно storage за backup destination. Не обявявайте Duplicati за готов, докато не можете да архивирате тестова директория в избраната дестинация, да изтриете source файл и да го възстановите в чист alternate path.

Кои данни на Duplicati трябва да бъдат включени в backup?

Направете /config persistent и включете configuration database на Duplicati и отделно проверените backup sets в същия recovery manifest. Clean Duplicati restore е успешен само когато нова Duplicati instance може да импортира конфигурацията и да възстанови избрани файлове с проверени hash-ове.

Необходим ли е HTTPS за Duplicati зад reverse proxy?

Използвайте HTTPS за публичния Duplicati origin и дръжте порт 8200 във вътрешния route. Конфигурирайте правилно настройката на Duplicati: дръжте management UI private или силно authenticated зад HTTPS. При Duplicati HTTPS защитава credentials или user content при пренос и поддържа consistent поведение на client-а, чувствително към origin-а.

Как трябва да се тества upgrade на Duplicati?

Възстановете текущия state на Duplicati в изолирана deployment среда, приложете кандидат-версията и повторете acceptance транзакцията. Обърнете специално внимание, защото промените в configuration database и backup format на Duplicati трябва да се тестват, без да се презаписва единственият remote backup set. Запазете предишния Duplicati image, докато не изясните границата на data migration и rollback.