Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

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 i seguenti tipi di backup, che dipendono dai requisiti di ripristino di emergenza (RE) e dal tipo 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 saperne di più, consulta Prestazioni 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 saperne di più, consulta Hot backup.

Puoi creare backup nei seguenti modi:

Abilita il backup automatico per consentire a Bigtable di creare backup giornalieri per te.
Crea un backup on demand utilizzando la console Google Cloud , gcloud CLI o una libreria client di Bigtable.
Crea una copia di un backup.

Prima di leggere questa pagina, consulta la panoramica di Bigtable e Gestisci le tabelle.

Funzionalità

I backup di Bigtable offrono le seguenti caratteristiche e vantaggi:

Completamente integrato: Bigtable gestisce i backup senza la necessità di importare o esportare i dati.
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 utilizzando altri servizi.
Scadenza automatica: ogni backup ha un periodo di conservazione definito dall'utente. Per saperne di più, consulta la sezione Conservazione di questo documento.
Opzioni di ripristino flessibili: esegui il ripristino da un backup in una tabella in un'istanza diversa da quella in cui è stato creato il backup.
Backup automatico: abilita i backup automatici per consentire a Bigtable di creare backup giornalieri.
Hot backup: gli hot backup pronti per la produzione ti consentono di pianificare il ripristino di emergenza.

Casi d'uso

I backup sono utili per i seguenti casi d'uso:

Continuità aziendale
Conformità alle norme
Test e sviluppo
Disaster recovery

Considera i seguenti scenari di ripristino di emergenza:

Obiettivo	Strategia di backup	Strategia di ripristino
Protezione dagli errori umani: vuoi avere sempre a portata di mano un backup recente dei tuoi dati in caso di eliminazione o danneggiamento accidentali.	Determina la pianificazione della creazione dei backup più adatta alle tue esigenze aziendali, ad esempio giornaliera. Facoltativamente, crea copie periodiche dei backup e archiviale in un progetto o una regione diversi per un maggiore isolamento e una maggiore protezione. Per una protezione ancora maggiore, archivia le copie di backup in un progetto o un'istanza con autorizzazioni di accesso limitate.	Esegui il ripristino in una nuova tabella dal backup o dalla copia, quindi indirizza nuovamente le richieste alla nuova tabella.
Non disponibilità della zona: devi assicurarti che, nell'improbabile caso in cui una zona Google Cloud non sia disponibile, i tuoi dati siano comunque disponibili.	Abilita il backup automatico per consentire a Bigtable di creare un backup giornaliero su ogni cluster nell'istanza. In alternativa, crea backup su base regolare 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 diversi).	Se la zona in cui si trova il cluster di distribuzione non è disponibile, esegui il ripristino dalla copia di backup remota in una nuova tabella, quindi indirizza nuovamente 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 è stata danneggiata.	Abilita la replica e il backup automatico per creare backup giornalieri in più regioni, in modo che, se una tabella viene danneggiata in un cluster, hai uno o più backup che non condividono lo spazio di archiviazione nel cluster danneggiato.	Esegui il ripristino dal backup in una nuova tabella nel nuovo cluster o nella nuova istanza. Quindi, scrivi un'applicazione utilizzando una libreria client di Bigtable o Dataflow che legge dalla nuova tabella e poi scrive i dati nella tabella di origine. Dopo aver copiato i dati nella tabella originale, elimina la nuova tabella.
Ripristino rapido: ripristina rapidamente i livelli di prestazioni di produzione completi, riducendo al minimo i tempi di inattività.	Configura i backup automatici per creare hot backup giornalieri o crea hot backup on demand per assicurarti di avere sempre un hot backup recente della tabella.	Esegui il ripristino in una nuova tabella dall'hot backup, quindi reindirizza le richieste alla nuova tabella.

Hot backup

Un hot backup è un backup pronto per la produzione ottimizzato per un ripristino rapido, con una latenza inferiore durante la lettura dalla nuova tabella poco dopo il ripristino. Il ripristino delle prestazioni di produzione da un hot backup è più rapido rispetto al ripristino da un backup standard.

Puoi creare un hot backup on demand ogni volta che ne hai bisogno o configurare una policy di backup automatico per creare hot backup giornalieri:

Hot backup on demand: l'impostazione di un tempo di transizione da hot a standard è facoltativa. Se non imposti un tempo di transizione, il backup rimane hot fino alla scadenza. Per eseguire automaticamente la transizione del backup a un backup standard, puoi impostare un tempo di transizione di almeno 24 ore dopo l'ora di inizio della creazione del backup. Puoi anche impostare o modificare questo orario in un secondo momento. Per ulteriori informazioni, consulta Crea un hot backup e Modifica un backup o una copia di backup.
Backup automatici hot: è necessario impostare una durata di conservazione hot. Per attivare i backup automatici hot su un'istanza SSD, devi specificare una durata compresa tra 24 ore e 10 giorni, che non superi il periodo di conservazione della policy. Questa impostazione determina per quanto tempo ogni backup giornaliero rimane hot prima di passare automaticamente a un backup standard per il resto del periodo di conservazione. Per saperne di più, consulta Configura i backup automatici hot.

Mantieni l'ultimo backup hot

Per bilanciare il ripristino di emergenza rapido con i costi di archiviazione, puoi mantenere hot solo il backup più recente e archiviare i backup meno recenti come backup standard:

Backup automatici giornalieri: configura una policy di backup automatico con una durata di conservazione di 24 ore o 1 giorno nella console Google Cloud . Poiché Bigtable crea un backup automatico ogni 24 ore, ogni backup giornaliero rimane hot fino alla creazione del backup giornaliero successivo, quindi passa automaticamente a un backup standard per il resto del periodo di conservazione. Per istruzioni, consulta Configura i backup automatici hot.
Backup on demand: quando crei hot backup in base a una pianificazione ricorrente, imposta il tempo di transizione da hot a standard di ogni backup in modo che corrisponda alla pianificazione del successivo hot backup (almeno 24 ore dopo l'ora di inizio della creazione del backup). Quando viene raggiunto questo periodo di tempo, il backup precedente passa automaticamente a un backup standard, mentre il backup più recente rimane hot. Per le istruzioni, consulta Crea un hot backup.

Limitazioni per gli hot backup

Gli hot backup presentano le seguenti limitazioni:

Puoi convertire un hot backup in un backup standard, ma non puoi convertire un backup standard in un hot backup.
Puoi creare hot backup on demand e configurare hot backup automatici solo per le tabelle nelle istanze SSD. Non puoi creare hot backup nelle istanze HDD.
Bigtable non supporta gli hot backup per le tabelle con archiviazione a livelli abilitata. Per saperne di più, consulta la panoramica dell'archiviazione a livelli.
La copia di un hot backup è sempre un backup standard. La copia di backup non ha lo stesso ripristino rapido delle prestazioni a livello di produzione e la pubblicazione a bassa latenza dell'hot backup originale.

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
Non puoi creare una copia di una copia di backup. La copia di un backup è sempre un backup standard, anche se l'origine è un hot backup.
Crea un backup standard	Qualsiasi cluster nella stessa istanza della tabella di origine
Crea un hot backup	Qualsiasi cluster nella stessa istanza della tabella di origine. L'istanza deve utilizzare lo spazio di archiviazione SSD.
Ripristina da un backup standard o hot in una nuova tabella	Qualsiasi istanza Qualsiasi regione Bigtable Qualsiasi progetto
Copia un backup^{1, 2}	Qualsiasi istanza Qualsiasi regione Bigtable Qualsiasi progetto

Consulta Gestisci i backup per istruzioni passo passo su queste azioni e su operazioni come l'aggiornamento e l'eliminazione dei backup.

Per utilizzare i backup di Bigtable, segui questi passaggi:

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 in modo programmatico viene archiviato in un singolo cluster specificato da te. Quando il backup automatico è abilitato, Bigtable archivia un backup su ogni cluster nell'istanza. Nella versione Enterprise Plus, puoi selezionare le località dei cluster in cui è abilitato il backup automatico.

Se il cluster supera i limiti consigliati per l'utilizzo della CPU o dello spazio di archiviazione quando crei un backup, la creazione del backup potrebbe subire ritardi. Per saperne di più, consulta Informazioni sull'utilizzo della CPU e del 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 della tabella di origine al momento della creazione del backup.

I backup di Bigtable sono incrementali. La quantità di spazio di archiviazione utilizzato da un backup 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 rispetto al backup precedente.

Puoi creare fino a 150 copie di backup per tabella per ogni cluster.

Puoi eliminare una tabella di cui è stato eseguito il backup. Per proteggere i backup, non puoi eliminare quanto segue:

Un cluster che contiene uno o più backup. Per eliminare il cluster, devi eliminare i backup o attendere che scadano.
Un cluster configurato come località nella policy di backup automatico di una tabella. Per eliminare il cluster, devi prima aggiornare la policy di backup automatico per rimuovere la località del cluster o disattivare il backup automatico per la tabella.
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ù. Lo spazio di archiviazione dei backup non viene conteggiato ai fini del limite di spazio di archiviazione dei nodi per un progetto.

I dati nei backup sono criptati.

Conservazione

I backup di Bigtable ti consentono di conservare i dati per un periodo di tempo specificato. Puoi configurare il periodo di conservazione per i singoli backup o come parte di una policy di backup automatico:

Il periodo di conservazione inizia dal momento in cui viene creato il backup.
Il periodo di conservazione predefinito per le tabelle con backup automatico abilitato è di sette giorni.
Puoi configurare un periodo di conservazione personalizzato per una policy di backup automatico fino a 90 giorni sia nella versione Enterprise sia nella versione Enterprise Plus. Per i singoli backup on demand o quando aggiorni un periodo di conservazione di un backup esistente, puoi specificare fino a 90 giorni nella versione Enterprise o fino a 365 giorni nella versione Enterprise Plus.
Se crei una copia di un backup, il periodo di conservazione massimo per la copia è di 30 giorni dal momento della creazione della copia.
Quando crei un backup, puoi specificare una data di scadenza anziché un periodo di conservazione. Una data di scadenza è una data e un'ora assolute, mentre un periodo di conservazione specifica una durata. Entrambi i metodi generano una data di scadenza che segue le stesse regole e limitazioni.
La transizione di un hot backup a un backup standard non modifica il periodo di conservazione o la data di scadenza. Per i backup on demand, l'impostazione di un tempo di transizione da hot a standard è facoltativa, mentre i backup automatici hot richiedono una durata di conservazione hot.

Puoi modificare il periodo di conservazione di un backup o di una policy di backup automatico. Per saperne di più, consulta Modifica un backup o una copia di backup e Aggiorna una policy di backup automatico.

Spazio di archiviazione post-ripristino

Il costo di archiviazione di 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 le sue dimensioni potrebbero diminuire dopo il ripristino. La differenza di dimensioni dipende da quanto di recente è stata eseguita la compattazione nel cluster di origine e nel cluster di destinazione.

Poiché la compattazione avviene su base continuativa, è possibile che venga eseguita 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 policy di garbage collection della tabella di origine. Configura le policy di garbage collection nella nuova tabella prima di iniziare a scrivere nuovi dati nella tabella. Per saperne di più, consulta Configura la garbage collection.

Costi

Quando utilizzi i backup, si applicano i costi di rete standard. Non ti vengono addebitati costi per le operazioni di backup, tra cui la creazione, la copia o il ripristino da un backup.

Costi di archiviazione

I costi di archiviazione sono diversi per i backup standard e i backup hot.

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, ovvero condivide lo spazio di archiviazione fisico 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 standard 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 giornalieri vengono creati su ogni cluster. Nella versione Enterprise Plus, puoi ridurre questi costi attivando i backup automatici solo per i cluster in località specifiche.

Costi di archiviazione dei backup hot

Per l'archiviazione di un hot backup, ti viene addebitata la tariffa di archiviazione degli hot backup per la regione in cui si trova il cluster che contiene l'hot backup.

Poiché un hot backup viene archiviato in uno stato pronto, ottimizzato per un ripristino rapido, ti viene addebitato il costo per l'archiviazione dell'intera copia logica della tabella, anziché per le parti incrementali, come avviene con un backup standard.

Quando un hot backup passa a un backup standard, anche quando scade la durata di conservazione hot di un backup automatico hot, ti viene addebitata la tariffa di archiviazione dell'hot backup mentre il backup è hot e la tariffa di archiviazione del backup standard dopo la transizione. Non ti verrà addebitato alcun costo aggiuntivo per la transizione stessa. Per controllare la durata di conservazione configurata per una tabella, consulta Visualizza la policy di backup automatico. Per saperne di più sulle tariffe di archiviazione dei backup, consulta Prezzi.

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 viene addebitato alcun costo per il traffico di rete quando crei una 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 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 in base 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 al momento dell'esecuzione. 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 affinché il processo di decrittografia del backup vada a buon fine. La nuova tabella è protetta con l'ultima versione principale 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 altri concetti da comprendere quando esegui 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 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. Nella versione Enterprise Plus, puoi limitare il backup automatico ai cluster solo in località specifiche.

Non è necessario interrompere la scrittura nel cluster che contiene il backup, ma devi capire in che modo Bigtable gestisce le scritture replicate nel cluster.

Un backup è una copia della tabella nel suo stato sul cluster in cui è archiviato il backup, 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. Questa incertezza è dovuta a due fattori:

Una scrittura potrebbe essere inviata a una sezione della tabella che il backup ha già copiato.
Una scrittura su 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 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é i tempi 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 dell'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 prestazioni ottimali, non creare un backup di una singola tabella più di una volta ogni cinque minuti. La creazione di backup più frequenti può potenzialmente portare a un aumento osservabile della latenza di gestione.

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. Questo è 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, inizialmente potresti riscontrare una latenza di 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 lo spazio di archiviazione HDD o SSD. Non è necessario che utilizzi 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 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 esegui il ripristino.

Azione	Autorizzazione IAM obbligatoria
Crea backup	bigtable.tables.readRows, bigtable.backups.create
Ottieni un backup	bigtable.backups.get
Elenco dei backup	bigtable.backups.list
Elimina un backup	bigtable.backups.delete
Aggiorna un backup	bigtable.backups.update
Copia un backup	bigtable.backups.read, bigtable.backups.create
Ripristina da un backup in una nuova tabella	bigtable.tables.create, bigtable.backups.restore
Recupera un'operazione	bigtable.instances.get
Elenca operazioni	bigtable.instances.get

Best practice

Prima di creare una strategia di backup, tieni presente le seguenti best practice. Per saperne di più 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 considerato i seguenti fattori:
- Costo. Un cluster della tua istanza potrebbe trovarsi in una regione con costi inferiori rispetto agli altri.
- Vicinanza al server dell'applicazione. Potresti voler archiviare il backup il più vicino possibile all'applicazione di gestione.
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 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 prendere decisioni quando si affronta un problema.
Se stai ripristinando una tabella per un motivo diverso dall'eliminazione accidentale, assicurati che tutte le letture e le scritture vengano eseguite sulla 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.
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 dalla creazione prima di eseguire il ripristino da un backup standard. Se hai bisogno di un ripristino più rapido, utilizza un hot backup.

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 di 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 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 di Bigtable e non sono integrati o correlati ai backup di altri servizi Google.
Non puoi creare un backup di una vista.

Ripristino

Non puoi eseguire il ripristino da un backup in una tabella esistente.
Puoi eseguire il ripristino solo in un'istanza già esistente. Bigtable non crea una nuova istanza quando esegue 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, 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.