Scenari di ripristino di emergenza dei dati

Last reviewed 2022-06-10 UTC

Questo articolo è 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 in che modo puoi evitare la perdita di dati durante una calamità. Il termine dati qui copre due scenari. Il backup e il recupero dei dati di database, log e altri tipi di dati rientrano in uno dei seguenti scenari:

  • Backup dei dati. Il backup dei dati da solo comporta la copia di una quantità discreta di dati da una posizione all'altra. I backup vengono eseguiti nell'ambito di un piano di ripristino, per ripristinare i dati in seguito a un danneggiamento dei dati, in modo da poter ripristinare lo stato di integrità noto direttamente nell'ambiente di produzione, oppure per ripristinare i dati nell'ambiente di RE quando l'ambiente di produzione non funziona. 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é in genere comportano il recupero fino al momento specifico. Pertanto, oltre a considerare come eseguire il backup e il ripristino dei backup del database e garantire che il sistema del database di ripristino esegua il mirroring della configurazione di produzione (stessa versione, configurazione del disco con mirroring), devi anche valutare come eseguire il backup dei log delle transazioni. Durante il ripristino, dopo aver ripristinato la funzionalità del database, devi applicare il backup più recente del database, quindi i log delle transazioni recuperati di cui è stato eseguito il backup dopo l'ultimo backup. A causa dei fattori complicati inerenti ai sistemi di database (ad esempio, la necessità di abbinare 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 più piccoli.

Il resto di questo articolo illustra esempi di come progettare alcuni scenari per dati e database che possano 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 ripristino dei dati

Puoi utilizzare una serie di strategie per implementare un processo per eseguire regolarmente il backup dei dati on-premise su 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 risposta diretta:

  • Cloud Storage

Un'opzione per il backup dei dati è creare un'attività pianificata che esegua 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 ripristino 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 credenziali a gsutil come parte 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 file nel bucket di destinazione.

  7. Segui le indicazioni relative a scripting delle attività di Data Transfer per configurare uno script pianificato.

  8. Configura un processo di recupero che utilizza gsutil per recuperare i dati nel tuo ambiente di ripristino di emergenza su Google Cloud.

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

Ad esempio, il seguente comando gsutil rsync rende i contenuti di un bucket Cloud Storage uguali a quelli nella directory di origine copiando gli oggetti o i file mancanti oppure i file 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 dell'utilizzo di gsutil cp. Questo a sua volta consente una pianificazione di backup più frequente e consente di ottenere un valore RPO inferiore.

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

Per maggiori 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 per i dati on-premise

Componenti di base per la risposta diretta:

  • Cloud Storage
  • Transfer Service for On Premises Data

Il trasferimento di grandi quantità di dati attraverso una rete spesso richiede un'attenta pianificazione e solide strategie di esecuzione. Sviluppare script personalizzati che siano scalabili, affidabili e gestibili non è un'attività banale. Spesso gli script personalizzati possono portare a valori dell'RPO più bassi e persino a un aumento del rischio di perdita di dati.

Un modo per implementare il trasferimento di dati su larga scala è utilizzare Transfer Service for On Premises Data. È un servizio gestito, scalabile, affidabile e gestito che ti consente di trasferire grandi quantità di dati dal tuo data center a un bucket Cloud Storage senza investire nei 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 risposta diretta:

  • Cloud Interconnect
  • Archiviazione a più livelli di Cloud Storage

Le applicazioni on-premise sono spesso integrate con soluzioni di terze parti che possono essere utilizzate nell'ambito della strategia di backup e ripristino dei dati. Le soluzioni spesso utilizzano uno schema di archiviazione a più livelli, con i backup più recenti in uno spazio di archiviazione più rapido, e migrano lentamente i backup meno recenti a uno spazio di archiviazione più economico (più lento). Quando utilizzi Google Cloud come destinazione, hai a disposizione diverse opzioni di classe di archiviazione da utilizzare come equivalente del livello più lento.

Un modo per implementare questo pattern è utilizzare un gateway partner tra il tuo spazio di archiviazione on-premise e Google Cloud per facilitare il trasferimento di dati a Cloud Storage. Il seguente diagramma illustra questo accordo, con una soluzione del partner che gestisce il trasferimento dall'appliance NAS on-premise o dalla 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 di RE viene utilizzato per gestire il traffico di produzione fino a quando non sei in grado di tornare all'ambiente di produzione. Il modo per ottenere questo risultato dipende dall'applicazione, dalla soluzione del partner e dalla sua architettura. (Alcuni scenari end-to-end sono discussi nel documento dell'applicazione di RE.)

Per ulteriori indicazioni su come trasferire i dati da 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 Partner sul sito web di Google Cloud.

Backup e ripristino del database

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

In questo articolo non rientra l'ambito di applicazione dei vari meccanismi integrati di backup e ripristino inclusi nei database di terze parti. Questa sezione fornisce indicazioni generali, che vengono implementate nelle soluzioni discusse qui.

Soluzione 1: backup e ripristino mediante un server di ripristino 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 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 (consulta i passaggi discussi in precedenza nella sezione relativa a backup e ripristino dei dati). Per maggiori dettagli, consulta Trasferimento di set di big data in Google Cloud.
  5. Copia i log delle transazioni sul tuo sito di ripristino su Google Cloud. Avere un backup dei log delle transazioni aiuta a mantenere piccoli i valori dell'RPO.

Dopo aver configurato questa topologia di backup, devi assicurarti di poter eseguire il ripristino nel sistema in Google Cloud. In genere questo passaggio non comporta solo il ripristino del file di backup nel database di destinazione, ma anche la riproduzione dei log delle transazioni per ottenere il valore RTO più piccolo. Una sequenza di recupero tipica è simile alla 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 esempio di implementazione.
  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 di database per il recupero dei file di backup.
  6. Applica l'ultimo set di file di log delle transazioni copiati in Cloud Storage.
  7. Sostituisci l'istanza minima con un'istanza più grande in grado di accettare traffico di produzione.
  8. Cambia client per puntare al database recuperato in Google Cloud.

Quando l'ambiente di produzione è in esecuzione e 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 il seguente 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 tuo sistema di database di produzione.
  4. Impedisci ai client di connettersi al sistema di database in Google Cloud, ad esempio interrompendo il servizio di sistema di database. Da questo momento in poi, l'applicazione non sarà disponibile fino a quando 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. Reindirizzare 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 su un hot standby del server del database.

  1. Connetti la tua rete on-premise e la rete Google Cloud.
  2. Crea un'immagine personalizzata del tuo server di database su Google Cloud. Il server di database deve avere nell'immagine la stessa configurazione 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 in modo da puntare al server di database on-premise.

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

Una volta che l'ambiente di produzione è stato sottoposto a backup e in grado di supportare i carichi di lavoro di produzione, devi risincronizzare il server di database di produzione con il server di database Google Cloud e quindi cambiare client in modo che punti indietro 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 ripristino 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 è su Google Cloud, il sistema di archiviazione a più livelli è simile al diagramma seguente. Esegui la migrazione dei dati a un livello con costi di archiviazione inferiori, perché è meno probabile che il requisito di accesso ai dati di cui è stato eseguito il backup.

Componenti di base per la risposta diretta:

Diagramma concettuale che mostra un'immagine che mostra una riduzione dei costi durante la migrazione dei dati da dischi permanenti a Nearline a Coldline

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

Backup e ripristino del database

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

Puoi impostare configurazioni ad alta disponibilità utilizzando le funzionalità dei componenti di base di RE appropriate per mantenere un RTO ridotto. Puoi progettare la configurazione del tuo database per semplificare il ripristino a uno stato il più vicino possibile a quello precedente alla crisi; in questo modo, i valori dell'RPO sono ridotti. Google Cloud offre una vasta serie di opzioni per questo scenario.

In questa sezione sono descritti due approcci comuni alla progettazione dell'architettura di recupero del database per database autogestiti su Google Cloud.

Ripristino 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 risposta diretta:

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

Il seguente diagramma illustra un'architettura di esempio che prende in esame lo scenario. Con l'implementazione di questa architettura, hai 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 procedendo nel seguente modo:

    1. Configura 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. Configura 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:

  • Apre un altro server di database con la versione corretta nella stessa zona.
  • Collega all'istanza del server di database appena creata un disco permanente contenente i file di log di backup e transazioni più recenti.
  • 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 vengano applicati al server di database recuperato.

Poiché l'istanza sostitutiva viene creata da un modello di istanza, i controlli applicati all'istanza originale vengono applicati a quest'ultima.

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 a quella che sta sostituendo. Tramite l'acquisizione di snapshot regolari dei dischi permanenti, ti assicuri che, quando i dischi vengono ricreati dagli snapshot e collegati all'istanza di sostituzione, l'istanza sostitutiva utilizzi i dati recuperati in base a un valore RPO dettato dalla frequenza degli snapshot. In questa architettura vengono ripristinati automaticamente anche gli ultimi file di log delle transazioni scritti nel disco permanente.

Il gruppo di istanze gestite fornisce approfondimenti ad alta disponibilità. 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 target pari a uno garantisce di avere una sola istanza attiva che viene eseguita nel gruppo di istanze gestite e gestisce il traffico.

I dischi permanenti standard sono a livello di zona, quindi in caso di errore a livello di zona, sono necessari snapshot per ricreare i dischi. Inoltre, gli snapshot sono disponibili in più regioni, il che ti consente di ripristinare un disco in una regione diversa con la stessa facilità con cui puoi farlo nella stessa regione.

Una variante di questa configurazione prevede l'utilizzo di dischi permanenti a livello di regione al posto dei dischi permanenti standard. In questo caso, non è necessario ripristinare lo snapshot nell'ambito del passaggio di ripristino.

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

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

Ripristino da danneggiamento parziale in database di grandi dimensioni

Se utilizzi un database in grado di archiviare petabyte di dati, potresti riscontrare un'interruzione che interessa alcuni dati, ma non tutti. In tal caso, vuoi ridurre al minimo la quantità di dati da ripristinare; non è necessario (o vuoi) recuperare l'intero database solo per ripristinare alcuni dei dati.

Esistono diverse strategie di mitigazione che puoi adottare:

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

  • Archivia i dati originali su Cloud Storage. Questo ti consente di creare una nuova tabella e ricaricare i dati non danneggiati. Da qui, puoi regolare le applicazioni in modo che puntino alla nuova tabella.

Inoltre, se l'RTO lo consente, puoi impedire l'accesso alla tabella contenente i dati danneggiati lasciando le applicazioni offline fino a quando i dati non danneggiati non vengono 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 meccanismi tradizionali di backup e ripristino che vedi con i RDMBS tradizionali non sono solitamente disponibili. Come nel caso dei database autogestiti, se utilizzi un database in grado di archiviare petabyte di dati, vuoi ridurre al minimo la quantità di dati da ripristinare in uno scenario di RE. Esistono diverse strategie per ogni database gestito al fine di raggiungere questo obiettivo.

Bigtable fornisce la replica di Bigtable. Un database Bigtable replicato può offrire una disponibilità superiore rispetto a un singolo cluster, una velocità effettiva di lettura aggiuntiva e una maggiore durabilità e resilienza di fronte a errori a livello di zona o a livello 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 in una nuova tabella in un secondo momento.

Puoi anche esportare le tabelle da Bigtable come una serie di file di sequenza di Hadoop. Puoi quindi archiviare questi file in Cloud Storage o utilizzarli per importare i dati in un'altra istanza di Bigtable. Puoi replicare il set di dati Bigtable in modo asincrono tra 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 diminuisce automaticamente del 50%. L'archiviazione a lungo termine di una tabella non comporta alcun peggioramento delle prestazioni, della durabilità, della disponibilità o di qualsiasi altra funzionalità. Se, tuttavia, la tabella viene modificata, viene ripristinato il normale prezzo di archiviazione e il conto alla rovescia di 90 giorni ricomincia.

BigQuery è replicato in due zone in una singola regione, ma questo non aiuterà a danneggiare le tabelle. Di conseguenza, devi avere un piano per poter recuperare da questo scenario. Ad esempio, puoi:

  • Se il danneggiamento viene rilevato entro 7 giorni, esegui una query sulla tabella in un determinato momento nel passato per ripristinarla prima del danneggiamento utilizzando i decoratori degli snapshot.
  • Esporta i dati da BigQuery e crea una nuova tabella che contenga i dati esportati ma escluda quelli danneggiati.
  • Archivia i dati in tabelle diverse per periodi di tempo specifici. Questo metodo garantisce di dover ripristinare in una nuova tabella solo un sottoinsieme di dati, anziché un intero set di dati.
  • Crea copie del set di dati in periodi di tempo specifici. Puoi utilizzare queste copie se si è verificato un evento di danneggiamento dei dati che non può essere acquisito da una query point-in-time, ad esempio più di 7 giorni prima. Puoi anche copiare un set di dati da una regione all'altra per garantire la disponibilità dei dati in caso di errori a livello di regione.
  • Archivia i dati originali su Cloud Storage. Questo ti consente di creare una nuova tabella e ricaricare i dati non danneggiati. Da qui, puoi regolare 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. Questo, a sua volta, ti consente di implementare una procedura utilizzabile per recuperare i dati dall'eliminazione accidentale.

Cloud SQL. Se utilizzi Cloud SQL, il database Google Cloud MySQL completamente gestito, devi abilitare i backup automatici e il logging binario per le istanze Cloud SQL. Ciò ti consente di eseguire un recupero point-in-time, che ripristina il database da un backup e lo ripristina in 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 avanzamento in caso di errore a livello di zona o di regione.

Spanner. Puoi utilizzare i modelli Dataflow per eseguire un'esportazione completa del 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 in 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. Questo ha un impatto diretto sui valori RTO.

La funzionalità timestamp del commit di Spanner può essere utile per i backup incrementali, poiché ti consente di selezionare solo le righe che sono state aggiunte o modificate dall'ultimo backup completo.

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

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

Il recupero point-in-time (PITR) di Spanner ti consente di recuperare i dati da un momento specifico nel passato. Ad esempio, se un operatore scrive inavvertitamente dei dati o un'implementazione dell'applicazione danneggia il database, con PITR puoi recuperare i dati da un momento specifico nel 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 copiarli in un altro progetto, set di dati o tabella (a seconda della soluzione utilizzata) o per 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, l'ambiente di produzione utilizza un altro cloud provider e il piano di ripristino di emergenza prevede l'utilizzo di Google Cloud come sito di ripristino.

Backup e ripristino 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 modo consigliato per trasferire oggetti da Amazon S3 a Cloud Storage.

Puoi configurare un job di trasferimento per pianificare una 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 sull'ora del giorno in cui preferisci trasferire i dati. Per raggiungere l'RPO desiderato, devi considerare i seguenti fattori:

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

  • Trasferisci il rendimento. Il tempo necessario per trasferire i file. Per i trasferimenti di file di grandi dimensioni, questo è in genere determinato dalla larghezza di banda disponibile tra origine e 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 di 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. Pertanto, è importante che gli intervalli tra job di trasferimento successivi non siano più lunghi del tuo 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 dello strumento a riga di comando gsutil.

Backup e ripristino del database

In questo articolo non rientra nell'ambito di applicazione dei vari meccanismi integrati di backup e ripristino inclusi nei database di terze parti oppure delle tecniche di backup e ripristino utilizzate su altri cloud provider. Se utilizzi database non gestiti sui servizi di computing, puoi sfruttare le funzionalità ad alta disponibilità disponibili dal tuo cloud provider di produzione. Puoi estenderle per incorporare un deployment ad alta disponibilità in Google Cloud oppure utilizzare Cloud Storage come destinazione definitiva per l'archiviazione a freddo dei file di backup del database.

Che cosa succede dopo?