Perché Restic o Borg segnalano un repository mancante o spostato dopo una modifica del punto di montaggio?
Restic o Borg possono sembrare incapaci di trovare un repository quando il percorso configurato ora punta a una directory vuota, a un altro filesystem o a un repository trasferito.
I dati del repository potrebbero essere ancora integri sul disco di backup, ma il job potrebbe aprire la directory di montaggio vuota prima che il disco sia disponibile, usare un percorso del container modificato, leggere una variabile d’ambiente obsoleta o rifiutare un repository Borg il cui ID compare in una nuova posizione. Diagnostica la sorgente montata e l’identità del repository prima di inizializzare qualsiasi cosa. Eseguire un comando di inizializzazione sul percorso vuoto sbagliato può creare un secondo repository e rendere meno evidente il problema originale.
Conferma cosa è montato nel percorso del repository configurato
Registra il percorso del repository utilizzato dal job pianificato, quindi confronta il percorso prima e dopo il montaggio del disco di backup. Acquisisci la sorgente del filesystem, l’UUID, il punto di montaggio e la capacità disponibile.
L’utilità Linux findmnt risolve il montaggio attivo dietro un percorso di destinazione, rendendola il primo controllo corretto quando una directory familiare potrebbe essere in realtà la cartella dell’host non montata.
Se il percorso appartiene al filesystem root invece che al disco di backup, arresta il servizio di backup prima che scriva un nuovo repository o set di backup in quella directory vuota.
Verifica la posizione esatta del repository Restic
Confronta il percorso passato con -r, --repository-file o RESTIC_REPOSITORY con il punto di montaggio attuale. Controlla gli script wrapper, i campi NAS, i file delle credenziali e gli ambienti delle attività pianificate.
Restic definisce un repository locale come una directory specifica contenente configurazione, dati, indici, chiavi, blocchi e snapshot, quindi modificare il punto di montaggio cambia la posizione che il comando tenta di aprire.
Non eseguire restic init solo perché il nuovo percorso indica che non esiste alcun repository. Individua prima le directory di configurazione e dati del repository originale sul disco montato.
Gestisci consapevolmente l’avviso di repository Borg trasferito
Registra l’URL del repository Borg, l’ID del repository, la posizione precedente, quella attuale, il percorso della cache e la directory di sicurezza. Conferma che lo stesso repository sia stato trasferito intenzionalmente.
La FAQ di Borg spiega che richiede l’approvazione dopo il trasferimento del repository perché la presenza dello stesso ID del repository in un nuovo percorso può anche indicare una sostituzione non sicura.
Approva il trasferimento solo dopo aver confrontato l’ID del repository e i contenuti dello storage. Non disattivare l’avviso globalmente quando diversi repository rimovibili possono essere collegati con percorsi variabili.
Sostituisci i percorsi basati sull’ordine dei dispositivi con un’identità persistente dello storage
Verifica se la configurazione del montaggio fa riferimento a /dev/sdX, a un’etichetta duplicata, all’UUID del filesystem, all’UUID della partizione o all’ID del dispositivo. Confronta tutti i dischi utilizzati a rotazione per individuare identificatori duplicati.
ArchWiki osserva che gli UUID riducono le collisioni dei nomi rispetto alle etichette e ai nomi dei dispositivi assegnati dal kernel, che possono cambiare in base all’ordine di rilevamento.
Un identificatore stabile deve comunque corrispondere alla directory di montaggio fissa prevista. L’UUID impedisce variazioni dovute all’ordine dei dischi, ma non aggiorna un job di backup che contiene ancora il percorso precedente.
Controlla la traduzione dei percorsi nei container e nei montaggi bind
Per un’interfaccia Restic, Borg o di backup in un container, confronta il punto di montaggio dell’host con la sorgente del montaggio bind e con il percorso del repository all’interno del container. Controlla il container in esecuzione, non solo il file compose salvato.
Docker documenta che i montaggi bind dipendono dal percorso esatto dell’host, quindi spostare un disco da /mnt/backup-a a /media/backup-a può lasciare il container associato a una directory vuota.
Mantieni il percorso hardware stabile sull’host ed esponi un unico percorso stabile nel container. Non inserire direttamente nella configurazione del repository percorsi specifici dell’host per supporti rimovibili quando è disponibile una mappatura fissa.
Fai attendere il montaggio al servizio di backup
Confronta i timestamp di avvio e del servizio. Conferma che il montaggio sia completato prima che lo scheduler del backup, il container, l’interfaccia del repository o l’attività di manutenzione tenti di accedere ai dati.
Le indicazioni di Red Hat sui montaggi persistenti raccomandano di definire un montaggio fisso in fstab, che può poi essere abbinato a dipendenze del servizio e a una convalida prima dell’avvio.
L’opzione di avvio nofail può essere appropriata per un disco di backup rimovibile, ma il servizio di backup deve comunque rifiutarsi di avviarsi quando il filesystem richiesto non è presente.
Ricollega il repository esistente prima di eseguire un backup
Arresta le pianificazioni, monta il filesystem corretto nel percorso fisso, verifica la struttura del repository, aprilo in sola lettura o elenca gli snapshot ed esegui un piccolo controllo del repository prima di riabilitare le scritture.
L’articolo di ZimaSpace sui percorsi delle app stabili basati su UUID tratta la catena generale dei montaggi; questo articolo si concentra sull’identità del repository e sulla sicurezza degli strumenti di backup dopo la modifica dei percorsi.
Il problema è risolto quando lo stesso ID del repository e la cronologia degli snapshot si aprono nel percorso previsto dopo ripetuti test di riavvio e rotazione dei dischi, senza che venga creato un nuovo repository nella directory di montaggio vuota.
Domande frequenti
È possibile spostare un repository Restic in un altro punto di montaggio?
Sì, purché il repository completo venga spostato intatto e tutti i job facciano ora riferimento alla nuova posizione. Restic identifica il repository nel percorso o nel backend fornito al comando.
Perché Borg avvisa quando i dati del repository non sono cambiati?
Borg registra l’identità del repository e la posizione precedente come misura di sicurezza. La comparsa dello stesso ID in un altro percorso richiede un’approvazione esplicita.
Devo inizializzare un repository nel nuovo percorso?
No, non prima di aver dimostrato che il vecchio repository sia assente. Inizializzare un punto di montaggio vuoto crea un repository separato invece di ricollegare quello originale.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
