Panoramica dei backup di Bigtable
Questa pagina fornisce una panoramica dei backup di Bigtable. I contenuti presentati qui sono destinati agli amministratori e agli sviluppatori di Bigtable.
I backup consentono di salvare una copia dello schema e dei dati di una tabella e di ripristinarli dal backup in una nuova tabella in un secondo momento. Bigtable offre due tipi di backup. Il tipo di backup che crei dipende dai requisiti di ripristino di emergenza e dal tipo di spazio di archiviazione (HDD o SSD) utilizzato dal cluster Bigtable.
- I backup standard sono ottimizzati per la conservazione a lungo termine. Quando esegui il ripristino da un backup standard a un cluster SSD, l'operazione di ripristino richiede un'ulteriore ottimizzazione da parte di Bigtable per portare la tabella a un livello di prestazioni di produzione. Per ulteriori informazioni, vedi Rendimento durante il ripristino.
- Gli hot backup offrono il ripristino più efficiente per le prestazioni a livello di produzione e la pubblicazione a bassa latenza. Per maggiori informazioni, vedi Backup a caldo.
Puoi creare backup nei seguenti modi:
- Abilita il backup automatico per consentire a Bigtable di creare backup giornalieri.
- Crea un backup on demand utilizzando la console Google Cloud , gcloud CLI o una libreria client Bigtable.
- Crea una copia di un backup.
Prima di leggere questa pagina, devi avere familiarità con la panoramica di Bigtable e con la gestione delle tabelle.
Funzionalità
- Completamente integrati: i backup vengono gestiti interamente dal servizio Bigtable, senza necessità di importazione o esportazione.
- Incrementale: un backup condivide lo spazio di archiviazione fisico con la tabella di origine e altri backup della tabella.
- Conveniente: l'utilizzo dei backup Bigtable ti consente di evitare i costi associati all'esportazione, all'archiviazione e all'importazione dei dati utilizzando altri servizi.
- Scadenza automatica: ogni backup ha una data di scadenza definita dall'utente che può essere fino a 90 giorni dopo la creazione del backup. Puoi archiviare una copia di un backup per un massimo di 30 giorni.
- Opzioni di ripristino flessibili: puoi eseguire il ripristino da un backup a una tabella in un'istanza diversa da quella in cui è stato creato il backup.
- Backup automatico: abilita il backup automatico per consentire a Bigtable di creare backup giornalieri.
- Hot backup: pianifica il ripristino di emergenza con hot backup pronti per la produzione.
Casi d'uso
I backup sono utili per i seguenti casi d'uso:
- Continuità aziendale
- Conformità normativa
- Test e sviluppo
- Disaster recovery
Considera i seguenti scenari di ripristino di emergenza:
| Obiettivo | Strategia di backup | Strategia di restauro |
|---|---|---|
| Protezione contro gli errori umani: vuoi avere sempre un backup recente dei dati pronto in caso di eliminazione o danneggiamento accidentale. | Determina la pianificazione di creazione dei backup più adatta alle esigenze della tua attività, ad esempio giornaliera. Se vuoi, crea copie periodiche dei backup e archiviale in un progetto o una regione diversi per una maggiore isolamento e protezione. Per una protezione ancora maggiore, archivia le copie di backup in un progetto o un'istanza con autorizzazioni di accesso limitato. | Ripristina una nuova tabella dal backup o dalla copia, quindi reindirizza le richieste alla nuova tabella. |
| Indisponibilità della zona: devi assicurarti che, nell'improbabile caso in cui una zona Google Cloud non sia più disponibile, i tuoi dati siano comunque accessibili. | Abilita il backup automatico per consentire a Bigtable di creare un backup giornaliero su ogni cluster nell'istanza. In alternativa, crea backup regolarmente e poi crea periodicamente una copia del backup più recente e archiviala in uno o più cluster in zone diverse (facoltativamente in un'istanza o un progetto diverso). | Se la zona in cui si trova il cluster di pubblicazione non è più disponibile, esegui il ripristino dalla copia di backup remota in una nuova tabella, quindi reindirizza le richieste alla nuova tabella. |
| Corruzione dei dati: utilizza un backup per recuperare parte dei dati di una tabella, ad esempio quando parte della tabella di origine è stata danneggiata. | Abilita la replica e il backup automatico per creare backup giornalieri in più regioni, in modo che se una tabella viene danneggiata su un cluster, tu abbia uno o più backup che non condividono lo spazio di archiviazione sul cluster danneggiato. | Esegui il ripristino dal backup in una nuova tabella nel nuovo cluster o nella nuova istanza. Poi scrivi un'applicazione utilizzando una libreria client Bigtable o Dataflow che legge dalla nuova tabella e poi riscrive i dati nella tabella di origine. Una volta copiati i dati nella tabella originale, elimina la nuova tabella. |
| Recupero rapido: ripristina rapidamente i livelli di prestazioni di produzione completi, riducendo al minimo i tempi di inattività. | Mantieni sempre un backup a caldo recente della tabella. | Esegui il ripristino in una nuova tabella dal backup a caldo e poi reindirizza le richieste alla nuova tabella. |
Backup a caldo
Un hot backup è un backup pronto per la produzione ottimizzato per un ripristino rapido, con una latenza inferiore durante la lettura dalla nuova tabella subito dopo il ripristino. Il ripristino delle prestazioni di produzione da un hot backup è più rapido rispetto al ripristino da un backup standard.
Puoi convertire un backup a caldo in un backup standard, ma non puoi convertire un backup standard in un backup a caldo.
Non puoi creare backup a caldo utilizzando il backup automatico e non puoi creare un backup a caldo su un cluster HDD.
Utilizzo dei backup di Bigtable
Per i backup Bigtable sono disponibili le seguenti azioni. In tutti i casi, il progetto, l'istanza e il cluster di destinazione devono già esistere. Non puoi creare queste risorse nell'ambito di un'operazione di backup.
|
||
| Azione | Opzioni di destinazione | |
|---|---|---|
| Crea un backup standard |
|
|
| Crea un hot backup |
|
|
| Esegui il ripristino da un backup standard o hot in una nuova tabella |
|
|
| Copiare un backup1, 2 |
|
|
Consulta Gestire i backup per istruzioni passo passo su queste azioni, nonché su operazioni come l'aggiornamento e l'eliminazione dei backup.
Utilizza quanto segue per lavorare con i backup Bigtable:
- La console Google Cloud
- Google Cloud CLI
- Le librerie client di Cloud Bigtable
Spazio di archiviazione dei backup
Un backup della tabella creato manualmente o a livello di programmazione viene archiviato in un singolo cluster specificato. Quando il backup automatico è abilitato, viene archiviato un backup su ogni cluster nell'istanza.
Se il cluster supera i limiti consigliati per l'utilizzo di CPU o spazio di archiviazione quando crei un backup, la creazione del backup potrebbe essere ritardata. Per ulteriori informazioni, consulta Informazioni sull'utilizzo di CPU e disco.
Un backup di una tabella include tutti i dati presenti nella tabella al momento della creazione del backup, nel cluster in cui viene creato il backup. Un backup non è mai più grande delle dimensioni della tabella di origine al momento della creazione.
I backup di Bigtable sono incrementali. La quantità di spazio di archiviazione che un backup consuma dipende dalle dimensioni della tabella e dalla misura in cui può condividere lo spazio di archiviazione dei dati invariati con la tabella originale o con altri backup della stessa tabella. Per questo motivo, le dimensioni di un backup dipendono dalla quantità di dati divergenti dal backup precedente.
Puoi creare fino a 150 backup per tabella per cluster.
Puoi eliminare una tabella di cui è stato eseguito il backup. Per proteggere i backup, non puoi eliminare un cluster che contiene un backup e non puoi eliminare un'istanza che ha uno o più backup in qualsiasi cluster.
Un backup esiste ancora dopo il ripristino in una nuova tabella. Puoi eliminarlo o lasciarlo scadere quando non ti serve più. Lo spazio di archiviazione dei backup non viene conteggiato ai fini del limite di archiviazione del nodo per un progetto.
I dati nei backup sono criptati.
Conservazione
Puoi specificare un periodo di conservazione fino a 90 giorni per un backup. Se crei una copia di un backup, il periodo di conservazione massimo per la copia è di 30 giorni dalla creazione.
Puoi modificare il periodo di conservazione di un backup per conservarlo fino a 90 giorni dopo la data di creazione. Per ulteriori informazioni, vedi Modificare un backup o una copia di backup.
Per le tabelle per le quali è abilitato il backup automatico, il periodo di conservazione è
di sette giorni se imposti il criterio utilizzando il
flag --enable-automated-backup. Puoi impostare un periodo di conservazione personalizzato
passando il flag --automated-backup-retention-period, che accetta un valore
da 3 a 90 giorni. Per maggiori informazioni, vedi Aggiornare un criterio di backup automatico.
Spazio di archiviazione post-ripristino
Il costo di archiviazione per una nuova tabella ripristinata da un backup è lo stesso di qualsiasi altra tabella.
Una tabella ripristinata da un backup potrebbe non consumare la stessa quantità di spazio di archiviazione della tabella originale e potrebbe ridursi di dimensioni dopo il ripristino. La differenza di dimensioni dipende dalla data dell'ultima compattazione nel cluster di origine e in quello di destinazione.
Poiché la compattazione avviene in modo continuo, è possibile che si verifichi non appena viene creata la tabella. Tuttavia, la compattazione può richiedere fino a una settimana.
Una nuova tabella ripristinata da un backup non eredita le norme di garbage collection della tabella di origine. Configura i criteri di garbage collection nella nuova tabella prima di iniziare a scrivere nuovi dati nella tabella. Per saperne di più, consulta Configurare la garbage collection.
Costi
Quando lavori con i backup, vengono applicati i costi di rete standard. Non ti vengono addebitati costi per le operazioni di backup, inclusi la creazione, la copia o il ripristino da un backup.
Costi di archiviazione
I costi di archiviazione sono diversi per i backup standard e gli hot backup.
Costi di archiviazione dei backup standard
Per archiviare un backup standard o una copia di un backup, ti viene addebitata la tariffa di archiviazione dei backup standard per la regione in cui si trova il cluster contenente il backup o la copia di backup.
Un backup standard è una copia logica completa di una tabella. Dietro le quinte, Bigtable ottimizza l'utilizzo dello spazio di archiviazione dei backup standard. Questa ottimizzazione significa che un backup standard è incrementale: condivide lo spazio di archiviazione fisico con la tabella originale o con altri backup della tabella ogni volta che è possibile. Grazie alle ottimizzazioni dello spazio di archiviazione integrato di Bigtable, il costo per archiviare un backup standard o una copia di un backup potrebbe talvolta essere inferiore rispetto al costo di una copia fisica completa del backup della tabella.
Nelle istanze replicate in cui è abilitato il backup automatico, i costi di archiviazione potrebbero essere superiori perché viene creato un backup giornaliero su ogni cluster.
Costi di archiviazione di backup a caldo
Per archiviare un backup a caldo, ti viene addebitata la tariffa di archiviazione del backup a caldo per la regione in cui si trova il cluster contenente il backup a caldo.
Poiché un backup a caldo viene archiviato in uno stato pronto, ottimizzato per il ripristino rapido, ti viene addebitato lo spazio di archiviazione dell'intera copia logica della tabella, anziché per le parti incrementali, come avviene con un backup standard.
Costi per la copia di un backup
Quando crei una copia di un backup in una regione diversa da quella del backup di origine, ti vengono addebitate le tariffe di rete standard per il costo della copia dei dati nel cluster di destinazione. Non ti vengono addebitati costi per il traffico di rete quando crei una copia nella stessa regione del backup di origine.
Costi durante il ripristino
Quando ripristini una nuova tabella da un backup, ti viene addebitato il costo di rete della replica. Se la nuova tabella si trova in un'istanza che utilizza la replica, ti verrà addebitato un costo di replica una tantum per la copia dei dati in tutti i cluster dell'istanza.
Se esegui il ripristino in un'istanza diversa da quella in cui è stato creato il backup e l'istanza del backup e l'istanza di destinazione non hanno almeno un cluster nella stessa regione, ti verrà addebitato un costo una tantum per la copia iniziale dei dati nel cluster di destinazione alle tariffe di rete standard.
CMEK
Quando crei un backup in un cluster protetto da una chiave di crittografia gestita dal cliente (CMEK), il backup viene bloccato sulla versione principale della chiave CMEK del cluster al momento della creazione. Una volta creato il backup, la chiave e la relativa versione non possono essere modificate, anche se la chiave KMS viene ruotata.
Quando esegui il ripristino da un backup, la versione della chiave a cui è associato il backup deve essere abilitata per il corretto completamento della procedura di decrittografia del backup. La nuova tabella è protetta con l'ultima versione primaria della chiave CMEK per ogni cluster nell'istanza di destinazione. Se vuoi eseguire il ripristino da un backup protetto da CMEK in un'altra istanza, anche l'istanza di destinazione deve essere protetta da CMEK ma non deve avere la stessa configurazione CMEK dell'istanza di origine.
Considerazioni sulla replica
Questa sezione descrive ulteriori concetti da comprendere durante il backup e il ripristino di una tabella in un'istanza che utilizza la replica.
Replica e backup
Quando esegui manualmente il backup di una tabella in un'istanza replicata, scegli il cluster in cui vuoi creare e archiviare il backup. Nel caso delle tabelle per le quali è abilitato il backup automatico, viene creato un backup giornaliero su ogni cluster nell'istanza.
Non devi interrompere la scrittura nel cluster che contiene il backup, ma devi capire come Bigtable gestisce le scritture replicate nel cluster.
Un backup è una copia della tabella nello stato in cui si trova nel cluster in cui è memorizzato, al momento della creazione del backup. I dati della tabella che non sono ancora stati replicati da un altro cluster nell'istanza non sono inclusi nel backup.
Ogni backup ha un'ora di inizio e di fine. Le scritture inviate al cluster poco prima o durante l'operazione di backup potrebbero non essere incluse nel backup. Due fattori contribuiscono a questa incertezza:
- Una scrittura potrebbe essere inviata a una sezione della tabella che il backup ha già copiato.
- Una scrittura in un altro cluster potrebbe non essere stata replicata nel cluster che contiene il backup.
In altre parole, è possibile che alcune scritture con timestamp precedenti all'ora del backup non vengano incluse nel backup.
Se questa incoerenza è inaccettabile per i requisiti della tua attività, puoi utilizzare un token di coerenza con le tue richieste di scrittura per assicurarti che tutte le scritture replicate siano incluse in un backup.
I backup delle tabelle replicate creati nell'ambito del backup automatico non sono copie esatte l'uno dell'altro, perché gli orari di backup possono variare da cluster a cluster.
Replica e ripristino
Quando ripristini un backup in una nuova tabella, la replica da e verso gli altri cluster nell'istanza inizia immediatamente dopo il completamento dell'operazione di ripristino nel cluster di destinazione.
Prestazioni
Durante la creazione dei backup, utilizza le seguenti best practice per assicurarti che le prestazioni rimangano ottimali.
Prestazioni durante il backup
La creazione di un backup richiede in genere meno di un minuto, anche se può richiedere fino a un'ora. In circostanze normali, la creazione di backup non influisce sulle prestazioni di pubblicazione.
Per un rendimento ottimale, non creare un backup di una singola tabella più di una volta ogni cinque minuti. La creazione di backup più frequenti può potenzialmente comportare un aumento osservabile della latenza di pubblicazione.
Prestazioni durante il ripristino
Il ripristino da un backup in una tabella in un'istanza a cluster singolo richiede alcuni minuti. Nelle istanze replicate, il ripristino richiede più tempo perché i dati devono essere copiati in tutti i cluster. Bigtable sceglie sempre il percorso più efficiente per copiare i dati.
Se esegui il ripristino in un'istanza diversa da quella in cui è stato creato il backup, l'operazione di ripristino richiede più tempo rispetto al ripristino nella stessa istanza. Ciò è particolarmente vero se l'istanza di destinazione non ha un cluster nella stessa zona del cluster in cui è stato creato il backup.
Il ripristino di una tabella più grande richiede più tempo rispetto a una tabella più piccola.
Se hai un'istanza SSD, potresti inizialmente riscontrare una latenza in lettura più elevata, anche dopo il completamento del ripristino, mentre la tabella viene ottimizzata. Puoi controllare lo stato in qualsiasi momento durante l'operazione di ripristino per verificare se l'ottimizzazione è ancora in corso.
Se esegui il ripristino in un'istanza diversa da quella in cui è stato creato il backup, l'istanza di destinazione può utilizzare l'archiviazione HDD o SSD. Non è necessario utilizzare lo stesso tipo di archiviazione dell'istanza di origine.
Controllo degli accessi
Le autorizzazioni IAM controllano l'accesso alle operazioni di backup e ripristino. Le autorizzazioni di backup sono a livello di istanza e si applicano a tutti i backup nell'istanza.
L'account che utilizzi per creare un backup di una tabella deve disporre dell'autorizzazione per leggere la tabella e creare backup nell'istanza in cui si trova la tabella (l'istanza di origine).
L'account che utilizzi per copiare un backup deve disporre dell'autorizzazione per leggere il backup di origine e per creare un backup nel progetto e nell'istanza di destinazione.
L'account che utilizzi per ripristinare una nuova tabella da un backup deve disporre dell'autorizzazione per creare una tabella nell'istanza in cui esegui il ripristino.
| Azione | Autorizzazione IAM obbligatoria |
|---|---|
| Crea backup | bigtable.tables.readRows, bigtable.backups.create |
| Ottenere un backup | bigtable.backups.get |
| Elenco dei backup | bigtable.backups.list |
| Eliminare un backup | bigtable.backups.delete |
| Aggiornare un backup | bigtable.backups.update |
| Copiare un backup | bigtable.backups.read, bigtable.backups.create |
| Esegui il ripristino da un backup in una nuova tabella | bigtable.tables.create, bigtable.backups.restore |
| Recupero di un'operazione | bigtable.instances.get |
| Elenca operazioni | bigtable.instances.get |
Best practice
Prima di creare una strategia di backup, considera le seguenti best practice. Per ulteriori informazioni sulla pianificazione del ripristino di emergenza, consulta la sezione Bigtable di Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud.
Creazione dei backup
- Non eseguire il backup di una tabella più di una volta ogni cinque minuti.
- Quando esegui il backup di una tabella che utilizza la replica, scegli il cluster in cui archiviare
il backup dopo aver preso in considerazione i seguenti fattori:
- Costo. Un cluster nella tua istanza potrebbe trovarsi in una regione a costi inferiori rispetto agli altri.
- Vicinanza al server delle applicazioni. Ti consigliamo di archiviare il backup il più vicino possibile all'applicazione di pubblicazione.
- Se devi assicurarti che tutte le scritture replicate siano incluse in un backup quando esegui il backup di una tabella in un'istanza che utilizza la replica, utilizza un token di coerenza con le tue richieste di scrittura.
Ripristino dai backup
- Pianifica in anticipo il nome della nuova tabella se devi eseguire il ripristino da un backup. Il punto chiave è prepararsi in anticipo in modo da non dover decidere quando stai affrontando un problema.
- Se ripristini una tabella per un motivo diverso dall'eliminazione accidentale, assicurati che tutte le letture e le scritture vengano eseguite nella nuova tabella prima di eliminare la tabella originale.
- Se prevedi di eseguire il ripristino in un'altra istanza, crea l'istanza di destinazione prima di avviare l'operazione di ripristino del backup.
- Per evitare un ripristino lento della tabella, attendi il completamento di un'operazione di ripristino prima di avviare un altro ripristino per la stessa tabella di origine nella stessa zona.
- Attendi almeno un'ora dopo la creazione prima di eseguire il ripristino da un backup standard. Se devi eseguire il ripristino più rapidamente, utilizza un backup a caldo.
Quote e limiti
Le richieste di backup e ripristino e lo spazio di archiviazione dei backup sono soggetti a quote e limiti di Bigtable.
Limitazioni
Ai backup Bigtable si applicano le seguenti limitazioni:
Generali
- Non puoi leggere direttamente da un backup.
- Un backup è una versione di una tabella in un singolo cluster in un momento specifico. I backup non rappresentano uno stato coerente. Lo stesso vale anche per i backup della stessa tabella in cluster diversi.
- Non puoi eseguire il backup di più di una tabella in un'unica operazione.
- Non puoi esportare, copiare o spostare un backup Bigtable in un altro servizio, ad esempio Cloud Storage.
- I backup di Bigtable contengono solo dati Bigtable e non sono integrati o correlati ai backup di altri servizi Google.
- Non puoi creare un backup di una visualizzazione.
Ripristino
- Non puoi ripristinare un backup in una tabella esistente.
- Puoi eseguire il ripristino solo su un'istanza già esistente. Bigtable non crea una nuova istanza durante il ripristino da un backup. Se l'istanza di destinazione specificata in una richiesta di ripristino non esiste, l'operazione di ripristino non riesce.
- Se esegui il ripristino da un backup a una tabella in un cluster SSD e poi elimini la tabella appena ripristinata, l'eliminazione della tabella potrebbe richiedere un po' di tempo perché Bigtable attende il completamento dell'ottimizzazione della tabella.
Copia
- Non puoi creare una copia di un backup che scade entro 24 ore.
- Non puoi creare una copia di una copia di backup.
CMEK
- Un backup protetto da CMEK deve essere ripristinato in una nuova tabella in un'istanza protetta da CMEK.
- Quando crei una copia di un backup protetto da CMEK, anche il cluster di destinazione deve essere protetto da CMEK.
Passaggi successivi
- Scopri come eseguire il backup e il ripristino delle tabelle.
- Scopri come attivare il backup automatico.