Vai al contenuto

Backup restic su B2: migrare dagli USA all’Europa con verifiche

Backup B2 da US a EU: GDPR, Hetzner, restic e il mio podio dei rimpianti

Per spostare un repository restic da una regione statunitense di Backblaze B2 a una europea bisogna preparare una destinazione distinta e dimostrare che i backup siano recuperabili da lì. Il lavoro finisce dopo il controllo dello storico, un ripristino e la verifica dei nuovi job.

La regione è una scelta utile da rendere esplicita, soprattutto quando si gestiscono dati per altri. Da sola, però, non dimostra né la conformità del trattamento né la qualità del backup.

La regione B2 appartiene all’account

Secondo la documentazione Backblaze sulle regioni, la regione viene scelta alla creazione dell’account e non si cambia successivamente. Per una destinazione in un’altra regione serve un altro account. Non basta creare un nuovo bucket nell’account statunitense.

Prima di iniziare, registrerei account sorgente e destinazione, repository coinvolti, responsabile delle credenziali e periodo di conservazione. Le chiavi applicative devono consentire le operazioni necessarie sui bucket corretti; una prova su dati non sensibili aiuta a individuare errori di endpoint e permessi.

Scegliere cosa trasferire: snapshot o repository a livello di oggetti

La funzione copy di restic trasferisce snapshot tra repository. La destinazione deve esistere; per una nuova destinazione la documentazione indica come copiare i parametri di chunking durante l’inizializzazione, preservando le condizioni per la deduplicazione.

Con chiavi di cifratura differenti, questa operazione legge i dati dalla sorgente e li scrive sulla destinazione. Va quindi dimensionata anche la macchina che esegue restic e il suo percorso di rete. La replica degli oggetti del provider è una procedura diversa: non la mescolerei con una copia logica senza prima definire come ottenere un repository completo e coerente.

Preparerei un elenco degli snapshot da conservare con date, host, percorsi e tag. La domanda non è soltanto se esiste un backup recente: potrei dover recuperare una versione di mesi prima. Una nuova destinazione con i soli ultimi giorni non equivale allo storico precedente.

Quattro controlli prima del cambio definitivo

  1. Copertura: confrontare lo storico richiesto con gli snapshot disponibili sulla destinazione, comprese le sorgenti meno frequenti.
  2. Integrità: eseguire i controlli del repository. restic check e restic check --read-data hanno una copertura diversa: il secondo legge anche i dati dei pack e richiede più tempo e traffico.
  3. Ripristino: recuperare un campione significativo in un ambiente separato e provare l’applicazione, non soltanto l’apertura di un file.
  4. Continuità: osservare un nuovo ciclo di backup verso la destinazione, poi controllare alert e conservazione.

Nei nostri audit tecnici abbiamo incontrato backup di file recenti insieme a dump di database fermi, e job di salvataggio riusciti mentre la retention falliva. Sono due motivi concreti per separare i segnali: “il cron è partito” non descrive quello che sarà possibile recuperare.

Per WordPress includerei database e media; per un’applicazione con storage esterno controllerei anche gli oggetti fuori dal server. Il test deve seguire i dati dell’applicazione, non il solo perimetro della macchina.

Conservare l’origine finché serve davvero

Deciderei in anticipo una finestra di sovrapposizione. La dismissione della sorgente dipende dalla copertura storica richiesta e dall’esito delle verifiche, non dal solo completamento del trasferimento. Durante la migrazione eviterei cambiamenti indipendenti alla retention che rendano difficile capire perché uno snapshot manca.

Il preventivo deve includere doppia occupazione temporanea, traffico, eventuali richieste a pagamento e lavoro operativo. Le condizioni di prezzo B2 vanno controllate per il percorso effettivo: vicinanza geografica e gratuità del trasferimento sono questioni distinte.

Che cosa cambia per il GDPR

Archiviare in Europa può contribuire a una scelta di localizzazione, ma occorre valutare ruoli, accordi con i fornitori, accessi, subfornitori e possibili trasferimenti. Nel GDPR, gli articoli 28 e 32 e il capo V trattano aspetti differenti di questo quadro. La scelta della regione non li assolve automaticamente.

Il documento finale della migrazione dovrebbe permettere di rispondere con prove a tre domande: quali dati abbiamo trasferito, da quale periodo possiamo recuperarli e chi ha verificato il ripristino. È questo il risultato operativo che cercherei.