Situaciones de recuperación ante desastres para datos

Last reviewed 2022-06-10 UTC

Este artículo es la tercera parte de una serie en la que se trata la recuperación ante desastres (DR) en Google Cloud. En esta parte, se analizan las situaciones para crear copias de seguridad y recuperar datos.

La serie consta de estas partes:

Introducción

En tus planes de recuperación ante desastres se debe especificar cómo puedes evitar la pérdida de datos durante un desastre. Aquí, el término datos incluye dos situaciones. La creación de copias de seguridad y la recuperación de bases de datos, los datos de registro y otros tipos de datos se adecúan a una de las siguientes situaciones:

  • Copias de seguridad de datos. La copia de seguridad de datos implica copiar una cantidad específica de datos de un lugar a otro. Las copias de seguridad se realizan como parte de un plan de recuperación para recuperarse de una corrupción de datos a fin de que puedas restablecer un estado óptimo conocido directamente en el entorno de producción. También se realizan para restablecer datos en el entorno de DR si el entorno de producción no funciona. Por lo general, las copias de seguridad de datos tienen un valor de RTO de pequeño a mediano y un RPO pequeño.
  • Copias de seguridad de bases de datos. Las copias de seguridad de bases de datos son un poco más complejas porque, por lo general, implican la recuperación hasta el momento. Por lo tanto, debes considerar cómo crear una copia de seguridad de las copias de seguridad de la base de datos y cómo restablecerlas, y asegurarte de que el sistema de recuperación de la base de datos duplique la configuración de producción (misma versión y configuración duplicada del disco). También debes considerar cómo crear copias de seguridad de los registros de transacciones. Durante la recuperación, después de restablecer la funcionalidad de la base de datos, debes aplicar la última copia de seguridad de la base de datos y, luego, los registros de transacciones restablecidos de los que se creó una copia de seguridad después de la última copia de seguridad. Debido a los factores de complicación inherentes a los sistemas de bases de datos (por ejemplo, tener que hacer coincidir las versiones entre los sistemas de producción y de recuperación), la adopción de un enfoque en el que se prioriza la alta disponibilidad para minimizar el tiempo de recuperación de una situación que podría causar la falta de disponibilidad del servidor de la base de datos te permite lograr valores de RTO y RPO más pequeños.

En el resto de este artículo, se analizan ejemplos de cómo diseñar algunas situaciones para datos y bases de datos que pueden ayudarte a alcanzar tus objetivos de RTO y RPO.

El entorno de producción es local

En esta situación, el entorno de producción es local, y el plan de recuperación ante desastres implica el uso de Google Cloud como el sitio de recuperación.

Copia de seguridad y recuperación de datos

Puedes usar una serie de estrategias para implementar un proceso en el que se creen copias de seguridad de datos con regularidad de forma local en Google Cloud. En esta sección, se analizan dos de las soluciones más comunes.

Solución 1: crea una copia de seguridad en Cloud Storage con una tarea programada

Los componentes básicos de DR son los siguientes:

  • Cloud Storage

Una opción para crear una copia de seguridad de los datos es generar una tarea programada que ejecute una secuencia de comandos o una aplicación que transfiera los datos a Cloud Storage. Puedes automatizar un proceso de copia de seguridad en Cloud Storage mediante la herramienta de línea de comandos de gsutil o una de las bibliotecas cliente de Cloud Storage. Por ejemplo, el siguiente comando de gsutil copia todos los archivos de un directorio de origen a un bucket específico.

gsutil -m cp -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

En los siguientes pasos, se describe cómo puedes implementar un proceso de copia de seguridad y de recuperación mediante la herramienta de gsutil.

  1. Instala gsutil en la máquina local que usas para subir los archivos de datos.
  2. Crea un bucket como destino de la copia de seguridad de los datos.
  3. Crea una clave de cuenta de servicio para una cuenta de servicio específica en formato JSON. Este archivo se usa para pasar credenciales a gsutil como parte de una secuencia de comandos automatizada.

  4. Copia la clave de la cuenta de servicio en la máquina local en la que ejecutas la secuencia de comandos que usas para subir las copias de seguridad.

  5. Crea una política de IAM para restringir quién puede acceder al depósito y sus objetos. (incluye la cuenta de servicio creada para este propósito y una cuenta de operador local). Si quieres obtener detalles sobre los permisos de acceso a Cloud Storage, consulta los permisos de IAM para los comandos de gsutil.

  6. Comprueba que puedes subir y descargar archivos en el depósito de destino.

  7. Sigue las instrucciones en Tareas de transferencia de datos con secuencias de comandos para configurar una secuencia de comandos programada.

  8. Configura un proceso de recuperación que use gsutil para recuperar los datos en el entorno de recuperación de DR en Google Cloud.

También puedes usar el comando gsutil rsync para realizar sincronizaciones incrementales en tiempo real entre tus datos y un bucket de Cloud Storage.

Por ejemplo, a través del siguiente comando gsutil rsync, se logra que el contenido en un bucket de Cloud Storage sea el mismo que el contenido del directorio del código fuente mediante la copia de los archivos o los objetos faltantes, o de aquellos cuyos datos cambiaron. Si el volumen de datos que cambió entre las sesiones sucesivas de copia de seguridad es pequeño en relación con el volumen completo de los datos de origen, el uso de gsutil rsync puede ser más eficaz que el uso de gsutil cp. Esto, a su vez, permite tener un programa de copia de seguridad más frecuente y te permite lograr un valor de RPO menor.

gsutil -m rsync -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

Para obtener más información, consulta Transferencias desde la colocación o el almacenamiento local, en el que se incluyen formas de optimizar el proceso de transferencia.

Solución 2: Crea una copia de seguridad en Cloud Storage mediante el servicio de transferencia de los datos locales

Los componentes básicos de DR son los siguientes:

  • Cloud Storage
  • Servicio de transferencia de los datos locales

La transferencia de grandes cantidades de datos en una red a menudo requiere una planificación cuidadosa y estrategias de ejecución sólidas. Desarrollar secuencias de comandos personalizadas que sean escalables, confiables y fáciles de mantener no es una tarea trivial. A menudo, las secuencias de comandos personalizadas pueden reducir los valores de RPO e incluso aumentar los riesgos de pérdida de datos.

Una forma de implementar una transferencia de datos a gran escala es usar el servicio de transferencia de los datos locales. Este es un servicio escalable, confiable y administrado que te permite transferir grandes cantidades de datos de tu centro de datos a un bucket de Cloud Storage sin invertir en equipos de ingeniería ni comprar soluciones de transferencia.

Solución 3: Crea una copia de seguridad en Cloud Storage mediante una solución de puerta de enlace de socios

Los componentes básicos de DR son los siguientes:

  • Cloud Interconnect
  • Almacenamiento en niveles de Cloud Storage

Las aplicaciones locales suelen integrarse a soluciones de terceros que pueden usarse como parte de la estrategia de copia de seguridad y recuperación de datos. En general, para las soluciones se usa un patrón de almacenamiento en niveles en el que se colocan las copias de seguridad más recientes en un almacenamiento más rápido y se migran con lentitud las copias de seguridad más antiguas a un almacenamiento más económico (más lento). Cuando usas Google Cloud como destino, tienes varias opciones de clase de almacenamiento disponibles para usar como equivalentes del nivel más lento.

Una forma de implementar este patrón es mediante el uso de una puerta de enlace de socios entre el almacenamiento local y Google Cloud para facilitar esta transferencia de datos a Cloud Storage. En el siguiente diagrama, se ilustra esta disposición, con una solución de socios que administra la transferencia desde el dispositivo NAS local o SAN.

Diagrama arquitectónico en el que se muestra un centro de datos local conectado a Google Cloud mediante una interconexión dedicada

En el caso de una falla, los datos de los que se está creando una copia de seguridad en ese momento deberán recuperarse en el entorno de DR. El entorno de DR se usa para entregar el tráfico de producción hasta que puedas volver al entorno de producción. La forma de lograrlo depende de la aplicación y de la solución del socio y su arquitectura. Algunas situaciones de extremo a extremo se analizan en el documento sobre DR en aplicaciones.

Para obtener más información sobre cómo transferir datos locales a Google Cloud, consulta Transfiere conjuntos de macrodatos a Google Cloud.

Si deseas obtener más información sobre las soluciones de los socios, consulta la Página de socios en el sitio web de Google Cloud.

Copia de seguridad y recuperación de la base de datos

Puedes usar varias estrategias para implementar un proceso de recuperación de un sistema de base de datos local en Google Cloud. En esta sección, se analizan dos de las soluciones más comunes.

En este artículo, no se analizan en detalle los diversos mecanismos integrados de copia de seguridad y recuperación que se incluyen en las bases de datos de terceros. En esta sección, se proporciona orientación general, que se implementa en las soluciones que se analizan aquí.

Solución 1: copia de seguridad y recuperación mediante un servidor de recuperación en Google Cloud

  1. Crea una copia de seguridad de la base de datos mediante los mecanismos de copia de seguridad integrados del sistema de administración de bases de datos.
  2. Conecta la red local y la red de Google Cloud.
  3. Crea un depósito de Cloud Storage para la copia de seguridad de los datos.
  4. Copia los archivos de copia de seguridad en Cloud Storage mediante gsutil o una solución de puerta de enlace de socios (consulta los pasos que se explicaron antes en la sección de copia de seguridad y recuperación de datos). Para obtener más información, consulta Transfiere conjuntos de macrodatos a Google Cloud.
  5. Copia los registros de transacciones en el sitio de recuperación en Google Cloud. Tener una copia de seguridad de los registros de transacciones ayuda a mantener los valores de RPO pequeños.

Después de configurar esta topología de copia de seguridad, debes asegurarte de poder recuperar el sistema que esté en Google Cloud. Por lo general, este paso implica restablecer el archivo de copia de seguridad en la base de datos de destino y, también, volver a reproducir los registros de transacciones para obtener el valor de RTO más pequeño. Una secuencia de recuperación típica incluye los siguientes pasos:

  1. Crea una imagen personalizada del servidor de la base de datos en Google Cloud. El servidor de la base de datos debe tener la misma configuración en la imagen que el servidor de base de datos local.
  2. Implementa un proceso para copiar los archivos de copia de seguridad locales y los archivos de registro de transacciones en Cloud Storage. Consulta la Solución 1 para ver una implementación de ejemplo.
  3. Inicia una instancia de tamaño mínimo a partir de la imagen personalizada y conecta los discos persistentes que sean necesarios.
  4. Establece la marca de eliminación automática en falso para los discos persistentes.
  5. Aplica el último archivo de copia de seguridad que se copió antes en Cloud Storage. Para ello, sigue las instrucciones del sistema de base de datos a fin de recuperar archivos de copia de seguridad.
  6. Aplica el último conjunto de archivos de registro de transacciones que se copió en Cloud Storage.
  7. Reemplaza la instancia mínima por una instancia más grande que pueda aceptar tráfico de producción.
  8. Cambia los clientes para que se orienten a la base de datos recuperada en Google Cloud.

Cuando el entorno de producción se encuentra en ejecución y puede admitir cargas de trabajo de producción, debes revertir los pasos que seguiste para conmutar por error al entorno de recuperación de Google Cloud. En una secuencia típica para volver al entorno de producción, se siguen estos pasos:

  1. Realiza una copia de seguridad de la base de datos que se ejecuta en Google Cloud.
  2. Copia el archivo de copia de seguridad en el entorno de producción.
  3. Aplica el archivo de copia de seguridad al sistema de base de datos de producción.
  4. Evita que los clientes se conecten al sistema de base de datos en Google Cloud; por ejemplo, mediante la detención del servicio del sistema de base de datos. Desde este punto, la aplicación no estará disponible hasta que termines de restablecer el entorno de producción.
  5. Copia los archivos de registro de transacciones en el entorno de producción y aplícalos.
  6. Redirecciona las conexiones del cliente al entorno de producción.

Solución 2: replicación a un servidor en espera en Google Cloud

Una forma de lograr valores de RTO y RPO muy pequeños es replicar los datos (no solo crear una copia de seguridad de ellos) y, en algunos casos, el estado de la base de datos en tiempo real a un modo de espera activa del servidor de la base de datos.

  1. Conecta la red local y la red de Google Cloud.
  2. Crea una imagen personalizada del servidor de la base de datos en Google Cloud. El servidor de la base de datos debe tener la misma configuración en la imagen que el servidor de la base de datos local.
  3. Inicia una instancia a partir de la imagen personalizada y conecta los discos persistentes que sean necesarios.
  4. Establece la marca de eliminación automática en falso para los discos persistentes.
  5. Configura la replicación entre el servidor de la base de datos local y el servidor de la base de datos de destino en Google Cloud. Para ello, sigue las instrucciones específicas del software de la base de datos.
  6. Los clientes se configuran en funcionamiento normal para que se orienten al servidor de la base de datos local.

Después de configurar esta topología de replicación, cambia los clientes para que se orienten al servidor en espera que se ejecuta en la red de Google Cloud.

Cuando se crea una copia de seguridad del entorno de producción, y este puede admitir cargas de trabajo de producción, debes volver a sincronizar el servidor de la base de datos de producción con el servidor de la base de datos de Google Cloud y, luego, cambiar los clientes para que se orienten al entorno de producción.

El entorno de producción es Google Cloud

En esta situación, el entorno de producción y el de recuperación ante desastres se ejecutan en Google Cloud.

Copia de seguridad y recuperación de datos

Un patrón común para las copias de seguridad de datos es usar un patrón de almacenamiento en niveles. Cuando la carga de trabajo de producción está en Google Cloud, el sistema de almacenamiento en niveles se parece al siguiente diagrama. Debes migrar los datos a un nivel que tiene costos de almacenamiento menores, porque es menos probable que necesites acceder a los datos de los que creaste una copia de seguridad.

Los componentes básicos de DR son los siguientes:

Diagrama conceptual en el que se ve una imagen con un costo decreciente a medida que los datos se migran de discos persistentes a Nearline y a Coldline

Debido a que las clases de almacenamiento Nearline, Coldline y Archive están destinadas a almacenar datos a los que se accede con poca frecuencia, hay costos adicionales asociados a la recuperación de datos o metadatos almacenados en estas clases, al igual que períodos mínimos de almacenamiento por los que se te cobra.

Copia de seguridad y recuperación de bases de datos

Cuando usas una base de datos autoadministrada (por ejemplo, si instalaste MySQL, PostgreSQL o SQL Server en una instancia de Compute Engine), los mismos problemas operativos se aplican a la administración de bases de datos de producción locales, pero ya no deberás administrar la infraestructura subyacente.

Puedes establecer las opciones de configuración de alta disponibilidad mediante las funciones de los componentes básicos de DR adecuadas para mantener el RTO pequeño. Puedes diseñar la configuración de la base de datos para que facilite la recuperación a un estado lo más similar posible al estado anterior al desastre; esto ayuda a mantener los valores de RPO pequeños. Google Cloud ofrece una amplia variedad de opciones para esta situación.

En esta sección, se analizan dos enfoques comunes de diseño de la arquitectura de recuperación de bases de datos para bases de datos autoadministradas en Google Cloud.

Recupera un servidor de base de datos sin sincronizar de estado

Un patrón común es habilitar la recuperación de un servidor de la base de datos que no requiera que el estado del sistema esté sincronizado con una espera activa.

Los componentes básicos de DR son los siguientes:

  • Compute Engine
  • Grupos de instancias administrados
  • Cloud Load Balancing (balanceo de cargas interno)

En el siguiente diagrama, se ilustra una arquitectura de ejemplo para abordar la situación. Si implementas esta arquitectura, tienes un plan de DR que reacciona de manera automática ante una falla sin requerir una recuperación manual.

Diagrama arquitectónico en el que se muestra una imagen de disco persistente tomada de un disco persistente en una zona

En los siguientes pasos, se describe cómo configurar esta situación:

  1. Crea una red de VPC.

  2. Para crear una imagen personalizada que se configure con el servidor de la base de datos, sigue estos pasos:

    1. Configura el servidor para que los archivos de la base de datos y los archivos de registro se escriban en un disco persistente estándar conectado.
    2. Crea una instantánea desde el disco persistente adjunto.
    3. Configura una secuencia de comandos de inicio para crear un disco persistente a partir de la instantánea y activar el disco.
    4. Crea una imagen personalizada del disco de arranque.

  3. Crea una plantilla de instancias que use la imagen.

  4. Con la plantilla de instancias, configura un grupo de instancias administrado con un tamaño de destino de 1.

  5. Configura la verificación de estado con las métricas de Cloud Monitoring.

  6. Configura el balanceo de cargas interno mediante el grupo de instancias administrado.

  7. Configura una tarea programada para crear instantáneas normales del disco persistente.

En el caso de que se necesite una instancia de base de datos de reemplazo, esta configuración hará lo siguiente de manera automática:

  • Abre otro servidor de la base de datos de la versión correcta en la misma zona.
  • Conectará un disco persistente que tenga los últimos archivos de registro de transacciones y la copia de seguridad a la instancia del servidor de la base de datos recién creada.
  • Minimizará la necesidad de volver a configurar los clientes que se comunican con el servidor de la base de datos en respuesta a un evento.
  • Garantizará que los controles de seguridad de Google Cloud (políticas de IAM y configuración de firewall) que se aplican al servidor de la base de datos de producción se apliquen al servidor de la base de datos recuperado.

Debido a que la instancia de reemplazo se crea a partir de una plantilla de instancias, los controles que se aplicaron a la original también se aplican a la instancia de reemplazo.

En esta situación, se aprovechan algunas de las características de la alta disponibilidad en Google Cloud; no debes iniciar ningún paso de la conmutación por error, porque comienzan de manera automática si ocurre un desastre. El balanceador de cargas interno garantiza que, incluso cuando se necesite una instancia de reemplazo, se use la misma dirección IP para el servidor de la base de datos. La plantilla de instancias y la imagen personalizada garantizan que la instancia de reemplazo esté configurada de manera idéntica a la instancia que reemplaza. Si tomas instantáneas con regularidad de los discos persistentes, te aseguras de que cuando los discos se vuelvan a crear a partir de las instantáneas y se conecten a la instancia de reemplazo, esta usará datos recuperados de acuerdo con un valor de RPO determinado por la frecuencia de las instantáneas. En esta arquitectura, los últimos archivos de registro de transacciones que se escribieron en el disco persistente también se restablecen de manera automática.

El grupo de instancias administrado proporciona alta disponibilidad en profundidad. Proporciona mecanismos para reaccionar ante fallas a nivel de la aplicación o instancia. Por lo tanto, no necesitas intervenir de manera manual si ocurre alguna de esas situaciones. La configuración de un tamaño de destino de uno garantiza que solo tengas una instancia activa que se ejecute en el grupo de instancias administrado y entregue tráfico.

Como los discos persistentes estándar son zonales, si hay una falla zonal, se requieren instantáneas para volver a crear los discos. Las instantáneas también están disponibles en todas las regiones, lo que te permite restablecer un disco en una región diferente con la misma facilidad con que lo puedes restablecer en la misma región.

Una variación de esta configuración es usar discos persistentes regionales en lugar de discos persistentes estándar. En este caso, no necesitas restablecer la instantánea como parte del paso de recuperación.

El enfoque que elijas depende de tu presupuesto y los valores de RTO y RPO.

Si quieres obtener más información sobre las opciones de configuración de bases de datos diseñadas para situaciones de alta disponibilidad y DR en Google Cloud, consulta lo siguiente:

Recupérate de la corrupción parcial en bases de datos muy grandes

Si usas una base de datos que puede almacenar petabytes de datos, es posible que experimentes una interrupción que afecte a algunos de los datos, pero no a todos. En ese caso, se recomienda que minimices la cantidad de datos que deberás restablecer; no es necesario (o no es conveniente) recuperar la base de datos completa solo para restablecer algunos de los datos.

Puedes adoptar las siguientes estrategias de mitigación:

  • Almacena los datos en tablas diferentes para períodos específicos. Este método garantiza que solo necesites restablecer un subconjunto de datos a una tabla nueva, en lugar de un conjunto de datos completo.

  • Almacena los datos originales en Cloud Storage. Esto te permite crear una tabla nueva y volver a cargar los datos no dañados. Desde allí, puedes configurar las aplicaciones para que se orienten a la tabla nueva.

Además, si el RTO lo permite, puedes evitar el acceso a la tabla que tiene los datos dañados si dejas las aplicaciones sin conexión hasta que los datos no dañados se restablezcan a una tabla nueva.

Servicios de bases de datos administradas en Google Cloud

En esta sección, se describen algunos métodos que puedes usar a fin de implementar mecanismos adecuados de copia de seguridad y recuperación para los servicios de base de datos administradas en Google Cloud.

Las bases de datos administradas están diseñadas para el escalamiento, por lo que los mecanismos de copia de seguridad y restablecimiento tradicionales que se ven en los RDMBS tradicionales no suelen estar disponibles. Al igual que con las bases de datos autoadministradas, si usas una base de datos que puede almacenar petabytes de datos, se recomienda que minimices la cantidad de datos que debes restablecer en una situación de DR. Hay una serie de estrategias para cada base de datos administrada que te permiten lograr este objetivo.

Bigtable proporciona replicación de Bigtable. Una base de datos replicada de Bigtable puede proporcionar mayor disponibilidad que un solo clúster, capacidad de procesamiento de lectura adicional y mayor durabilidad y resiliencia ante fallas zonales o regionales.

Las copias de seguridad de Bigtable son un servicio completamente administrado que te permite guardar una copia del esquema y los datos de una tabla y, luego, restablecer la copia de seguridad en una nueva tabla más adelante.

También puedes exportar tablas desde Bigtable como una serie de archivos de secuencia de Hadoop. Luego, puedes almacenar estos archivos en Cloud Storage o usarlos para importar los datos en otra instancia de Bigtable. Puedes replicar el conjunto de datos de Bigtable de manera asíncrona entre zonas dentro de una región de Google Cloud.

BigQuery. Si deseas archivar datos, puedes aprovechar el almacenamiento a largo plazo de BigQuery. Si una tabla no se edita durante 90 días consecutivos, el precio de almacenamiento disminuye un 50 % de forma automática. El rendimiento, la durabilidad, la disponibilidad y otras funciones no disminuyen cuando una tabla se considera como almacenamiento a largo plazo. Sin embargo, si la tabla se edita, vuelve a los precios de almacenamiento normales y, la cuenta regresiva de 90 días vuelve a comenzar.

BigQuery se replica en 2 zonas en una sola región, pero esto no ayudará con la corrupción de las tablas. Por lo tanto, debes tener un plan para poder recuperarte de esa situación. Por ejemplo, puedes hacer lo siguiente:

  • Si el daño se detecta en un plazo de 7 días, consulta la tabla en un momento del pasado para recuperarla antes del daño mediante decoradores de instantáneas.
  • Exporta los datos desde BigQuery y crea una tabla nueva que contenga los datos exportados, pero excluya los datos dañados.
  • Almacena los datos en tablas diferentes para períodos específicos. Este método garantiza que solo necesites restablecer un subconjunto de datos a una tabla nueva, en lugar de un conjunto de datos completo.
  • Crea copias de tu conjunto de datos en períodos específicos. Puedes usar estas copias si se produce un evento de corrupción de datos más allá de lo que puede capturar una consulta de un momento determinado (por ejemplo, hace más de 7 días). También puedes copiar un conjunto de datos de una región en otra para garantizar la disponibilidad de los datos en caso de que ocurran fallas en la región.
  • Almacena los datos originales en Cloud Storage. Esto te permite crear una tabla nueva y volver a cargar los datos no dañados. Desde allí, puedes configurar las aplicaciones para que se orienten a la tabla nueva.

Firestore. El servicio de importación y exportación administrado te permite importar y exportar entidades de Firestore mediante un bucket de Cloud Storage. Esto, a su vez, te permite implementar un proceso que puedes usar para recuperarte de una eliminación de datos accidental.

Cloud SQL. Si usas Cloud SQL, la base de datos MySQL de Google Cloud completamente administrada, debes habilitar las copias de seguridad automáticas y el registro binario para las instancias de Cloud SQL. Esto te permite realizar una recuperación de un momento determinado, en la que se restablece la base de datos a partir de una copia de seguridad y se la recupera en una instancia de Cloud SQL nueva. Para obtener más información, consulta Copias de seguridad y recuperación en Cloud SQL.

También puedes configurar Cloud SQL en una configuración de HA y réplicas entre regiones para maximizar el tiempo en caso de una falla zonal o regional.

Spanner. Puedes usar plantillas de Dataflow a fin de realizar una exportación completa de la base de datos a un conjunto de archivos Avro en un bucket de Cloud Storage y usar otra plantilla para volver a importar los archivos exportados a una base de datos de Spanner nueva.

En cuanto a las copias de seguridad más controladas, el conector de Dataflow te permite escribir un código para leer y escribir datos en Spanner en una canalización de Dataflow. Por ejemplo, puedes usar el conector para copiar datos fuera de Spanner y en Cloud Storage como destino de la copia de seguridad. La velocidad a la que se pueden realizar operaciones de lectura de los datos desde Spanner (o volver a realizar operaciones de escritura) depende de la cantidad de nodos configurados. Esto tiene un impacto directo en los valores de RTO.

La función de marca de tiempo de confirmación de Spanner puede ser útil para las copias de seguridad incrementales, ya que te permite seleccionar solo las filas que se agregaron o modificaron desde la última copia de seguridad completa.

Para las copias de seguridad administradas, Copia de seguridad y restablecimiento de Spanner te permite crear copias de seguridad coherentes que se pueden retener por hasta 1 año. El valor de RTO es menor en comparación con la exportación, ya que la operación de restablecimiento activa directamente la copia de seguridad sin copiar los datos.

A fin de obtener valores de RTO pequeños, podrías configurar una instancia de Spanner en espera semiactiva con la cantidad mínima de nodos necesarios para cumplir con tus requisitos de capacidad de procesamiento de lectura y escritura y de almacenamiento.

La recuperación de un momento determinado (PITR) de Spanner te permite recuperar datos de un momento específico en el pasado. Por ejemplo, si un operador escribe datos de forma inadvertida o el lanzamiento de una aplicación daña la base de datos, con la PITR, puedes recuperar los datos de un momento en el pasado, hasta un máximo de 7 días.

Cloud Composer. Puedes usar Cloud Composer (una versión administrada de Apache Airflow) para programar copias de seguridad regulares de varias bases de datos de Google Cloud. Puedes crear un grafo acíclico dirigido (DAG) que se ejecute en una programación (por ejemplo, a diario) a fin de copiar los datos en otro proyecto, conjunto de datos o tabla (según la solución usada), o para exportar los datos a Cloud Storage.

Puedes exportar o copiar datos mediante los distintos operadores de Cloud Platform.

Por ejemplo, puedes crear un DAG para que realice cualquiera de las siguientes acciones:

El entorno de producción es otra nube

En esta situación, el entorno de producción usa otro proveedor de servicios en la nube, y el plan de recuperación ante desastres implica el uso de Google Cloud como el sitio de recuperación.

Copia de seguridad y recuperación de datos

La transferencia de datos entre almacenamientos de objetos es un caso de uso común para las situaciones de DR. El Servicio de transferencia de almacenamiento es compatible con Amazon S3 y es el método recomendado para transferir objetos de Amazon S3 a Cloud Storage.

Puedes configurar un trabajo de transferencia para programar la sincronización periódica de la fuente de datos al receptor de datos, con filtros avanzados en función de las fechas de creación de los archivos, los filtros de nombres de los archivos y las horas del día en las que prefieres transferir datos. Para lograr el RPO que deseas, debes tener en cuenta los siguientes factores:

  • Frecuencia de cambio: Es la cantidad de datos que se generan o actualizan durante un período determinado. Cuanto más alta sea la frecuencia de cambio, se necesitarán más recursos para transferir los cambios al destino en cada período de transferencia incremental.

  • Rendimiento de la transferencia: Es el tiempo que lleva transferir archivos. Para las transferencias de archivos grandes, esto se suele determinar mediante el ancho de banda disponible entre la fuente y el destino. Sin embargo, si un trabajo de transferencia consta de una gran cantidad de archivos pequeños, las QPS pueden convertirse en un factor limitante. Si ese es el caso, puedes programar varios trabajos simultáneos para escalar el rendimiento siempre que haya suficiente ancho de banda disponible. Te recomendamos que midas el rendimiento de la transferencia mediante el uso de un subconjunto representativo de tus datos reales.

  • Frecuencia: Es el intervalo entre los trabajos de copia de seguridad. La actualidad de los datos en el destino es tan reciente como la última vez que se programó un trabajo de transferencia. Por lo tanto, es importante que los intervalos entre los trabajos de transferencia sucesivos no superen el objetivo de RPO. Por ejemplo, si el objetivo de RPO es de 1 día, el trabajo de transferencia debe programarse al menos una vez al día.

  • Supervisión y alertas: El Servicio de transferencia de almacenamiento proporciona notificaciones de Pub/Sub en una amplia variedad de eventos. Te recomendamos que te suscribas a estas notificaciones para controlar las fallas o los cambios inesperados en los tiempos de finalización de un trabajo.

Otra opción para mover datos de AWS a Google Cloud es usar boto, que es una herramienta de Python compatible con Amazon S3 y Cloud Storage. Se puede instalar como un complemento de la herramienta de línea de comandos de gsutil.

Copia de seguridad y recuperación de la base de datos

En este artículo, no se analizan en detalle los diversos mecanismos de copia de seguridad y recuperación integrados que se incluyen en las bases de datos de terceros o las técnicas de copia de seguridad y recuperación usadas en otros proveedores de servicios en la nube. Si usas bases de datos no administradas en los servicios de procesamiento, puedes aprovechar las instalaciones de alta disponibilidad que tu proveedor de servicios en la nube de producción tiene disponibles. Puedes ampliarlas a fin de incorporar una implementación de alta disponibilidad en Google Cloud. También puedes usar Cloud Storage como el destino final para el almacenamiento en frío de los archivos de copia de seguridad de la base de datos.

¿Qué sigue?