Jak self-hostovat Duplicati v roce 2026: šifrované zálohy, mounty a testy obnovy

Pokud jste se už pokoušeli self-hostovat Duplicati, pravděpodobně znáte tento frustrující stav: UI se zobrazí, ale kontejner vidí prázdnou cestu, protože zdrojové adresáře z hostitele byly připojeny jinam. Opětovné vytvoření kontejneru obvykle nevyřeší nesoulad mezi URL, stavem a závislostmi.

Tento návod používá jedno konkrétní kritérium dokončení — zazálohovat testovací adresář do zvoleného cíle, smazat zdrojový soubor a obnovit ho do čisté alternativní cesty. Každé konfigurační rozhodnutí posuzujeme podle tohoto kritéria, nikoli podle zeleného indikátoru kontejneru.

Porty, procesy a privátní služby

Užitečný diagram Duplicati zobrazuje veřejnou trasu, privátní port 8200, hranici stavu a všechny podpůrné požadavky. Označte, které šipky přenášejí přihlašovací údaje a které představují běžný provoz uživatelů. Síťový kontrakt pro Duplicati tvoří mounty zdrojů jen pro čtení a dostupné úložiště cíle zálohy. Privátní endpointy ponechte na interním DNS, povolte pouze potřebná odchozí volání a Duplicati přidělte service credential s omezeným rozsahem oprávnění.

Diagram ověřte jednou skutečnou akcí: zazálohujte testovací adresář do zvoleného cíle, smažte zdrojový soubor a obnovte ho do čisté alternativní cesty. Pravděpodobné zatížení vychází z počtu zdrojových souborů, komprese, šifrování, latence cíle a překrývání naplánovaných úloh; sledujte tuto cestu, místo abyste všechny HTTP requesty považovali za rovnocenné.

Jak diagnostikovat Duplicati, které vypadá zdravě

Dashboardy postavte na počtu zdrojových souborů, kompresi, šifrování, latenci cíle a překrývání naplánovaných úloh. Graf CPU bez kontextu tohoto workloadu nedokáže vysvětlit, proč je Duplicati pomalé. Přidejte syntetický nebo naplánovaný check, který se pokusí zazálohovat testovací adresář do zvoleného cíle, smazat zdrojový soubor a obnovit ho do čisté alternativní cesty s použitím neškodných testovacích dat.

Před upgradem zohledněte toto riziko specifické pro aplikaci: změny konfigurační databáze a formátu záloh Duplicati je nutné testovat bez přepsání jediné vzdálené backup sady. Obnovte aktuální zálohu do izolovaného deploymentu, spusťte v něm migrace a porovnejte chování. Pokud kontejner vidí prázdnou cestu, protože zdrojové adresáře z hostitele byly připojeny jinam, zkontrolujte příslušnou hranici — veřejný origin, úložiště nebo závislost — dříve, než začnete měnit nesouvisející nastavení.

Co musí projít, než dorazí skutečná data Duplicati

Záznam o release pro Duplicati potřebuje fakta, ne „vypadá to dobře“. Uložte digest zvoleného image, checksum konfigurace, veřejný hostname a výsledek s timestampem pro tuto operaci: zazálohovat testovací adresář do zvoleného cíle, smazat zdrojový soubor a obnovit ho do čisté alternativní cesty. Použijte neprodukční ukázková data, aby bylo možné check spustit po každém deploymentu.

Dvě události životního cyklu prokažte odděleně. Nahrazení kontejneru musí zachovat běžný provoz; čistá obnova musí ukázat, že nová instance Duplicati dokáže importovat konfiguraci a obnovit vybrané soubory s ověřenými hashi. Během checků měřte počet zdrojových souborů, kompresi, šifrování, latenci cíle a překrývání naplánovaných úloh a výsledek si ponechte jako očekávaný envelope pro tuto verzi.

Otestujte také zamítnutý nebo neplatný stav: dočasně testovací identitě odeberte přístup k mountům zdrojů jen pro čtení a dostupnému úložišti cíle zálohy. Duplicati by mělo selhat diagnostikovatelným způsobem a nemělo by přepsat zdravý stav. Vraťte platný stav, znovu spusťte ukázkový test a přiložte relevantní redigované logy. Tyto artefakty poskytnou budoucímu rozhodnutí o rollbacku konkrétní důkazy.

Proměňte lokální příkaz v inspectovatelnou službu

Následující příkaz zviditelní hranici kontejneru, aniž by předstíral provisioning všech externích služeb.

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

Před otevřením ingressu zkontrolujte výsledné prostředí, mounty a listener. Přidejte ověřené connection settings pro mounty zdrojů jen pro čtení a dostupné úložiště cíle zálohy; pro privátní služby používejte privátní názvy. Úspěšný launch končí ve chvíli, kdy můžete zazálohovat testovací adresář do zvoleného cíle, smazat zdrojový soubor a obnovit ho do čisté alternativní cesty, nikoli ve chvíli, kdy docker ps vypíše Up.

Udělejte obnovu Duplicati měřitelnou

Ještě před vytvořením prvního skutečného záznamu sepište stav: konfigurační databázi Duplicati a samostatně ověřené backup sady. Připojte /config ještě před bootstrapem, zapište neškodná ukázková data a nahraďte kontejner, abyste prokázali, že je tato cesta skutečně perzistentní. Mount potvrďte zápisem neškodných dat, nahrazením Duplicati a jejich opětovným načtením.

Snapshoty jsou cenné pro rychlý rollback, ale v případě ztráty hostitele nebo volume je potřeba nezávislá záloha. Obnovte data do prázdného prostředí s připnutým image a ověřte, že nová instance Duplicati dokáže importovat konfiguraci a obnovit vybrané soubory s ověřenými hashi. Použijte persistent volumes and snapshots, abyste tyto dva mechanismy obnovy udrželi oddělené.

TLS je snadné; generované URL nikoli

Vystavte pro Duplicati jeden HTTPS hostname; raw port 8200 ponechte privátní. Management UI ponechte privátní nebo ho za HTTPS silně autentizujte. Zabráníte tak tomu, aby se prohlížeče a API klienti dozvěděli o dvou konkurenčních adresách.

Z čistého klienta spusťte známou funkční transakci a zkontrolujte první request, který selže. Pokud je problém v DNS nebo TLS, použijte custom-domain guide. Stav „kontejner vidí prázdnou cestu, protože zdrojové adresáře z hostitele byly připojeny jinam“ řešte jako samostatnou aplikační diagnostiku až poté, co ověříte trasu.

Zabezpečte Duplicati po bootstrapu

Bootstrap credentials jsou dočasné; trust model je trvalý. U Duplicati sledujte, zda nejsou zdroje záloh připojené s právem zápisu a zda nedojde ke ztrátě šifrovací passphrase. Zdroje připojujte jen pro čtení, management UI ponechte privátní a passphrase k zálohám ukládejte mimo server.

SETTINGS_ENCRYPTION_KEY vygenerujte jednou, nepřidávejte ho do Gitu a uchovejte ho s recovery manifestem, protože jeho změna může zneplatnit zašifrovaný nebo podepsaný aplikační stav. Image spouštějte bez nepotřebných linuxových capabilities a vystavte pouze veřejnou aplikační trasu. Aktivitu administrátorů ponechte viditelnou, ale nezapisujte tajné hodnoty.

Použijte Dockup pro platformní vrstvu

U Duplicati může Dockup vytvořit trasu a TLS certifikát, zachovat mounty, doručit secrets a umístit mounty zdrojů jen pro čtení i dostupné úložiště cíle zálohy do privátní sítě při nasazení na Dockup nebo na připojené servery.

Release gate stále představuje konkrétní transakce Duplicati: zazálohovat testovací adresář do zvoleného cíle, smazat zdrojový soubor a obnovit ho do čisté alternativní cesty. Ověřte také podmínku obnovy — nová instance Duplicati dokáže importovat konfiguraci a obnovit vybrané soubory s ověřenými hashi. Tyto dva checky ukazují, zda deployment funguje a zda ho lze obnovit.

Často kladené otázky

Co Duplicati potřebuje pro produkční deployment?

Kontejner Duplicati veďte přes port 8200 jedním HTTPS originem. Požadavek podpůrné sítě tvoří mounty zdrojů jen pro čtení a dostupné úložiště cíle zálohy. Duplicati nepovažujte za připravené, dokud nemůžete zazálohovat testovací adresář do zvoleného cíle, smazat zdrojový soubor a obnovit ho do čisté alternativní cesty.

Která data Duplicati patří do zálohy?

Zachovejte /config a do stejného recovery manifestu zahrňte konfigurační databázi Duplicati i samostatně ověřené backup sady. Čistá obnova Duplicati je úspěšná pouze tehdy, když nová instance Duplicati dokáže importovat konfiguraci a obnovit vybrané soubory s ověřenými hashi.

Vyžaduje Duplicati HTTPS za reverse proxy?

Pro veřejný origin Duplicati použijte HTTPS a port 8200 ponechte na interní trase. Nastavení Duplicati aplikujte správně: management UI ponechte privátní nebo ho za HTTPS silně autentizujte. U Duplicati HTTPS chrání credentials nebo obsah uživatelů při přenosu a zajišťuje konzistentní chování klienta závislé na originu.

Jak testovat upgrade Duplicati?

Obnovte aktuální stav Duplicati do izolovaného deploymentu, aplikujte kandidátní verzi a zopakujte její akceptační transakci. Věnujte tomu zvláštní pozornost, protože změny konfigurační databáze a formátu záloh Duplicati je nutné testovat bez přepsání jediné vzdálené backup sady. Předchozí image Duplicati ponechte, dokud nebudete rozumět hranici migrace dat a rollbacku.