Un messaggio di Duplicati che indica che manca un file .dblock.zip.aes file mancante fa pensare a una corruzione del backup, ma la discussione originale mostra perché una riparazione distruttiva non dovrebbe essere la prima reazione. La destinazione del backup esisteva sull’host ZimaOS ed era visibile tramite Samba, ma il container di Duplicati non riusciva effettivamente a vedere quell’HDD attraverso le sue mappature dei volumi Docker.
Dopo aver mappato il vero HDD dell’host nel container e aver selezionato la nuova destinazione lato container, l’utente ha risposto che sembrava funzionare. La fonte si è quindi conclusa con una soluzione confermata basata sulla mappatura dei percorsi Docker, non con una conferma dell’eliminazione del backup danneggiato.
L’errore iniziale sembrava indicare un repository Duplicati danneggiato
Duplicati ha segnalato che la riparazione non era riuscita perché nella destinazione di archiviazione del backup mancava uno specifico dblock file. Il messaggio proponeva due modalità di ripristino: ricostruire i file di blocco mancanti dai dati di origine locali oppure eliminare le voci di backup che non potevano più essere ripristinate.
Queste opzioni sono funzionalità reali di Duplicati, ma hanno senso solo dopo aver verificato che la destinazione del backup esaminata sia quella corretta e completa.
L’utente eseguiva il backup di un disco locale su un altro
La configurazione prevista era:
- dati di origine su un SSD locale;
- destinazione del backup su un HDD separato;
- Duplicati installato dall’App Store di ZimaOS e quindi in esecuzione in Docker.
L’utente ha selezionato i percorsi tramite il selettore di cartelle dell’applicazione e ha pensato che ciò significasse che il container potesse vedere lo stesso spazio di archiviazione dell’host.
Un percorso dell’host in ZimaOS e un percorso del container in Duplicati non sono la stessa cosa
Un’app Docker vede solo le cartelle dell’host che sono state montate nel container. ZimaOS può accedere a un disco tramite Files o Samba, mentre Duplicati non vede nulla se quel disco non è presente nella configurazione dei volumi dell’app.
Ecco perché un semplice test di connessione può trarre in inganno: il tipo di destinazione può essere valido, mentre i contenuti della cartella prevista non sono effettivamente visibili nello spazio dei nomi del container.
Il test del file temporaneo ha rivelato il vero problema
L’utente ha creato un temp.txt file nella cartella di destinazione. Era visibile tramite Samba, ma non nel browser dei file di Duplicati. Questa era una prova evidente che Duplicati non stava visualizzando i contenuti effettivi dell’HDD dell’host.
A quel punto, il responsabile della risposta della community ha esplicitamente consigliato di non eseguire ancora il purge o la ricostruzione.
La soluzione funzionante consisteva nel mappare l’HDD nel container
Il responsabile della risposta ha indicato all’utente di aprire le impostazioni dell’app ZimaOS, aggiungere l’HDD come volume dell’host e mapparlo a un semplice percorso del container, come /backup, riavvia il container e poi scegli una destinazione all’interno di quel percorso del container.
L’autore del post originale ha risposto: «Sembra funzionare ora.»
Ciò ha confermato che la mappatura del volume era la soluzione pratica.
Le unità di origine aggiuntive richiedono mappature proprie
L'utente ha quindi chiesto se un'unica attività di Duplicati potesse contenere più cartelle di origine. La risposta della community è stata sì, a condizione che ogni percorso di origine sia visibile anche all'interno del container.
Se un secondo disco non è esposto nei volumi Docker dell'app, non apparirà correttamente in Duplicati, indipendentemente dalla validità del percorso dell'host.
Usa l'attuale mappatura dei volumi delle app ZimaOS invece di indovinare i percorsi grezzi
L'attuale versione di ZimaOS espone i percorsi dell'host e del container nelle impostazioni delle applicazioni e documenta come viene mappato lo spazio di archiviazione persistente nelle app Docker.
Usa l'attuale modello dei percorsi Docker di ZimaOS quando aggiungi origini o destinazioni di backup.
Quando la riparazione di Duplicati è appropriata
La documentazione attuale della riga di comando di Duplicati afferma che Repair può ricostruire il database locale dall'archiviazione remota o tentare di ricostruire i dati remoti mancanti quando il contenuto locale di origine richiesto è ancora disponibile.
L'opzione avanzata --rebuild-missing-dblock-files L'opzione tenta specificamente di ricreare i file di blocchi mancanti dai dati locali di origine, ma Duplicati avverte che i dati potrebbero essere cambiati e che il ripristino potrebbe essere incompleto o lento.
purge-broken-files È distruttivo per la cronologia dei ripristini
La documentazione attuale di Duplicati afferma che purge-broken-files rimuove dai backup le versioni dei file che non possono più essere ripristinate, consentendo al set di backup di continuare a funzionare. Deve essere usato solo quando i dati remoti mancanti non possono essere recuperati.
Prima di eliminare i file, controlla i comandi di ripristino attuali di Duplicati e le relative conseguenze. Un'esecuzione di prova o un elenco dei file danneggiati è più sicuro che eliminare alla cieca la cronologia dei backup.
Il messaggio di errore era reale, ma la destinazione sottostante era errata
Duplicati segnalava correttamente che la vista del repository a cui aveva accesso non conteneva i file previsti. L'elemento fuorviante era presumere che quella vista del repository rappresentasse il disco rigido reale. La mappatura dei percorsi Docker aveva indirizzato l'applicazione verso una vista del filesystem incompleta o diversa.
FAQ sui dblock di Duplicati
È stato dimostrato che il repository di backup dell'origine era danneggiato?
No. Il problema dell'origine è stato risolto correggendo la mappatura del volume Docker.
L'eliminazione dei file danneggiati dovrebbe essere il primo passaggio?
No. Verifica che la destinazione completa corretta sia montata e visibile prima di qualsiasi riparazione distruttiva.
Un'attività di Duplicati può eseguire il backup di più unità ZimaOS?
Sì, ma ogni unità di origine deve essere mappata nel container di Duplicati.
