Panoramica del ripristino di un'istanza

Cloud SQL consente di ripristinare le istanze da un backup o eseguendo il recupero point-in-time (PITR). In questo modo puoi recuperare un'istanza in un periodo o un momento specifico ripristinando il backup in un'istanza esistente o in una nuova istanza. Per il ripristino, puoi utilizzare il backup di un'istanza attiva o eliminata. L'operazione di ripristino prende le impostazioni, i database e gli utenti dell'istanza di origine e li imposta nell'istanza target che scegli.

Quando esegui il ripristino in una nuova istanza, l'istanza target può trovarsi in una regione o un progetto diversi rispetto all'istanza di origine. L'istanza target può anche utilizzare un numero di core o una quantità di memoria diversi rispetto all'istanza di origine.

Cloud SQL imposta sempre la capacità di archiviazione dell'istanza target sul valore massimo della dimensione del disco configurato e del disco di backup. Il disco di backup ha le dimensioni del disco al momento della creazione del backup.

Quando esegui un ripristino su un'istanza, tieni presente quanto segue:

• L'operazione di ripristino sovrascrive tutti i dati nell'istanza di destinazione.
• I flag dell'istanza di origine non vengono ripristinati. Eventuali flag impostati in precedenza sull'istanza target vengono conservati dopo il ripristino.
• L'istanza target non è disponibile per le connessioni durante l'operazione di ripristino; le connessioni esistenti vengono perse.
• Se esegui il ripristino in un'istanza con repliche di lettura, devi eliminare tutte le repliche e ricrearle al termine dell'operazione di ripristino.
• L'operazione di ripristino riavvia l'istanza.
• Dopo il ripristino da un backup, le configurazioni di backup dell'istanza target vengono impostate sui valori predefiniti. Se l'istanza di origine aveva configurazioni di backup personalizzate o utilizzava i backup avanzati, dovrai aggiornare le configurazioni di backup al termine del ripristino.

Ripristina utilizzando un backup

Cloud SQL ti consente di ripristinare un'istanza utilizzando un backup. Puoi utilizzare un backup di un'istanza attiva o eliminata e utilizzarlo per il ripristino in un'istanza nuova o esistente. Puoi utilizzare qualsiasi backup disponibile per ripristinare l'istanza. Per scoprire di più sul funzionamento dei backup in Cloud SQL, consulta la panoramica dei backup.

Quando ripristini un'istanza utilizzando un backup, puoi:

• Ripristina in una nuova istanza
• Ripristina in un'istanza esistente
• Esegui il ripristino in un'istanza in un altro progetto o in un'altra regione

In caso di interruzione, puoi comunque recuperare un elenco di backup in un progetto specifico da cui eseguire il ripristino.

Per ripristinare l'istanza utilizzando un backup, consulta Ripristina un'istanza utilizzando un backup.

Ripristina un'istanza abilitata per CMEK utilizzando i backup avanzati

Quando utilizzi istanze abilitate per CMEK con backup avanzati, i backup sono protetti dalla stessa CMEK dell'istanza. Questa può essere una parte importante del tuo piano di backup per le istanze che richiedono la crittografia CMEK, perché mantiene i backup crittografati con CMEK in un progetto separato in cui possono essere ripristinati correttamente anche se il progetto del workload originale viene compromesso o eliminato.

Quando ripristini un backup avanzato di un'istanza abilitata per CMEK in una nuova istanza, puoi scegliere una delle seguenti opzioni di crittografia per la nuova istanza:

• Utilizza la stessa chiave Cloud KMS dell'istanza originale. Questo è il comportamento predefinito.
• Seleziona una chiave Cloud KMS diversa per l'istanza target. Per selezionare una chiave diversa, imposta il flag --disk-encryption-key nel comando di ripristino.
• Ripristina Google Cloud-powered encryption keys per l'istanza target. Per utilizzare GMEK, imposta il flag --clear-disk-encryption nel comando di ripristino.

Se il vault di backup si trova in una regione diversa da quella dell'istanza, i backup sono comunque protetti dalla chiave Cloud KMS dell'istanza, che si trova nella regione dell'istanza. Se la regione dell'istanza non è disponibile, la chiave non può essere utilizzata per decriptare i backup e non puoi ripristinarli finché la regione non è disponibile. I backup delle istanze che utilizzano Google Cloud-powered encryption keys non hanno questa limitazione. Per saperne di più, consulta Backup tra regioni.

Quando ripristini un backup in una nuova istanza in una regione diversa rispetto all'istanza di origine, l'istanza target non può utilizzare la chiave dell'istanza di origine. Per utilizzare CMEK per l'istanza target, imposta il flag --disk-encryption-key su una chiave Cloud KMS che si trova nella regione dell'istanza target.

Recupero point-in-time (PITR)

Il PITR consente di ripristinare l'istanza a un momento specifico del database. Ad esempio, se un errore causa una perdita di dati, puoi ripristinare un database nello stato in cui si trovava prima che si verificasse l'errore. A differenza del ripristino tramite un backup, il PITR crea sempre una nuova istanza. Non puoi eseguire un PITR su un'istanza esistente. La nuova istanza eredita le impostazioni dell'istanza di origine, in modo simile a quando crei un clone.

Se crei un'istanza della versione Cloud SQL Enterprise Plus, il PITR è abilitato per impostazione predefinita. Se non vuoi che sia attiva, devi disattivarla manualmente.

Se crei un'istanza della versione Cloud SQL Enterprise nella console Cloud de Confiance , il PITR viene abilitato per impostazione predefinita. In caso contrario, se crei l'istanza utilizzando gcloud CLI, Terraform o l'API Cloud SQL Admin, il PITR è disabilitato per impostazione predefinita. Per attivare il PITR per queste istanze, devi attivarlo manualmente.

Per istruzioni passo passo sull'esecuzione del PITR, consulta Utilizza il recupero point-in-time (PITR).

Archiviazione dei log per il PITR

Il PITR utilizza il write-ahead logging (WAL) per archiviare i log. Quando ripristini un'istanza esistente utilizzando un backup, questi log di archiviazione vengono eliminati e non saranno disponibili per eseguire un PITR. Solo i nuovi log generati dopo il completamento del ripristino possono essere utilizzati per PITR.

Il 9 gennaio 2023 abbiamo lanciato l'archiviazione dei log delle transazioni per il PITR in Cloud Storage. Da questo lancio, si applicano le seguenti condizioni:

• Tutte le istanze della versione Cloud SQL Enterprise Plus archiviano i log write-ahead utilizzati per il PITR in Cloud Storage. Solo le istanze della versione Cloud SQL Enterprise Plus di cui hai eseguito l'upgrade dalla versione Cloud SQL Enterprise prima del 1° aprile 2024 e per le quali era abilitato il PITR prima del 9 gennaio 2023 continuano ad archiviare i log per il PITR su disco.

• Le istanze della versione Cloud SQL Enterprise create con il PITR abilitato prima del 9 gennaio 2023 continuano ad archiviare i log per il PITR su disco.

• Se esegui l'upgrade di un'istanza della versione Cloud SQL Enterprise dopo il 9 gennaio 2023 che archivia i log delle transazioni per il PITR su disco alla versione Cloud SQL Enterprise Plus, il processo di upgrade cambia la posizione di archiviazione dei log delle transazioni utilizzati per il PITR in Cloud Storage. Per saperne di più, consulta Esegui l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade sul posto.

• Tutte le istanze della versione Cloud SQL Enterprise create con PITR abilitato dopo il 9 gennaio 2023 archiviano i log utilizzati per il PITR in Cloud Storage.

Se l'istanza utilizza Cloud Storage per archiviare i log write-ahead, questi vengono archiviati nella stessa regione dell'istanza principale. Questi log vengono archiviati per un massimo di 35 giorni per la versione Cloud SQL Enterprise Plus e di 7 giorni per la versione Cloud SQL Enterprise e non generano costi aggiuntivi per istanza.

Per saperne di più su come controllare la località di archiviazione dei log delle transazioni utilizzati per il PITR, consulta Controlla dove sono archiviati i log delle transazioni per l'istanza.

Per le istanze che archiviano i log write-ahead solo su disco, puoi cambiare la località di archiviazione dei log delle transazioni utilizzati per il PITR da disco a Cloud Storage utilizzando gcloud CLI o l'API Cloud SQL Admin. Per saperne di più, consulta Cambia lo spazio di archiviazione dei log delle transazioni in Cloud Storage.

Per assicurarti che i log della tua istanza siano archiviati in Cloud Storage anziché su disco, completa le seguenti azioni:

• Controlla l'architettura di rete dell'istanza. Se l'istanza si trova sulla vecchia architettura di rete, esegui l'upgrade alla nuova architettura di rete.

• Se le dimensioni dei log sul disco causano problemi di prestazioni per l'istanza, disattiva il PITR e riattivalo. Questa azione garantisce che i nuovi log vengano archiviati in Cloud Storage anziché su disco.

Periodo di conservazione dei log

Cloud SQL conserva i log delle transazioni in Cloud Storage per un periodo massimo pari al valore impostato nell'impostazione di configurazione PITR transactionLogRetentionDays. Questo valore può variare da 1 a 35 giorni per la versione Cloud SQL Enterprise Plus e da 1 a 7 giorni per la versione Cloud SQL Enterprise. Se non viene impostato un valore per questo parametro, il periodo di conservazione predefinito del log delle transazioni è di 14 giorni per le istanze della versione Cloud SQL Enterprise Plus e di 7 giorni per le istanze della versione Cloud SQL Enterprise. Per saperne di più su come impostare i giorni di conservazione del log delle transazioni, consulta Imposta la conservazione del log delle transazioni.

Sebbene un'istanza archivi i log write-ahead utilizzati per il PITR in Cloud Storage, l'istanza conserva anche un numero inferiore di log write-ahead duplicati sul disco per consentire la replica dei log in Cloud Storage. Per impostazione predefinita, quando crei un'istanza con il PITR abilitato, l'istanza archivia i log write-ahead per il PITR in Cloud Storage. Cloud SQL imposta automaticamente anche il valore dei flag expire_logs_days e binlog_expire_logs_seconds sull'equivalente di un giorno. Ciò si traduce in un giorno di log su disco.

Per i log write-ahead PITR archiviati su disco, che vengono trasferiti su Cloud Storage o che sono già stati trasferiti su Cloud Storage, Cloud SQL conserva i log per il valore minimo impostato per una delle seguenti configurazioni:

• L'impostazione di configurazione del backup transactionLogRetentionDays
• Il flag expire_logs_days o il flag binlog_expire_logs_seconds

Cloud SQL non imposta alcun valore per questi flag se i log write-ahead sono archiviati su disco, se è in corso il passaggio a Cloud Storage o se il passaggio a Cloud Storage è già stato eseguito. Quando i log vengono archiviati sul disco, la modifica dei valori di questi flag può influire sul comportamento del recupero PITR e sul numero di giorni di log archiviati sul disco. Durante il passaggio della località di archiviazione dei log a Cloud Storage, non puoi modificare i valori dei flag. Inoltre, sconsigliamo di configurare il valore di uno dei flag su 0. Per saperne di più, consulta Configura i flag di database.

• Impostazione di configurazione transactionLogRetentionDays
• expire_logs_days flag di database
• binlog_expire_logs_seconds flag di database

Ad esempio, per evitare problemi di prestazioni, riduci il valore dei flag di un giorno, ogni giorno, per diversi giorni. Di conseguenza, Cloud SQL non elimina tutti i log write-ahead contemporaneamente.

Per le istanze abilitate per le chiavi di crittografia gestite dal cliente (CMEK), i log write-ahead vengono criptati utilizzando l'ultima versione della CMEK. Per eseguire un ripristino, è necessaria l'ultima versione della chiave per tutti i giorni conservati nell'ambito del parametro retained-transaction-log-days.

Limitazioni del PITR

Le seguenti limitazioni sono associate all'abilitazione del PITR per l'istanza e alle dimensioni dei log delle transazioni su disco che causano un problema per l'istanza:

• Puoi disattivare il PITR e riattivarlo per assicurarti che Cloud SQL archivi i log in Cloud Storage nella stessa regione dell'istanza. Tuttavia, Cloud SQL elimina tutti i log esistenti, quindi non puoi eseguire un'operazione PITR prima della riattivazione del PITR.
• Puoi aumentare le dimensioni dello spazio di archiviazione dell'istanza, ma l'aumento dell'utilizzo del disco dovuto alle dimensioni del log delle transazioni potrebbe essere temporaneo.
• Per evitare problemi imprevisti di spazio di archiviazione, ti consigliamo di attivare gli incrementi automatici dello spazio di archiviazione. Questo suggerimento si applica solo se l'istanza ha il PITR abilitato e i log sono archiviati sul disco.

Per istruzioni passo passo su come eseguire il PITR, consulta [Utilizza il recupero point-in-time (PITR)][perform-pitr].

Ripristina un'istanza non disponibile

Puoi utilizzare il PITR per ripristinare un'istanza Cloud SQL non disponibile. Il PITR offre in genere un Recovery Point Objective (RPO) di cinque minuti o meno.

Se l'istanza non è disponibile, puoi utilizzare l'API per ottenere il tempo di recupero più recente e meno recente in cui puoi ripristinare l'istanza ed eseguire il recupero in quel momento. Se la zona in cui è configurata l'istanza non è accessibile, puoi ripristinare l'istanza in una zona principale o secondaria diversa fornendo i valori per le zone preferite.

Supponiamo che un'istanza Cloud SQL non sia più disponibile alle 16:00 EST. Se l'ultimo tempo di recupero è alle 15:55 EST, puoi recuperare l'istanza fino a questo momento.

Ripristina un'istanza eliminata utilizzando il PITR

Puoi utilizzare il PITR per ripristinare un'istanza Cloud SQL dopo l'eliminazione. Per utilizzare questa funzionalità, l'istanza deve avere il PITR e i backup conservati abilitati prima dell'eliminazione dell'istanza. Se abilitata, i log PITR vengono conservati dopo l'eliminazione dell'istanza.

Dopo l'eliminazione di un'istanza, i log PITR continuano a seguire le impostazioni di conservazione definite dall'istanza quando era attiva. I log PITR scadono in base alle impostazioni di conservazione su base continuativa dopo l'eliminazione dell'istanza. Il periodo continuativo viene definito in base al periodo di conservazione PITR impostato nell'istanza prima dell'eliminazione. Ad esempio, se l'istanza Cloud SQL Enterprise Plus ha una conservazione PITR impostata su 14 giorni, il log PITR più recente verrà eliminato 14 giorni dopo l'eliminazione dell'istanza. Quando un log PITR scade, non può essere recuperato.

Poiché i nomi delle istanze possono essere riutilizzati dopo l'eliminazione di un'istanza in Cloud SQL, i log PITR conservati possono essere identificati in Cloud de Confiance by S3NS con i seguenti campi:

• instance_deletion_time
• log_retention_days

Questi campi ti consentono di identificare se un log PITR appartiene a un'istanza eliminata.

La finestra di recupero PITR è definita come i tempi di recupero più recenti e meno recenti disponibili per ripristinare l'istanza utilizzando il PITR. Per trovare i tempi di recupero più recenti e meno recenti dell'istanza eliminata, consulta Recupera il tempo di recupero più recente e meno recente.

Per ripristinare un'istanza utilizzando il PITR dopo l'eliminazione dell'istanza, consulta Esegui il PITR su un'istanza eliminata.

Requisiti per il ripristino in una nuova istanza

Quando ripristini l'istanza in una nuova istanza, tieni presente i seguenti requisiti:

• L'istanza target deve avere la stessa versione del database dell'istanza da cui è stato eseguito il backup.

• Quando crei una nuova istanza, la funzionalità storageAutoResize è attivata per impostazione predefinita. Qualsiasi backup creato successivamente eredita la stessa impostazione storageAutoResize. Ciò significa che, indipendentemente dal fatto che il backup venga ripristinato in un'istanza nuova o esistente, l'istanza ridimensionerà automaticamente la capacità di archiviazione in base alle esigenze. Questa funzionalità non è abilitata per le istanze legacy. Per controllare le impostazioni dell'istanza, consulta Visualizza le impostazioni dell'istanza.

• L'istanza target deve essere nello stato RUNNABLE.

• Se ripristini un backup crittografato con CMEK in un progetto diverso, concedi il ruolo Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) al account di servizio Cloud SQL del progetto di destinazione sulla chiave Cloud KMS. Se esegui anche il ripristino in una regione diversa, specifica una chiave Cloud KMS nella regione di destinazione e concedi il ruolo su entrambe le chiavi. Per saperne di più, consulta Utilizza le chiavi di crittografia gestite dal cliente (CMEK).

• Se ripristini un backup tra progetti con i Controlli di servizio VPC, aggiungi i progetti di backup di origine e di istanza target allo stesso perimetro di servizio o a un bridge del perimetro. Se l'istanza di backup o l'istanza target utilizza CMEK, anche il progetto della chiave Cloud KMS deve appartenere allo stesso perimetro di servizio o a un bridge del perimetro connesso. Per saperne di più, consulta Ripristina in un'istanza nuova o esistente in un progetto diverso e la voce dell'API Cloud SQL Admin nella tabella dei prodotti supportati dai Controlli di servizio VPC.

Limitazioni della frequenza di ripristino

Puoi eseguire un massimo di tre operazioni di ripristino ogni 30 minuti per istanza, per regione e per progetto. Se un'operazione di ripristino non va a buon fine, non viene conteggiata ai fini di questa quota. Se raggiungi il limite, l'operazione non va a buon fine e viene visualizzato un messaggio di errore che ti comunica quando puoi eseguirla di nuovo.

Cloud SQL utilizza i token di un bucket per determinare quante operazioni di ripristino sono disponibili in un determinato momento. Per ogni backup, è presente un bucket per ogni progetto e regione di destinazione. Le istanze target dello stesso progetto condividono un bucket se si trovano nella stessa regione. In ogni bucket è presente un massimo di tre token che puoi utilizzare per le operazioni di ripristino. Ogni 10 minuti, un nuovo token viene aggiunto al bucket. Se il bucket è pieno, il token va in overflow.

Ogni volta che esegui un'operazione di ripristino, viene concesso un token dal bucket. Se l'operazione va a buon fine, il token viene rimosso dal bucket. Se l'operazione non va a buon fine, il token viene restituito al bucket. Il seguente diagramma mostra come funziona:

Ad esempio, nella figura seguente, Backup1, Backup2 e Backup3 sono i backup della stessa istanza di origine.

• Ogni backup (Backup1, Backup2 e Backup3) ha il proprio bucket di token per le operazioni di ripristino che hanno come target istanze diverse nel Progetto 1 nella Regione A (Bucket11A, Bucket21A e Bucket31A). Poiché ogni backup ha il proprio bucket, puoi ripristinare ogni backup nella stessa istanza tre volte ogni 30 minuti.
• Ogni backup ha un bucket per un progetto separato e per una regione separata. Ad esempio, se in una regione sono presenti cinque progetti, sono presenti cinque bucket per il backup in quella regione, uno in ogni progetto. Nella figura precedente, abbiamo due progetti nella regione A: Progetto 1 e Progetto n.
  • Backup1 ha due bucket di token per le operazioni di ripristino nella regione A. Un bucket per il Progetto 1 (Bucket11A) e un bucket per il Progetto n (Bucket1nA).
  • Analogamente, Backup3 ha due bucket per le operazioni di ripristino nella Regione A. Uno per il Progetto 1 (Bucket31A) e uno per il Progetto n (Bucket3nA).
• Backup3 ha un bucket nella Regione B, per Project1, perché tutte le istanze nello stesso progetto di destinazione e nella stessa regione di destinazione condividono un bucket.

Passaggi successivi

• Esegui il ripristino da un backup
• Utilizza il recupero point-in-time (PITR)