Retención de datos con viaje en el tiempo y seguridad ante fallas

En este documento se describe la retención de datos viajes en el tiempo y segura para fallas de las ventanas de conjuntos de datos. Durante los períodos de viaje en el tiempo y seguridad ante fallas, los datos que cambiaste o borraste en cualquier tabla del conjunto de datos se siguen almacenando en caso de que necesites recuperarlos.

Viaje en el tiempo

Puedes acceder a los datos desde cualquier punto dentro del período de viaje en el tiempo, que abarca los últimos siete días de forma predeterminada. El viaje en el tiempo te permite consultar datos actualizados o borrados y restablecer una tabla o un conjunto de datos que se borró o una tabla que venció.

Configura el período de viaje en el tiempo

Puedes configurar la duración del período de viaje en el tiempo, desde un mínimo de dos días hasta un máximo de siete días. El valor predeterminado es siete días. Establece el período de viaje en el tiempo a nivel del conjunto de datos, que luego se aplica a todas las tablas dentro del conjunto de datos. También se puede configurar un predeterminado a nivel de proyecto.

Puedes configurar el período de viaje en el tiempo para que sea más largo en los casos en los que sea importante tener más tiempo para recuperar datos actualizados o borrados y para que sea más corto cuando no sea necesarios. Usar un período de viaje en el tiempo más corto te permite ahorrar en costos de almacenamiento cuando usas el modelo de facturación de almacenamiento físico. Estos ahorros no se aplican cuando se usa el modelo de facturación de almacenamiento lógico.

Para obtener más información sobre cómo el modelo de facturación de almacenamiento afecta el costo, consulta Facturación.

Cómo el período de viaje en el tiempo afecta la recuperación de la tabla y el conjunto de datos

Una tabla o un conjunto de datos borrados usa la duración del período de viaje en el tiempo que estaba vigente en el momento de la eliminación.

Por ejemplo, si tienes una duración de período de dos días y, luego, aumenta la duración a siete días, las tablas borradas antes de ese cambio solo se podrán recuperar durante dos días. Del mismo modo, si tienes una duración de período de cinco días y reduces esa duración a tres días, cualquier tabla que se haya borrado antes del cambio se podrá recuperar durante cinco días.

Debido a que los períodos de viaje en el tiempo se establecen a nivel del conjunto de datos, no puedes cambiar el período de viaje en el tiempo de un conjunto de datos borrado hasta que se recupere.

Si reduces la duración del período de viaje en el tiempo, borra una tabla y, luego, te das cuenta de que necesitas un período más largo de capacidad de recuperación de esos datos, puedes crear una instantánea de la tabla desde un momento anterior a la eliminación de tablas. Debes hacerlo mientras la tabla borrada aún se puede recuperar. Para obtener más información, consulta Crea una instantánea de tabla mediante viajes en el tiempo.

Especifica un período de viaje en el tiempo

Puedes usar la consola de Google Cloud, la herramienta de línea de comandos de bq o la API de BigQuery para especificar el período de tiempo de un conjunto de datos.

A fin de obtener instrucciones para especificar el período de viaje de un conjunto de datos nuevo, consulta Crea conjuntos de datos.

Para obtener instrucciones sobre cómo actualizar el período de viaje actual de un conjunto de datos existente, consulta Actualiza los períodos del viaje en el tiempo.

Si la marca de tiempo especifica un período fuera del período de viaje o antes de que se cree la tabla, la consulta fallará y mostrará un error como el siguiente:

Table ID was created at time which is
before its allowed time travel interval timestamp. Creation
time: timestamp

Viaje en el tiempo y acceso a nivel de fila

Si una tabla tiene o tuvo políticas de acceso a nivel de fila, solo un administrador de tabla puede acceder a los datos históricos de la tabla.

Se necesita el siguiente permiso de Identity and Access Management (IAM):

Permiso Recurso
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions La tabla a cuyos datos históricos se accede

El siguiente rol de BigQuery proporciona el permiso necesario:

Función Recurso
roles/bigquery.admin La tabla a cuyos datos históricos se accede

El permiso bigquery.rowAccessPolicies.overrideTimeTravelRestrictions no se puede agregar a un rol personalizado.

  • Ejecuta el siguiente comando para obtener el tiempo Unix equivalente:

    date -d '2023-08-04 16:00:34.456789Z' +%s000

  • Reemplaza el tiempo Unix 1691164834000 que se recibió del comando anterior en la herramienta de línea de comandos de bq. Ejecuta el siguiente comando para restablecer una copia de la tabla borrada deletedTableID en otra tabla restoredTable, dentro del mismo conjunto de datos myDatasetID:

    bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable

Seguridad ante fallas

BigQuery proporciona un período de seguridad ante fallas. Durante el período de seguridad ante fallas, los datos borrados se conservan automáticamente durante siete días más después del período de viaje en el tiempo, de modo que estén disponibles para la recuperación de emergencia. Los datos se pueden recuperar a nivel de la tabla. Los datos de una tabla se recuperan desde el momento representado por la marca de tiempo de cuándo se borró esa tabla. El período de seguridad ante fallas no se puede configurar.

No puedes consultar ni recuperar directamente los datos en el almacenamiento de seguridad ante fallas. Para recuperar datos del almacenamiento de seguridad ante fallas, comunícate con Atención al cliente de Cloud.

Facturación

Cuando configuras tu modelo de facturación de almacenamiento para usar bytes físicos, los costos totales de almacenamiento activo que se te facturan incluyen los bytes usados para el almacenamiento de seguridad ante fallas y viaje en el tiempo. El almacenamiento de viaje en el tiempo y de seguridad ante fallas se cobran según la tarifa de almacenamiento físico activo. Puedes configurar la ventana de viaje en el tiempo para balancear los costos de almacenamiento con tus necesidades de retención de datos.

Si configuras tu modelo de facturación de almacenamiento para usar bytes lógicos, los costos totales de almacenamiento que se te facturan no incluyen los bytes usados para el almacenamiento de viaje en el tiempo ni de seguridad ante fallas.

En la siguiente tabla, se muestra una comparación de los costos de almacenamiento físico y lógico:

Modelo de facturación ¿Qué es lo que pagas?
Almacenamiento físico (comprimido)
  • Pagas por bytes activos
  • Paga por el almacenamiento a largo plazo
  • Pagas por el almacenamiento de viaje en el tiempo
  • Pagas por el almacenamiento de seguridad ante fallas
Almacenamiento lógico (sin comprimir) (configuración predeterminada)
  • Pagas por el almacenamiento activo
  • Paga por el almacenamiento a largo plazo
  • No pagas por el almacenamiento de viaje en el tiempo
  • No pagas por el almacenamiento de seguridad ante fallas

Si usas almacenamiento físico, puedes ver los bytes que se usaron en el viaje en el tiempo y la seguridad ante fallas; para ello, consulta las columnas TIME_TRAVEL_PHYSICAL_BYTES y FAIL_SAFE_PHYSICAL_BYTES en las vistas TABLE_STORAGE y TABLE_STORAGE_BY_ORGANIZATION. Si deseas ver un ejemplo de cómo usar una de estas vistas para calcular los costos, consulta Predice la facturación de almacenamiento.

Los costos de almacenamiento se aplican a los datos de viaje en el tiempo y a los datos seguros contra fallas, pero solo se te factura si las tarifas de almacenamiento de datos no se aplican en ningún otro lugar de BigQuery. Se aplican los siguientes detalles:

  • Cuando se crea una tabla, no hay costo de almacenamiento de viaje en el tiempo ni a prueba de fallas.
  • Si se cambian o borran datos, se te cobrará por el almacenamiento de los datos modificados o borrados que se guardaron con el viaje en el tiempo durante el período de viaje en el tiempo y el período de seguridad ante fallas. Esto es similar a los precios de almacenamiento para las instantáneas y clonaciones de tablas.

Ejemplo de retención de datos

En la siguiente tabla, se muestra cómo se transfieren datos borrados o modificados entre períodos de retención de almacenamiento. En este ejemplo, se muestra una situación en la que el almacenamiento activo total es de 200 GiB y se borran 50 GiB con un período de viaje en el tiempo de siete días:

Día 0 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 Día 8 Día 9 Día 10 Día 11 Día 12 Día 13 Day 14 Día 15
Almacenamiento activo 200 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
Almacenamiento de viaje en el tiempo 50 50 50 50 50 50 50
Almacenamiento de seguridad ante fallas 50 50 50 50 50 50 50

Borrar datos del almacenamiento físico a largo plazo funciona de la misma manera.

Limitaciones

¿Qué sigue?