Scenari di ripristino di emergenza dei dati

Last reviewed 2024-08-05 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. Il termine dati qui copre due scenari. Il backup e il successivo 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 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 aver ripristinato la funzionalità del database, devi applicare l'ultimo backup del database 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 abbinare le versioni tra i sistemi di produzione e di recupero), l'adozione di un approccio incentrato sull'alta disponibilità per ridurre al minimo il tempo necessario per recuperare da una situazione che potrebbe causare l'interruzione del servizio del server di database consente di ottenere valori RTO e RPO inferiori.

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 diverse strategie per implementare un processo per eseguire regolarmente il backup dei dati on-premise su Google Cloud. Questa sezione esamina due delle soluzioni più comuni.

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

Questo pattern utilizza i seguenti componenti di base per 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 una procedura di backup su Cloud Storage utilizzando il gcloud storage comando Google Cloud CLI o una delle librerie client di Cloud Storage. Ad esempio, il seguente comando gcloud storage copia tutti i file da una directory di origine a un bucket specificato.

gcloud storage cp -r SOURCE_DIRECTORY gs://BUCKET_NAME

Sostituisci SOURCE_DIRECTORY con il percorso della directory di origine e BUCKET_NAME con un nome a tua scelta per il bucket. Il nome deve soddisfare i requisiti per i nomi dei bucket.

I passaggi riportati di seguito descrivono come implementare una procedura di backup e recupero utilizzando il comando gcloud storage.

  1. Installa gcloud CLI 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. Crea un account di servizio.
  4. Crea un criterio IAM per limitare chi può accedere al bucket e ai relativi oggetti. Includi il servizio creato appositamente per questo scopo. Per maggiori dettagli sulle autorizzazioni per accedere a Cloud Storage, vedi Autorizzazioni IAM per gcloud storage.
  5. Utilizza l'appropriazione di identità dell'account di servizio per consentire all'utente (o all'account di servizio) Google Cloud locale di assumere l'identità dell'account di servizio che hai appena creato in precedenza. In alternativa, puoi creare un nuovo utente appositamente per questo scopo.
  6. Verifica che sia possibile caricare e scaricare nel bucket di destinazione.
  7. Configura una pianificazione per lo script che utilizzi per caricare i backup utilizzando strumenti come Linux crontab e l'Utilità di pianificazione di Windows.
  8. Configura una procedura di recupero che utilizza il comando gcloud storage per recuperare i tuoi dati al tuo 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 di un bucket Cloud Storage uguali a quelli nella directory di origine copiando eventuali file o oggetti mancanti o quelli cuyosi dati sono stati modificati. Se il volume di dati che è cambiato tra sessioni di backup successive è ridotto rispetto all'intero volume dei dati di origine, l'utilizzo di gcloud storage rsync può essere più efficiente rispetto all'utilizzo del comando gcloud storage cp. Utilizzando gcloud storage rsync, puoi implementare una strategia della pianificazione del backup e ottenere un RPO più basso.

gcloud storage rsync -r SOURCE_DIRECTORY gs:// BUCKET_NAME

Per ulteriori informazioni, vedi Comando gcloud storage per piccoli trasferimenti di dati on-premise.

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

Questo pattern utilizza i seguenti componenti di base del DR:

  • 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. Sviluppare script personalizzati scalabili, affidabili e gestibili non è un'operazione banale. Spesso gli script personalizzati possono una riduzione dei valori RPO e persino un aumento del rischio di perdita di dati.

Per indicazioni sullo spostamento di grandi volumi di dati da località on-premise a Cloud Storage, consulta Sposta o esegui il backup dei dati dallo spazio di archiviazione on-premise.

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

Questo pattern utilizza i seguenti componenti di base del DR:

  • Cloud Interconnect
  • Archiviazione a più 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 modello di archiviazione a più livelli in cui i backup più recenti si trovano su uno spazio di archiviazione più veloce e i backup meno recenti vengono migrati lentamente a uno spazio di archiviazione più economico (più lento). 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 di 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.)

Puoi anche utilizzare i database Google Cloud gestiti come destinazioni di DR. Ad esempio, Cloud SQL per SQL Server supporta le importazioni dei log delle transazioni. Puoi esportare i log delle transazioni dall'istanza SQL Server on-premise, caricarli in Cloud Storage e importarli in Cloud SQL per SQL Server.

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 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 recuperare un sistema di database on-premise in Google Cloud. Questa sezione esamina due delle soluzioni più comuni.

Non rientra nell'ambito del presente 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 alla 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 l'gcloud storage interfaccia a riga di comando gcloud o una soluzione di gateway partner (consulta i passaggi descritti in precedenza nella sezione sul backup e sul recupero dei dati). Per informazioni dettagliate, consulta Eseguire la migrazione a Google Cloud: trasferire i set di dati di grandi dimensioni.
  5. Copia i log delle transazioni nel tuo sito di recupero su Google Cloud. Avere un backup dei log delle transazioni consente di mantenere bassi 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. Una sequenza di recupero 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 sull'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 che è stato precedentemente copiato 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 che sono stati copiati in Cloud Storage.
  7. Sostituisci l'istanza minima con un'istanza più grande in grado di accettare il traffico di produzione.
  8. Cambia client in modo che puntino 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 annullare i passaggi che hai seguito per eseguire il failover nell'ambiente di ripristino 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 dei client all'ambiente di produzione.

Soluzione 2: replica su un server di riserva 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, lo stato del database in tempo reale in una replica del server 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 collega tutti 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 in modalità di funzionamento normale per puntare al database server on-premise.

Dopo aver configurato questa topologia di replica, imposta i client in modo che indirizzino il server di riserva in esecuzione nella tua 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 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 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.

Questo pattern utilizza i seguenti componenti di base per RE:

Diagramma concettuale che mostra un'immagine che indica il costo in diminuzione man mano che i dati vengono migrati dai dischi permanenti a Nearline e poi 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 vengono addebitati dei 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), 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.

Il servizio di backup e RE è una soluzione cloud-native centralizzata per il backup e il recupero dei carichi di lavoro cloud e ibridi. Offre un rapido recupero dei dati e facilita la rapida ripresa delle operazioni aziendali essenziali.

Per ulteriori informazioni sull'utilizzo di Backup e RE per scenari di database autogestiti su Google Cloud, consulta quanto segue:

In alternativa, 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 gamma di opzioni per questo scenario.

In questa sezione vengono descritti due approcci comuni per progettare l'architettura di recupero del database per i database autogestiti su Google Cloud.

Recupero di un server di database senza sincronizzare lo stato

Un pattern comune è abilitare il ripristino di un server di database che richiede la sincronizzazione dello stato del sistema con una replica in standby aggiornata.

Questo pattern utilizza i seguenti componenti di base del DR:

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

Il seguente diagramma mostra un'architettura di esempio che risolve lo scenario. Se implementi 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 riportati di seguito descrivono come configurare questo scenario:

  1. Crea una rete VPC.

  2. Crea un'immagine personalizzata configurata con il server di database nel seguente modo:

    1. Configura il server in modo che i file di log e del database vengano scritti su un disco permanente standard collegato.
    2. Crea uno snapshot dal disco permanente collegato.
    3. Configura uno script di avvio per creare un disco permanente dallo snapshot e montarlo.
    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 del carico interno utilizzando il gruppo di istanze gestite.

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

Se è necessaria un'istanza di database sostitutiva, questa configurazione svolge automaticamente le seguenti operazioni:

  • Viene visualizzato un altro server 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 vengono applicati all'istanza sostitutiva.

Questo scenario sfrutta alcune delle funzionalità di HA disponibili in Google Cloud. Non devi avviare alcun passaggio di failover, perché vengono eseguiti automaticamente in caso di disastro. 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 di sostituzione 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 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 HA in modo approfondito. 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, quindi in caso di errore a livello di zona, sono necessari gli snapshot per ricreare i dischi. Gli snapshot sono disponibili anche tra regioni, consentendoti di ripristinare un disco non solo all'interno della stessa regione, ma anche in un'altra regione.

Una variante di questa configurazione è l'utilizzo di dischi permanenti regionali al posto di quelli standard. In questo caso, non è necessario ripristinare lo snapshot nell'ambito del passaggio di recupero.

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

Recupero da un danneggiamento parziale in database di grandi dimensioni

Replica asincrona del disco permanente offre una replica con archiviazione a blocchi con RPO e RTO basso per più regioni RE attiva-passiva. Questa opzione di archiviazione ti consente di gestire la replica per Compute Engine carichi di lavoro a livello di infrastruttura, non a livello di carico di lavoro.

Se utilizzi un database in grado di archiviare petabyte di dati, potresti riscontrare un'interruzione del servizio che interessa alcuni dati, ma non tutti. In questo caso, devi ridurre al minimo la quantità di dati da ripristinare. Non è necessario (o consigliabile) 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 devi ripristinare solo un sottoinsieme di dati in una nuova tabella, anziché in un intero set di dati.

  • Archivia i dati originali su Cloud Storage. Questo approccio 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 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 utilizzare per implementare meccanismi di backup e recupero appropriati per i servizi di database gestiti su 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, per aiutarti a raggiungere questo obiettivo.

Bigtable fornisce la 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.

backups 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 si riduce automaticamente del 50%. L'archiviazione a lungo termine di una tabella non comporta alcuna penalizzazione in termini di prestazioni, durabilità, disponibilità o qualsiasi altra funzionalità. Tuttavia, se la tabella viene modificata, vengono ripristinati i prezzi dell'archiviazione standard e il conto alla rovescia di 90 giorni ricomincia.

BigQuery viene replicato in due zone in un'unica regione, ma questo non risolve i problemi di corruzione delle tabelle. Di conseguenza, devi avere un piano per poter recuperare da questo scenario. Ad esempio, puoi eseguire seguenti:

  • Se l'integrità viene rilevata entro 7 giorni, esegui una query sulla tabella fino a un punto nel tempo passato per recuperarla prima dell'integrità utilizzando i decoratori degli 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 metodo garantisce che dovrai ripristinare solo un sottoinsieme di dati in una nuova tabella anziché in un intero set di dati.
  • Crea copie del tuo set di dati in specifici periodi di tempo. Puoi utilizzare queste copie se si è verificato un evento di corruzione dei dati oltre a quanto può essere acquisito da una query in un determinato momento (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 nella regione.
  • Archiviare i dati originali su Cloud Storage, crea una nuova tabella e ricarica i dati non danneggiati. Da qui, puoi aggiustare 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, il database MySQL di Google Cloud completamente gestito, devi attivare i backup automatici e il logging binario per le tue istanze Cloud SQL. Questo approccio ti consente di eseguire un recupero point-in-time, che ripristina il database da un backup e lo recupera in una nuova istanza Cloud SQL. Per saperne di più, consulta Informazioni sui backup di Cloud SQL e Informazioni sul ripristino di emergenza (RE) in 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 attivato la manutenzione pianificata con tempi di inattività quasi nulli per Cloud SQL, puoi valutare l'impatto degli eventi di manutenzione sulle tue istanze simulando eventi di manutenzione pianificata con tempi di inattività quasi nulli su Cloud SQL per MySQL e su Cloud SQL per PostgreSQL.

Per la versione Cloud SQL Enterprise Plus, puoi utilizzare il ripristino di emergenza (DR) avanzato per semplificare le procedure di recupero e fallback senza perdita di dati dopo aver eseguito un failover tra regioni.

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 i dati da Spanner a Cloud Storage come destinazione del backup. 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, Spanner Backup and Restore consente di creare backup coerenti che possono essere conservati per un massimo di un 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 un'istanza Spanner in standby caldo con il numero minimo di nodi necessari per soddisfare i requisiti di archiviazione e di throughput 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 dei dati o l'implementazione di un'applicazione danneggia il database, con la PITR puoi recuperare i dati da un determinato punto nel passato, fino a un massimo di 7 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) 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 può essere eseguita utilizzando i vari operatori della piattaforma cloud.

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 provider cloud e il piano di ripristino di emergenza prevede l'utilizzo di Google Cloud come sito di recupero.

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 modo 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 data sink, 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 il RPO che preferisci, 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.

  • Rendimento del trasferimento. Il tempo necessario per trasferire i file. Per i trasferimenti di file di grandi dimensioni, questo valore è solitamente determinato dalla larghezza di banda disponibile tra la sorgente e la destinazione. Tuttavia, se un job di trasferimento è costituito da un gran numero di file di piccole dimensioni, il QPS può diventare un fattore limitante. In questo caso, puoi pianificare più job simultanei per scalare le prestazioni, a condizione che sia disponibile una larghezza di banda sufficiente. Ti consigliamo di misurare il rendimento 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 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 gestire errori imprevisti o modifiche ai 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 utilizzi database non gestiti sui servizi di calcolo, puoi sfruttare le funzionalità di HA messe a disposizione dal tuo fornitore di cloud di produzione. Puoi estenderli per incorporare un deployment HA su Google Cloud o utilizzare Cloud Storage come destinazione finale per l'archiviazione a freddo dei file di backup del database.

Passaggi successivi