I backup delle app self-hosted sono coerenti? Verifica database, file e ordine di ripristino

Un backup può riuscire anche se l’applicazione non è sincronizzata

Un’applicazione aziendale può archiviare i record in un database e i file caricati in una directory separata o in un servizio di archiviazione. I backup di questi componenti possono essere leggibili singolarmente, ma riferirsi a momenti diversi. Dopo un ripristino, un record potrebbe rimandare a un allegato mancante oppure potrebbe esserci un file senza il record a cui è associato.

L’obiettivo è verificare se l’applicazione può essere ricostruita usando un insieme di backup compatibili, non soltanto se i file di backup sono stati creati. Un rapporto di esecuzione completata indica che il processo è stato avviato, ma da solo non dimostra che l’intero servizio sia ripristinabile.

• Scegli un record rappresentativo con un allegato caricato o un altro file collegato.
• Individua dove vengono archiviati il record, il file e il collegamento tra i due.
• Considera le pianificazioni di backup separate come un aspetto da verificare, non come prova di incoerenza o di coordinamento.

Individua ciò di cui ha bisogno l’applicazione

Consulta la documentazione dell’applicazione e le impostazioni di distribuzione per identificare tutto ciò che deve essere disponibile per un ripristino. Non dare per scontato che il database rappresenti l’intero servizio o che i file siano archiviati accanto a esso. Se non puoi verificare un componente, chiedi al provider di hosting di chiarirne l’ambito.

Le istruzioni dell’applicazione possono definire il backup come composto da più parti. Per esempio, la guida ai backup self-hosted di Hudu descrive un backup completo come composto da due parti distinte e indica il database PostgreSQL come una di esse. Usa le istruzioni della tua applicazione per stabilire quali componenti sono necessari: [Assistenza Hudu: backup e ripristini self-hosted](https://support.hudu.com/hc/en-us/articles/11653994397079-Self-Hosted-Backups-and-Restores).

• Database e file persistenti, inclusi allegati e altri contenuti caricati.
• Configurazione ed eventuali credenziali, chiavi di crittografia o token necessari durante il ripristino.
• Archiviazione esterna o servizi da cui dipende l’applicazione.
• Versioni dell’applicazione e del database o dettagli di distribuzione richiesti dalla procedura di ripristino documentata.

Verifica come e quando viene acquisito ogni componente

Chiedi se i componenti correlati vengono acquisiti insieme o secondo pianificazioni indipendenti. Valuta cosa succede se gli utenti stanno modificando record o caricando file, oppure se le attività in background stanno modificando i dati durante il backup.

Segui la procedura di backup documentata per il tuo database e la tua applicazione. Se la documentazione non chiarisce come acquisire i componenti correlati, chiedi indicazioni al fornitore o al provider di hosting.

• I backup del database e dei file vengono acquisiti insieme o secondo pianificazioni distinte?
• Se sono separati, in che modo il processo garantisce che rappresentino uno stato compatibile dell’applicazione?
• Come vengono gestite durante l’acquisizione le modifiche attive, i caricamenti, le attività pianificate e i processi in background?
• L’applicazione documenta una procedura di backup o manutenzione da seguire?

Chiarisci cosa gestisce il provider di hosting

La parola “backup” non specifica cosa includa il servizio di un provider di hosting. Verifica se il processo copre il database, l’archiviazione persistente dei file e gli altri dati necessari all’applicazione, e se i componenti correlati vengono coordinati.

Airbip esegue le istanze delle applicazioni come carichi di lavoro Docker sui server cloud Airbip e offre backup giornalieri, settimanali e mensili configurabili. Queste funzionalità, da sole, non stabiliscono cosa includa un determinato backup, come vengano coordinati i componenti o cosa verrà recuperato con un ripristino. Verifica l’ambito e la procedura di ripristino della tua istanza, senza dedurli dalla pianificazione.

Annota le risposte del provider e le attività di ripristino che dovrai gestire, compreso chi deve richiedere il ripristino e chi deve convalidarlo.

• Quali dati e percorsi di archiviazione sono inclusi? Cosa è escluso o gestito separatamente?
• Il provider coordina l’acquisizione del database e dei file? Quale livello di coerenza può confermare?
• Chi avvia un ripristino, fornisce le informazioni necessarie sull’applicazione e verifica il servizio ripristinato?
• Dove puoi consultare la pianificazione dei backup aggiornata e le condizioni di servizio applicabili?

Esegui il ripristino seguendo le istruzioni dell’applicazione

Non esiste un ordine di ripristino universale valido per tutte le applicazioni self-hosted. Segui le istruzioni ufficiali di ripristino dell’applicazione e la procedura del provider. Prima di iniziare, verifica le dipendenze; ripristina i componenti correlati come un insieme compatibile e controlla quando è sicuro avviare l’applicazione o riconnettere utenti e processi in background.

A meno che il tuo piano non preveda esplicitamente un approccio diverso, usa un ambiente di test isolato. Durante la prova, mantieni i dati ripristinati separati dall’ambiente di produzione.

• Verifica l’ambiente di destinazione e gli accessi necessari per effettuare il ripristino.
• Recupera configurazione e segreti necessari tramite la procedura sicura appropriata.
• Ripristina il database e i file seguendo la procedura documentata, mantenendo la relazione prevista tra loro.
• Annota i componenti che devono essere ricreati o ricollegati invece di essere ripristinati dal backup.

Verifica i record collegati e il normale funzionamento dell’applicazione

Una prova di ripristino fornisce riscontri pratici sulla possibilità di usare i backup. Scegli un insieme di backup rappresentativo e provalo in un ambiente isolato. Controlla record ordinari e record con allegati: non limitarti a verificare se il database o l’applicazione si avviano.

Confronta i dati ripristinati con esempi noti dell’ambiente di origine, comprese le modifiche recenti che dovrebbero essere presenti nel backup selezionato. Se manca qualcosa, annota il problema e verifica se dipende dall’ambito, dalla tempistica di acquisizione, dalla procedura di ripristino o da una dipendenza esterna.

• Apri record rappresentativi e verifica che gli allegati o i file collegati siano accessibili.
• Controlla i record recenti e le modifiche che dovrebbero essere presenti nel backup selezionato.
• Se l’applicazione consente di verificarlo, cerca file orfani o record che rimandano a file mancanti.
• Prova una normale operazione dell’applicazione, non soltanto l’accesso.
• Annota cosa è stato ripristinato, gli errori o i dati mancanti e gli eventuali passaggi di recupero manuale.

Documenta e rivedi il piano di ripristino

Conserva una breve scheda dei backup in un luogo accessibile al personale che si occupa del ripristino. Distingui i dettagli confermati dalle supposizioni e dalle domande senza risposta. Una pianificazione indica con quale frequenza possono essere creati i backup; da sola non ne definisce la conservazione, la copertura o la coerenza.

Aggiorna la scheda quando cambiano l’applicazione, l’archiviazione, la configurazione o la modalità di hosting, e periodicamente in base alle esigenze operative. Se un dettaglio importante non è ancora stato confermato, contrassegnalo come non verificato e decidi se richiedere una risposta documentata o effettuare una prova.

• Annota copertura confermata, esclusioni, pianificazione, conservazione e procedura per accedere ai dati di backup.
• Indica chi contatta il provider, fornisce le informazioni a livello di applicazione e convalida il ripristino.
• Conserva i risultati datati delle prove di ripristino, inclusi i controlli non superati e le azioni successive.
• Dopo ogni modifica, verifica nuovamente le dipendenze e ripeti le prove di ripristino pertinenti.