Proteggere i dati utilizzando i backup

Seleziona una versione della documentazione:

Questa pagina descrive l'architettura di riferimento per la disponibilità standard di AlloyDB Omni, che fornisce la protezione dei dati tramite backup.

Casi d'uso

Questa architettura di riferimento supporta i seguenti scenari:

  • Hai database che possono tollerare alcuni tempi di inattività e perdita di dati dall'ultimo backup.
  • Vuoi proteggere il tuo database AlloyDB Omni da errori dell'utente, danneggiamenti o guasti fisici a livello di database (anziché snapshot di immagini di server o VM).
  • Vuoi essere in grado di 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 la disponibilità standard copre il backup e il recupero dei database AlloyDB Omni, sia che vengano eseguiti come istanza autonoma su un server host, come macchina virtuale (Install AlloyDB Omni), o in un cluster Kubernetes (Install AlloyDB Omni on Kubernetes).

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 da eseguire il backup, più tempo è necessario per ripristinare e recuperare il database. La perdita di dati dipende dal tipo di backup. Se viene eseguito il backup dei file di dati solo periodicamente, quando esegui il ripristino, si verifica una perdita di dati dall'ultimo backup.

Riduzione dell'RPO

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

Se i file WAL vengono archiviati solo quando sono completi 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 il Recovery Point Objective (RPO) deve tenere conto della potenziale perdita di dati. Al contrario, il trasferimento continuo dei dati WAL massimizza la perdita di dati pari a zero.

Quando esegui backup continui, puoi eseguire il recupero in un momento specifico. Il recupero point-in-time consente il ripristino a uno stato precedente a un errore, ad esempio l'eliminazione accidentale di una tabella o aggiornamenti batch errati. Tuttavia, questo metodo di recupero influisce sul Recovery Point Objective (RPO) a meno che non venga utilizzato un database ausiliario temporaneo.

Strategie di backup

Puoi configurare i backup a livello di PostgreSQL di AlloyDB Omni in modo che vengano archiviati nello spazio di archiviazione locale o remoto. Sebbene lo spazio di archiviazione locale possa essere più veloce per il backup e il recupero, lo spazio di archiviazione remoto è in genere più affidabile per la gestione degli errori quando si verifica un errore dell'intero host o VM.

Backup in ambienti non Kubernetes

Per i deployment non Kubernetes, puoi pianificare i backup utilizzando i seguenti strumenti PostgreSQL:

In alternativa, per i database di piccole dimensioni, puoi scegliere di eseguire un backup logico del database (utilizzando pg_dump per un singolo database o pg_dumpall per l'intero cluster). Puoi eseguire il ripristino utilizzando pg_restore.

Backup in Kubernetes utilizzando l'operatore AlloyDB Omni

Per AlloyDB Omni di cui è stato eseguito il deployment in un cluster Kubernetes, puoi configurare i backup continui utilizzando un piano di backup per ogni cluster di database. Per ulteriori informazioni, vedi Eseguire il backup e il ripristino in Kubernetes.

Puoi archiviare i backup di AlloyDB Omni localmente o da remoto in Cloud Storage, incluse le opzioni fornite da qualsiasi fornitore di servizi cloud. Per ulteriori informazioni, 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.

I backup possono essere eseguiti in opzioni di archiviazione locali o remote. I backup locali tendono a essere più veloci 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 forniscono una protezione ottimale, inclusi gli errori a livello di zona.

Puoi anche dividere i backup locali in spazio di archiviazione locale o condiviso. Sebbene le opzioni di archiviazione locale siano interessate dalla mancanza di opzioni di ripristino di emergenza in caso di errore di un host di database, lo spazio di archiviazione condiviso consente di spostare lo spazio di archiviazione su un altro server e quindi utilizzarlo per il recupero. Ciò significa che lo spazio di archiviazione condiviso offre potenzialmente un RTO più rapido.

Per i deployment di spazio di archiviazione locale e condiviso, i seguenti tipi di backup possono essere pianificati o eseguiti manualmente su richiesta:

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

Recupero point-in-time

I backup continui dei file WAL (Write-Ahead Logging) 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 recupero senza perdita di dati.

Per controllare la scrittura dei file WAL, puoi configurare i seguenti parametri:

Parametro Descrizione

wal_writer_delay

Specifica la frequenza con cui il writer WAL esegue il flush del WAL su disco, a meno che la scrittura non venga riattivata prima da una transazione che esegue il commit in modo asincrono Il valore predefinito è 200 ms. L'aumento di questo valore riduce la frequenza delle scritture, ma potrebbe aumentare la quantità di dati persi in caso di arresto anomalo del server.

wal_writer_flush_after

Specifica la quantità di dati WAL che possono accumularsi prima che il writer WAL forzi un flush su disco. Il valore predefinito è 1 MB. Se impostato su zero, i dati WAL vengono sempre scaricati immediatamente su disco.

synchronous_commit

Specifica se il commit restituisce una risposta all'utente prima che i dati WAL vengano scaricati su disco. L'impostazione predefinita è on, che garantisce la durabilità della transazione. In altre parole, il commit è stato scritto su disco prima di restituire un codice di successo all'utente. Se impostato su off, prima che la transazione venga scritta su disco, trascorrono fino a tre volte wal_writer_delay.

Monitoraggio dell'utilizzo di WAL

Puoi utilizzare i seguenti metodi per osservare l'utilizzo di WAL:

Metodo di osservazione Descrizione

pg_stat_wal

Questa visualizzazione standard ha le colonne wal_write e wal_sync, che memorizzano i conteggi del numero di scritture WAL e sincronizzazioni WAL. Quando il parametro di configurazione track_wal_io_timing è abilitato, vengono memorizzati anche wal_write_time e wal_sync_time. Gli snapshot regolari di questa visualizzazione possono aiutare a visualizzare l'attività di scrittura e sincronizzazione WAL nel tempo.
pg_current_wal_lsn() Questa funzione restituisce la posizione corrente del numero di sequenza di log (LSN), che, se associata a un timestamp e raccolta come snapshot nel tempo, può fornire i byte/secondo di WAL generati utilizzando la funzione pg_wal_lsn_diff(lsn1, lsn2). Questa funzione è una metrica utile per comprendere la frequenza delle transazioni e il rendimento dei file WAL.

Streaming dei dati WAL in una posizione remota

Quando utilizzi Barman, puoi anche configurare lo streaming dei dati WAL in tempo reale in una posizione remota per garantire una perdita di dati minima o nulla durante il recupero. Nonostante lo streaming in tempo reale, esiste una piccola possibilità di perdere le transazioni di cui è stato eseguito il commit, poiché le scritture di streaming sul server Barman remoto sono asincrone per impostazione predefinita. Tuttavia, è possibile configurare lo streaming WAL utilizzando la modalità sincrona che archivia il WAL e invia una risposta di stato al database di origine. Tieni presente che questo approccio può rallentare le transazioni se devono attendere il completamento di questa scrittura prima di continuare.

Pianificazioni di backup

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

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

Utilizzando questa pianificazione tipica, una finestra di recupero continua di una settimana richiede spazio di archiviazione per un massimo di tre backup completi più i backup incrementali o differenziali richiesti. Questo approccio supporta il recupero per un errore che si verifica durante il backup completo di domenica e il recupero del database deve estendersi alla domenica precedente all'inizio del backup.

Per ridurre al minimo l'RTO con un potenziale RPO più elevato, è possibile eseguire altri database in modalità di recupero continuo. Ciò comporta 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 dei file WAL e dall'utilizzo dello streaming WAL.

Ripristino in ambienti non Kubernetes

Per i deployment non Kubernetes, il ripristino di un database AlloyDB Omni prevede l'arresto del container Docker e il ripristino dei dati oppure il ripristino dei dati in una posizione diversa e l'avvio di una nuova istanza Docker utilizzando i dati ripristinati. Una volta riavviato il container, il database è accessibile con i dati ripristinati.

Per ulteriori informazioni sulle opzioni di recupero, vedi Ripristinare un cluster AlloyDB Omni utilizzando pgBackRest e Ripristinare un cluster AlloyDB Omni utilizzando Barman.

Ripristino in Kubernetes utilizzando l'operatore

Per ripristinare un database in Kubernetes, l'operatore offre il recupero nello stesso cluster e spazio dei nomi Kubernetes, da un backup denominato o da un clone da un momento specifico (PIT). Per clonare un database in un cluster Kubernetes diverso, utilizza pgBackRest. Per ulteriori informazioni, vedi Eseguire il backup e il ripristino in Kubernetes e Panoramica della clonazione di un cluster di database da un backup di 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 e adatto a database non critici con RTO/RPO flessibili.
  • Hardware aggiuntivo minimo richiesto
  • I backup sono sempre necessari per un piano di ripristino di emergenza completo
  • È possibile eseguire il recupero in qualsiasi momento all'interno della finestra di recupero

Limitazioni

  • Requisiti di spazio di archiviazione potenzialmente maggiori del database stesso, a seconda dei requisiti di conservazione.
  • Il recupero 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 l'errore del database, che potrebbe influire negativamente sull'RPO.

Alternative

  • Valuta l'architettura di disponibilità avanzata o premium per opzioni di disponibilità e ripristino di emergenza migliorate.

Passaggi successivi