Conservazione dei dati con viaggi nel tempo e sicurezza
Questo documento descrive i periodi di conservazione dei dati relativi ai viaggi nel tempo e ai problemi di sicurezza per e dei set di dati. Durante il viaggio cronologico e i periodi di sicurezza, i dati che hai modificato o eliminato in qualsiasi tabella nel set di dati continua a essere archiviato nel caso devi recuperarlo.
Viaggio nel tempo
Puoi accedere ai dati da qualsiasi punto della finestra di spostamento cronologico, copre gli ultimi sette giorni per impostazione predefinita. Il viaggio nel tempo ti consente di eseguire query sui dati aggiornati o eliminati, ripristinare una tabella o un set di dati eliminato o ripristinare una tabella scaduta.
Configurare la finestra di spostamento cronologico
Puoi impostare la durata della finestra di spostamento cronologico da un minimo di due giorni per un massimo di sette giorni. Il valore predefinito è 7 giorni. Sei tu che imposti il viaggio cronologico a livello del set di dati, che verrà applicata a tutte le tabelle all'interno del del set di dati. È possibile configurare anche un valore predefinito a livello di progetto.
Puoi configurare la finestra di viaggio nel tempo in modo che sia più lunga nei casi in cui è importante avere più tempo per recuperare i dati aggiornati o eliminati e più breve se non è necessario. L'utilizzo di una finestra di spostamento cronologico consente Risparmiare sui costi di archiviazione grazie alla fatturazione modello. Questi risparmi non si applicano quando si utilizza il modello di fatturazione dello spazio di archiviazione logico.
Per ulteriori informazioni sulle modalità di di fatturazione incide sui costi. Vedi Fatturazione.
In che modo la finestra di spostamento cronologico influisce sul recupero di tabelle e set di dati
Una tabella o un set di dati eliminati utilizza la durata della finestra di viaggio nel tempo in vigore al momento dell'eliminazione.
Ad esempio, se la tua finestra di spostamento cronologico ha una durata di due giorni e poi aumentare la durata a sette giorni, le tabelle eliminate prima della modifica sono ancora recuperabili solo per due giorni. Analogamente, se hai una finestra di viaggio nel tempo di cinque giorni e la riduci a tre giorni, tutte le tabelle eliminate prima della modifica sono ancora recuperabili per cinque giorni.
Poiché le finestre di spostamento cronologico sono impostate a livello di set di dati, non puoi modificare finestra di spostamento cronologico di un set di dati eliminato fino all'annullamento dell'eliminazione.
Se riduci la durata della finestra di spostamento cronologico, elimini una tabella e poi che hai bisogno di un periodo di recupero più lungo per i dati, puoi Creare uno snapshot della tabella da un momento precedente all'eliminazione della tabella. Devi farlo finché la tabella eliminata è ancora recuperabile. Per ulteriori informazioni, vedi Crea uno snapshot della tabella utilizzando lo spostamento cronologico.
Specifica una finestra di spostamento cronologico
Puoi utilizzare la console Google Cloud, lo strumento a riga di comando bq o l'API BigQuery per specificare la finestra di viaggio nel tempo per un set di dati.
Per istruzioni su come specificare la finestra di spostamento cronologico per un nuovo set di dati, consulta Creare set di dati.
Per istruzioni su come aggiornare la finestra di spostamento cronologico per un account esistente del set di dati, consulta Aggiornare le finestre di spostamento cronologico.
Se il timestamp specifica un'ora esterna alla finestra di spostamento cronologico oppure prima della creazione della tabella, la query non riesce e restituisce un errore come seguenti:
TableID
was created at time which is before its allowed time travel intervaltimestamp
. Creation time:timestamp
Viaggio nel tempo e accesso a livello di riga
Se una tabella ha o ha avuto criteri di accesso a livello di riga, solo un amministratore della tabella può accedere ai dati storici della tabella.
Le seguenti Identity and Access Management (IAM) l'autorizzazione è obbligatoria:
Autorizzazione | Risorsa |
---|---|
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions
|
La tabella di cui si accede ai dati storici |
Il seguente ruolo BigQuery fornisce l'autorizzazione richiesta:
Role | Risorsa |
---|---|
roles/bigquery.admin
|
La tabella a cui si accede per i dati storici |
Autorizzazione bigquery.rowAccessPolicies.overrideTimeTravelRestrictions
non possono essere aggiunte a un ruolo personalizzato.
Esegui questo comando per ottenere il tempo di epoca Unix equivalente:
date -d '2023-08-04 16:00:34.456789Z' +%s000
Sostituisci il timestamp UNIX
1691164834000
ricevuto dal comando precedente nello strumento a riga di comando bq. Esegui questo comando per ripristinare una copia dell'elemento eliminato tabelladeletedTableID
in un'altra tabellarestoredTable
, all'interno della stessa set di datimyDatasetID
:bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable
A prova di errore
BigQuery offre un periodo di sicurezza. Durante il periodo di sicurezza, i dati eliminati vengono conservati automaticamente per altri sette giorni dopo la finestra di viaggio nel tempo, in modo che siano disponibili per il recupero di emergenza. Dati sia recuperabile a livello di tabella. I dati di una tabella vengono recuperati dal punto nel tempo rappresentato dal timestamp della data di eliminazione della tabella. Il periodo di sicurezza non è configurabile.
Non puoi eseguire query o recuperare direttamente i dati nello spazio di archiviazione fail-safe. Per recuperare i dati dall'archiviazione non sicura, contatta l'assistenza clienti Google Cloud.
Fatturazione
Se imposti modello di fatturazione dello spazio di archiviazione per utilizzare i byte fisici, i costi di archiviazione totali che ti vengono fatturati includono byte utilizzati per i viaggi nel tempo e per l'archiviazione in sicurezza. Lo spazio di archiviazione per Time-Travel e Fail-Safe viene addebitato alla tariffa dello spazio di archiviazione fisico attivo. Puoi configurare la finestra di spostamento cronologico per bilanciare i costi di archiviazione in base alle tue esigenze di conservazione dei dati.
Se imposti il modello di fatturazione dello spazio di archiviazione per l'utilizzo di byte logici, lo spazio di archiviazione totale che i costi fatturati non includono i byte utilizzati per i viaggi nel tempo e archiviazione sicura.
La tabella seguente mostra un confronto dei costi di archiviazione fisica e logica:
Modello di fatturazione | Per cosa paghi? |
---|---|
Archiviazione fisica (compressa) |
|
Archiviazione logica (non compressa) (impostazione predefinita) |
|
Se utilizzi lo spazio di archiviazione fisico, puoi vedere i byte utilizzati dallo spostamento cronologico e dal fail-safe esaminando le colonne TIME_TRAVEL_PHYSICAL_BYTES
e FAIL_SAFE_PHYSICAL_BYTES
nelle visualizzazioni TABLE_STORAGE
e TABLE_STORAGE_BY_ORGANIZATION
. Per un esempio di come utilizzare una di queste visualizzazioni per stimare i costi,
vedi
Prevedere la fatturazione dello spazio di archiviazione.
Si applicano costi di archiviazione per i viaggi nel tempo e per i casi di sicurezza ma ti vengono addebitati dei costi solo se le tariffe per l'archiviazione dei dati non si applicano altrove in in BigQuery. Si applicano i seguenti dettagli:
- Quando viene creata una tabella, non è previsto alcun costo per lo spazio di archiviazione di Time-Travel o Fail-Safe.
- Se i dati vengono modificati o eliminati, ti viene addebitato il costo per l'archiviazione dati modificati o eliminati salvati dal viaggio cronologico durante la finestra di spostamento cronologico e il periodo di sicurezza. È simile ai prezzi dello spazio di archiviazione per gli snapshot e i cloni delle tabelle.
Esempio di conservazione dei dati
La tabella seguente mostra come si spostano i dati eliminati o modificati di conservazione dello spazio di archiviazione. Questo esempio mostra una situazione in cui il numero totale lo spazio di archiviazione è di 200 GiB e 50 GiB vengono eliminati con un viaggio nel tempo finestra di sette giorni:
Giorno 0 | Giorno 1 | Giorno 2 | Giorno 3 | Giorno 4 | Giorno 5 | Giorno 6 | Giorno 7 | Giorno 8 | Giorno 9 | Giorno 10 | Giorno 11 | Giorno 12 | Giorno 13 | Giorno 14 | Giorno 15 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Archiviazione attiva | 200 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 | 150 |
Archiviazione dei viaggi nel tempo | 50 | 50 | 50 | 50 | 50 | 50 | 50 | |||||||||
Archiviazione a prova di errore | 50 | 50 | 50 | 50 | 50 | 50 | 50 |
L'eliminazione dei dati dallo spazio di archiviazione fisico a lungo termine funziona allo stesso modo.
Limitazioni
- Lo spostamento cronologico consente di accedere ai dati storici solo per la durata del finestra di spostamento cronologico. Per conservare i dati della tabella per scopi non di emergenza per più tempo rispetto alla finestra di viaggio nel tempo, utilizza gli snapshot delle tabelle.
- Se una tabella ha o ha avuto in precedenza criteri di accesso a livello di riga, il movimento nel tempo può essere utilizzato solo dagli amministratori della tabella. Per ulteriori informazioni, vedi Viaggio nel tempo e accesso a livello di riga.
- Il viaggio nel tempo non ripristina i metadati delle tabelle.
- I viaggi cronologici non sono supportati nei seguenti tipi di tabelle:
- Tabelle esterne
- Tabelle dei risultati delle query memorizzate nella cache temporanee
- Tabelle delle sessioni temporanee
- Tabelle multiistruzione temporanee
- Tabelle elencate in Set di dati esterni.
Passaggi successivi
- Scopri come eseguire query e recuperare i dati relativi al viaggio nel tempo.
- Scopri di più sugli snapshot delle tabelle.