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 ti 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 (DR) e dal tipo di archiviazione (HDD o SSD) utilizzato dal tuo cluster Bigtable.
- I backup standard sono ottimizzati per la conservazione a lungo termine. Quando ripristini da un backup standard a un cluster SSD, l'operazione di ripristino richiede un'ulteriore ottimizzazione da parte di Bigtable per a livello di produzione. Per ulteriori informazioni, vedi Prestazioni durante il ripristino
- I backup a caldo offrono il ripristino più efficiente a livello di produzione e gestione a bassa latenza. Per ulteriori informazioni, consulta Hot backups
Puoi creare backup nei seguenti modi:
- Attiva il backup automatico per consentire a Bigtable di creare backup giornalieri per tuo conto
- 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 conoscere la panoramica di Bigtable e Gestire le tabelle.
Funzionalità
- Completamente integrato: 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.
- Economico: l'utilizzo dei backup di Bigtable ti consente di evitare i costi associati all'esportazione, allo stoccaggio 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. 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 a una tabella di un'istanza diversa da quella in cui è stato creato il backup.
- Backup automatico: abilita il backup automatico per consentire a Bigtable per creare backup giornalieri.
- Backup attivi: pianifica il ripristino di emergenza con backup a caldo pronti per la produzione.
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 |
|---|---|---|
| Protezione da errori umani: è consigliabile avere sempre a disposizione un backup recente dei dati in caso di eliminazione o danneggiamento accidentale. | Determina la pianificazione della creazione dei backup adatta alle tue esigenze aziendali, ad esempio quotidiane. Se vuoi, crea copie periodiche dei backup e archiviale in un progetto o una regione diversa per una maggiore isolamento e protezione. Per una protezione ancora maggiore, archivia il backup vengono copiate in un progetto o in un'istanza con autorizzazioni di accesso limitato. | Ripristinare una tabella dal backup o dalla copia e poi eseguire nuovamente il routing richieste alla nuova tabella. |
| Mancata disponibilità della zona: devi assicurarti che, nell'improbabile caso in cui una zona Google Cloud non sia più disponibile, i tuoi dati siano ancora disponibili. | Abilita il backup automatico per consentire a Bigtable di creare un backup giornaliero su ogni cluster dell'istanza. In alternativa, crea i backup su base regolare, poi crea periodicamente una copia del backup più recente e archiviala su uno o più cluster in zone diverse (facoltativo in un'istanza o un progetto diverso). | Se la zona in cui il cluster di gestione non è disponibile, ripristina dalla copia di backup remota a una nuova tabella, quindi reindirizzi 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. | Abilita la replica e il backup automatico per creare backup giornalieri in in più regioni, in modo che se una tabella si danneggia in un cluster, hai uno o più backup che non condividono lo spazio di archiviazione sul in un cluster Kubernetes. | Ripristina dal backup in una nuova tabella nel nuovo cluster o nella nuova istanza. Poi scrivere un'applicazione utilizzando una libreria client Bigtable Dataflow che legge dal nuovo e poi scrive 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 riposo. | Mantieni sempre un backup caldo recente della tabella. | Ripristinalo in una nuova tabella dal backup attivo e ripeti il routing richieste alla nuova tabella. |
Backup a caldo
Un backup caldo è un backup pronto per la produzione ottimizzato per il recupero rapido, con una latenza inferiore durante la lettura dalla nuova tabella poco dopo il ripristino. Il ripristino delle prestazioni di produzione da un backup caldo è più rapido rispetto al ripristino da un backup standard.
Puoi convertire un backup a caldo in un backup standard, ma non puoi un backup standard a un backup a caldo.
Non puoi creare backup a caldo utilizzando il backup automatico e non puoi creare il backup su un cluster HDD.
Utilizzo dei backup di Bigtable
Per i backup di 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 come parte di un'operazione di backup.
|
||
| Azione | Opzioni di destinazione | |
|---|---|---|
| Crea un backup standard |
|
|
| Creare un backup caldo |
|
|
| Ripristino da un backup standard o caldo in una nuova tabella |
|
|
| Copiare un backup1, 2 |
|
|
Consulta Gestire i backup per istruzioni dettagliate su queste azioni, nonché operazioni come l'aggiornamento e l'eliminazione dei backup.
Spazio di archiviazione dei backup
Un backup delle tabelle creato on demand viene archiviato in un unico cluster specificare. Quando il backup automatico è abilitato, viene creato e archiviato un backup su ogni cluster dell'istanza.
Un backup di una tabella include tutti i dati presenti al momento della creazione del backup nel 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 standard sono incrementali. La quantità di spazio di archiviazione di cui viene eseguito il backup consuma dipende dalle dimensioni della tabella e dalla misura in cui può condividere dei dati non modificati con la tabella originale o altri backup tabella. Per questo motivo, le dimensioni di un backup dipendono dalla quantità di dati divergenti dal backup precedente.
Un backup caldo, invece, è una copia completa che consuma la stessa quantità di spazio di archiviazione al momento del backup, indipendentemente dalle modifiche apportate alla tabella di origine. Il backup è considerato hot per via dello spazio di archiviazione ottimizzato, per ripristinare i livelli delle prestazioni di produzione in modo efficiente.
Puoi creare fino a 150 backup per tabella per in un cluster Kubernetes.
Puoi eliminare una tabella di cui esiste un 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 spazio di archiviazione del nodo per un progetto.
I dati nelle copie di 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 della copia è di 30 giorni dalla data di creazione.
Per le tabelle in cui è abilitato il backup automatico, il periodo di conservazione predefinito è tre giorni. Puoi modificare il periodo di conservazione di un backup per conservarlo fino a 90 giorni dopo la 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 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 eseguita 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 i criteri di raccolta dei rifiuti della tabella di origine. Configura i criteri di garbage collection nel nuovo prima di iniziare a scrivere nuovi dati nella tabella. Per ulteriori informazioni, consulta Configurare il garbage collection.
Costi
Quando si utilizza i backup si applicano costi di rete standard. Non ti vengono addebitati costi per le operazioni di backup, tra cui creazione, copia o ripristino da un backup.
Costi di archiviazione
I costi di archiviazione sono diversi per i backup standard e i backup a caldo.
Costi di archiviazione dei backup standard
Per archiviare un backup standard o una copia di un backup, ti viene addebitato il di archiviazione di backup per la regione in cui il cluster contiene in cui si trova la copia di backup o di backup.
Un backup standard è una copia logica completa di una tabella. Dietro le quinte, Bigtable ottimizza l'utilizzo dello spazio di archiviazione di backup standard. Questo dell'ottimizzazione, quando un backup standard è incrementale, condivide archiviazione fisica con la tabella originale o con altri backup della tabella ove 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 al costo di una copia fisica completa del backup della tabella.
Nelle istanze replicate in cui è abilitato il backup automatico, il costo dello spazio di archiviazione potrebbe essere superiore perché ogni giorno viene creato un backup in ogni cluster.
Costi di archiviazione dei backup a caldo
Per archiviare un backup a caldo, ti viene addebitato il costo della tariffa di archiviazione dei backup a caldo per la regione in cui si trova il cluster contenente il backup a caldo.
Poiché un backup a caldo è archiviato nello stato Pronto, ottimizzato per ripristino, ti viene addebitata l'archiviazione dell'intera copia logica anziché per parti incrementali, come accade 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 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 di 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 esegui il ripristino in 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 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 viene 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. La nuova tabella è protetta con la versione principale più recente 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 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 backup automatico abilitato, viene creato un backup giornaliero su ogni cluster in esecuzione in un'istanza Compute Engine.
Non devi interrompere la scrittura sul cluster che contiene il backup, dovrebbe capire in che modo Bigtable gestisce le scritture replicate in un cluster Kubernetes.
Un backup è una copia della tabella nel suo stato sul cluster in cui viene archiviato al momento della creazione. I dati delle tabelle che non sono stati ancora replicati da un altro cluster nell'istanza non sono inclusi 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. A questa incertezza contribuiscono due fattori:
- 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 che contiene il backup.
In altre parole, è possibile che alcune scritture con timestamp precedenti all'ora del backup non siano incluse nel backup.
Se questa incoerenza non è accettabile per i requisiti della tua attività, puoi utilizzare un token di coerenza con le 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'una dell'altra, perché i tempi di backup possono variare da cluster a cluster.
Replica e ripristino
Quando ripristini un backup in una nuova tabella, la replica verso e da altri cluster nell'istanza inizia immediatamente al termine dell'operazione di ripristino sul cluster di destinazione.
Prestazioni
Durante la creazione dei backup, segui le best practice riportate di seguito per assicurarti che il rendimento rimanga ottimale.
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 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. La creazione di backup più di frequente può potenzialmente 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 alcune minuti. Nelle istanze replicate, il ripristino richiede più tempo perché i dati devono essere copiati in tutti i cluster. Bigtable sceglie sempre un percorso 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. Questo accade soprattutto 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, inizialmente potresti riscontrare una latenza in lettura più elevata, anche al termine di un ripristino, mentre la tabella viene 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 alle operazioni di backup e ripristino. Le autorizzazioni di backup sono a livello di istanza e si applicano a tutte i backup nell'istanza.
L'account utilizzato 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 di origine e di creare un backup nell'istanza di destinazione progetto.
L'account utilizzato per ripristinare una nuova tabella da un backup deve avere l'autorizzazione per creare una tabella nell'istanza in cui esegui 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 di 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 memorizzare 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. 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 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. Questo può influire sul cluster che scegli.
- Se devi assicurarti che tutte le scritture replicate siano incluse in un backup quando effettui 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 della nuova tabella se devi eseguire il ripristino da un 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 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'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 lo spazio di archiviazione dei backup sono soggetti alle quote e ai 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ù tabelle in un'unica 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 di Bigtable e non sono integrati o correlati ai backup di altri servizi Google.
Ripristino
- Non puoi eseguire il ripristino da un backup in 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 riesce.
- 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, 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.