Scenari di ripristino di emergenza dei dati

Last reviewed 2024-08-05 UTC

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

La serie è composta dai seguenti componenti:

Introduzione

I piani di ripristino di emergenza devono specificare come evitare di perdere dati durante un'emergenza. 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 dati da solo comporta la copia di una quantità distinta di dati da un luogo all'altro. I backup vengono eseguiti nell'ambito di un piano di recupero per recuperare da un danneggiamento dei dati in modo da ripristinare uno stato noto buono direttamente nell'ambiente di produzione o per ripristinare i dati nell'ambiente di RE se l'ambiente di produzione è inattivo. In genere, i backup dei dati hanno un RTO da piccolo a medio e un RPO ridotto.
  • Backup dei database. I backup del database sono leggermente più complessi, perché in genere prevedono il recupero fino al punto in tempo. Pertanto, oltre a valutare come eseguire il backup e il ripristino dei backup del database e assicurarti che il sistema di database di recupero rispecchi la configurazione di produzione (stessa versione, configurazione dei dischi in mirroring), devi anche valutare 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.

Quando esegui carichi di lavoro di produzione su Google Cloud, puoi utilizzare un sistema distribuito a livello globale in modo che, se si verifica un problema in una regione, l'applicazione continui a fornire il servizio anche se è meno disponibile. In sostanza, l'applicazione richiama il proprio piano di RE.

Nella parte rimanente di questo documento vengono descritti esempi di come progettare alcuni scenari per dati e database che possono aiutarti a raggiungere i tuoi obiettivi RTO e RPO.

L'ambiente di produzione è on-premise

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

Backup e recupero dei dati

Puoi utilizzare 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 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 un processo 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 da cui carichi i 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 l'account di servizio creato appositamente per questo scopo. Per informazioni dettagliate sulle autorizzazioni per l'accesso a Cloud Storage, consulta 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 di poter caricare e scaricare file 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 un processo di recupero che utilizzi il comando gcloud storage per recuperare i dati nel tuo ambiente di RE di recupero 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 pianificazione dei backup più frequente e ottenere un RPO inferiore.

gcloud storage rsync -r SOURCE_DIRECTORY gs:// BUCKET_NAME

Per ulteriori informazioni, consulta il comando gcloud storage per trasferimenti più piccoli 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 RE:

  • Cloud Storage
  • Transfer Service for On Premises Data

Il trasferimento di grandi quantità di dati su una rete spesso richiede un'attenta pianificazione e strategie di esecuzione solide. Sviluppare script personalizzati scalabili, affidabili e gestibili non è un'operazione banale. Gli script personalizzati possono spesso portare a valori RPO inferiori e persino a un aumento dei rischi di perdita di dati.

Per indicazioni su come spostare grandi volumi di dati da località on-premise a Cloud Storage, consulta Spostare dati o eseguirne il backup dall'archiviazione on-premise.

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

Questo pattern utilizza i seguenti componenti di base RE:

  • 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 recupero 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 diverse opzioni di classi di archiviazione da utilizzare come equivalente del livello più lento.

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

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 nel tuo ambiente RE. L'ambiente di DR viene utilizzato per gestire il traffico di produzione fino a quando non potrai ripristinare l'ambiente di produzione. La modalità di ottenimento dipende dalla tua applicazione, dalla soluzione del partner e dalla relativa architettura. Alcuni scenari end-to-end sono descritti nel documento relativo all'applicazione del DR.

Puoi anche utilizzare i database Google Cloud gestiti come destinazioni di RE. 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 sui modi per trasferire i dati da ambienti on-premise a Google Cloud, consulta Trasferimento di set di big data in 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.

Questo documento non tratta in dettaglio i vari meccanismi di backup e recupero integrati inclusi nei database di terze parti. Questa sezione fornisce indicazioni generali, che vengono implementate nelle soluzioni discusse qui.

Soluzione 1: backup e ripristino utilizzando 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 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 l'gcloud storage gcloud CLI 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 sito di ripristino 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 recupero sul sistema su 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 è la seguente:

  1. Crea una immagine personalizzata del 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 una procedura per copiare i file di backup e i file di log delle transazioni on-premise in Cloud Storage. Per un esempio di implementazione, consulta la soluzione 1.
  3. Avvia un'istanza di dimensioni minime dall'immagine personalizzata e collega tutti 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 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. Fai in modo che i client indirizzino il 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 di Google Cloud. Una sequenza tipica per tornare all'ambiente di produzione è la seguente:

  1. Esegui il backup del database in esecuzione su Google Cloud.
  2. Copia il file di backup nell'ambiente di produzione.
  3. Applica il file di backup al sistema di database di produzione.
  4. Impedire ai client di connettersi al sistema di database in Google Cloud, ad esempio interrompendo il servizio del sistema di database. Da questo momento, l'applicazione non sarà disponibile finché non avrai completato il ripristino dell'ambiente di produzione.
  5. Copia i file di log delle transazioni nell'ambiente di produzione e applicali.
  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 una immagine personalizzata del server di database su Google Cloud. Il server di database deve avere sull'immagine la stessa configurazione del 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 condizioni normali per puntare al server di database on-premise.

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

Una volta eseguito il backup dell'ambiente di produzione e abilitato il supporto dei carichi di lavoro di produzione, devi sincronizzare nuovamente il server di database di produzione con il server di database Google Cloud e poi impostare i client in modo che indirizzino nuovamente l'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 è utilizzare un pattern di archiviazione a più livelli. Quando il tuo carico di lavoro di produzione è su Google Cloud, il sistema di archiviazione a più livelli è simile al seguente diagramma. Esegui la migrazione dei dati a un livello con costi di archiviazione inferiori, perché è meno probabile che sia necessario accedere ai dati di cui è stato eseguito il backup.

Questo pattern utilizza i seguenti componenti di base RE:

Diagramma concettuale che mostra l'immagine che mostra 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), si applicano gli stessi problemi operativi della gestione dei database di produzione on-premise, ma non devi più gestire l'infrastruttura di base.

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 configurare le configurazioni HA utilizzando le funzionalità dei componenti di base di DR appropriati per mantenere basso il RTO. Puoi progettare la configurazione del database in modo da rendere possibile il recupero a uno stato il più vicino possibile a quello precedente al disastro. In questo modo, i valori RPO rimangono ridotti. 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 recupero di un server di database che non richiede la sincronizzazione dello stato del sistema con una replica di standby aggiornata.

Questo pattern utilizza i seguenti componenti di base RE:

  • 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 di architettura che mostra un'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. Configura i controlli di stato 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.

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 contenente i file di backup e dei log delle transazioni più recenti all'istanza del server di database appena creata.
  • Riduci al minimo la necessità di riconfigurare i client che comunicano con il tuo server di database in risposta a un evento.
  • Assicurati che i controlli di sicurezza di Google Cloud (criteri IAM, impostazioni di firewall) applicati 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'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. Se esegui regolarmente snapshot dei dischi permanenti, ti assicuri che, quando i dischi vengono ricreati dagli snapshot e collegati all'istanza sostitutiva, l'istanza sostitutiva utilizzi i dati recuperati in base a un valore RPO dettato dalla frequenza degli snapshot. In questa architettura, vengono anche ripristinati automaticamente i file dei log delle transazioni più recenti scritti sul disco permanente.

Il gruppo di istanze gestite fornisce HA in modo approfondito. Fornisce meccanismi per reagire ai guasti a livello di applicazione o istanza e non devi intervenire manualmente se si verifica uno di questi scenari. L'impostazione di una dimensione target pari a 1 garantisce che nel gruppo di istanze gestite venga eseguita una sola istanza attiva che 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 variazione scelta dipende dal budget e dai valori RTO e RPO.

Ripristino da una corruzione parziale in database di grandi dimensioni

La replica asincrona dei dischi permanenti offre una replica dell'archiviazione a blocchi con RPO e RTO bassi per il RE attivo-passivo tra regioni. Questa opzione di archiviazione ti consente di gestire la replica per i workload Compute Engine a livello di infrastruttura anziché a livello di workload.

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 diverse 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 aggiustare le applicazioni in modo che puntino alla nuova tabella.

Inoltre, se il tuo RTO lo consente, puoi impedire l'accesso alla tabella contenente i dati danneggiati lasciando le applicazioni offline finché i dati non danneggiati non sono 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 essere scalabili, pertanto i meccanismi di backup e ripristino tradizionali che vedi con i sistemi RDBMS tradizionali in genere non sono disponibili. Come nel caso dei database autogestiti, se utilizzi un database in grado di memorizzare petabyte di dati, devi ridurre al minimo la quantità di dati da ripristinare in uno scenario di RE. Esistono diverse strategie per ogni database gestito che ti aiutano a raggiungere questo obiettivo.

Bigtable fornisce la replica Bigtable. Un database Bigtable replicato può offrire una disponibilità superiore rispetto a un singolo cluster, un throughput di lettura aggiuntivo e una maggiore durabilità e resilienza in caso di errori a livello di zona o di regione.

I backup di Bigtable sono un servizio completamente gestito che ti consente di salvare una copia dello schema e dei dati di una tabella, quindi di ripristinarli dal backup in una nuova tabella in un secondo momento.

Puoi anche esportare le tabelle da Bigtable come una serie di file di sequenza Hadoop. Puoi quindi archiviare questi file in Cloud Storage o utilizzarli per importare nuovamente 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 sfruttare la funzionalità 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 le seguenti operazioni:

  • 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 creare una nuova tabella contenente i dati esportati, ma che escluda 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 periodi di tempo specifici. 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.
  • Archivia i dati originali su Cloud Storage, in modo da poter creare una nuova tabella e ricaricare i dati non danneggiati. Da qui, puoi aggiustare le applicazioni in modo che puntino alla nuova tabella.

Firestore. Il servizio di esportazione e importazione gestito ti consente di importare ed esportare entità Firestore utilizzando un bucket Cloud Storage. Puoi quindi implementare un processo che può essere utilizzato 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 in una configurazione HA e con repliche tra regioni per massimizzare il tempo di attività in caso di guasto zonale o regionale.

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 (RE) avanzato per semplificare le procedure di recupero e fallback senza perdita di dati dopo aver eseguito un failover tra regioni.

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

Per eseguire 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 a Cloud Storage come destinazione del backup. La velocità con cui i dati possono essere letti da Spanner (o riscritti al suo interno) dipende dal numero di nodi configurati. Ciò ha un impatto diretto sui valori RTO.

La funzionalità timestamp commit di Spanner può essere utile per i backup incrementali, in quanto consente di selezionare solo le righe aggiunte o modificate dall'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 all'esportazione perché l'operazione di ripristino 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) da eseguire in base a una pianificazione (ad esempio giornaliera) per copiare i dati in un altro progetto, set di dati o tabella (a seconda della soluzione utilizzata) oppure per esportarli 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 dei dati tra oggetti è un caso d'uso comune per gli 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 generati o aggiornati per un determinato periodo di tempo. Maggiore è il tasso di variazione, maggiori sono le risorse necessarie per trasferire le modifiche alla destinazione in ogni periodo di trasferimento incrementale.

  • 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 come l'ultima volta che è stato pianificato un job di trasferimento. Pertanto, è importante che gli intervalli tra i job di trasferimento successivi non siano più lunghi dell'obiettivo RPO. Ad esempio, se l'obiettivo RPO è 1 giorno, il job di trasferimento deve essere pianificato almeno una volta al giorno.

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

Backup e ripristino del database

Questo documento non tratta in dettaglio i vari meccanismi di backup e recupero integrati inclusi nei database di terze parti o le tecniche di backup e recupero utilizzate su altri provider cloud. 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