Guida alla migrazione di Borg Backup per spostare un repository su un nuovo spazio di archiviazione

L’approccio sicuro consiste nel sospendere le scritture, copiare o trasferire con il metodo appropriato alla versione, verificare la destinazione ed effettuare il passaggio con rollback come una sequenza di controlli osservabili, non come un singolo comando.

In un repository BorgBackup su spazio di archiviazione locale, NAS o accessibile tramite SSH, il rischio pratico consiste nel dover spostare un repository Borg senza creare una copia divisa o silenziosamente incompleta. Registra l’identità attuale e il punto di ripristino, inizia con il discriminante meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo spazio di archiviazione diventa instabile o l’unica copia recuperabile verrebbe esposta. Il flusso di lavoro seguente termina solo quando il carico di lavoro originale ha esito positivo oppure le prove raggiungono una soglia di escalation.

Registra il contratto del repository prima della copia

Salva la versione di Borg, l’URL del repository, l’ID del repository, la modalità di crittografia, la posizione della chiave, il processo di recupero della passphrase, l’elenco degli archivi, la dimensione, lo spazio libero, le impostazioni di sola aggiunta e ogni client o processo automatizzato che può effettuare scritture. Il repository non è recuperabile dalla sola cache locale e i repository crittografati possono dipendere da materiale delle chiavi archiviato al di fuori della destinazione.

L’articolo di ZimaSpace su una guida al ripristino dopo la perdita della cache Borg distingue lo stato della cache ricostruibile dalle chiavi mancanti o dai danni al repository. Esegui questa verifica prima della migrazione, così un problema con la chiave non verrà scoperto solo dopo che lo spazio di archiviazione originale sarà stato rimosso.

Scegli se si tratta del trasferimento byte per byte dello stesso repository oppure di un trasferimento in un repository appena inizializzato. La versione e il formato di Borg determinano i metodi disponibili; non combinare esempi di comandi Borg 1 e Borg 2 e non presumere che l’identità del repository debba cambiare.

Sospendi le scritture e crea un punto coerente della sorgente

Disabilita timer, processi cron, container e client remoti, quindi conferma che non siano attivi processi Borg o lock del repository. Esegui borg list e un borg check appropriato prima della copia. Se la sorgente non supera il controllo, conservala e diagnostica quella condizione invece di clonare l’incertezza nella destinazione.

Una discussione su Super User evidenzia il rischio di usare la copia di un repository attivo con rsync mentre un repository Borg deduplicato cambia. La regola sicura consiste nel copiare un repository in stato quiescente oppure nell’utilizzare uno snapshot del filesystem acquisito dopo l’arresto di tutte le scritture Borg, in modo che indici, segmenti, stato dei nonce e dati appartengano allo stesso punto.

Mantieni disattivati i programmi di backup finché la convalida della destinazione non è completata. Se il downtime è troppo lungo, esegui una copia iniziale mentre il repository è inattivo, arresta le scritture e poi esegui una sincronizzazione finale; non consentire mai alla sorgente e alla destinazione di accettare backup indipendenti durante il passaggio.

Copia con il metodo supportato dalla tua versione di Borg

Per il trasferimento dello stesso repository, preserva tutti i file, i permessi, la gestione dei file sparsi e la proprietà con uno strumento di copia locale o remoto adeguato e controlla il relativo registro degli errori. Copia la radice del repository come un’unità, non singoli archivi o directory di dati apparentemente grandi. Lascia intatta la sorgente dopo la sincronizzazione finale.

Per un nuovo repository o una migrazione di formato, usa la funzionalità di trasferimento solo quando è supportata dalle versioni di Borg installate e dal piano di crittografia. Una risposta su Server Fault descrive il trasferimento di un repository Borg come la direzione da repository a repository associata a Borg 2, che non è intercambiabile con una copia del filesystem di Borg 1.

Dopo la copia, monta o rendi inizialmente disponibile la destinazione ai client in sola lettura. Se l’ID del repository, l’accesso alla chiave, i permessi o il formato sono imprevisti, fermati e correggi la destinazione; non “inizializzare” sopra i dati copiati e non eseguire riparazioni per forzarne il riconoscimento.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifica gli archivi, esegui il passaggio dei client e conserva il rollback

Esegui Borg list, info e i controlli appropriati del repository e degli archivi nella destinazione. Estrai file campione da un archivio recente e da uno più vecchio in una directory separata, quindi confronta contenuti, metadati e permessi. Esegui il test con lo stesso binario Borg e lo stesso percorso remoto che utilizzerà l’automazione.

Aggiorna un client indicando il nuovo URL, cancella o ricostruisci solo lo stato della cache che Borg identifica come necessario e crea un piccolo archivio di prova. Ripristina da quell’archivio e conferma che la pianificazione dello sfoltimento o della compattazione rimanga disabilitata finché tutti i client non utilizzano la nuova posizione.

Il passaggio è riuscito quando l’inventario degli archivi corrisponde, i controlli hanno esito positivo, due ripristini sono utilizzabili e un nuovo backup viene completato dopo il riavvio o il riavvio dello scheduler. Mantieni la sorgente in sola lettura per almeno un ciclo normale; eliminala solo dopo la scadenza del periodo di rollback oppure avvia un’escalation se i controlli differiscono tra sorgente e destinazione.