Scenari di ripristino di emergenza dei dati

Last reviewed 2022-06-10 UTC

Questo documento è la terza parte di una serie che tratta Ripristino di emergenza (RE) in Google Cloud. In questa sezione vengono descritti gli scenari per il backup e il ripristino e i dati di Google Cloud.

La serie è costituita dai seguenti componenti:

Introduzione

I piani di ripristino di emergenza devono specificare come evitare di perdere dati durante un una catastrofe. In questo caso, il termine dati si riferisce a due scenari. Backup e poi il recupero di database, dati di log e altri tipi di dati rientra in una delle i seguenti scenari:

  • Backup dei dati. Il backup dei dati da solo comporta la copia di una quantità di dati da un luogo all'altro. I backup vengono eseguiti nell'ambito di di ripristino in seguito a un danneggiamento dei dati, in modo da al ripristino a uno stato noto direttamente nell'ambiente di produzione, circa è possibile ripristinare i dati nell'ambiente RE se le istanze non è attivo. In genere, i backup dei dati hanno un RTO medio-piccolo un RPO ridotto.
  • Backup dei database. I backup dei database sono leggermente più complessi, di solito comportano il recupero fino al momento giusto. Pertanto, oltre a considerare come eseguire il backup e ripristinare i backup del database assicurandosi che il sistema di database di ripristino esegua il mirroring dei dati di produzione (stessa versione, configurazione del disco con mirroring), devi anche valuta come eseguire il backup dei log delle transazioni. Durante il recupero, dopo se ripristini la funzionalità del database, devi applicare il database più recente il backup e i log delle transazioni recuperati di cui è stato eseguito il backup dopo l'ultimo backup. A causa dei fattori di complicazione inerenti al database sistemi diversi (ad esempio, la necessità di far corrispondere le versioni tra sistemi di ripristino di emergenza), adottando un approccio incentrato sulla disponibilità elevata per ridurre al minimo il tempo necessario per riprendersi da una situazione che potrebbe causare l'indisponibilità del consente di avere valori RTO e RPO più piccoli.

Il resto del documento illustra esempi di come progettare scenari per dati e database che possono aiutarti a rispettare i tuoi RTO e RPO obiettivi.

L'ambiente di produzione è on-premise

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

Backup e recupero dei dati

Puoi utilizzare una serie di strategie per implementare una procedura di backup regolare i dati da on-premise a Google Cloud. Questa sezione prende in esame due dei le 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 eseguire il backup dei dati è creare un'attività pianificata che esegua uno script o un'applicazione per trasferire i dati in Cloud Storage. Puoi automatizzare di un processo di backup in Cloud Storage utilizzando Google Cloud CLI o utilizzando uno dei cluster Cloud Storage librerie client. Ad esempio, il seguente comando gcloud storage copia tutti i file da un di origine in un bucket specificato.

gcloud storage cp [SOURCE_DIRECTORY] gs://[BUCKET_NAME] --recursive

I passaggi seguenti spiegano come implementare un processo di backup e ripristino utilizzando gcloud CLI.

  1. Installa l'interfaccia a riga di comando gcloud sulla macchina on-premise che utilizzi per caricare i tuoi 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 è utilizzato per passa le credenziali a gcloud CLI nell'ambito di uno script automatizzato

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

  5. Crea un Criterio IAM per limitare chi può accedere al bucket e ai suoi oggetti. (Includi il servizio creato appositamente per questo scopo e un operatore on-premise ). Per maggiori dettagli sulle autorizzazioni per l'accesso a Cloud Storage, consulta Autorizzazioni IAM per i comandi gcloud storage.

  6. Verifica che sia possibile caricare e scaricare nel bucket di destinazione.

  7. Configura un processo di recupero che utilizza gcloud CLI per il ripristino i tuoi dati nell'ambiente di ripristino di emergenza su Google Cloud.

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

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

gcloud storage rsync [SOURCE_DIRECTORY] gs://[BUCKET_NAME] --recursive

Per ulteriori informazioni, vedi Trasferimento da colocation o archiviazione on-premise, che includono 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 richiede spesso un'attenta pianificazione e solide strategie di attuazione. Non è semplice sviluppare modelli scalabili, affidabili e gestibili. Spesso gli script personalizzati possono una riduzione dei valori RPO e persino 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. Questo servizio è un servizio affidabile e gestito, che consente di trasferire grandi quantità di dati dal tuo data center a un bucket Cloud Storage senza investire in progettazione team di prodotto 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 può essere utilizzata come parte della tua strategia di backup e ripristino dei dati. Le soluzioni spesso utilizzano un pattern di archiviazione a più livelli in cui sono presenti i backup più recenti archiviazione più rapida ed eseguire lentamente la migrazione dei backup meno recenti a una versione più economica (più lenta) archiviazione. Quando utilizzi Google Cloud come destinazione, hai a disposizione opzioni delle classi di archiviazione disponibili equivalente del livello più lento.

Un modo per implementare questo pattern è utilizzare un gateway partner tra archiviazione on-premise e Google Cloud per facilitare il trasferimento di archiviazione ideale in Cloud Storage. Il seguente diagramma illustra tale disposizione, con una soluzione partner che gestisce il trasferimento dall'appliance NAS on-premise o 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 su per l'ambiente di RE. L'ambiente RE viene utilizzato per gestire il traffico di produzione finché non sarai in grado di tornare all'ambiente di produzione. Come per raggiungere questo obiettivo dipende dall'applicazione, dalla soluzione del partner e la sua architettura. (Alcuni scenari end-to-end sono discussi nel Documento di richiesta RE.)

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

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

Backup e ripristino del database

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

Non rientra nell'ambito di questo documento discutere in dettaglio dei vari modelli i meccanismi di backup e ripristino inclusi con i 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 recupero su Google Cloud

  1. Crea un backup del database utilizzando i meccanismi di backup integrati di gestione dei 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 gcloud storage o un alla soluzione gateway del partner (vedi passi di cui abbiamo parlato in precedenza, nella sezione Backup e ripristino dei dati). Per maggiori dettagli, vedi Trasferimento di set di big data a 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 al sistema su Google Cloud. Questo passaggio in genere non comporta ripristinare solo il file di backup nel database di destinazione, ma anche ripetere log delle transazioni per ottenere il valore RTO minimo. Un recupero tipico questa sequenza ha il seguente aspetto:

  1. Crea un immagine personalizzata del tuo server di database su Google Cloud. Il server del database deve avere la stessa configurazione nell'immagine del server di database on-premise.
  2. Implementa un processo per copiare i file di backup e la transazione on-premise di log in Cloud Storage. Consulta soluzione 1 per un'implementazione di esempio.
  3. Avvia un'istanza di dimensioni minime dall'immagine personalizzata e collegare eventuali 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 Cloud Storage, seguendo le istruzioni del tuo database per il recupero dei file di backup.
  6. Applica l'ultimo set di file di log delle transazioni che sono stati copiati in di archiviazione ideale 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 la produzione carichi di lavoro, devi invertire i passaggi seguiti per eseguire il failover Ambiente di ripristino di Google Cloud. Una sequenza tipica per tornare di produzione è simile al seguente:

  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. Impedisci ai client di connettersi al sistema di database in Google Cloud. ad esempio interrompendo il servizio di sistema del database. A questo punto, la tua applicazione non sarà disponibile fino al termine ripristinare l'ambiente di produzione.
  5. Copia tutti i file di log delle transazioni nell'ambiente di produzione e e applicarle.
  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 di RTO e RPO molto piccoli è replicarli (non solo dei dati e, in alcuni casi, lo stato del database in tempo reale fino a un hot standby server di 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 del database deve avere nell'immagine la stessa configurazione di quella dei server di database on-premise.
  3. Avvia un'istanza dall'immagine personalizzata e collegare eventuali 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 server di database di destinazione in Google Cloud seguendo le istruzioni specifiche per il software del database.
  6. I client sono configurati in modalità di funzionamento normale per puntare al database server on-premise.

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

Quando il tuo ambiente di produzione è in esecuzione e puoi supportare la produzione carichi di lavoro, devi risincronizzare il server del database di produzione server di database Google Cloud e poi cambiare client in modo che puntino ambiente di produzione

L'ambiente di produzione è Google Cloud

In questo scenario, sia l'ambiente di produzione sia il ripristino di emergenza 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 di produzione si trova su Google Cloud, il sistema di archiviazione a più livelli come mostrato nel diagramma seguente. Esegui la migrazione dei dati a un livello con spazio di archiviazione inferiore poiché la necessità di 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 soluzioni Nearline, Coldline e Archive Storage sono destinate ad archiviare dati a cui si accede raramente, costi aggiuntivi associati al recupero di dati o metadati archiviati in queste classi, le durate minime di archiviazione che ti vengono addebitate.

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), lo stesso e problemi operativi si applicano alla gestione dei database di produzione on-premise, ma non hanno più bisogno di gestire l'infrastruttura sottostante.

Puoi impostare le configurazioni ad alta disponibilità utilizzando Funzionalità dei componenti di base per la RE per ridurre l'RTO. Puoi progettare la configurazione del database per è stato possibile ripristinare uno stato il più vicino possibile a quello precedente alla catastrofe; Ciò consente di mantenere bassi i valori dell'RPO. Google Cloud offre un'ampia varietà di opzioni per questo scenario.

Due approcci comuni alla progettazione dell'architettura di ripristino del database In questa sezione vengono trattati i 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 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 si rivolge in questo scenario. Implementando questa architettura, si dispone 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 configurato con il server di database nel seguente modo:

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

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

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

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

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

  7. Configura un'attività pianificata per creare snapshot regolari dell'istanza disco.

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 il backup e il log delle transazioni più recenti i file nell'istanza del server di database appena creata.
  • Riduce al minimo la necessità di riconfigurare i client che comunicano con i tuoi server di database in risposta a un evento.
  • Garantisce che i controlli di sicurezza di Google Cloud (criteri IAM, impostazioni firewall) che si applicano al server del database di produzione si applicano il server del database ripristinato.

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

Questo scenario sfrutta alcune delle funzionalità ad alta disponibilità disponibili in Google Cloud. non devi avviare passaggi di failover, avvengono automaticamente in caso di emergenza. Il bilanciatore del carico interno assicura che, anche quando è necessaria un'istanza sostitutiva, venga utilizzato lo stesso indirizzo IP usato per il server del database. Il modello di istanza e l'immagine personalizzata assicurano che l'istanza sostitutiva è configurata in modo identico all'istanza di cui sostituzione. Mediante l'acquisizione di snapshot regolari dei dischi permanenti, ti assicuri che quando i dischi vengono ricreati dagli snapshot e collegati al cluster Ad esempio, l'istanza sostitutiva utilizza dati recuperati in base a un RPO dettato dalla frequenza degli snapshot. In questa architettura, vengono inoltre creati i file di log delle transazioni più recenti scritti sul disco permanente, ripristinato automaticamente.

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

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

Una variante di questa configurazione è l'utilizzo dei dischi permanenti a livello di regione dei dischi permanenti standard. In questo caso, non è necessario ripristinare come parte del passaggio di ripristino.

La variante che scegli è dettata dal budget, nonché dall'RTO e dall'RPO e i relativi valori.

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

Recupero da un danneggiamento parziale in database di grandi dimensioni

Se utilizzi un database in grado di memorizzare petabyte di dati, potrebbero verificarsi interruzioni che interessano alcuni dati, ma non tutti. Nella in questo caso vuoi ridurre al minimo la quantità di dati da ripristinare. tu non hanno bisogno di (o si vuole) ripristinare l'intero database solo per ripristinare alcuni i dati.

Esistono varie strategie di mitigazione che puoi adottare:

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

  • Archivia i dati originali in Cloud Storage. Questo approccio ti consente crea una nuova tabella e ricarica i dati non danneggiati. Da qui puoi regolare le applicazioni in modo che puntino alla nuova tabella.

Inoltre, se il vostro RTO lo consente, potete impedire l'accesso alla tabella che ha i dati danneggiati lasciando le applicazioni offline fino a quando siano stati ripristinati in una nuova tabella.

Servizi di database gestiti su Google Cloud

Questa sezione illustra alcuni metodi che puoi usare per implementare le funzionalità di backup di recupero per i servizi di database gestiti in Google Cloud.

I database gestiti sono progettati per la scalabilità, quindi i tradizionali sistemi di backup i meccanismi che vedi con gli RDMBS tradizionali di solito non sono disponibili. Come nella nel caso dei database autogestiti, se utilizzi un database in grado di se archivi petabyte di dati, vuoi ridurre al minimo la quantità di dati necessaria da ripristinare in uno scenario di RE. Esistono varie strategie per ogni modello gestito, che ti aiuti a raggiungere questo obiettivo.

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

Backup Bigtable è un servizio completamente gestito che consente di salvare una copia dello schema 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 Hadoop file di sequenza. Puoi quindi archiviare questi file in Cloud Storage o utilizzarli per importarli di nuovo i dati in un'altra istanza di Bigtable. Puoi replicare il set di dati Bigtable in modo asincrono tra le zone all'interno di una regione Google Cloud.

BigQuery. Se vuoi archiviare i dati, puoi usufruire di Archiviazione a lungo termine di BigQuery. Se una tabella non viene modificata per 90 giorni consecutivi, il relativo prezzo di archiviazione la tabella si riduce automaticamente del 50%. Non si verifica alcun peggioramento delle prestazioni, durabilità, disponibilità o qualsiasi altra funzionalità quando si considera una tabella archiviazione a lungo termine. Se la tabella viene modificata, tuttavia, viene ripristinato con lo spazio di archiviazione standard e il conto alla rovescia di 90 giorni ricomincia.

BigQuery è replicato in due zone di una singola regione, ma questo non contribuirà al danneggiamento delle tabelle. Pertanto, devi avere un piano per il ripristino da questo scenario. Ad esempio, puoi eseguire seguenti:

  • Se il problema viene rilevato entro 7 giorni, esegui una query sulla tabella con un certo punto. nel passato per ripristinare la tabella prima del danneggiamento decoratori di snapshot.
  • Esportare i dati da BigQuery, e crea una nuova tabella che contiene i dati esportati, ma esclude i dati danneggiati.
  • Archivia i dati in tabelle diverse per periodi di tempo specifici. Questo garantisce che sarà necessario ripristinare solo un sottoinsieme di dati in un nuovo anziché un intero set di dati.
  • Crea copie del tuo set di dati in specifici periodi di tempo. Puoi utilizzare queste copie se un file di dati si è verificato oltre ciò che una query point-in-time può 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 nel caso in cui degli errori per le regioni.
  • Archiviare i dati originali su Cloud Storage, crea una nuova tabella e ricarica i dati non danneggiati. Da qui puoi regolare le applicazioni in modo che puntino alla nuova tabella.

Firestore. La servizio di esportazione e importazione gestito consente di importare ed esportare entità Firestore utilizzando un nel bucket Cloud Storage. Puoi quindi implementare un processo utilizzabili per recuperare i dati dall'eliminazione accidentale.

Cloud SQL. Se utilizzi Cloud SQL, lo strumento completamente gestito Database Google Cloud MySQL, devi abilitare i backup automatici il logging per le istanze Cloud SQL. Questo approccio ti consente di eseguire un recupero point-in-time, che ripristina il database da un backup lo recupera in una nuova istanza Cloud SQL. Per ulteriori dettagli, vedi Backup e ripristino di Cloud SQL.

Puoi anche configurare Cloud SQL 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 l'impatto degli eventi di manutenzione sulle istanze simulando eventi di manutenzione pianificata con tempi di inattività prossimi allo zero Cloud SQL per MySQL, e oltre Cloud SQL per PostgreSQL.

Spanner. Puoi usare i modelli Dataflow per preparando una esportare del tuo database a un insieme di file Avro in un nel bucket Cloud Storage e usare un altro modello reimportazione 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 un Dataflow. Ad esempio, puoi utilizzare il connettore per copiare da Spanner a Cloud Storage come backup target. La velocità con cui i dati possono essere letti da Spanner (o riscritto) dipende dal numero di istanze nodi. Ciò ha un impatto diretto sui valori RTO.

Spanner Timestamp del commit può essere utile per i backup incrementali, consentendoti di selezionare solo le righe che sono state aggiunte o modificate dopo l'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é il ripristino l'operazione monta direttamente il backup senza copiare i dati.

Per valori RTO ridotti, puoi configurare uno Spanner in standby configurata con il numero minimo di nodi necessario per soddisfare le tue requisiti di archiviazione e velocità effettiva di lettura e scrittura.

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

Cloud Composer. Puoi utilizzare Cloud Composer (una soluzione di Apache Airflow) per pianificare backup regolari dei database Google Cloud. Puoi creare un grafo diretto aciclico (DAG) 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 di esportare in Cloud Storage.

L'esportazione o la copia dei dati possono essere eseguite 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 servizio sito.

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 dai dati dall'origine al sink di dati, con filtri avanzati basati sulle date di creazione dei file, filtri nome file e le ore 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 che vengono generati o aggiornati per un determinato periodo di tempo. Più alto è il tasso di modifica, più risorse sono necessario per trasferire le modifiche alla destinazione a ogni trasferimento incrementale punto.

  • Trasferimento delle prestazioni. Il tempo necessario per trasferire i file. Per trasferimenti di file di grandi dimensioni, è determinato generalmente dalla larghezza di banda disponibile sorgente e destinazione. Tuttavia, se un job di trasferimento è costituito da un di file di piccole dimensioni, il valore QPS può diventare un fattore limitante. Se si tratta del puoi pianificare più job simultanei per scalare solo se è disponibile una larghezza di banda sufficiente. Ti consigliamo Misuri le prestazioni del trasferimento utilizzando un sottoinsieme rappresentativo del tuo di dati reali.

  • Frequenza. L'intervallo tra i job di backup. L'aggiornamento dei dati nella destinazione è recente quanto l'ultimo l'ora in cui è stato pianificato un job di trasferimento. Pertanto, è importante che tra un job di trasferimento successivo e l'altro non siano più lunghi di 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 di diversi tipi di eventi. Ti consigliamo di iscriverti a queste notifiche per ricevere Gestire errori o modifiche imprevisti nei tempi di completamento dei job.

Backup e ripristino del database

Non rientra nell'ambito del presente documento discutere in dettaglio dei vari modelli i meccanismi di backup e ripristino inclusi nei database di terze parti o e di ripristino usate da altri cloud provider. Se operi non gestiti sui servizi di computing, puoi sfruttare l'alta disponibilità le strutture a disposizione del provider cloud di produzione. Puoi estendere per incorporare un deployment ad alta disponibilità in Google Cloud, Cloud Storage come destinazione definitiva per il cold storage di backup del database.

Passaggi successivi