Panoramica dei backup di Bigtable
Questa pagina fornisce una panoramica dei backup di Bigtable. I contenuti qui presentati sono destinati agli amministratori e agli sviluppatori di Bigtable.
I backup di Bigtable consentono di salvare una copia dello schema e dei dati di una tabella per poi ripristinarli dal backup a una nuova tabella in un secondo momento. Puoi creare i backup manualmente o abilitare il backup automatico per consentire a Bigtable di creare backup giornalieri. Puoi anche creare una copia di un backup.
Prima di leggere questa pagina, dovresti acquisire familiarità con le sezioni Panoramica di Bigtable e Gestisci tabelle.
Funzionalità
- Completamente integrato: i backup sono gestiti interamente dal servizio Bigtable, senza bisogno di importazione o esportazione.
- incrementale: un backup condivide lo spazio di archiviazione fisico con la tabella di origine e altri backup della tabella.
- Convenienza: l'utilizzo dei backup di Bigtable ti consente di evitare i costi associati all'esportazione, all'archiviazione e all'importazione dei dati tramite altri servizi.
- Scadenza automatica: ogni backup ha una data di scadenza definita dall'utente che può essere fino a 90 giorni dopo la sua creazione. 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 cui è stato creato il backup.
- Backup automatico: abilita il backup automatico per consentire a Bigtable di creare backup giornalieri.
Casi d'uso
I backup sono utili per i seguenti casi d'uso:
- Continuità aziendale
- Conformità normativa
- Test e sviluppo
- Ripristino di emergenza
Considera i seguenti scenari di ripristino di emergenza:
| Obiettivo | Strategia di backup | Strategia di ripristino |
|---|---|---|
| Proteggiti dagli errori umani: vuoi avere sempre a disposizione un backup recente dei tuoi dati in caso di eliminazione accidentale o danneggiamento. | Determina la pianificazione della creazione dei backup adatta alle tue esigenze aziendali, ad esempio ogni giorno. Facoltativamente, puoi creare copie periodiche dei backup e archiviarle in un progetto o in una regione diversi per aumentare l'isolamento e la protezione. Per una protezione ancora maggiore, archivia le copie di backup in un progetto o in un'istanza con autorizzazioni di accesso limitato. | Ripristina una nuova tabella dal backup o dalla copia, quindi reindirizza le richieste alla nuova tabella. |
| Non disponibilità zona: devi assicurarti che, nell'improbabile eventualità che una zona Google Cloud non sia disponibile, i tuoi dati siano ancora disponibili. | Crea backup regolarmente, ad esempio ogni giorno. Quindi, 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 il cluster di gestione non è disponibile, esegui il ripristino dalla copia di backup remoto a una nuova tabella, quindi reindirizza le richieste alla nuova tabella. |
| Danneggiamento dei dati : utilizza un backup per recuperare alcuni dati di una tabella, ad esempio quando parte della tabella di origine si è danneggiata. | Crea periodicamente backup dei tuoi dati. | Esegui il ripristino dal backup in una nuova tabella nella nuova istanza. Quindi scrivi un'applicazione utilizzando una libreria client Bigtable o Dataflow che legga dalla nuova tabella e poi scrive di nuovo i dati nella tabella di origine. Dopo aver copiato i dati nella tabella originale, elimina la nuova tabella. |
Utilizzo dei backup di Bigtable
Le seguenti azioni sono disponibili per i backup di Bigtable. In tutti i casi, il progetto, l'istanza e il cluster di destinazione devono già esistere. Non puoi creare queste risorse come parte di un'operazione di backup. Non puoi creare una copia di una copia di backup.
| Action (Azione) | Opzioni di destinazione |
|---|---|
| Crea backup |
|
| Ripristina da un backup in una nuova tabella |
|
| Copiare un backup |
|
Consulta Gestire i backup per le istruzioni dettagliate su queste azioni e su operazioni come l'aggiornamento e l'eliminazione dei backup.
Utilizza quanto segue per lavorare con i backup di Bigtable:
- Nella console Google Cloud
- Google Cloud CLI
- Le librerie client di Cloud Bigtable
Puoi anche accedere direttamente all'API Cloud Bigtable Admin, ma ti consigliamo vivamente di farlo solo se non puoi utilizzare una libreria client di Cloud Bigtable che effettua chiamate di backup all'API.
Come funzionano i backup di Bigtable
La creazione di un backup richiede di comprendere l'archiviazione e la conservazione del backup in Bigtable.
Spazio di archiviazione dei backup
Puoi creare un backup della tabella manualmente oppure puoi abilitare il backup automatico per consentire a Bigtable di eseguire backup giornalieri. Un backup della tabella viene archiviato in un cluster in un'istanza. In caso di backup manuali, il backup della tabella viene archiviato in un cluster nell'istanza selezionata. Quando è abilitato il backup automatico, viene archiviato un backup della tabella su ciascun cluster nell'istanza.
Un backup di una tabella include tutti i dati contenuti nella tabella al momento della creazione del backup, nel cluster in cui viene creato il backup. Un backup non è mai superiore alle dimensioni della tabella di origine al momento della creazione del backup.
I backup di Bigtable sono incrementali. La quantità di spazio di archiviazione utilizzata da un backup dipende dalle dimensioni della tabella e dalla misura in cui può condividere lo spazio di archiviazione dei dati non modificati con la tabella originale o altri backup della stessa tabella. Per questo motivo, la dimensione di un backup dipende dalla quantità di divergenza dei dati rispetto al backup precedente.
Puoi creare fino a 150 backup per tabella per ogni cluster.
Puoi eliminare una tabella che ha un backup. Per proteggere i tuoi backup, non puoi eliminare un cluster che contiene un backup e non puoi eliminare un'istanza con 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ù. L'archiviazione dei backup non conta ai fini del limite di archiviazione dei nodi per un progetto.
I dati nelle copie di backup sono criptati.
Conservazione
Puoi specificare un periodo di conservazione di massimo 90 giorni per un backup. Se crei una copia di un backup, il periodo di conservazione massimo per la copia è di 30 giorni dal momento della creazione della copia.
Per le tabelle in cui è abilitato il backup automatico, il periodo di conservazione predefinito è di 3 giorni. Puoi modificare il periodo di conservazione di un backup fino a 90 giorni dalla data di creazione del backup.
Archiviazione post-ripristino
Il costo di archiviazione per una nuova tabella ripristinata da un backup è lo stesso di qualsiasi tabella.
Una tabella ripristinata da un backup potrebbe non consumare la stessa quantità di spazio di archiviazione della tabella originale e le dimensioni potrebbero diminuire dopo il ripristino. La differenza delle dimensioni dipende da quanto è recente la compattazione sul cluster di origine e su quello di destinazione.
Poiché la compattazione avviene su base continuativa, è possibile che venga eseguita non appena viene creata la tabella. Tuttavia, il processo di compattazione può richiedere fino a una settimana.
Una nuova tabella ripristinata da un backup non eredita i criteri 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 maggiori informazioni, consulta Configurare la garbage collection.
Costi
Quando si lavora con i backup, vengono applicati i costi di rete standard. Non ti viene addebitato alcun costo per le operazioni di backup, inclusi la creazione, la copia o il ripristino da un backup.
Costi di archiviazione
Per archiviare un backup o una copia di un backup, ti viene addebitata la tariffa di archiviazione di backup standard per la regione in cui si trova il cluster che contiene la copia di backup o di backup.
Un backup è una copia logica completa di una tabella. Bigtable ottimizza in background l'uso dello spazio di archiviazione dei backup. Questa ottimizzazione significa che un backup è incrementale: condivide l'archiviazione fisica con la tabella originale o con altri backup della tabella, se possibile. A causa delle ottimizzazioni dello spazio di archiviazione integrate di Bigtable, il costo per archiviare un backup o una copia di un backup potrebbe a volte essere inferiore 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 più elevati perché i backup vengono creati quotidianamente su ogni cluster.
Costi di 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 viene addebitato alcun costo 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 viene addebitato un costo di replica una tantum per i dati da copiare in tutti i cluster dell'istanza.
Se ripristini un'istanza diversa da quella in cui è stato creato il backup e l'istanza di backup e l'istanza di destinazione non hanno almeno un cluster nella stessa regione, ti viene 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 alla versione principale della chiave CMEK del cluster nel momento in cui viene eseguito. Una volta creato il backup, la relativa chiave e versione della chiave non possono essere modificate, anche se la chiave KMS viene ruotata.
Quando esegui il ripristino da un backup, la versione della chiave a cui è bloccato il backup deve essere abilitata affinché il processo di decriptazione del backup vada a buon fine. La nuova tabella è protetta con la versione primaria più recente della chiave CMEK per ogni cluster nell'istanza di destinazione. Se vuoi eseguire il ripristino da un backup protetto da CMEK a un'altra istanza, anche l'istanza di destinazione deve essere protetta con CMEK, ma non deve avere la stessa configurazione CMEK dell'istanza di origine.
Considerazioni sulla replica
Questa sezione descrive concetti aggiuntivi da comprendere per 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. Per le tabelle in cui è abilitato il backup automatico, viene eseguito un backup giornaliero su ogni cluster nell'istanza.
Non è necessario interrompere la scrittura sul cluster che contiene il backup, ma dovresti comprendere come vengono gestite le scritture replicate nel cluster.
Un backup è una copia della tabella nel suo stato nel cluster in cui è archiviato il backup, al momento della creazione del backup. I dati delle tabelle 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:
- È possibile che venga inviata una scrittura a una sezione della tabella già copiata dal backup.
- 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 un timestamp precedente all'ora del backup non siano incluse nel backup. Questo vale anche per i backup creati quando è abilitato il backup automatico. I backup di un'istanza non sono copie esatte l'uno dell'altro, perché i tempi di backup possono variare da cluster a cluster.
Se questa incoerenza non è accettabile per i tuoi requisiti aziendali, puoi utilizzare un token di coerenza con le richieste di scrittura per assicurarti che tutte le operazioni di scrittura replicate siano incluse in un backup.
Replica e ripristino
Quando ripristini un backup in una nuova tabella, la replica da e verso gli altri cluster nell'istanza viene avviata immediatamente dopo il completamento dell'operazione di ripristino sul cluster di destinazione.
Prestazioni
Durante la creazione dei backup, segui le best practice riportate di seguito per assicurarti che le prestazioni rimangano ottimali.
Prestazioni durante il backup
La creazione di un backup di solito richiede meno di un minuto, ma può richiedere fino a un'ora. In circostanze normali, la creazione del backup non influisce sulle prestazioni della pubblicazione.
Per prestazioni ottimali, non creare un backup di una singola tabella più di una volta ogni cinque minuti. Creare backup con maggiore frequenza può portare a un aumento osservabile della latenza di pubblicazione.
Prestazioni durante il ripristino
Il ripristino da un backup a 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 la route più efficiente per copiare i dati.
Se esegui il ripristino in un'istanza diversa da 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 di quello 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 di lettura più elevata, anche dopo il completamento di un ripristino, mentre la tabella è ottimizzata. Puoi controllare lo stato in qualsiasi momento durante l'operazione di ripristino per vedere se l'ottimizzazione è ancora in corso.
Se esegui il ripristino in un'istanza diversa da cui è stato creato il backup, l'istanza di destinazione può utilizzare lo spazio di archiviazione HDD o SSD. Non è necessario usare lo stesso tipo di archiviazione dell'istanza di origine.
Controllo dell'accesso
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 il 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 nell'istanza e nel progetto 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 stai eseguendo il ripristino.
| Action (Azione) | Autorizzazione IAM richiesta |
|---|---|
| Crea backup | bigtable.tables.readRows, bigtable.backups.create |
| Ottieni 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 |
| Ripristina da un backup in una nuova tabella | bigtable.tables.create, bigtable.backups.restore |
| Ottieni un'operazione | bigtable.instances.get |
| Elenca operazioni | bigtable.instances.get |
Best practice
Prima di creare una strategia di backup, è necessario osservare le seguenti best practice.
Creazione dei backup in corso...
- 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 considerato i seguenti fattori:
- Costo. Un cluster della tua istanza potrebbe trovarsi in una regione con costi inferiori rispetto agli altri.
- Vicinanza al server delle applicazioni. Ti consigliamo di archiviare il backup il più vicino possibile all'applicazione di pubblicazione.
- Utilizzo dello spazio di archiviazione. Hai bisogno di spazio di archiviazione a sufficienza per conservare i backup. A seconda del carico di lavoro, potresti avere cluster di dimensioni diverse o con utilizzo del disco diversi. Ciò può influire sul cluster che scegli.
- Per 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 richieste di scrittura.
Ripristino dai backup
- Pianifica in anticipo il nome da assegnare alla nuova tabella se devi eseguire il ripristino da un backup. L'importante è essere preparati in anticipo in modo da non dover decidere quando affrontare un problema.
- Se stai ripristinando una tabella per un motivo diverso dall'eliminazione accidentale, assicurati che tutte le operazioni di lettura e scrittura vengano trasferite alla nuova tabella prima di eliminare la tabella originale.
- Se prevedi di eseguire il ripristino in un'istanza diversa, crea l'istanza di destinazione prima di avviare l'operazione di ripristino del backup.
Quote e limiti
Le richieste di backup e ripristino e l'archiviazione di backup sono soggette a quote e limiti di Bigtable.
Limitazioni
Le seguenti limitazioni si applicano ai backup di Bigtable:
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 una singola operazione.
- Non puoi esportare, copiare o spostare un backup di 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 per altri servizi Google.
Ripristino
- Non puoi eseguire il ripristino da un backup a una tabella esistente.
- Puoi ripristinare solo 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 va a buon fine.
- Se esegui il ripristino da un backup a una tabella in un cluster SSD e poi elimini la tabella appena ripristinata, il completamento dell'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 entro 24 ore dalla scadenza.
- 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.