Información general sobre la restauración de instancias

MySQL   |  PostgreSQL   |  SQL Server

Cloud SQL te permite restaurar tus instancias a partir de una copia de seguridad o mediante la recuperación a un momento dado (PITR). Esto te permite recuperar una instancia a un periodo o una hora concretos restaurando la copia de seguridad en una instancia ya creada o en una nueva. Para restaurar una instancia, puedes usar la copia de seguridad de una instancia activa o eliminada. La operación de restauración toma los ajustes, las bases de datos y los usuarios de la instancia de origen y los establece en la instancia de destino que elijas.

Cuando restauras una copia de seguridad en una instancia nueva, la instancia de destino puede estar en una región o un proyecto diferente de la instancia de origen. La instancia de destino también puede usar un número de núcleos o una cantidad de memoria diferentes a los de la instancia de origen.

Cloud SQL siempre asigna a la instancia de destino la capacidad de almacenamiento máxima entre el tamaño del disco configurado y el del disco de copia de seguridad. El disco de copia de seguridad tiene el tamaño del disco en el momento en que se crea la copia de seguridad.

Cuando realices una restauración en una instancia, ten en cuenta lo siguiente:

• La operación de restauración sobrescribe todos los datos en la instancia de destino.
• Las marcas de la instancia de origen no se restauran. Las marcas que se hayan definido previamente en la instancia de destino se conservarán después de la restauración.
• La instancia de destino no está disponible para las conexiones durante la operación de restauración; se pierden las conexiones existentes.
• Si vas a restaurar una instancia con réplicas de lectura, debes eliminar todas las réplicas y volver a crearlas una vez que se haya completado la operación de restauración.
• La operación de restauración reinicia la instancia.
• Después de restaurar una copia de seguridad, las configuraciones de copia de seguridad de la instancia de destino se definen con los valores predeterminados. Si tu instancia de origen tenía configuraciones de copia de seguridad personalizadas o usaba copias de seguridad mejoradas, tendrás que actualizar las configuraciones de copia de seguridad una vez que se haya completado la restauración.

Restaurar con una copia de seguridad

Cloud SQL te permite restaurar una instancia mediante una copia de seguridad. Puedes usar una copia de seguridad de una instancia activa o eliminada para restaurarla en una instancia nueva o ya creada. Puedes usar cualquier copia de seguridad disponible para restaurar la instancia. Para obtener más información sobre cómo funcionan las copias de seguridad en Cloud SQL, consulta el resumen de copias de seguridad.

Cuando restauras una instancia a partir de una copia de seguridad, puedes hacer lo siguiente:

• Restaurar en una instancia nueva
• Restaurar en una instancia
• Restaurar en una instancia de otro proyecto o región

En caso de interrupción, puedes consultar una lista de copias de seguridad de un proyecto concreto para restaurar una.

Para restaurar una instancia mediante una copia de seguridad, consulta Restaurar una instancia mediante una copia de seguridad.

Recuperación a un momento dado (PITR)

La recuperación a un momento dado te permite restaurar tu instancia a un momento específico de la base de datos. Por ejemplo, si un error provoca una pérdida de datos, puedes recuperar el estado de una base de datos antes de que se produjera el error. A diferencia de la restauración mediante una copia de seguridad, la restauración a un momento dado siempre crea una instancia nueva. No puedes realizar una restauración a un momento dado en una instancia. La nueva instancia hereda la configuración de la instancia de origen, como cuando crea un clon.

Si creas una instancia de la edición Enterprise Plus de Cloud SQL, PITR estará habilitado de forma predeterminada. Tienes que inhabilitar la función manualmente.

Si creas una instancia de la edición Enterprise de Cloud SQL en la Google Cloud consola, PITR estará habilitado de forma predeterminada. Si creas una instancia de Cloud SQL para MySQL con la alta disponibilidad habilitada, PITR también se habilitará de forma predeterminada. De lo contrario, si creas la instancia mediante la CLI de gcloud, Terraform o la API Cloud SQL Admin, la restauración a un momento dado estará inhabilitada de forma predeterminada. Para habilitar PITR en estas instancias, debes hacerlo manualmente.

Para ver instrucciones detalladas sobre cómo realizar una recuperación a un momento dado, consulta Usar la recuperación a un momento dado (PITR).

Almacenamiento de registros para PITR

PITR usa el registro binario para archivar registros. Cuando restauras una instancia con una copia de seguridad, estos registros de archivo se eliminan y no estarán disponibles para realizar una PITR. Solo se pueden usar los registros nuevos generados después de que se complete la PITR.

El 11 de agosto del 2023, lanzamos el almacenamiento de registros de transacciones para PITR en Cloud Storage. Desde el lanzamiento, se aplican las siguientes condiciones:

• Todas las instancias de la edición Cloud SQL Enterprise Plus almacenan sus registros binarios, que se usan para PITR, en Cloud Storage. Solo las instancias de la edición Cloud SQL Enterprise Plus a las que hayas actualizado desde la edición Cloud SQL Enterprise antes del 1 de abril del 2024 y que tuvieran habilitada la recuperación a un momento dado antes del 11 de agosto del 2023 seguirán almacenando sus registros para la recuperación a un momento dado en el disco.

• Las instancias de la edición Enterprise de Cloud SQL creadas con PITR habilitado antes del 11 de agosto del 2023 seguirán almacenando sus registros para PITR en el disco.

  Nota: En el caso de las instancias creadas antes del 11 de agosto del 2023, Cloud SQL cambia automáticamente la ubicación de los registros de transacciones que se usan para la recuperación a un momento dado. Puedes usar gcloud CLI o la API Cloud SQL Admin para consultar dónde se almacenan los registros de transacciones de tu instancia.

• Si actualizas a la edición Enterprise Plus de Cloud SQL una instancia de la edición Enterprise de Cloud SQL que almacena registros de transacciones para la recuperación a un momento dado en el disco después del 11 de agosto del 2023, el proceso de actualización cambiará la ubicación de almacenamiento de los registros de transacciones que se usan para la recuperación a un momento dado a Cloud Storage. Para obtener más información, consulta el artículo Actualizar una instancia a la edición Enterprise Plus de Cloud SQL mediante una actualización in situ.

• Todas las instancias de la edición Enterprise de Cloud SQL que crees con la función PITR habilitada después del 11 de agosto del 2023 almacenan los registros utilizados para PITR en Cloud Storage.

Si tu instancia usa Cloud Storage para almacenar registros binarios, estos se almacenan en la misma región que la instancia principal. Estos registros se almacenan durante un máximo de 35 días en la edición Enterprise Plus de Cloud SQL y durante 7 días en la edición Enterprise de Cloud SQL, y no generan ningún coste adicional por instancia.

Para obtener más información sobre cómo comprobar la ubicación de almacenamiento de los registros de transacciones que se usan en la restauración a un momento dado, consulta Comprobar dónde se almacenan los registros de transacciones de una instancia.

En las instancias que almacenan registros binarios solo en el disco, puedes cambiar la ubicación de almacenamiento de los registros de transacciones que se usan para la recuperación a un punto en el tiempo del disco a Cloud Storage mediante la CLI de gcloud o la API Admin de Cloud SQL. Para obtener más información, consulta Cambiar el almacenamiento de los registros de transacciones a Cloud Storage.

Precaución: Si mueves los registros de transacciones del disco a Cloud Storage, se producirá un tiempo de inactividad de varios minutos y se perderán los registros anteriores de PITR. El tiempo de inactividad se debe a que las instancias deben reiniciarse y los registros se borran al desactivar PITR.

Para asegurarte de que los registros de tu instancia se almacenan en Cloud Storage en lugar de en el disco, haz lo siguiente:

• Comprueba la arquitectura de red de la instancia. Si la instancia usa la arquitectura de red antigua, actualízala a la nueva arquitectura de red.

• Si el tamaño de los registros en el disco está provocando problemas de rendimiento en tu instancia, desactiva PITR y vuelve a habilitarlo. De esta forma, los nuevos registros se almacenan en Cloud Storage en lugar de en el disco.

  Advertencia: Si desactivas y vuelves a activar PITR, se eliminarán todos los registros y no podrás realizar PITR antes de la hora en la que lo hayas vuelto a activar. Para habilitar y desactivar PITR, es necesario reiniciar la base de datos.

Periodo de conservación de los registros

Cloud SQL conserva los registros de transacciones en Cloud Storage durante el tiempo que se haya definido en el ajuste de configuración transactionLogRetentionDays PITR. Este valor puede oscilar entre 1 y 35 días en la edición Cloud SQL Enterprise Plus, y entre 1 y 7 días en la edición Cloud SQL Enterprise. Si no se define ningún valor para este parámetro, el periodo de conservación predeterminado de los registros de transacciones es de 14 días para las instancias de la edición Enterprise Plus de Cloud SQL y de 7 días para las instancias de la edición Enterprise de Cloud SQL. Para obtener más información sobre cómo definir los días de retención del registro de transacciones, consulta Definir la retención del registro de transacciones.

Aunque una instancia almacena los registros binarios que se usan para PITR en Cloud Storage, la instancia también conserva un número menor de registros binarios duplicados en el disco para permitir la replicación de los registros en Cloud Storage. De forma predeterminada, cuando creas una instancia con PITR habilitado, la instancia almacena sus registros binarios para PITR en Cloud Storage. Cloud SQL también define automáticamente el valor de las marcas expire_logs_days y binlog_expire_logs_seconds en el equivalente a un día. Esto equivale a un día de registros en el disco.

En el caso de los registros binarios de PITR que se almacenan en el disco, que se están cambiando a Cloud Storage o que ya se han cambiado a Cloud Storage, Cloud SQL conserva los registros durante el valor mínimo establecido para una de las siguientes configuraciones:

• El ajuste de configuración de copia de seguridad transactionLogRetentionDays
• La marca expire_logs_days o binlog_expire_logs_seconds

Cloud SQL no asigna ningún valor a estas marcas si los registros binarios se almacenan en el disco, se están cambiando a Cloud Storage o ya se han cambiado a Cloud Storage. Cuando los registros se almacenan en el disco, modificar los valores de estas marcas puede afectar al comportamiento de la recuperación PITR y al número de días de registros que se almacenan en el disco. Mientras se cambia la ubicación de almacenamiento de los registros a Cloud Storage, no puedes modificar los valores de las marcas. Tampoco le recomendamos que configure ninguno de los valores de las marcas como 0. Para obtener más información, consulta el artículo sobre cómo configurar marcas de bases de datos.

Nota: Si tu instancia tiene un gran número de registros binarios en el disco y quieres ahorrar espacio en disco, te recomendamos que reduzcas lentamente el valor de lo siguiente:

• transactionLogRetentionDays de configuración
• expire_logs_days marca de base de datos
• binlog_expire_logs_seconds marca de base de datos

Por ejemplo, para evitar problemas de rendimiento, reduce el valor de las marcas en un día cada día durante varios días. Por lo tanto, Cloud SQL no purga todos los registros binarios simultáneamente.

En las instancias con claves de cifrado gestionadas por el cliente (CMEK), los registros binarios se cifran con la versión más reciente de la CMEK. Para realizar una restauración, se necesita la versión más reciente de la clave de todos los días que se conserven como parte del parámetro retained-transaction-log-days.

Registros y uso del disco

Los registros se generan periódicamente y usan espacio de almacenamiento. Los registros binarios se eliminan automáticamente junto con la copia de seguridad automática asociada, lo que ocurre cuando se alcanza el valor establecido para transactionLogRetentionDays.

Para saber cuánto espacio en disco están usando los registros binarios, consulta la métrica bytes_used_by_data_type de la instancia. El valor del tipo de datos binlog devuelve el tamaño de los archivos de registro binario en el disco. En las instancias que almacenan registros de transacciones usados para PITR en el disco, Cloud SQL purga los datos del disco a diario para cumplir el ajuste de transactionLogRetentionDaysPITR, tal como se describe en Retención de copias de seguridad automáticas y registros de transacciones. Sin embargo, si asignas a las marcas expire_logs_days o binlog_expire_logs_seconds un valor inferior a los días de conservación de los registros de transacciones, Cloud SQL podrá purgar los registros binarios antes.

Si el tamaño de los registros binarios está causando un problema en tu instancia, haz lo siguiente:

• Comprueba si tu instancia almacena registros en el disco. Puedes cambiar la ubicación de almacenamiento de los registros que usa Cloud SQL para la recuperación a un momento dado del disco a Cloud Storage sin tiempo de inactividad mediante la CLI de gcloud o la API Admin de Cloud SQL. Si usas la edición Enterprise de Cloud SQL, también puedes actualizar a la edición Enterprise Plus de Cloud SQL para cambiar la ubicación de almacenamiento de tus registros de PITR.

• Puedes aumentar el tamaño del almacenamiento de la instancia. Sin embargo, el aumento del tamaño del registro binario en el uso del disco puede ser temporal.

• Le recomendamos que habilite el aumento automático del almacenamiento para evitar problemas inesperados con el almacenamiento.

Para obtener más información sobre la recuperación a un momento dado, consulta Recuperación a un momento dado (PITR).

Una vez que hayas completado el cambio de la ubicación de almacenamiento de los registros de transacciones a Cloud Storage, puedes liberar espacio en disco reduciendo los valores de las marcas expire_logs_days o binlog_expire_logs_seconds. Para comprobar el estado del interruptor, consulta Comprobar la ubicación de almacenamiento de los registros de transacciones utilizados para la restauración a un momento dado. Si quieres que haya más registros disponibles en el disco (por ejemplo, para consultar los registros binarios con la utilidad mysqlbinlog), aumenta los valores de estas marcas. Cloud SQL conserva los registros binarios en el disco durante el número mínimo de días de conservación de los registros de transacciones o los valores definidos para las marcas. Para obtener más información sobre cómo se almacenan los registros de PITR después del cambio y cómo liberar espacio en disco, consulta Registros después del cambio a Cloud Storage.

Nota: Es posible que algunas instancias creadas entre junio y agosto del 2023 tengan los valores de las marcas expire_logs_days o binlog_expire_logs_seconds definidos automáticamente como el equivalente a 7 días.

Limitaciones de PITR

Las siguientes limitaciones están asociadas a que tu instancia tenga habilitada la recuperación a un punto en el tiempo y a que el tamaño de los registros de transacciones en el disco provoque un problema en tu instancia:

• Puedes desactivar PITR y volver a habilitarlo para asegurarte de que Cloud SQL almacene los registros en Cloud Storage en la misma región que la instancia. Sin embargo, Cloud SQL elimina los registros existentes, por lo que no puedes realizar una operación de PITR anterior al momento en que volviste a habilitar PITR.
• Puedes aumentar el tamaño del almacenamiento de la instancia, pero el aumento del tamaño del registro de transacciones en el uso del disco puede ser temporal.
• Para evitar problemas de almacenamiento inesperados, le recomendamos que habilite los aumentos automáticos del almacenamiento. Esta recomendación solo se aplica si tu instancia tiene habilitada la recuperación a un momento dado y tus registros se almacenan en el disco.

• Si quieres eliminar registros y recuperar almacenamiento, puedes desactivar PITR sin volver a habilitarlo. Sin embargo, reducir el almacenamiento utilizado no disminuye el tamaño del disco aprovisionado para la instancia.

• Los registros se purgan una vez al día, no de forma continua. Si se define la retención de registros en dos días, se conservarán al menos dos días de registros y, como máximo, tres. Te recomendamos que definas el número de copias de seguridad como uno más que los días de conservación de registros.

  Por ejemplo, si especifica 7 como valor del parámetro transactionLogRetentionDays, en el parámetro backupRetentionSettings, defina el número de retainedBackups en 8.

Para ver instrucciones detalladas sobre cómo realizar una recuperación a un momento dado, consulta [Usar la recuperación a un momento dado (PITR)][perform-pitr].

Restaurar una instancia no disponible

Puedes usar PITR para restaurar una instancia de Cloud SQL que no esté disponible. PITR suele ofrecer un objetivo de punto de recuperación (RPO) de cinco minutos o menos.

Si la instancia no está disponible, puedes usar la API para obtener la hora de recuperación más antigua y más reciente a la que puedes restaurar la instancia y realizar la recuperación a esa hora. Si no se puede acceder a la zona en la que está configurada la instancia, puedes restaurar la instancia en otra zona principal o secundaria proporcionando valores para las zonas preferidas.

Supongamos que una instancia de Cloud SQL deja de estar disponible a las 16:00 (EST). Si la hora de recuperación más reciente es las 15:55 (EST), puedes recuperar la instancia hasta esa hora.

Restaurar una instancia eliminada mediante PITR

Puedes usar PITR para restaurar una instancia de Cloud SQL después de eliminarla. Para usar esta función, tu instancia debe tener habilitadas las opciones PITR y copias de seguridad conservadas antes de que se elimine la instancia. Si está habilitada, los registros de PITR se conservan después de eliminar la instancia.

Una vez que se elimina una instancia, los registros de PITR siguen las opciones de conservación definidas por la instancia cuando estaba activa. Los registros de PITR caducan en función de los ajustes de conservación de forma continua después de que se elimine la instancia. El periodo continuo se define en función del periodo de conservación de PITR establecido en la instancia antes de la eliminación. Por ejemplo, si tu instancia de la edición Enterprise Plus de Cloud SQL tiene una conservación de PITR de 14 días, el registro de PITR más reciente se eliminará 14 días después de la eliminación de la instancia. Cuando caduca un registro de PITR, no se puede recuperar.

Como los nombres de las instancias se pueden reutilizar después de eliminar una instancia en Cloud SQL, los registros de PITR conservados se pueden identificar en Google Cloud con los siguientes campos:

• instance_deletion_time
• log_retention_days

Estos campos le permiten identificar si un registro de PITR pertenece a una instancia eliminada.

El periodo de recuperación de PITR se define como los momentos de recuperación más antiguos y más recientes disponibles para restaurar tu instancia mediante PITR. Para consultar las horas de recuperación más antiguas y más recientes de tu instancia eliminada, consulta Obtener las horas de recuperación más antiguas y más recientes.

Para restaurar una instancia mediante PITR después de eliminarla, consulta Realizar una recuperación a un momento dado en una instancia eliminada.

Requisitos para restaurar una copia de seguridad en una instancia nueva

Cuando restaure su instancia en una nueva, tenga en cuenta los siguientes requisitos:

• La instancia de destino debe tener la misma versión de base de datos que la instancia de la que se tomó la copia de seguridad.

• La capacidad de almacenamiento de la instancia de destino debe ser al menos igual que la capacidad de la instancia de la que se va a crear la copia de seguridad. La cantidad de almacenamiento utilizado no importa. Puedes ver la capacidad de almacenamiento de la instancia en la página de instancias de Cloud SQL de la consola.

• La instancia de destino debe tener en el estado RUNNABLE.

Restaurar las limitaciones de frecuencia

Puedes realizar un máximo de tres operaciones de restauración cada 30 minutos por instancia, región y proyecto. Si falla una operación de restauración, no se tendrá en cuenta para esta cuota. Si alcanzas el límite, la operación fallará y recibirás un mensaje de error que te indicará cuándo podrás volver a ejecutarla.

Cloud SQL usa tokens de un contenedor para determinar cuántas operaciones de restauración están disponibles en un momento dado. Por cada copia de seguridad, hay un contenedor para cada proyecto y región de destino. Las instancias de destino del mismo proyecto comparten un segmento si están en la misma región. Puedes usar un máximo de tres tokens en cada contenedor para las operaciones de restauración. Cada 10 minutos, se añade un nuevo token al contenedor. Si el contenedor está lleno, el token se desborda.

Cada vez que emites una operación de restauración, se concede un token del contenedor. Si la operación se realiza correctamente, el token se elimina del segmento. Si falla, el token se devuelve al contenedor. En el siguiente diagrama se muestra cómo funciona:

Por ejemplo, en la siguiente figura, CopiaSeguridad1, CopiaSeguridad2 y CopiaSeguridad3 son copias de seguridad de la misma instancia de origen.

• Cada copia de seguridad (Copia de seguridad 1, Copia de seguridad 2 y Copia de seguridad 3) tiene su propio segmento de tokens para las operaciones de restauración que se dirigen a diferentes instancias del proyecto 1 en la región A (Segmento11A, Segmento21A y Segmento31A). Como cada copia de seguridad tiene su propio contenedor, puedes restaurar cada copia de seguridad en la misma instancia tres veces cada 30 minutos.
• Cada copia de seguridad tiene un contenedor para un proyecto y una región independientes. Por ejemplo, si hay cinco proyectos en una región, habrá cinco segmentos para esa copia de seguridad en esa región, uno en cada proyecto. En la figura anterior, tenemos dos proyectos en la región A: Proyecto 1 y Proyecto n.
  • Backup1 tiene dos cubos de tokens para las operaciones de restauración en la región A. Un segmento para el proyecto 1 (Segmento11A) y un segmento para el proyecto n (Segmento1nA).
  • Del mismo modo, Backup3 tiene dos cubos para las operaciones de restauración en la región A. Una para el proyecto 1 (Bucket31A) y otra para el proyecto n (Bucket3nA).
• Backup3 tiene un segmento en la región B para Project1, ya que todas las instancias del mismo proyecto de destino y de la misma región de destino comparten un segmento.

Siguientes pasos

• Restaurar a partir de una copia de seguridad
• Usar la recuperación a un momento dado (PITR)