Proteggere i dati utilizzando i backup

Seleziona una versione della documentazione:

Questa pagina descrive l'architettura di riferimento di AlloyDB Omni Standard Availability, che fornisce la protezione dei dati utilizzando i backup.

Casi d'uso

Questa architettura di riferimento supporta i seguenti scenari:

  • Hai database che possono tollerare un certo tempo di inattività e una perdita di dati dall'ultimo backup.
  • Vuoi proteggere il tuo database AlloyDB Omni da errori dell'utente, danneggiamento o errori fisici a livello di database, anziché snapshot di immagini di server o VM.
  • Vuoi recuperare il database in loco o da remoto, possibilmente fino a un momento specifico.

Come funziona l'architettura di riferimento

L'architettura di riferimento per l'alta affidabilità standard copre il backup e il ripristino dei database AlloyDB Omni.

Sebbene la disponibilità standard sia un'implementazione di base e riduca al minimo l'hardware o i servizi aggiuntivi richiesti, il Recovery Time Objective (RTO) aumenta man mano che il database diventa più grande. Più dati sono presenti nel backup, più tempo sarà necessario per ripristinare e recuperare il database. La perdita di dati dipende dal tipo di backup. Se viene eseguito periodicamente il backup solo dei file di dati, quando esegui il ripristino si verifica una perdita di dati dall'ultimo backup.

Riduzione dell'RPO

La funzionalità di archiviazione continua di PostgreSQL ti consente di ottenere un Recovery Point Objective (RPO) basso e di abilitare il recupero point-in-time tramite i backup. Questo processo prevede l'archiviazione dei file Write-Ahead Logging (WAL) e lo streaming dei dati WAL, potenzialmente in una posizione di archiviazione remota.

Se i file WAL vengono archiviati solo quando sono pieni o a intervalli specifici, una perdita completa del database (inclusi i file WAL correnti) limita il recupero all'ultimo file WAL archiviato, il che significa che l'RPO deve tenere conto della potenziale perdita di dati. Al contrario, il trasferimento continuo dei dati WAL riduce al minimo la potenziale perdita di dati.

Quando configuri i backup continui, puoi eseguire il recupero point-in-time. Il recupero point-in-time consente di ripristinare un database allo stato in cui si trovava prima di un errore, ad esempio l'eliminazione accidentale di una tabella o aggiornamenti batch errati. Tuttavia, questo metodo di recupero influisce sia sull'RPO che sull'RTO, a meno che non utilizzi un database ausiliario temporaneo. Il ripristino di un intero database in loco esegue il rollback delle transazioni successive sulle tabelle non interessate e porta il database offline, mentre il ripristino in un database ausiliario temporaneo consente di copiare solo i dati recuperati.

Strategie di backup

AlloyDB Omni supporta strategie di protezione dei dati come backup fisici periodici, recupero point-in-time, archiviazione e streaming WAL e archiviazione dei backup in località diverse. In alternativa, per i database di piccole dimensioni, puoi eseguire un backup logico utilizzando pg_dump per un singolo database o pg_dumpall per l'intero cluster ed eseguire il ripristino utilizzando pg_restore.

Strumenti di backup

Per i deployment Kubernetes, puoi configurare i backup continui utilizzando un piano di backup (BackupPlan) gestito dall'operatore AlloyDB Omni per ogni cluster di database. Per saperne di più, consulta Backup e ripristino in Kubernetes.

A seconda dell'opzione di deployment, puoi configurare AlloyDB Omni per archiviare i backup in uno spazio di archiviazione locale o remoto, come Cloud Storage o le opzioni di archiviazione fornite da qualsiasi fornitore di cloud. Sebbene lo spazio di archiviazione locale possa essere più veloce per il backup e il ripristino, lo spazio di archiviazione remoto è solitamente più affidabile per la gestione degli errori quando un intero host o una VM non funziona. Per saperne di più, vedi la Figura 1, che mostra le potenziali destinazioni di backup.

AlloyDB Omni con opzioni di backup

Figura 1. AlloyDB Omni con opzioni di backup.

Puoi eseguire i backup su opzioni di archiviazione locali o remote. I backup locali tendono a essere più rapidi perché si basano solo sul throughput di I/O, mentre i backup remoti di solito hanno una latenza più elevata e una larghezza di banda di rete inferiore. Tuttavia, i backup remoti offrono una protezione migliore contro gli errori dell'host e della zona rispetto ai backup locali.

Puoi anche suddividere i backup locali in spazio di archiviazione locale o condiviso. Mentre lo spazio di archiviazione locale non dispone di opzioni di ripristino di emergenza in caso di errore dell'host del database, lo spazio di archiviazione condiviso consente di spostare lo spazio di archiviazione su un altro server e utilizzarlo per il ripristino. Ciò significa che lo spazio di archiviazione condiviso offre potenzialmente un RTO più rapido.

Per i deployment di archiviazione locale, condivisa e remota, puoi pianificare i seguenti tipi di backup o eseguirli manualmente on demand:

  • Backup completi: backup completi di tutti i file di database necessari per il recupero dati.
  • Backup differenziali: backup delle sole modifiche ai file dall'ultimo backup completo.
  • Backup incrementali: backup delle sole modifiche ai file dall'ultimo backup di qualsiasi tipo.

Recupero point-in-time

I backup continui dei file WAL di PostgreSQL supportano il recupero point-in-time. Se, dopo un evento di errore, i file WAL sono intatti e utilizzabili, puoi utilizzarli per eseguire il ripristino a un momento specifico e ridurre al minimo la perdita di dati.

Pianificazioni di backup

Nella maggior parte degli ambienti, i backup vengono solitamente pianificati su base settimanale. Di seguito è riportata una pianificazione settimanale tipica dei backup:

  • Domenica: backup completo
  • Lunedì, martedì: backup incrementale
  • Mercoledì: backup differenziale
  • Giovedì, venerdì: backup incrementale
  • Sabato: backup differenziale

Utilizzando questa pianificazione tipica, una finestra di recupero in sequenza di una settimana richiede spazio di archiviazione per un massimo di tre backup completi, oltre ai backup incrementali o differenziali richiesti. Questo approccio supporta il ripristino in caso di errore che si verifica durante il backup completo di domenica, quando il ripristino del database deve estendersi alla domenica precedente prima dell'inizio del backup.

Per ridurre al minimo l'RTO con un potenziale di RPO più elevato, altri database possono operare in modalità di recupero continuo. Questa modalità prevede la riproduzione dei backup e l'aggiornamento continuo dell'ambiente secondario tramite l'archiviazione e la riproduzione di nuovi file WAL. L'RPO effettivo, che riflette la potenziale perdita di dati, dipende dalla frequenza delle transazioni, dalle dimensioni del file WAL e dall'utilizzo dello streaming WAL.

Ripristino del backup

Puoi ripristinare un database AlloyDB Omni da un backup archiviato o recuperarlo in un momento specifico all'interno della finestra di conservazione. A seconda dell'ambiente di deployment e delle esigenze di ripristino, puoi ripristinare i dati in loco o ripristinare il backup in una nuova istanza o un nuovo cluster di database.

Per i deployment Kubernetes, l'operatore AlloyDB Omni supporta il recupero di un database nello stesso cluster e spazio dei nomi Kubernetes da un backup denominato o la clonazione da un momento specifico. Per saperne di più, consulta Backup e ripristino in Kubernetes e Panoramica della clonazione manuale di un cluster di database da un backup Kubernetes.

Implementazione

Quando scegli un'architettura di riferimento per la disponibilità, tieni presente i seguenti vantaggi, limitazioni e alternative.

Vantaggi

  • È semplice da usare e gestire ed è adatto per database non critici con RTO e RPO flessibili.
  • Richiede un hardware aggiuntivo minimo.
  • Fornisce i backup di base richiesti per un piano di ripristino di emergenza.
  • Supporta il ripristino in qualsiasi momento all'interno della finestra di ripristino.

Limitazioni

  • Può richiedere più spazio di archiviazione rispetto al database stesso, a seconda dei requisiti di conservazione.
  • Il ripristino può essere lento e potrebbe comportare un RTO più elevato.
  • Può comportare una perdita di dati, a seconda della disponibilità dei dati WAL correnti dopo un errore del database, il che potrebbe influire negativamente sull'RPO.

Alternative

Prendi in considerazione l'architettura di riferimento Disponibilità avanzata o Disponibilità premium per migliorare la disponibilità e le opzioni di ripristino di emergenza.

Passaggi successivi