Come spostare un repository di backup USB in un nuovo percorso di montaggio senza compromettere la cronologia incrementale
Spostare un repository di backup USB in un nuovo percorso di mount è sicuro quando il repository rimane intatto e il job di backup viene ricollegato deliberatamente a esso.
L’errore pericoloso consiste nel trattare il nuovo percorso come una nuova destinazione e lasciare che l’applicazione di backup inizializzi un repository vuoto accanto a quello precedente. Prima di modificare etichette, regole di mount o struttura delle directory, annota l’identità fisica del filesystem, la radice del repository, l’ID del repository se lo strumento lo espone, il materiale di crittografia, la configurazione del job e l’ultimo punto di ripristino utilizzabile. Poi sposta o rimonta il repository esistente come un’unica unità e verifica che l’applicazione riconosca la cronologia precedente prima della scrittura successiva.
Registra il repository esistente prima di modificare il percorso
Salva la sorgente di mount attuale, l’UUID o l’etichetta del filesystem, la directory del repository, il nome del job, la posizione della chiave di crittografia o della password e l’identificatore del repository, se lo strumento di backup lo espone. Elenca diversi snapshot o archivi recenti come riferimento.
Kopia separa la creazione del repository dal collegamento a un repository esistente, una distinzione fondamentale da preservare durante lo spostamento del percorso di mount.
Non iniziare il trasferimento finché non riesci a identificare la cronologia precedente senza affidarti esclusivamente al percorso di mount. Se hai registrato solo il percorso, in seguito un secondo disco USB montato nello stesso punto potrebbe sembrare ingannevolmente valido.
Sposta il repository come un’unica unità completa
Arresta il job di backup e qualsiasi processo di eliminazione, compattazione, verifica o ripristino prima di spostare i file del repository. Copia o rimonta l’intera radice del repository, inclusi indici, configurazione, pacchetti, blocchi, chiavi memorizzate al suo interno e metadati specifici dello strumento.
Borg descrive il proprio repository come un archivio transazionale strutturato con metadati del repository accanto ai dati di backup; per questo copiare solo i file visibili simili ad archivi non è un modello di trasferimento sicuro.
Mantieni invariato il repository originale finché il nuovo percorso non supera un elenco o un controllo in sola lettura. Evita di aprire entrambe le istanze, originale e copiata, per le normali scritture quando lo strumento le considera appartenenti alla stessa identità di repository.
Modifica il percorso di destinazione senza inizializzare una nuova cronologia
Aggiorna il job esistente o la connessione al repository indicando il nuovo percorso del filesystem. Se l’interfaccia offre le opzioni Crea e Connetti, Importa, Ricollega o Usa esistente, scegli il percorso relativo al repository esistente e verifica la destinazione prima di salvare.
I manutentori di Duplicati spiegano che, dopo aver spostato un archivio esistente, puoi modificare la destinazione e continuare quando il database del job viene indirizzato all’archivio trasferito.
Se l’applicazione propone immediatamente di inizializzare una destinazione vuota, annulla l’operazione. È un segnale che non ha ancora riconosciuto il vecchio repository; l’inizializzazione può creare una seconda cronologia e rendere ambigua la pulizia successiva.
Considera che alcuni strumenti rilevano lo spostamento del repository
Un client di backup può memorizzare informazioni che vanno oltre il contenuto del repository. Le cache locali possono associare l’identità di un repository alla posizione precedente e chiedere un’approvazione esplicita quando lo stesso repository viene rilevato in un nuovo punto.
Un caso di migrazione del percorso di mount in Duplicacy riguarda il ricollegamento di un repository spostato, mostrando perché una modifica del percorso del repository debba essere trattata come un ricollegamento e non come una nuova inizializzazione.
Approva lo spostamento solo dopo aver verificato l’identità del repository, gli snapshot previsti, lo stato della crittografia e il filesystem USB. Un avviso relativo al disco sbagliato è un motivo per fermarsi, non la prova che il software sia eccessivamente prudente.
Assegna al filesystem USB un’identità di mount stabile
Una volta riconosciuto il repository, associa il filesystem USB fisico a un percorso fisso gestito dall’amministratore utilizzando un identificatore persistente appropriato. Evita di legare i backup pianificati all’ordine di rilevamento di /dev/sdX o a una directory di mount della sessione desktop.
Gli strumenti Linux possono identificare i filesystem tramite un’etichetta o un UUID stabili, consentendo allo stesso percorso del repository di sopravvivere alle normali variazioni nell’enumerazione dei dispositivi.
Se modifichi intenzionalmente l’etichetta del filesystem, aggiorna la regola di mount e testala prima di riattivare i backup. L’applicazione di backup dovrebbe continuare a vedere la stessa radice del repository anche quando cambia l’etichetta leggibile.
Verifica la cronologia prima della prima scrittura dopo lo spostamento
Monta il disco USB nel nuovo percorso, connetti il repository esistente, elenca gli snapshot precedenti, controlla l’ultimo punto di ripristino e ripristina un file di piccole dimensioni in una directory temporanea. Solo dopo esegui il primo nuovo backup.
Un esempio relativo a restic osserva che un repository locale può essere rinominato e utilizzato nuovamente indicando il nuovo percorso, a conferma che la cronologia del repository dipende dal contenuto del repository e non dalla grafia di un singolo percorso di mount.
Lo spostamento è completato quando i vecchi snapshot rimangono consultabili, un ripristino di prova funziona e il nuovo backup viene aggiunto alla stessa cronologia. L’articolo correlato di ZimaSpace sui percorsi di mount USB che cambiano dopo il riavvio è la soluzione a monte quando il cambiamento del percorso non era pianificato, bensì una conseguenza non prevista.
Domande frequenti
La modifica dell’etichetta di un volume USB interrompe automaticamente la cronologia dei backup?
Non necessariamente. Diventa un problema quando la regola di mount o il job di backup utilizza quell’etichetta come parte dell’identità della destinazione e il repository non viene più trovato nel percorso previsto.
Devo copiare nel nuovo percorso solo la cartella dell’ultimo backup?
No, nel caso degli strumenti di backup basati su repository. Mantieni insieme l’intera struttura del repository, perché indici, cataloghi, file pacchetto, chiavi e punti di ripristino precedenti possono dipendere gli uni dagli altri.
Posso mantenere online contemporaneamente le copie vecchia e nuova del repository?
Mantieni la vecchia copia come fonte per un eventuale ripristino, ma evita di scrivere indipendentemente su due istanze clonate che condividono la stessa identità di repository, a meno che lo strumento di backup non supporti esplicitamente questo flusso di lavoro.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
