Perché un disco USB di backup ruotato ottiene un percorso di montaggio con suffisso dopo il riavvio?
Un disco USB di backup ruotato può ottenere un percorso di montaggio con suffisso quando la directory preferita basata sull'etichetta è già occupata, duplicata o assegnata da un altro sistema di montaggio automatico.
La rotazione dei backup utilizza spesso diversi dischi simili e gli amministratori possono clonare i filesystem o riutilizzare la stessa etichetta di volume per comodità. Dopo un riavvio, l'ordine di rilevamento, il montaggio automatico del desktop, directory di montaggio obsolete, etichette duplicate o una voce fstab in conflitto possono costringere un disco a comparire in un percorso come BACKUP_1 invece di BACKUP. Il disco potrebbe essere integro, mentre il processo di backup ora punta alla directory sbagliata. Verifica l'identità prima di spostare file o modificare i percorsi.
Identificare il filesystem dietro il percorso imprevisto
Registra il dispositivo effettivo, l'UUID del filesystem, l'etichetta, il numero di serie o il percorso by-id, l'origine del montaggio, la destinazione, il tipo di filesystem e le opzioni per ogni disco di rotazione collegato.
Il comando Linux findmnt associa una destinazione alla sua origine attiva, evitando che il nome fuorviante di una cartella venga scambiato per il disco di backup previsto.
Se la directory con suffisso appartiene all'UUID corretto, il problema riguarda l'assegnazione del percorso. Se appartiene a un altro disco, interrompi il backup prima che scriva nel set di rotazione sbagliato.
Verificare la presenza di etichette o UUID duplicati del filesystem
Confronta UUID, etichetta, PARTUUID, numero di serie e nomi by-id tra tutti i dischi ruotati, inclusi quelli attualmente offline se sono disponibili dei registri.
ArchWiki spiega che le etichette sono più facili da duplicare rispetto agli UUID, rendendo rischioso il montaggio automatico basato solo sull'etichetta quando diversi dischi di backup condividono intenzionalmente un nome intuitivo.
La clonazione di un filesystem può clonare anche il suo UUID. Assegna un'identità univoca al filesystem prima di affidarti alla rotazione automatica e documenta quale disco fisico appartiene a ciascun ID.
Capire perché i sistemi di montaggio automatico aggiungono un suffisso
Verifica se una sessione desktop, un servizio NAS, un assistente UDisks o un gestore dei supporti rimovibili ha montato il disco prima che fstab o il servizio di backup intervenissero.
Il Filesystem Hierarchy Standard consente di aggiungere cifre alle directory di montaggio dei supporti rimovibili quando più dispositivi richiedono una posizione di montaggio simile.
La politica esatta dei suffissi varia in base al sistema di montaggio automatico, ma il principio diagnostico è lo stesso: il percorso preferito non era disponibile o era ambiguo quando il dispositivo è stato rilevato.
Verificare se la directory di montaggio preferita era già occupata
Controlla la directory prevista prima di collegare il disco. Determina se contiene un altro montaggio, file estranei scritti mentre il disco era assente, un bind mount o una directory di lavoro obsoleta di un processo.
Le indicazioni di Oracle sui supporti rimovibili spiegano che le etichette dei supporti vengono utilizzate per denominare i percorsi di montaggio, creando una collisione quando più oggetti multimediali presentano lo stesso percorso derivato dall'etichetta.
Non eliminare una directory occupata prima di aver verificato se contiene backup scritti accidentalmente nel filesystem radice. Sposta i dati estranei verificati seguendo una procedura di ripristino controllata.
Definire un punto di montaggio fisso in fstab per ogni disco di rotazione
Scegli una politica stabile: assegna a ogni disco fisico la propria directory fissa oppure utilizza uno script di rotazione che monti l'UUID attualmente selezionato in un unico percorso di backup controllato dopo averne verificato l'identità.
Red Hat documenta il montaggio persistente tramite fstab con un UUID e un punto di montaggio fisso, eliminando dall'esecuzione automatica l'influenza dell'ordine di rilevamento e le collisioni tra etichette intuitive.
Non creare diverse voci fstab attive in conflitto per la stessa directory di destinazione. Un flusso di rotazione dovrebbe confermare che il disco precedente sia stato smontato prima di collegare quello successivo.
Fare in modo che l'avvio del backup dipenda dal montaggio verificato
Verifica se l'utilità di pianificazione si avvia prima che il rilevamento USB e il montaggio siano completati. Aggiungi un controllo preliminare per UUID, punto di montaggio, stato di scrittura e file indicatore previsto.
La documentazione Debian sui montaggi systemd spiega che le voci fstab diventano dipendenze di montaggio systemd, consentendo ai servizi di backup di attendere un montaggio specifico anziché una directory arbitraria.
Il controllo dell'esistenza della directory non è sufficiente, perché la directory semplice esiste anche quando il disco è assente. Convalida l'identità del filesystem montato.
Testare l'intera rotazione dopo riavvii e sostituzioni dei dischi
Per ogni disco, esegui uno smontaggio pulito, scollegalo, riavvia, ricollegalo, convalida l'identità, esegui una scrittura usa e getta, una simulazione del backup e una verifica di rilettura. Registra il percorso e l'UUID previsti.
L'articolo di ZimaSpace sui montaggi UUID e percorsi stabili delle app tratta il più ampio approccio basato su percorsi fissi; questo articolo si concentra sulle collisioni create dalla rotazione di diversi dischi di backup rimovibili.
Il problema è risolto quando ogni disco di rotazione corrisponde al percorso documentato dopo ripetuti test di riavvio e sostituzione e il backup rifiuta di avviarsi quando l'UUID previsto manca o è montato altrove.
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,...
