Scenari di ripristino di emergenza dei dati

Last reviewed 2022-06-10 UTC

Questo documento è la terza parte di una serie che illustra il ripristino di emergenza (RE) in Google Cloud. Questa parte illustra gli scenari per il backup e il recupero dei dati.

La serie è costituita dai seguenti componenti:

Introduzione

I tuoi piani di ripristino di emergenza devono specificare come evitare di perdere dati durante un'emergenza. In questo caso, il termine dati si riferisce a due scenari. Il backup e il recupero di database, dati di log e altri tipi di dati rientrano in uno dei seguenti scenari:

  • Backup dei dati. Il backup dei soli dati comporta la copia di una quantità discreta di dati da un luogo all'altro. I backup vengono eseguiti nell'ambito di un piano di ripristino per ripristinare i dati dopo un danneggiamento dei dati in modo da poter ripristinare uno stato noto direttamente nell'ambiente di produzione o per ripristinare i dati nell'ambiente di RE se l'ambiente di produzione è inattivo. In genere, i backup dei dati hanno un RTO medio-piccolo e un RPO ridotto.
  • Backup dei database. I backup dei database sono leggermente più complessi perché di solito prevedono il ripristino fino al momento giusto. Pertanto, oltre a considerare come eseguire il backup e ripristinare i backup del database e assicurarti che il sistema di database di ripristino rispecchi la configurazione di produzione (stessa versione, configurazione del disco con mirroring), devi anche considerare come eseguire il backup dei log delle transazioni. Durante il ripristino, dopo aver ripristinato la funzionalità del database, devi applicare il backup del database più recente e poi i log delle transazioni recuperati di cui è stato eseguito il backup dopo l'ultimo backup. A causa dei fattori di complicazione inerenti ai sistemi di database (ad esempio la necessità di far corrispondere le versioni tra i sistemi di produzione e di ripristino), l'adozione di un approccio incentrato sulla disponibilità elevata per ridurre al minimo il tempo di ripristino da una situazione che potrebbe causare l'indisponibilità del server del database, consente di ottenere valori RTO e RPO minori.

Il resto di questo documento illustra esempi di come progettare alcuni scenari per dati e database che possono aiutarti a raggiungere gli obiettivi RTO e RPO.

L'ambiente di produzione è on-premise

In questo scenario, l'ambiente di produzione è on-premise e il piano di ripristino di emergenza prevede l'utilizzo di Google Cloud come sito di ripristino.

Backup e recupero dei dati

Puoi utilizzare una serie di strategie per implementare un processo di backup regolare dei dati da un ambiente on-premise a Google Cloud. Questa sezione prende in esame due delle soluzioni più comuni.

Soluzione 1: esegui il backup in Cloud Storage utilizzando un'attività pianificata

Componenti di base per la RE:

  • Cloud Storage

Un'opzione per il backup dei dati è creare un'attività pianificata che esegue uno script o un'applicazione per trasferire i dati in Cloud Storage. Puoi automatizzare un processo di backup in Cloud Storage utilizzando lo strumento a riga di comando gsutil o una delle librerie client di Cloud Storage. Ad esempio, il seguente comando gsutil copia tutti i file da una directory di origine a un bucket specificato.

gsutil -m cp -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

I passaggi seguenti spiegano come implementare una procedura di backup e recupero utilizzando lo strumento gsutil.

  1. Installa gsutil sulla macchina on-premise che utilizzi per caricare i file di dati.
  2. Crea un bucket come destinazione per il backup dei dati.
  3. Genera una chiave dell'account di servizio per un account di servizio dedicato in formato JSON. Questo file viene utilizzato per passare le credenziali a gsutil nell'ambito di uno script automatico

  4. Copia la chiave dell'account di servizio nella macchina on-premise in cui esegui lo script che utilizzi per caricare i backup.

  5. Crea un criterio IAM per limitare gli utenti che possono accedere al bucket e ai suoi oggetti. (Includi l'account di servizio creato appositamente per questo scopo e un account operatore on-premise). Per maggiori dettagli sulle autorizzazioni per l'accesso a Cloud Storage, vedi Autorizzazioni IAM per i comandi gsutil.

  6. Verifica di poter caricare e scaricare i file nel bucket di destinazione.

  7. Segui le indicazioni fornite nell'articolo Eseguire lo script delle attività di trasferimento di dati per configurare uno script pianificato.

  8. Configura un processo di recupero che utilizzi gsutil per recuperare i dati nell'ambiente di ripristino di emergenza su Google Cloud.

Puoi anche utilizzare il comando gsutil rsync per eseguire sincronizzazioni incrementali in tempo reale tra i tuoi dati e un bucket Cloud Storage.

Ad esempio, il seguente comando gsutil rsync rende i contenuti di un bucket Cloud Storage uguali a quelli della directory di origine copiando eventuali file o oggetti mancanti o i cui dati sono stati modificati. Se il volume di dati che è cambiato tra le sessioni di backup successive è ridotto rispetto all'intero volume dei dati di origine, l'utilizzo di gsutil rsync può essere più efficiente rispetto all'uso di gsutil cp. Ciò consente a sua volta una pianificazione del backup più frequente e un valore RPO più basso.

gsutil -m rsync -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

Per ulteriori informazioni, consulta Trasferimento da colocation o archiviazione on-premise, che include modi per ottimizzare il processo di trasferimento.

Soluzione 2: esegui il backup in Cloud Storage utilizzando Transfer Service for On Premises Data

Componenti di base per la RE:

  • Cloud Storage
  • Transfer Service for On Premises Data

Il trasferimento di grandi quantità di dati su una rete spesso richiede un'attenta pianificazione e solide strategie di esecuzione. Sviluppare script personalizzati scalabili, affidabili e gestibili non è semplice. Gli script personalizzati possono spesso portare a valori RPO più bassi e persino a maggiori rischi di perdita di dati.

Un modo per implementare il trasferimento di dati su larga scala è utilizzare Transfer Service for On Premises Data. Questo servizio è un servizio scalabile, affidabile e gestito che consente di trasferire grandi quantità di dati dal tuo data center a un bucket Cloud Storage senza investire in team di progettazione o acquistare soluzioni di trasferimento.

Soluzione 3: esegui il backup in Cloud Storage utilizzando una soluzione gateway partner

Componenti di base per la RE:

  • Cloud Interconnect
  • Archiviazione a livelli di Cloud Storage

Le applicazioni on-premise sono spesso integrate con soluzioni di terze parti che possono essere utilizzate come parte della strategia di backup e ripristino dei dati. Le soluzioni spesso utilizzano un pattern di archiviazione a livelli in cui disponi dei backup più recenti in un'archiviazione più veloce e migrano lentamente i backup meno recenti a quelli più economici (più lenti). Quando utilizzi Google Cloud come destinazione, hai a disposizione diverse opzioni della classe di archiviazione da utilizzare come equivalente del livello più lento.

Un modo per implementare questo pattern è utilizzare un gateway partner tra lo spazio di archiviazione on-premise e Google Cloud per facilitare il trasferimento di dati in Cloud Storage. Il seguente diagramma illustra questa disposizione, con una soluzione partner che gestisce il trasferimento dall'appliance NAS on-premise o dalla rete SAN.

Diagramma dell'architettura che mostra un data center on-premise connesso a Google Cloud tramite un'interconnessione dedicata.

In caso di errore, i dati di cui viene eseguito il backup devono essere recuperati nell'ambiente di RE. L'ambiente RE viene utilizzato per gestire il traffico di produzione fino a quando non sei in grado di tornare all'ambiente di produzione. Il modo in cui puoi raggiungerlo dipende dall'applicazione, dalla soluzione del partner e dalla sua architettura. (Alcuni scenari end-to-end sono discussi nel documento dell'applicazione RE.)

Per ulteriori indicazioni su come trasferire i dati da un ambiente on-premise a Google Cloud, consulta Trasferimento di set di big data in Google Cloud.

Per ulteriori informazioni sulle soluzioni dei partner, consulta la pagina dei partner sul sito web di Google Cloud.

Backup e ripristino del database

Puoi utilizzare una serie di strategie per implementare un processo di ripristino di un sistema di database da un ambiente on-premise a Google Cloud. Questa sezione prende in esame due delle soluzioni più comuni.

Non rientra nell'ambito di questo documento discutere in dettaglio i vari meccanismi integrati di backup e ripristino inclusi nei database di terze parti. Questa sezione fornisce indicazioni generali, implementate nelle soluzioni qui discusse.

Soluzione 1: backup e ripristino mediante un server di recupero su Google Cloud

  1. Crea un backup del database utilizzando i meccanismi di backup integrati del tuo sistema di gestione del database.
  2. Connetti la tua rete on-premise e la tua rete Google Cloud.
  3. Crea un bucket Cloud Storage come destinazione per il backup dei dati.
  4. Copia i file di backup in Cloud Storage utilizzando gsutil o una soluzione gateway partner (vedi i passaggi illustrati in precedenza nella sezione relativa a backup e recupero dei dati). Per maggiori dettagli, consulta Trasferimento di set di big data in Google Cloud.
  5. Copia i log delle transazioni nel tuo sito di recupero su Google Cloud. Disporre di un backup dei log delle transazioni consente di ridurre i valori RPO.

Dopo aver configurato questa topologia di backup, devi assicurarti di poter eseguire il ripristino nel sistema che si trova su Google Cloud. Questo passaggio in genere comporta non solo il ripristino del file di backup nel database di destinazione, ma anche la riproduzione dei log delle transazioni per ottenere il valore RTO minimo. Una sequenza di ripristino tipica è la seguente:

  1. Crea un'immagine personalizzata del tuo server di database su Google Cloud. Il server di database deve avere la stessa configurazione nell'immagine del server di database on-premise.
  2. Implementare un processo per copiare i file di backup on-premise e i file di log delle transazioni in Cloud Storage. Consulta la soluzione 1 per un'implementazione di esempio.
  3. Avvia un'istanza di dimensioni minime dall'immagine personalizzata e collega i dischi permanenti necessari.
  4. Imposta il flag di eliminazione automatica su false per i dischi permanenti.
  5. Applica il file di backup più recente copiato in precedenza in Cloud Storage, seguendo le istruzioni del sistema del database per recuperare i file di backup.
  6. Applica l'ultimo set di file di log delle transazioni che sono stati copiati in Cloud Storage.
  7. Sostituisci l'istanza minima con un'istanza più grande in grado di accettare traffico di produzione.
  8. Cambia client in modo che puntino al database recuperato in Google Cloud.

Quando il tuo ambiente di produzione è in esecuzione ed è in grado di supportare i carichi di lavoro di produzione, devi invertire i passaggi seguiti per eseguire il failover nell'ambiente di ripristino di Google Cloud. Una sequenza tipica per tornare all'ambiente di produzione ha questo aspetto:

  1. Esegui un backup del database in esecuzione su Google Cloud.
  2. Copia il file di backup nell'ambiente di produzione.
  3. Applica il file di backup al sistema di database di produzione.
  4. Impedire ai client di connettersi al sistema di database in Google Cloud, ad esempio arrestando il servizio di sistema di database. A questo punto, l'applicazione non sarà disponibile finché non avrai completato il ripristino dell'ambiente di produzione.
  5. Copia tutti i file di log delle transazioni nell'ambiente di produzione e applicali.
  6. Reindirizza le connessioni client all'ambiente di produzione.

Soluzione 2: replica su un server in standby su Google Cloud

Un modo per ottenere valori RTO e RPO molto ridotti è replicare (non solo eseguire il backup) dei dati e, in alcuni casi, dello stato del database in tempo reale in un hot standby del server del database.

  1. Connetti la tua rete on-premise e la tua rete Google Cloud.
  2. Crea un'immagine personalizzata del tuo server di database su Google Cloud. Il server di database deve avere la stessa configurazione nell'immagine di quella del server di database on-premise.
  3. Avvia un'istanza dall'immagine personalizzata e collega i dischi permanenti necessari.
  4. Imposta il flag di eliminazione automatica su false per i dischi permanenti.
  5. Configura la replica tra il server di database on-premise e il server di database di destinazione in Google Cloud seguendo le istruzioni specifiche per il software del database.
  6. I client sono configurati durante il normale funzionamento per puntare al server del database on-premise.

Dopo aver configurato questa topologia di replica, cambia client in modo che punti al server in standby in esecuzione nella rete Google Cloud.

Quando il tuo ambiente di produzione è in fase di backup ed è in grado di supportare i carichi di lavoro di produzione, devi risincronizzare il server del database di produzione con il server di database di Google Cloud e poi cambiare client in modo che punti di nuovo all'ambiente di produzione

L'ambiente di produzione è Google Cloud

In questo scenario, sia l'ambiente di produzione sia l'ambiente di ripristino di emergenza vengono eseguiti su Google Cloud.

Backup e recupero dei dati

Un pattern comune per i backup dei dati è l'utilizzo di un pattern di archiviazione a più livelli. Quando il carico di lavoro di produzione si trova su Google Cloud, il sistema di archiviazione a più livelli è simile al seguente diagramma. Esegui la migrazione dei dati a un livello con costi di archiviazione inferiori, poiché il requisito per accedere ai dati di cui è stato eseguito il backup è meno probabile.

Componenti di base per la RE:

Diagramma concettuale che mostra un'immagine che mostra una diminuzione dei costi durante la migrazione dei dati dai dischi permanenti a Nearline a Coldline.

Poiché le classi di archiviazione Nearline, Coldline e Archive sono destinate ad archiviare dati a cui si accede raramente, sono previsti costi aggiuntivi associati al recupero di dati o metadati archiviati in queste classi, oltre a durate minime di archiviazione per le quali vengono addebitati i costi.

Backup e ripristino del database

Quando utilizzi un database autogestito (ad esempio, hai installato MySQL, PostgreSQL o SQL Server su un'istanza di Compute Engine), si applicano gli stessi problemi operativi della gestione dei database di produzione on-premise, ma non è più necessario gestire l'infrastruttura sottostante.

Puoi impostare le configurazioni ad alta disponibilità utilizzando le funzionalità dei componenti di base per la RE appropriate per ridurre le dimensioni dell'RTO. È possibile progettare la configurazione del database in modo da consentire il ripristino a uno stato il più vicino possibile a quello precedente all'emergenza. In questo modo, è possibile ridurre i valori dell'RPO. Google Cloud offre un'ampia varietà di opzioni per questo scenario.

In questa sezione vengono discussi due approcci comuni alla progettazione dell'architettura di recupero dei database per database autogestiti su Google Cloud.

Recupero di un server di database senza sincronizzazione dello stato

Un pattern comune è abilitare il ripristino di un server di database che non richiede la sincronizzazione dello stato del sistema con un hot standby.

Componenti di base per la RE:

  • Compute Engine
  • gruppi di istanze gestite
  • Cloud Load Balancing (bilanciamento del carico interno)

Il seguente diagramma illustra un'architettura di esempio che affronta lo scenario. Con l'implementazione di questa architettura, disponi di un piano di RE che reagisce automaticamente a un errore senza richiedere il ripristino manuale.

Diagramma dell'architettura che mostra l'immagine di un disco permanente acquisita da un disco permanente in una zona

I passaggi seguenti spiegano come configurare questo scenario:

  1. Crea una rete VPC.

  2. Crea un'immagine personalizzata configurata con il server di database seguendo questi passaggi:

    1. Configurare il server in modo che i file di database e i file di log vengano scritti su un disco permanente standard collegato.
    2. Crea uno snapshot dal disco permanente collegato.
    3. Configurare uno script di avvio per creare un disco permanente dallo snapshot e per montare il disco.
    4. Crea un'immagine personalizzata del disco di avvio.

  3. Crea un modello di istanza che utilizzi l'immagine.

  4. Utilizzando il modello di istanza, configura un gruppo di istanze gestite con una dimensione di destinazione pari a 1.

  5. Configurare il controllo di integrità utilizzando le metriche di Cloud Monitoring.

  6. Configura il bilanciamento del carico interno utilizzando il gruppo di istanze gestite.

  7. Configurare un'attività pianificata per creare snapshot regolari del disco permanente.

Nel caso in cui sia necessaria un'istanza di database sostitutiva, questa configurazione esegue automaticamente quanto segue:

  • Consente di aprire un altro server di database della versione corretta nella stessa zona.
  • Collega un disco permanente con i file di backup e di log delle transazioni più recenti all'istanza del server di database appena creata.
  • Riduce al minimo la necessità di riconfigurare i client che comunicano con il server del database in risposta a un evento.
  • Garantisce che i controlli di sicurezza di Google Cloud (criteri IAM, impostazioni firewall) applicabili al server di database di produzione si applichino al server di database ripristinato.

Poiché l'istanza sostitutiva viene creata a partire da un modello di istanza, i controlli applicati all'istanza originale si applicano all'istanza sostitutiva.

Questo scenario sfrutta alcune delle funzionalità ad alta disponibilità disponibili in Google Cloud. Non è necessario avviare passaggi di failover, perché si verificano automaticamente in caso di emergenza. Il bilanciatore del carico interno garantisce che, anche quando è necessaria un'istanza sostitutiva, venga utilizzato lo stesso indirizzo IP per il server di database. Il modello di istanza e l'immagine personalizzata assicurano che l'istanza sostitutiva sia configurata in modo identico all'istanza che sta sostituendo. Mediante l'acquisizione di snapshot regolari dei dischi permanenti, ti assicuri che, quando i dischi vengono ricreati dagli snapshot e collegati all'istanza sostitutiva, l'istanza sostitutiva utilizza i dati recuperati in base a un valore RPO dettato dalla frequenza degli snapshot. In questa architettura, vengono ripristinati automaticamente anche i file di log delle transazioni più recenti scritti sul disco permanente.

Il gruppo di istanze gestite fornisce l'alta disponibilità in profondità. Fornisce meccanismi per reagire agli errori a livello di applicazione o istanza e non è necessario intervenire manualmente se si verifica uno di questi scenari. L'impostazione di una dimensione di destinazione pari a 1 garantisce la presenza di una sola istanza attiva in esecuzione nel gruppo di istanze gestite che gestisce il traffico.

I dischi permanenti standard sono a livello di zona, perciò in caso di errore a livello di zona, sono necessari snapshot per ricreare i dischi. Inoltre, gli snapshot sono disponibili in più regioni, consentendoti di ripristinare un disco non solo all'interno della stessa regione, ma anche in una regione diversa.

Una variante di questa configurazione è l'utilizzo di dischi permanenti a livello di regione al posto di quelli standard. In questo caso, non è necessario ripristinare lo snapshot durante il passaggio di ripristino.

La variante che scegli è dettata dal tuo budget e dai valori RTO e RPO.

Per ulteriori informazioni sulle configurazioni di database progettate per gli scenari di alta disponibilità e RE su Google Cloud, consulta quanto segue:

Recupero da un danneggiamento parziale in database di grandi dimensioni

Se utilizzi un database in grado di archiviare petabyte di dati, potrebbe verificarsi un'interruzione che interessa alcuni dati, ma non tutti. In questo caso, vuoi ridurre al minimo la quantità di dati da ripristinare. Non hai bisogno (o vuoi) recuperare l'intero database solo per ripristinare alcuni dati.

Esistono varie strategie di mitigazione che puoi adottare:

  • Archivia i dati in tabelle diverse per periodi di tempo specifici. Questo metodo garantisce che sia necessario ripristinare solo un sottoinsieme di dati in una nuova tabella, anziché un intero set di dati.

  • Archivia i dati originali in Cloud Storage. In questo modo, puoi creare una nuova tabella e ricaricare i dati non danneggiati. Da qui puoi modificare le applicazioni in modo che puntino alla nuova tabella.

Inoltre, se il RTO lo consente, è possibile impedire l'accesso alla tabella contenente i dati danneggiati lasciando le applicazioni offline finché i dati non danneggiati non saranno stati ripristinati in una nuova tabella.

Servizi di database gestiti su Google Cloud

Questa sezione illustra alcuni metodi che puoi utilizzare per implementare meccanismi di backup e ripristino appropriati per i servizi di database gestiti su Google Cloud.

I database gestiti sono progettati per la scalabilità, pertanto i tradizionali meccanismi di backup e ripristino che caratterizzano gli RDMBS tradizionali non sono generalmente disponibili. Come nel caso dei database autogestiti, se utilizzi un database in grado di archiviare petabyte di dati, dovresti ridurre al minimo la quantità di dati da ripristinare in uno scenario di RE. Per ogni database gestito esistono diverse strategie per raggiungere questo obiettivo.

Bigtable fornisce la replica di Bigtable. Un database Bigtable replicato può offrire una disponibilità maggiore rispetto a un singolo cluster, una velocità effettiva di lettura aggiuntiva e una maggiore durabilità e resilienza a fronte di errori a livello di zona o di regione.

I backup di Bigtable sono un servizio completamente gestito che consente di salvare una copia dello schema e dei dati di una tabella per poi eseguire il ripristino dal backup a una nuova tabella in un secondo momento.

Puoi anche esportare le tabelle da Bigtable come una serie di file di sequenza Hadoop. Puoi quindi archiviare questi file in Cloud Storage o utilizzarli per importare di nuovo i dati in un'altra istanza di Bigtable. Puoi replicare il tuo set di dati Bigtable in modo asincrono tra le zone all'interno di una regione Google Cloud.

BigQuery. Se vuoi archiviare i dati, puoi sfruttare l'archiviazione a lungo termine di BigQuery. Se una tabella non viene modificata per 90 giorni consecutivi, il relativo prezzo di archiviazione si riduce automaticamente del 50%. Non si verifica alcun peggioramento delle prestazioni, della durabilità, della disponibilità o di qualsiasi altra funzionalità quando una tabella viene considerata l'archiviazione a lungo termine. Se la tabella viene modificata, tuttavia, vengono ripristinati i prezzi di archiviazione standard e il conto alla rovescia di 90 giorni ricomincia.

BigQuery è replicato in due zone in una singola regione, ma questo non contribuisce al danneggiamento delle tabelle. Devi quindi avere un piano per poter ripristinare lo scenario da questo scenario. Ad esempio, puoi:

  • Se il danneggiamento viene rilevato entro 7 giorni, esegui una query sulla tabella per un momento passato per recuperare la tabella prima del danneggiamento utilizzando decoratori snapshot.
  • Esporta i dati da BigQuery e crea una nuova tabella che contiene i dati esportati, ma esclude quelli danneggiati.
  • Archivia i dati in tabelle diverse per periodi di tempo specifici. Questo metodo garantisce che sia necessario ripristinare solo un sottoinsieme di dati in una nuova tabella, anziché un intero set di dati.
  • Crea copie del tuo set di dati in periodi di tempo specifici. Puoi utilizzare queste copie se si è verificato un evento di danneggiamento dei dati oltre l'intervallo di tempo in cui una query point-in-time è in grado di acquisire (ad esempio, più di 7 giorni fa). Puoi anche copiare un set di dati da una regione all'altra per garantire la disponibilità dei dati in caso di errori delle regioni.
  • Archivia i dati originali su Cloud Storage, così puoi creare una nuova tabella e ricaricare i dati non danneggiati. Da qui puoi modificare le applicazioni in modo che puntino alla nuova tabella.

Firestore. Il servizio di esportazione e importazione gestito consente di importare ed esportare entità Firestore utilizzando un bucket Cloud Storage. Puoi quindi implementare un processo utilizzabile per il ripristino dall'eliminazione accidentale dei dati.

Cloud SQL. Se utilizzi Cloud SQL, il database MySQL completamente gestito, dovresti abilitare i backup automatici e il logging binario per le istanze Cloud SQL. Questo approccio consente di eseguire un recupero point-in-time, che ripristina il database da un backup e lo recupera a una nuova istanza Cloud SQL. Per maggiori dettagli, consulta Backup e ripristino di Cloud SQL.

Puoi anche configurare Cloud SQL in una configurazione ad alta disponibilità e repliche tra regioni per massimizzare il tempo di attività in caso di errore a livello di zona o di regione.

Se hai abilitato la manutenzione pianificata con tempi di inattività quasi azzerati per Cloud SQL, puoi valutare gli eventi di manutenzione dell'impatto sulle tue istanze simulando eventi di manutenzione pianificata con tempi di inattività prossimi allo zero su Cloud SQL per MySQL e su Cloud SQL per PostgreSQL.

Spanner. Puoi utilizzare i modelli Dataflow per eseguire un'esportazione completa del tuo database in un set di file Avro in un bucket Cloud Storage e utilizzare un altro modello per reimportare i file esportati in un nuovo database Spanner.

Per backup più controllati, il connettore Dataflow consente di scrivere codice per leggere e scrivere dati su Spanner in una pipeline Dataflow. Ad esempio, puoi utilizzare il connettore per copiare i dati da Spanner e in Cloud Storage come destinazione di backup. La velocità con cui i dati possono essere letti da Spanner (o riscritti) dipende dal numero di nodi configurati. Ciò ha un impatto diretto sui valori RTO.

La funzionalità di timestamp di commit di Spanner può essere utile per i backup incrementali, consentendoti di selezionare solo le righe aggiunte o modificate dall'ultimo backup completo.

Per i backup gestiti, Backup e ripristino di Spanner consente di creare backup coerenti che possono essere conservati per un massimo di 1 anno. Il valore RTO è inferiore rispetto a export perché l'operazione di ripristino monta direttamente il backup senza copiare i dati.

Per valori RTO ridotti, puoi configurare un'istanza Spanner in modalità standby configurata con il numero minimo di nodi necessario per soddisfare i requisiti di archiviazione, velocità effettiva di lettura e scrittura.

Il recupero point-in-time (PITR) di Spanner consente di recuperare i dati da un momento specifico nel passato. Ad esempio, se un operatore scrive inavvertitamente dati o un'implementazione di un'applicazione danneggia il database, con PITR puoi recuperare i dati da un momento passato, fino a un massimo di sette giorni.

Cloud Composer. Puoi utilizzare Cloud Composer (una versione gestita di Apache Airflow) per pianificare backup regolari di più database Google Cloud. Puoi creare un grafo diretto aciclico (DAG) da eseguire in base a una pianificazione (ad esempio, ogni giorno) per copiare i dati in un altro progetto, set di dati o tabella (a seconda della soluzione utilizzata) o esportare i dati in Cloud Storage.

L'esportazione o la copia dei dati può essere eseguita utilizzando i vari operatori di Cloud Platform.

Ad esempio, puoi creare un DAG per eseguire una delle seguenti operazioni:

L’ambiente di produzione è un altro cloud

In questo scenario, il tuo ambiente di produzione utilizza un altro cloud provider e il tuo piano di ripristino di emergenza prevede l'utilizzo di Google Cloud come sito di ripristino.

Backup e recupero dei dati

Il trasferimento di dati tra archivi di oggetti è un caso d'uso comune per scenari di RE. Storage Transfer Service è compatibile con Amazon S3 ed è il metodo consigliato per trasferire oggetti da Amazon S3 a Cloud Storage.

Puoi configurare un job di trasferimento per pianificare la sincronizzazione periodica dall'origine dati al sink dati, con filtri avanzati basati sulle date di creazione dei file, sui filtri dei nomi dei file e sulle ore del giorno in cui preferisci trasferire i dati. Per ottenere l'RPO desiderato, devi considerare i seguenti fattori:

  • Tasso di variazione. La quantità di dati che vengono generati o aggiornati per un determinato periodo di tempo. Maggiore è la frequenza di modifica, maggiori sono le risorse necessarie per trasferire le modifiche alla destinazione a ogni periodo di trasferimento incrementale.

  • Trasferimento delle prestazioni. Il tempo necessario per trasferire i file. Per trasferimenti di file di grandi dimensioni, questo è in genere determinato dalla larghezza di banda disponibile tra l'origine e la destinazione. Tuttavia, se un job di trasferimento è costituito da un numero elevato di file di piccole dimensioni, il valore QPS può diventare un fattore limitante. In questo caso, puoi pianificare più job simultanei per scalare le prestazioni purché sia disponibile una larghezza di banda sufficiente. Ti consigliamo di misurare le prestazioni del trasferimento utilizzando un sottoinsieme rappresentativo dei tuoi dati reali.

  • Frequenza. L'intervallo tra i job di backup. L'aggiornamento dei dati nella destinazione è recente rispetto all'ultima volta in cui è stato pianificato un job di trasferimento. Di conseguenza, è importante che gli intervalli tra job di trasferimento successivi non siano più lunghi dell'obiettivo RPO. Ad esempio, se l'obiettivo RPO è 1 giorno, il job di trasferimento deve essere pianificato almeno una volta al giorno.

  • Monitoraggio e avvisi. Storage Transfer Service fornisce notifiche Pub/Sub su una serie di eventi. Ti consigliamo di iscriverti a queste notifiche per gestire errori o modifiche imprevisti nei tempi di completamento dei job.

Un'altra opzione per spostare i dati da AWS a Google Cloud è utilizzare boto, uno strumento Python compatibile con Amazon S3 e Cloud Storage. Può essere installato come plug-in per lo strumento a riga di comando gsutil.

Backup e ripristino del database

Non rientra nell'ambito di questo documento discutere in dettaglio dei vari meccanismi integrati di backup e ripristino inclusi nei database di terze parti o delle tecniche di backup e ripristino utilizzate da altri cloud provider. Se utilizzi database non gestiti sui servizi di computing, puoi sfruttare le strutture ad alta disponibilità disponibili dal tuo provider cloud di produzione. Puoi estendere questi strumenti per incorporare un deployment ad alta disponibilità in Google Cloud, oppure utilizzare Cloud Storage come destinazione definitiva per il cold storage dei file di backup del tuo database.

Che cosa succede dopo?