Información general sobre las copias de seguridad de Bigtable
En esta página se ofrece una descripción general de las copias de seguridad de Bigtable. El contenido que se presenta aquí está dirigido a administradores y desarrolladores de Bigtable.
Las copias de seguridad te permiten guardar una copia del esquema y los datos de una tabla y, después, restaurarla en una tabla nueva. Bigtable ofrece dos tipos de copias de seguridad. El tipo de copia de seguridad que crees depende de tus requisitos de recuperación tras desastres y del tipo de almacenamiento (HDD o SSD) que use tu clúster de Bigtable.
- Las copias de seguridad estándar están optimizadas para la conservación a largo plazo. Cuando restauras una copia de seguridad estándar en un clúster SSD, Bigtable debe optimizar la operación de restauración para que la tabla alcance un rendimiento de nivel de producción. Para obtener más información, consulta Rendimiento al restaurar.
- Las copias de seguridad activas proporcionan la restauración más eficiente al rendimiento de nivel de producción y al servicio de baja latencia. Para obtener más información, consulta Copias de seguridad activas.
Puedes crear copias de seguridad de las siguientes formas:
- Habilita las copias de seguridad automáticas para que Bigtable cree copias de seguridad diarias por ti.
- Crea una copia de seguridad a petición mediante la Google Cloud consola, la CLI de gcloud o una biblioteca de cliente de Bigtable.
- Crea una copia de una copia de seguridad.
Antes de leer esta página, debes familiarizarte con la descripción general de Bigtable y con Gestionar tablas.
Funciones
- Totalmente integrado: el servicio Bigtable se encarga por completo de las copias de seguridad, por lo que no es necesario importar ni exportar nada.
- Incrementales: las copias de seguridad comparten el almacenamiento físico con la tabla de origen y con otras copias de seguridad de la tabla.
- Rentable: usar copias de seguridad de Bigtable te permite evitar los costes asociados a la exportación, el almacenamiento y la importación de datos con otros servicios.
- Vencimiento automático: cada copia de seguridad tiene una fecha de vencimiento definida por el usuario, que puede ser de hasta 90 días después de que se cree la copia de seguridad. Puedes almacenar una copia de una copia de seguridad durante un máximo de 30 días.
- Opciones de restauración flexibles: puedes restaurar una copia de seguridad en una tabla de una instancia diferente a la de la copia de seguridad.
- Copia de seguridad automática: habilita la copia de seguridad automática para que Bigtable cree copias de seguridad diarias.
- Copias de seguridad dinámicas: planifica la recuperación tras fallos con copias de seguridad dinámicas listas para producción.
Casos prácticos
Las copias de seguridad son útiles en los siguientes casos prácticos:
- Continuidad de la actividad empresarial
- Cumplimiento de las normativas
- Pruebas y desarrollo
- Recuperación tras fallos
Ten en cuenta las siguientes situaciones de recuperación tras desastres:
| Objetivo | Estrategia de copia de seguridad | Estrategia de restauración |
|---|---|---|
| Protección contra errores humanos: siempre es recomendable tener una copia de seguridad reciente de tus datos por si se eliminan o se dañan por error. | Determina la programación de creación de copias de seguridad que mejor se adapte a las necesidades de tu empresa, como la diaria. También puedes crear copias periódicas de las copias de seguridad y almacenarlas en otro proyecto u otra región para aumentar el aislamiento y la protección. Para disfrutar de una protección aún mayor, almacena las copias de seguridad en un proyecto o una instancia con permisos de acceso restringido. | Restaura la copia de seguridad o la copia en una tabla nueva y, a continuación, redirige las solicitudes a la tabla nueva. |
| Disponibilidad de zonas: debes asegurarte de que, en el improbable caso de que una zona deje de estar disponible, tus datos sigan estando disponibles. Google Cloud | Habilita las copias de seguridad automáticas para que Bigtable cree una copia de seguridad diaria en cada clúster de la instancia. También puedes crear copias de seguridad de forma periódica y, después, crear una copia de la copia de seguridad más reciente y almacenarla en uno o varios clústeres de diferentes zonas (opcionalmente, en otra instancia u otro proyecto). | Si la zona en la que se encuentra tu clúster de servicio deja de estar disponible, restaura la copia de seguridad remota en una tabla nueva y, a continuación, redirige las solicitudes a la tabla nueva. |
| Datos dañados: usa una copia de seguridad para recuperar algunos datos de una tabla, por ejemplo, cuando parte de la tabla de origen se ha dañado. | Habilita la replicación y la copia de seguridad automatizada para crear copias de seguridad diarias en varias regiones. De esta forma, si una tabla se daña en un clúster, tendrás una o varias copias de seguridad que no compartan el almacenamiento del clúster dañado. | Restaura la copia de seguridad en una tabla nueva del clúster o la instancia nuevos. A continuación, escribe una aplicación con una biblioteca de cliente de Bigtable o Dataflow que lea de la nueva tabla y, después, escriba los datos en la tabla de origen. Cuando los datos se hayan copiado en la tabla original, elimina la tabla nueva. |
| Recuperación rápida: restaura los niveles de rendimiento de producción completos rápidamente y minimiza el tiempo de inactividad. | Mantén siempre una copia de seguridad activa reciente de tu tabla. | Restaura la copia de seguridad activa en una tabla nueva y, a continuación, redirige las solicitudes a la tabla nueva. |
Copias de seguridad en caliente
Una copia de seguridad activa es una copia de seguridad lista para producción que se ha optimizado para que la recuperación sea rápida y tenga una latencia menor al leer de la tabla nueva poco después de la restauración. Restaurar el rendimiento de producción a partir de una copia de seguridad activa es más rápido que restaurar a partir de una copia de seguridad estándar.
Puedes convertir una copia de seguridad dinámica en una estándar, pero no al revés.
No puedes crear copias de seguridad activas con la copia de seguridad automatizada, ni tampoco en un clúster de HDD.
Trabajar con copias de seguridad de Bigtable
Las siguientes acciones están disponibles para las copias de seguridad de Bigtable. En todos los casos, el proyecto, la instancia y el clúster de destino ya deben existir. No puedes crear estos recursos como parte de una operación de copia de seguridad.
|
||
| Acción | Opciones de destino | |
|---|---|---|
| Crear una copia de seguridad estándar |
|
|
| Crear una copia de seguridad activa |
|
|
| Restaurar una copia de seguridad estándar o activa en una tabla nueva |
|
|
| Copiar una copia de seguridad1, 2 |
|
|
Consulta Gestionar copias de seguridad para ver instrucciones detalladas sobre estas acciones, así como sobre otras operaciones, como actualizar y eliminar copias de seguridad.
Utiliza lo siguiente para trabajar con copias de seguridad de Bigtable:
- La Google Cloud consola
- Google Cloud CLI
- Las bibliotecas de cliente de Cloud Bigtable
Almacenamiento de copias de seguridad
Las copias de seguridad de tablas que creas manualmente o mediante programación se almacenan en un único clúster que especifiques. Cuando la copia de seguridad automática está habilitada, se almacena una copia de seguridad en cada clúster de la instancia.
Si tu clúster supera los límites recomendados de uso de CPU o almacenamiento al crear una copia de seguridad, es posible que la creación de la copia de seguridad se retrase. Para obtener más información, consulta Información sobre el uso de CPU y disco.
Una copia de seguridad de una tabla incluye todos los datos que contenía la tabla en el momento en que se creó la copia de seguridad, en el clúster en el que se creó. Las copias de seguridad nunca superan el tamaño de la tabla de origen en el momento en que se crean.
Las copias de seguridad de Bigtable son incrementales. La cantidad de almacenamiento que ocupa una copia de seguridad depende del tamaño de la tabla y de la medida en que pueda compartir el almacenamiento de los datos sin cambios con la tabla original u otras copias de seguridad de la misma tabla. Por este motivo, el tamaño de una copia de seguridad depende de la divergencia de datos que se haya producido desde la copia anterior.
Puedes crear hasta 150 copias de seguridad por tabla y clúster.
Puedes eliminar una tabla que tenga una copia de seguridad. Para proteger tus copias de seguridad, no puedes eliminar un clúster que contenga una copia de seguridad ni una instancia que tenga una o varias copias de seguridad en ningún clúster.
La copia de seguridad sigue existiendo después de restaurarla en una tabla nueva. Puedes eliminarlo o dejar que caduque cuando ya no lo necesites. El almacenamiento de copias de seguridad no se tiene en cuenta para calcular el límite de almacenamiento de los nodos de un proyecto.
Los datos de las copias de seguridad están cifrados.
Retención
Puedes especificar un periodo de retención de hasta 90 días para una copia de seguridad. Si creas una copia de una copia de seguridad, el periodo de conservación máximo de la copia es de 30 días a partir del momento en que se crea.
Puedes cambiar el periodo de conservación de una copia de seguridad para conservarla hasta 90 días después de la hora de creación. Para obtener más información, consulta Modificar una copia de seguridad o una copia de seguridad.
En las tablas en las que se ha habilitado la copia de seguridad automática, el periodo de conservación es de siete días si se define la política mediante la marca --enable-automated-backup. Puedes definir un periodo de conservación personalizado
introduciendo la marca --automated-backup-retention-period, que acepta un valor
de entre 3 y 90 días. Para obtener más información, consulta Actualizar una política de copias de seguridad automáticas.
Almacenamiento posterior a la restauración
El coste de almacenamiento de una tabla nueva restaurada a partir de una copia de seguridad es el mismo que el de cualquier otra tabla.
Es posible que una tabla restaurada a partir de una copia de seguridad no consuma la misma cantidad de almacenamiento que la tabla original y que su tamaño se reduzca después de la restauración. La diferencia de tamaño depende de la frecuencia con la que se haya producido la compresión en el clúster de origen y en el de destino.
Como la compactación se produce de forma continua, es posible que se lleve a cabo en cuanto se cree la tabla. Sin embargo, la compactación puede tardar hasta una semana en producirse.
Una tabla nueva restaurada a partir de una copia de seguridad no hereda las políticas de recogida de elementos no utilizados de la tabla de origen. Configura las políticas de recogida de elementos no utilizados en la nueva tabla antes de empezar a escribir datos en ella. Para obtener más información, consulta Configurar la recogida de elementos no utilizados.
Costes
Se aplican los costes de red estándar al trabajar con copias de seguridad. No se te cobrará por las operaciones de copia de seguridad, como crear, copiar o restaurar una copia de seguridad.
Costes de almacenamiento
Los costes de almacenamiento son diferentes para las copias de seguridad estándar y las activas.
Costes de almacenamiento de copias de seguridad estándar
Para almacenar una copia de seguridad estándar o una copia de una copia de seguridad, se te cobra la tarifa de almacenamiento de copias de seguridad estándar de la región en la que se encuentre el clúster que contenga la copia de seguridad o la copia de la copia de seguridad.
Una copia de seguridad estándar es una copia lógica completa de una tabla. En segundo plano, Bigtable optimiza el uso del almacenamiento de copias de seguridad estándar. Esta optimización significa que una copia de seguridad estándar es incremental, es decir, comparte el almacenamiento físico con la tabla original o con otras copias de seguridad de la tabla siempre que sea posible. Debido a las optimizaciones del almacenamiento integradas en Bigtable, puede haber ocasiones en las que el coste de almacenar una copia de seguridad estándar o una copia de una copia de seguridad sea menor que el de una copia física completa de la copia de seguridad de la tabla.
En las instancias replicadas en las que se ha habilitado la copia de seguridad automática, los costes de almacenamiento pueden ser más altos porque se crea una copia de seguridad en cada clúster a diario.
Costes de almacenamiento de copias de seguridad activas
Para almacenar una copia de seguridad activa, se te cobrará la tarifa de almacenamiento de copias de seguridad activas de la región en la que se encuentre el clúster que contiene la copia de seguridad activa.
Como las copias de seguridad dinámicas se almacenan en un estado listo y optimizado para restaurarlas rápidamente, se te cobra por el almacenamiento de toda la copia lógica de la tabla, en lugar de por las partes incrementales, como ocurre con las copias de seguridad estándar.
Costes al copiar una copia de seguridad
Cuando creas una copia de una copia de seguridad en una región diferente a la de la copia de seguridad de origen, se te aplican las tarifas de red estándar por el coste de copiar los datos en el clúster de destino. No se te cobrará por el tráfico de red cuando crees una copia en la misma región que la copia de seguridad de origen.
Costes al restaurar
Cuando restauras una tabla nueva a partir de una copia de seguridad, se te cobra el coste de red de la replicación. Si la tabla nueva está en una instancia que tiene activada la replicación, se te cobrará un importe único por la replicación de los datos en todos los clústeres de la instancia.
Si restauras una copia de seguridad en una instancia diferente a la instancia en la que se creó y la instancia de la copia de seguridad y la instancia de destino no tienen al menos un clúster en la misma región, se te cobrará un importe único por la copia de datos inicial en el clúster de destino a las tarifas de red estándar.
CMEK
Cuando creas una copia de seguridad en un clúster protegido por una clave de cifrado gestionada por el cliente (CMEK), la copia de seguridad se fija a la versión principal de la clave CMEK del clúster en el momento en que se crea. Una vez creada la copia de seguridad, no se pueden modificar ni su clave ni su versión, aunque se rote la clave de KMS.
Cuando restauras una copia de seguridad, la versión de la clave a la que está fijada la copia de seguridad debe estar habilitada para que el proceso de descifrado de la copia de seguridad se complete correctamente. La tabla nueva está protegida con la versión principal más reciente de la clave CMEK de cada clúster de la instancia de destino. Si quieres restaurar una copia de seguridad protegida con CMEK en otra instancia, la instancia de destino también debe estar protegida con CMEK, pero no es necesario que tenga la misma configuración de CMEK que la instancia de origen.
Consideraciones sobre la replicación
En esta sección se describen otros conceptos que debe conocer al crear copias de seguridad y restaurar una tabla en una instancia que usa la replicación.
Replicación y copias de seguridad
Cuando creas una copia de seguridad de una tabla manualmente en una instancia replicada, eliges el clúster en el que quieres crear y almacenar la copia de seguridad. En las tablas con copias de seguridad automáticas habilitadas, se crea una copia de seguridad diaria en cada clúster de la instancia.
No tienes que dejar de escribir en el clúster que contiene la copia de seguridad, pero debes saber cómo gestiona Bigtable las escrituras replicadas en el clúster.
Una copia de seguridad es una copia de la tabla en el estado en el que se encontraba en el clúster donde se almacena la copia de seguridad en el momento en que se crea. Los datos de las tablas que aún no se han replicado desde otro clúster de la instancia no se incluyen en la copia de seguridad.
Cada copia de seguridad tiene una hora de inicio y otra de finalización. Es posible que las escrituras que se envíen al clúster poco antes o durante la operación de copia de seguridad no se incluyan en la copia de seguridad. Esta incertidumbre se debe a dos factores:
- Es posible que se envíe una escritura a una sección de la tabla que la copia de seguridad ya haya copiado.
- Es posible que una escritura en otro clúster no se haya replicado en el clúster que contiene la copia de seguridad.
Es decir, es posible que algunas escrituras con marcas de tiempo anteriores a la hora de la copia de seguridad no se incluyan en ella.
Si esta incoherencia no se ajusta a los requisitos de tu empresa, puedes usar un token de coherencia con tus solicitudes de escritura para asegurarte de que todas las escrituras replicadas se incluyan en una copia de seguridad.
Las copias de seguridad de las tablas replicadas que se crean como parte de la copia de seguridad automatizada no son copias exactas entre sí, ya que los tiempos de copia de seguridad pueden variar de un clúster a otro.
Replicación y restauración
Cuando restauras una copia de seguridad en una tabla nueva, la replicación hacia y desde los demás clústeres de la instancia comienza inmediatamente después de que se haya completado la operación de restauración en el clúster de destino.
Rendimiento
Cuando crees copias de seguridad, sigue estas prácticas recomendadas para asegurarte de que el rendimiento siga siendo óptimo.
Rendimiento al crear copias de seguridad
Crear una copia de seguridad suele tardar menos de un minuto, aunque puede llevar hasta una hora. En circunstancias normales, la creación de copias de seguridad no afecta al rendimiento del servicio.
Para que el rendimiento sea óptimo, no cree una copia de seguridad de una misma tabla más de una vez cada cinco minutos. Crear copias de seguridad con más frecuencia puede provocar un aumento observable de la latencia de servicio.
Rendimiento al restaurar
Restaurar una copia de seguridad en una tabla de una instancia de un solo clúster lleva unos minutos. En las instancias replicadas, la restauración tarda más porque los datos se tienen que copiar en todos los clústeres. Bigtable siempre elige la ruta más eficiente para copiar datos.
Si restauras una copia de seguridad en una instancia diferente a la que se usó para crearla, la operación de restauración tardará más que si la restauras en la misma instancia. Esto es especialmente cierto si la instancia de destino no tiene un clúster en la misma zona que el clúster en el que se creó la copia de seguridad.
Se tarda más en restaurar una tabla grande que una pequeña.
Si tienes una instancia SSD, es posible que al principio experimentes una mayor latencia de lectura, incluso después de que se haya completado la restauración, mientras se optimiza la tabla. Puedes consultar el estado en cualquier momento durante la operación de restauración para ver si la optimización sigue en curso.
Si restauras una copia de seguridad en una instancia diferente a la de origen, la instancia de destino puede usar almacenamiento en HDD o SSD. No es necesario que use el mismo tipo de almacenamiento que la instancia de origen.
Control de acceso
Los permisos de gestión de identidades y accesos controlan el acceso a las operaciones de copia de seguridad y restauración. Los permisos de copia de seguridad son a nivel de instancia y se aplican a todas las copias de seguridad de la instancia.
La cuenta que uses para crear una copia de seguridad de una tabla debe tener permiso para leer la tabla y crear copias de seguridad en la instancia en la que se encuentra la tabla (la instancia de origen).
La cuenta que uses para copiar una copia de seguridad debe tener permiso para leer la copia de seguridad de origen y para crear una copia de seguridad en la instancia y el proyecto de destino.
La cuenta que uses para restaurar una tabla nueva a partir de una copia de seguridad debe tener permiso para crear una tabla en la instancia en la que vas a restaurar la copia.
| Acción | Permiso de gestión de identidades y accesos necesario |
|---|---|
| Crear una copia de seguridad | bigtable.tables.readRows, bigtable.backups.create |
| Obtener una copia de seguridad | bigtable.backups.get |
| Mostrar copias de seguridad | bigtable.backups.list |
| Eliminar una copia de seguridad | bigtable.backups.delete |
| Actualizar una copia de seguridad | bigtable.backups.update |
| Copiar una copia de seguridad | bigtable.backups.read, bigtable.backups.create |
| Restaurar una copia de seguridad en una tabla nueva | bigtable.tables.create, bigtable.backups.restore |
| Obtener una operación | bigtable.instances.get |
| Mostrar operaciones | bigtable.instances.get |
Prácticas recomendadas
Antes de crear una estrategia de copia de seguridad, ten en cuenta las siguientes prácticas recomendadas. Para obtener más información sobre la planificación de la recuperación tras fallos, consulta la sección de Bigtable del artículo Diseño de la recuperación tras fallos para interrupciones de la infraestructura de la nube.
Crear copias de seguridad
- No cree copias de seguridad de una tabla con una frecuencia superior a una vez cada cinco minutos.
- Cuando crees una copia de seguridad de una tabla que usa la replicación, elige el clúster en el que se almacenará la copia de seguridad teniendo en cuenta los siguientes factores:
- Coste. Puede que un clúster de tu instancia esté en una región con un coste inferior al de los demás.
- Proximidad a tu servidor de aplicaciones. Te recomendamos que almacenes la copia de seguridad lo más cerca posible de tu aplicación de servicio.
- Si necesitas asegurarte de que todas las escrituras replicadas se incluyan en una copia de seguridad al crear una copia de seguridad de una tabla en una instancia que usa la replicación, usa un token de coherencia con tus solicitudes de escritura.
Restauración de datos desde copias de seguridad
- Planifica el nombre que le darás a la nueva tabla si necesitas restaurar una copia de seguridad. Lo importante es prepararse con antelación para no tener que tomar decisiones cuando te enfrentes a un problema.
- Si vas a restaurar una tabla por un motivo distinto a la eliminación accidental, asegúrate de que todas las lecturas y escrituras se dirijan a la nueva tabla antes de eliminar la original.
- Si tienes previsto restaurar una copia de seguridad en otra instancia, crea la instancia de destino antes de iniciar la operación de restauración.
- Para evitar que la restauración de tablas sea lenta, espera a que se complete una operación de restauración antes de iniciar otra para la misma tabla de origen en la misma zona.
- Espera al menos una hora después de la creación antes de restaurar una copia de seguridad estándar. Si necesitas restaurar los datos más rápido, utiliza una copia de seguridad activa.
Cuotas y límites
Las solicitudes de copia de seguridad y restauración, así como el almacenamiento de copias de seguridad, están sujetos a las cuotas y los límites de Bigtable.
Limitaciones
Se aplican las siguientes limitaciones a las copias de seguridad de Bigtable:
General
- No puedes leer directamente desde una copia de seguridad.
- Una copia de seguridad es una versión de una tabla de un solo clúster en un momento concreto. Las copias de seguridad no representan un estado coherente. Lo mismo ocurre con las copias de seguridad de la misma tabla en diferentes clústeres.
- No puedes crear copias de seguridad de más de una tabla en una sola operación.
- No puedes exportar, copiar ni mover una copia de seguridad de Bigtable a otro servicio, como Cloud Storage.
- Las copias de seguridad de Bigtable solo contienen datos de Bigtable y no están integradas ni relacionadas con las copias de seguridad de otros servicios de Google.
- No puedes crear una copia de seguridad de una vista.
Restaurar
- No puedes restaurar una copia de seguridad en una tabla que ya exista.
- Solo puedes restaurar una copia de seguridad en una instancia que ya exista. Bigtable no crea una instancia al restaurar una copia de seguridad. Si la instancia de destino especificada en una solicitud de restauración no existe, la operación de restauración falla.
- Si restauras una copia de seguridad en una tabla de un clúster SSD y, a continuación, eliminas la tabla recién restaurada, es posible que la eliminación tarde un tiempo en completarse, ya que Bigtable espera a que finalice la optimización de la tabla.
Copiando
- No puedes crear una copia de una copia de seguridad que vaya a caducar en las próximas 24 horas.
- No puedes crear una copia de una copia de seguridad.
CMEK
- Las copias de seguridad protegidas con CMEK deben restaurarse en una tabla nueva de una instancia protegida con CMEK.
- Cuando creas una copia de una copia de seguridad protegida con CMEK, el clúster de destino también debe estar protegido con CMEK.
Siguientes pasos
- Consulta cómo crear copias de seguridad y restaurar tablas.
- Consulta cómo habilitar la copia de seguridad automática.