Come eseguire il self-hosting di Duplicati nel 2026: backup crittografati, mount e test di ripristino

Se hai già provato a eseguire il self-hosting di Duplicati, probabilmente conosci bene questa situazione frustrante: l'interfaccia utente viene visualizzata, ma il container vede un percorso vuoto perché le sorgenti sull'host sono state montate altrove. Ricreare il container raramente risolve un disallineamento tra URL, stato e dipendenze.

Questa guida utilizza un unico criterio concreto di completamento: eseguire il backup di una directory di test nella destinazione scelta, eliminare un file sorgente e ripristinarlo in un percorso alternativo vuoto. Ogni scelta di configurazione viene valutata rispetto a questo criterio, non in base a un badge verde del container.

Porte, processi e servizi privati

Un diagramma utile di Duplicati mostra il percorso pubblico, la porta privata 8200, il confine dello stato e ogni requisito di supporto. Indica quali frecce trasportano credenziali e quali rappresentano il normale traffico degli utenti. Il contratto di rete per Duplicati consiste in mount delle sorgenti in sola lettura e storage di destinazione del backup raggiungibile. Mantieni gli endpoint privati sul DNS interno, consenti solo le chiamate in uscita necessarie e assegna a Duplicati credenziali di servizio con ambito limitato.

Dimostra il diagramma con un'azione reale: esegui il backup di una directory di test nella destinazione scelta, elimina un file sorgente e ripristinalo in un percorso alternativo vuoto. Il carico probabile dipende dal numero di file sorgente, dalla compressione, dalla crittografia, dalla latenza della destinazione e dalla sovrapposizione tra i job pianificati; monitora questo percorso invece di considerare equivalenti tutte le richieste HTTP.

Diagnosticare un'istanza di Duplicati dall'aspetto sano

Costruisci dashboard incentrate sul numero di file sorgente, sulla compressione, sulla crittografia, sulla latenza della destinazione e sulla sovrapposizione tra i job pianificati. Un grafico della CPU privo del contesto del carico di lavoro non può spiegare perché Duplicati sia lento. Aggiungi un controllo sintetico o pianificato che provi a eseguire il backup di una directory di test nella destinazione scelta, eliminare un file sorgente e ripristinarlo in un percorso alternativo vuoto usando dati di test innocui.

Prima di eseguire l'upgrade, considera questo rischio specifico dell'applicazione: le modifiche al database di configurazione e al formato dei backup di Duplicati devono essere testate senza riscrivere l'unico set di backup remoto. Ripristina un backup recente in un deployment isolato, esegui lì le migration e confronta il comportamento. Se il container vede un percorso vuoto perché le sorgenti sull'host sono state montate altrove, verifica il confine coinvolto — origine pubblica, storage o dipendenza — prima di modificare impostazioni non correlate.

Cosa deve superare i test prima che arrivino dati reali in Duplicati

Il record di rilascio per Duplicati deve contenere fatti, non un semplice “sembra funzionare”. Salva il digest dell'immagine selezionata, il checksum della configurazione, l'hostname pubblico e il risultato con timestamp per questa procedura: eseguire il backup di una directory di test nella destinazione scelta, eliminare un file sorgente e ripristinarlo in un percorso alternativo vuoto. Usa dati di esempio non di produzione, così il controllo può essere eseguito dopo ogni deployment.

Dimostra separatamente due eventi del ciclo di vita. La sostituzione di un container deve preservare il normale funzionamento; un recovery pulito deve dimostrare che una nuova istanza di Duplicati può importare la configurazione e ripristinare i file selezionati con hash verificati. Mentre esegui i controlli, misura il numero di file sorgente, la compressione, la crittografia, la latenza della destinazione e la sovrapposizione tra i job pianificati, quindi conserva il risultato come envelope atteso per questa versione.

Testa anche una condizione negata o non valida: nega temporaneamente all'identità di test l'accesso ai mount delle sorgenti in sola lettura e allo storage di destinazione del backup raggiungibile. Duplicati dovrebbe fallire in modo diagnosticabile e non dovrebbe sovrascrivere uno stato integro. Ripristina la condizione valida, ripeti il test con i dati di esempio e allega i log pertinenti dopo averne rimossi i dati sensibili. Questi artefatti forniscono elementi concreti per una futura decisione di rollback.

Trasformare il comando locale in un servizio ispezionabile

Il comando seguente rende visibile il confine del container senza fingere di configurare ogni servizio esterno.

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

Prima di aprire l'ingress, controlla l'ambiente risolto, i mount e il listener. Aggiungi le impostazioni di connessione verificate per i mount delle sorgenti in sola lettura e per lo storage di destinazione del backup raggiungibile; usa nomi privati per i servizi privati. Un avvio riuscito termina quando puoi eseguire il backup di una directory di test nella destinazione scelta, eliminare un file sorgente e ripristinarlo in un percorso alternativo vuoto, non quando docker ps stampa Up.

Rendere misurabile il recovery di Duplicati

Elenca lo stato prima di creare il primo record reale: il database di configurazione di Duplicati e i set di backup verificati separatamente. Monta /config prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che il percorso è effettivamente persistente. Conferma il mount scrivendo dati innocui, sostituendo Duplicati e rileggendoli.

Gli snapshot sono utili per un rollback rapido, ma serve un backup indipendente quando l'host o il volume scompare. Esegui il ripristino in un ambiente vuoto con l'immagine fissata e verifica che una nuova istanza di Duplicati possa importare la configurazione e ripristinare i file selezionati con hash verificati. Usa volumi persistenti e snapshot per mantenere distinti questi due meccanismi di recovery.

TLS è semplice; gli URL generati no

Esponi un unico hostname HTTPS per Duplicati e mantieni privata la porta 8200 non elaborata. Mantieni privata l'interfaccia di gestione oppure proteggila con un'autenticazione forte dietro HTTPS. In questo modo impedisci a browser e client API di apprendere due indirizzi in conflitto.

Da un client pulito, esegui la transazione verificata e analizza la prima richiesta che fallisce. Usa la guida ai domini personalizzati quando DNS o TLS non funzionano correttamente. Considera “il container vede un percorso vuoto perché le sorgenti sull'host sono state montate altrove” come una diagnosi applicativa separata, dopo aver verificato il percorso.

Proteggere Duplicati dopo il bootstrap

Le credenziali di bootstrap sono temporanee; il modello di trust è permanente. Con Duplicati, fai attenzione a non montare le sorgenti dei backup in lettura-scrittura e a non perdere la passphrase di crittografia; monta le sorgenti in sola lettura, mantieni privata l'interfaccia di gestione e conserva la passphrase del backup fuori dal server.

Genera SETTINGS_ENCRYPTION_KEY una sola volta, non inserirla in Git e conservarla insieme al manifest di recovery, perché modificarla può invalidare lo stato applicativo crittografato o firmato. Esegui l'immagine senza capability Linux non necessarie ed esponi solo il percorso applicativo pubblico. Mantieni visibile l'attività degli amministratori senza registrare valori segreti.

Usare Dockup per il platform layer

Per Duplicati, Dockup può creare il percorso e il certificato TLS, preservare i mount, distribuire i secret e collocare i mount delle sorgenti in sola lettura e lo storage di destinazione del backup raggiungibile su una rete privata, eseguendo il deployment su Dockup o su server collegati.

Il release gate resta comunque la transazione concreta di Duplicati: eseguire il backup di una directory di test nella destinazione scelta, eliminare un file sorgente e ripristinarlo in un percorso alternativo vuoto. Verifica anche la condizione di ripristino: una nuova istanza di Duplicati deve poter importare la configurazione e ripristinare i file selezionati con hash verificati. Questi due controlli mostrano se il deployment funziona e se può essere recuperato.

Domande frequenti

Di cosa ha bisogno Duplicati per un deployment in produzione?

Instrada il container di Duplicati sulla porta 8200 attraverso un'unica origine HTTPS. Il requisito di rete di supporto consiste in mount delle sorgenti in sola lettura e storage di destinazione del backup raggiungibile. Non considerare Duplicati pronto finché non puoi eseguire il backup di una directory di test nella destinazione scelta, eliminare un file sorgente e ripristinarlo in un percorso alternativo vuoto.

Quali dati di Duplicati devono essere inclusi in un backup?

Rendi persistente /config e includi il database di configurazione di Duplicati e i set di backup verificati separatamente nello stesso manifest di recovery. Un ripristino pulito di Duplicati ha esito positivo solo quando una nuova istanza di Duplicati può importare la configurazione e ripristinare i file selezionati con hash verificati.

Duplicati richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di Duplicati e mantieni la porta 8200 sul percorso interno. Applica correttamente l'impostazione di Duplicati: mantieni privata l'interfaccia di gestione oppure proteggila con un'autenticazione forte dietro HTTPS. Per Duplicati, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento dei client sensibile all'origine.

Come deve essere testato un upgrade di Duplicati?

Ripristina lo stato attuale di Duplicati in un deployment isolato, applica la versione candidata e ripeti la transazione di accettazione. Presta particolare attenzione perché le modifiche al database di configurazione e al formato dei backup di Duplicati devono essere testate senza riscrivere l'unico set di backup remoto. Conserva l'immagine precedente di Duplicati finché non avrai compreso i confini della migrazione dei dati e del rollback.