Panoramica dei backup di Bigtable
Questa pagina fornisce una panoramica dei backup di Bigtable. I contenuti qui presentata è rivolta agli amministratori di Bigtable sviluppatori.
I backup di Bigtable consentono di salvare una copia lo schema e i dati della tabella, per poi ripristinarli dal backup a una nuova tabella in un secondo momento. Puoi creare i backup manualmente o abilitare le funzionalità per consentire a Bigtable di creare backup giornalieri. Puoi anche creare una copia di un backup.
Prima di leggere questa pagina, dovresti conoscere le Panoramica di Bigtable e Gestisci per le tabelle.
Funzionalità
- Completamente integrata: i backup sono gestiti interamente dall'amministratore Servizio Bigtable, che non richiede importazioni o esportazioni.
- Incrementale: un backup condivide lo spazio di archiviazione fisico con la tabella di origine e altri backup della tabella.
- Conveniente: l'utilizzo dei backup di Bigtable ti consente di evitare associati all'esportazione, all'archiviazione e all'importazione dei dati utilizzando altre i servizi di machine learning.
- Scadenza automatica: ogni backup ha una data di scadenza definita dall'utente che possono essere fino a 90 giorni dopo la creazione del backup. Tu puoi archiviare una copia di un backup per un massimo di 30 giorni.
- Opzioni di ripristino flessibili: puoi eseguire il ripristino da un backup in una tabella di un'istanza diversa da quella in cui è stato creato il backup.
- Backup automatico: attiva il backup automatico per consentire Bigtable creano 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 sempre Avere a disposizione un backup recente dei dati in caso di errore l'eliminazione o il danneggiamento. | Determina la pianificazione della creazione dei backup adatta alle tue esigenze aziendali, ad esempio quotidiane. Se vuoi, crea copie periodiche dei i backup e archiviarli in un'altra regione o in un progetto di isolamento e protezione maggiori. Per una protezione ancora maggiore, archivia il backup vengono copiate in un progetto o in un'istanza con autorizzazioni di accesso limitato. | Ripristinare i dati in una nuova tabella dal backup o dalla copia e quindi eseguire nuovamente il routing. richieste alla nuova tabella. |
| Zona non disponibile: verifica che in l'improbabile caso che una zona Google Cloud diventi non disponibile, i dati sono ancora disponibili. | Crea backup regolarmente, ad esempio ogni giorno. Poi, periodicamente crea una copia del backup più recente e archiviala su uno o più in zone diverse (facoltativamente in un'istanza diversa progetto). | Se la zona in cui il cluster di gestione non è disponibile, ripristina dalla copia di backup remota a una nuova tabella, quindi richieste alla nuova tabella. |
| Danneggiamento dei dati : utilizza un backup per il ripristino. alcuni dati di una tabella, ad esempio quando parte della tabella di origine contiene danneggiarsi. | Crea periodicamente backup dei tuoi dati. | Esegui il ripristino dal backup in una nuova tabella nella nuova istanza. Poi scrivere un'applicazione utilizzando una libreria client Bigtable Dataflow che legge dal nuovo e scrive i dati nella tabella di origine. Quando sono stati copiati nella tabella originale, elimina i nuovi . |
Utilizzo dei backup di Bigtable
Le seguenti azioni sono disponibili per i backup di Bigtable. In tutto casi, il progetto, l'istanza e il cluster di destinazione devono già esistere. Tu non sono in grado di creare queste risorse nell'ambito di un'operazione di backup. Stai impossibile creare una copia di una copia di backup.
| Azione | Opzioni di destinazione |
|---|---|
| Crea backup |
|
| Ripristina da un backup in una nuova tabella |
|
| Copiare un backup |
|
Consulta Gestire i backup per istruzioni dettagliate su queste azioni, nonché 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 chiamate di backup all'API.
Come funzionano i backup di Bigtable
Per creare un backup è necessario comprendere lo spazio di archiviazione e la conservazione dei backup Bigtable.
Spazio di archiviazione dei backup
Puoi creare un backup della tabella manualmente oppure puoi abilitare il backup automatico per Bigtable per l'esecuzione di backup giornalieri. Un backup della tabella viene archiviato su un cluster in in esecuzione in un'istanza Compute Engine. In caso di backup manuali, il backup della tabella viene archiviato in un cluster nella selezionata. Quando il backup automatico è abilitato, viene archiviato un backup della tabella su ogni in un cluster Kubernetes.
Il backup di una tabella include tutti i dati contenuti al suo interno è stato creato un backup sul cluster in cui viene creato. Un backup è mai superiore alle dimensioni della tabella di origine al momento in cui viene eseguito il backup è stato creato.
I backup di Bigtable sono incrementali. La quantità di spazio di archiviazione consumata 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, le dimensioni di un backup dipendono dalla quantità di la divergenza dei dati rispetto al backup precedente.
Puoi creare fino a 150 backup per tabella per in un cluster Kubernetes.
Puoi eliminare una tabella che ha un backup. Per proteggere le tue copie di backup, non puoi un cluster che contiene un backup e non puoi eliminare un'istanza ha uno o più backup in qualsiasi cluster.
Un backup esiste ancora dopo il ripristino in una nuova tabella. Puoi eliminare o lasciarla scadere quando non ti serve più. Lo spazio di archiviazione di backup non conta per il 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 è 3 giorni. Puoi modificare il periodo di conservazione per un backup fino a un massimo di 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 .
Una tabella ripristinata da un backup potrebbe non utilizzare la stessa quantità di spazio di archiviazione di della tabella originale e le sue dimensioni potrebbero diminuire dopo il ripristino. Le dimensioni dipende da quando è avvenuta la compattazione sulla di origine e di destinazione.
Poiché la compattazione avviene a rotazione, è possibile che viene eseguito non appena la tabella viene creata. Tuttavia, la compattazione può richiedere fino a settimana prima dell'evento.
Una nuova tabella ripristinata da un backup non eredita la garbage collection i criteri della tabella di origine. Configura i criteri di garbage collection nel nuovo prima di iniziare a scrivere nuovi dati nella tabella. Per ulteriori informazioni, vedi 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, tra cui 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 addebitato il backup standard di archiviazione più elevata per la regione in cui il cluster contiene la copia di backup o di backup è presente.
Un backup è una copia logica completa di una tabella. Dietro le quinte, Bigtable ottimizza l'utilizzo dello spazio di archiviazione di backup. Questa ottimizzazione significa che un backup è incrementale: condivide lo spazio di archiviazione fisico con o con altri backup della tabella, se possibile. A causa di le ottimizzazioni dello spazio di archiviazione integrate di Bigtable, il costo un backup o una copia di un backup può talvolta essere inferiore al costo di un copia fisica del backup della tabella.
Nelle istanze replicate in cui è abilitato il backup automatico, i costi di archiviazione potrebbero essere più elevati poiché su ogni cluster vengono creati backup giornalieri.
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 cluster di destinazione. Non ti viene addebitato alcun costo per il traffico di rete quando crei un 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 di replica. Se la nuova tabella si trova in un'istanza che utilizza la replica, viene addebitato un costo di replica una tantum affinché i dati in tutti i cluster nell'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 uno nella stessa regione, ti viene addebitato un costo una tantum per i dati iniziali copiarli nel cluster di destinazione alle tariffe di rete standard.
CMEK
Quando crei un backup in un cluster protetto da un sistema gestito dal cliente chiave di crittografia (CMEK), il backup è bloccato sulla della chiave CMEK del cluster nel momento in cui viene utilizzata. Una volta eseguito il backup creata, la relativa chiave e la relativa versione non possono essere modificate, anche se la chiave KMS è ruotato.
Quando esegui il ripristino da un backup, la versione della chiave a cui è bloccato il backup deve essere abilitato affinché il processo di decriptazione del backup vada a buon fine. Il nuovo sia 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 su un'altra istanza, l'istanza di destinazione deve essere È anche protetta da CMEK, ma non ha bisogno della stessa configurazione CMEK come istanza di origine.
Considerazioni sulla replica
Questa sezione descrive concetti aggiuntivi da comprendere per il backup Ripristinare 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 nel cluster in cui vuoi creare e archiviare il backup. Per le tabelle con è abilitato il backup automatico, viene eseguito un backup giornaliero su ogni cluster in esecuzione in un'istanza Compute Engine.
Non c'è bisogno di fermarsi scrivere nel cluster che contiene il backup, ma dovresti sapere come e le scritture replicate nel cluster.
Un backup è una copia della tabella nel suo stato nel cluster in cui viene eseguito archiviati nel momento in cui viene creato il backup. Dati della tabella non ancora replicato da un altro cluster nell'istanza non è incluso nel backup.
Ogni backup ha un'ora di inizio e di fine. Scritture inviate al cluster poco prima o durante l'operazione di backup potrebbe non essere inclusa nella backup. Due fattori contribuiscono a questa incertezza:
- Potrebbe essere inviata una scrittura a una sezione della tabella che il backup ha già copiato.
- Una scrittura in un altro cluster potrebbe non essere stata replicata nel cluster contiene il backup.
In altre parole, è possibile che alcune scrivano con un timestamp prima data e ora del backup potrebbero non essere 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 poiché i tempi del backup possono variare da cluster a cluster.
Se questa incoerenza non è accettabile per i requisiti della tua attività, puoi utilizzare un metodo di coerenza il token con le tue richieste di scrittura per garantire che tutti sono incluse in un backup.
Replica e ripristino
Quando ripristini un backup in una nuova tabella, la replica da e verso l'altra di cluster nell'istanza viene avviato subito dopo l'esecuzione dell'operazione di ripristino completata sul cluster di destinazione.
Prestazioni
Durante la creazione dei backup, segui le best practice riportate di seguito per assicurarti il rendimento rimane ottimale.
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 sulla pubblicazione. delle prestazioni.
Per prestazioni ottimali, non creare un backup di una singola tabella per più di una volta ogni cinque minuti. Creare backup con maggiore frequenza può generare 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 alcune minuti. Nelle istanze replicate, il ripristino richiede più tempo perché i dati sono da copiare in tutti i cluster. Bigtable sceglie sempre un percorso 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. Questo è soprattutto se l'istanza di destinazione non ha un cluster nello stesso come il 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 notare che latenza di lettura, anche dopo il completamento di un ripristino, mentre la tabella è ottimizzata. Puoi controllare lo stato in qualsiasi momento durante il ripristino. per vedere se l'ottimizzazione è ancora in corso.
Se esegui il ripristino in un'istanza diversa da cui è stato creato il backup, 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 al backup e al ripristino operations. Le autorizzazioni di backup sono a livello di istanza e si applicano a tutte i backup nell'istanza.
L'account che utilizzi per creare il backup di una tabella deve disporre dell'autorizzazione per legge la tabella e crea backup nell'istanza in cui si trova (l'istanza di origine).
L'account che utilizzi per copiare un backup deve disporre dell'autorizzazione per leggere di origine e di creare un backup nell'istanza di destinazione progetto.
L'account che utilizzi per ripristinare una nuova tabella da un backup deve avere per creare una tabella nell'istanza in cui stai eseguendo il ripristino.
| 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 da utilizzare
archiviare il backup dopo aver considerato i seguenti fattori:
- Costo. Un cluster della tua istanza potrebbe avere un costo inferiore regione rispetto agli altri.
- Vicinanza al server delle applicazioni. Potresti voler archiviare il più vicino possibile all'applicazione di gestione.
- Utilizzo dello spazio di archiviazione. Hai bisogno di spazio di archiviazione sufficiente i backup man mano che si accumulano. A seconda del carico di lavoro, potresti con cluster di dimensioni diverse o con di utilizzo del disco. 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 token di coerenza con le tue richieste di scrittura.
Ripristino dai backup
- Pianifica in anticipo il nome da assegnare alla nuova tabella se devi eseguire il ripristino da una backup. È fondamentale prepararsi per tempo in modo da non devi decidere quando hai a che fare con un problema.
- Se stai ripristinando una tabella per un motivo diverso da quello accidentale l'eliminazione, assicurati che tutte le operazioni di lettura e scrittura vengano indirizzate alla nuova tabella prima elimini la tabella originale.
- Se prevedi di eseguire il ripristino in un'altra istanza, crea l'istanza di destinazione prima di avviare la dell'operazione di ripristino del backup.
Quote e limiti
Le richieste di backup e ripristino e l'archiviazione di backup sono soggetti a Quote e limiti 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 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 su un altro come Cloud Storage,
- I backup di Bigtable contengono solo dati Bigtable Non 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 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 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, la destinazione anche un cluster deve essere protetto da CMEK.
Passaggi successivi
- Scopri come eseguire il backup e il ripristino delle tabelle.
- Scopri come attivare il backup automatico.