Cum să găzduiești Duplicati în regim propriu în 2026: backupuri criptate, mount-uri și teste de restaurare

Dacă ai încercat deja să găzduiești Duplicati în regim propriu, probabil îți este familiară situația frustrantă: interfața apare, dar containerul vede o cale goală, deoarece sursele de pe host au fost montate în altă parte. Recrearea containerului rezolvă rareori o neconcordanță între URL-uri, stare și dependențe.

Acest ghid folosește un criteriu concret de finalizare — să faci backup unui director de test către destinația aleasă, să ștergi un fișier sursă și să îl restaurezi într-o cale alternativă curată. Fiecare alegere de configurare este evaluată în funcție de acest criteriu, nu în funcție de o insignă verde a containerului.

Porturi, procese și servicii private

O diagramă utilă pentru Duplicati arată ruta publică, portul privat 8200, limita de separare a stării și fiecare cerință de suport. Marchează ce săgeți transportă credențiale și care reprezintă trafic obișnuit al utilizatorilor. Contractul de rețea pentru Duplicati constă în mount-uri read-only pentru surse și acces la spațiul de stocare al destinației backupului. Păstrează endpoint-urile private în DNS intern, permite doar apelurile outbound necesare și oferă Duplicati o credențială de serviciu cu permisiuni limitate.

Dovedește diagrama printr-o acțiune reală: fă backup unui director de test către destinația aleasă, șterge un fișier sursă și restaurează-l într-o cale alternativă curată. Cel mai probabil, presiunea va proveni din numărul de fișiere sursă, compresie, criptare, latența destinației și suprapunerea joburilor programate; monitorizează această rută în loc să tratezi toate requesturile HTTP ca fiind echivalente.

Diagnosticarea unui Duplicati care pare sănătos

Construiește dashboarduri în jurul numărului de fișiere sursă, compresiei, criptării, latenței destinației și suprapunerii dintre joburile programate. Un grafic CPU fără acest context al workloadului nu poate explica de ce Duplicati este lent. Adaugă o verificare sintetică sau programată care încearcă să facă backup unui director de test către destinația aleasă, să șteargă un fișier sursă și să îl restaureze într-o cale alternativă curată, folosind date de test inofensive.

Înainte de upgrade, ține cont de acest risc specific aplicației: modificările aduse bazei de date de configurare și formatului de backup al Duplicati trebuie testate fără a rescrie singurul set de backup remote. Restaurează un backup recent într-un deployment izolat, rulează acolo migrările și compară comportamentul. Dacă containerul vede o cale goală deoarece sursele de pe host au fost montate în altă parte, inspectează limita implicată — originea publică, stocarea sau dependența — înainte să modifici setări fără legătură.

Ce trebuie să treacă înainte să ajungă date reale în Duplicati

Înregistrarea release-ului pentru Duplicati are nevoie de fapte, nu de „pare în regulă”. Păstrează digestul imaginii selectate, checksum-ul configurației, hostname-ul public și un rezultat cu timestamp pentru: să faci backup unui director de test către destinația aleasă, să ștergi un fișier sursă și să îl restaurezi într-o cale alternativă curată. Folosește date de exemplu care nu sunt de producție, astfel încât verificarea să poată rula după fiecare deployment.

Dovedește separat două evenimente din ciclul de viață. Înlocuirea unui container trebuie să păstreze funcționarea normală; o recuperare completă trebuie să arate că o instanță Duplicati nouă poate importa configurația și restaura fișierele selectate cu hashuri verificate. În timp ce rulează verificările, măsoară numărul de fișiere sursă, compresia, criptarea, latența destinației și suprapunerea dintre joburile programate și păstrează rezultatul ca interval așteptat pentru această versiune.

Testează și o condiție refuzată sau invalidă: refuză temporar identității de test accesul la mount-urile read-only pentru surse și la spațiul de stocare accesibil al destinației backupului. Duplicati trebuie să eșueze într-un mod ușor de diagnosticat și să nu suprascrie starea sănătoasă. Restabilește condiția validă, rulează din nou exemplul și atașează logurile relevante, cu datele sensibile eliminate. Aceste artefacte oferă unei decizii viitoare de rollback dovezi concrete.

Transformă comanda locală într-un serviciu inspectabil

Comanda următoare face vizibilă limita containerului, fără să pretindă că furnizează toate serviciile externe.

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

Înainte să deschizi ingress-ul, inspectează environment-ul rezolvat, mount-urile și listenerul. Adaugă setările de conexiune verificate pentru mount-uri read-only ale surselor și spațiul de stocare accesibil al destinației backupului; folosește nume private pentru serviciile private. O pornire reușită se încheie atunci când poți face backup unui director de test către destinația aleasă, să ștergi un fișier sursă și să îl restaurezi într-o cale alternativă curată, nu atunci când docker ps afișează Up.

Fă recuperarea Duplicati măsurabilă

Enumeră starea înainte de crearea primei înregistrări reale: baza de date de configurare Duplicati și seturile de backup verificate separat. Montează /config înainte de bootstrap, scrie date de exemplu inofensive și înlocuiește containerul pentru a demonstra că acea cale este într-adevăr persistentă. Confirmă mount-ul scriind date inofensive, înlocuind Duplicati și citindu-le din nou.

Snapshoturile sunt valoroase pentru rollback rapid, dar ai nevoie de un backup independent atunci când hostul sau volumul dispare. Restaurează într-un mediu gol folosind imaginea fixată la o versiune și verifică dacă o instanță Duplicati nouă poate importa configurația și restaura fișierele selectate cu hashuri verificate. Folosește volume persistente și snapshoturi pentru a păstra distincte aceste două mecanisme de recuperare.

TLS este simplu; URL-urile generate nu sunt

Expune un singur hostname HTTPS pentru Duplicati; păstrează portul brut 8200 privat. Păstrează interfața de administrare privată sau protejată prin autentificare puternică în spatele HTTPS. Astfel, împiedici browserele și clienții API să afle două adrese concurente.

De pe un client curat, rulează tranzacția verificată și inspectează primul request care eșuează. Folosește ghidul pentru domenii personalizate atunci când DNS-ul sau TLS-ul este configurat greșit. Tratează situația „containerul vede o cale goală deoarece sursele de pe host au fost montate în altă parte” ca pe un diagnostic separat al aplicației, după ce ruta a fost verificată.

Securizează Duplicati după bootstrap

Credențialele de bootstrap sunt temporare; modelul de încredere este permanent. În cazul Duplicati, urmărește montarea surselor backupului cu acces read-write sau pierderea passphrase-ului de criptare și montează sursele read-only, păstrează interfața de administrare privată și stochează passphrase-ul backupului în afara serverului.

Generează SETTINGS_ENCRYPTION_KEY o singură dată, nu îl păstra în Git și conservă-l împreună cu manifestul de recuperare, deoarece schimbarea lui poate invalida starea criptată sau semnată a aplicației. Rulează imaginea fără capabilități Linux inutile și expune doar ruta publică a aplicației. Păstrează vizibilă activitatea administratorilor fără să înregistrezi valorile secrete.

Folosește Dockup pentru nivelul de platformă

Pentru Duplicati, Dockup poate crea ruta și certificatul TLS, păstra mount-urile, livra secretele și plasa mount-urile read-only pentru surse, împreună cu spațiul de stocare accesibil al destinației backupului, într-o rețea privată, efectuând deployment-ul fie în Dockup, fie pe servere atașate.

Criteriul de release rămâne tranzacția concretă Duplicati: să faci backup unui director de test către destinația aleasă, să ștergi un fișier sursă și să îl restaurezi într-o cale alternativă curată. Verifică și condiția de restaurare — o instanță Duplicati nouă poate importa configurația și restaura fișierele selectate cu hashuri verificate. Aceste două verificări arată dacă deployment-ul funcționează și dacă poate fi recuperat.

Întrebări frecvente

De ce are nevoie Duplicati pentru un deployment în producție?

Rutează containerul Duplicati pe portul 8200 printr-o singură origine HTTPS. Cerința de rețea pentru serviciile de suport constă în mount-uri read-only pentru surse și acces la spațiul de stocare al destinației backupului. Nu considera Duplicati pregătit până când nu poți face backup unui director de test către destinația aleasă, să ștergi un fișier sursă și să îl restaurezi într-o cale alternativă curată.

Ce date Duplicati trebuie incluse într-un backup?

Păstrează /config și include baza de date de configurare Duplicati și seturile de backup verificate separat în același manifest de recuperare. O restaurare curată a Duplicati este reușită doar atunci când o instanță Duplicati nouă poate importa configurația și restaura fișierele selectate cu hashuri verificate.

Are Duplicati nevoie de HTTPS în spatele unui reverse proxy?

Folosește HTTPS pentru originea publică Duplicati și păstrează portul 8200 pe ruta internă. Aplică corect setarea Duplicati: păstrează interfața de administrare privată sau protejată prin autentificare puternică în spatele HTTPS. Pentru Duplicati, HTTPS protejează credențialele sau conținutul utilizatorilor în tranzit și menține consecvent comportamentul clientului dependent de origine.

Cum trebuie testat un upgrade Duplicati?

Restaurează starea actuală Duplicati într-un deployment izolat, aplică versiunea candidată și repetă tranzacția de acceptanță. Acordă o atenție deosebită acestui aspect, deoarece modificările bazei de date de configurare și formatului de backup al Duplicati trebuie testate fără a rescrie singurul set de backup remote. Păstrează imaginea Duplicati anterioară până când limitele migrării datelor și ale rollbackului sunt înțelese.