Esta página proporciona información para revisar antes de restaurar una instancia desde una copia de seguridad o realizar una recuperación de un punto en el tiempo (PITR).
¿Qué sucede durante una restauración?
En las ediciones Cloud SQL Enterprise y Cloud SQL Enterprise Plus, puede restaurar una instancia a partir de una copia de seguridad. También puede restaurar copias de seguridad entre instancias de diferentes ediciones.
Cuando se restaura una instancia, los siguientes datos de la instancia principal se restauran a la nueva instancia:
- Bases de datos
- Usuarios
La operación de restauración hace que la instancia se reinicie.
Recuperación en un punto en el tiempo (PITR)
La recuperación a un punto en el tiempo (PITR) le ayuda a recuperar una instancia a un punto específico. Por ejemplo, si un error provoca una pérdida de datos, puede recuperar una base de datos a su estado anterior al error.
PITR siempre crea una nueva instancia; no se puede ejecutar PITR en una instancia existente. La nueva instancia hereda la configuración de la instancia de origen, de forma similar a cómo funciona la creación de clones .
Cuando crea una instancia de Cloud SQL en el Google Cloud consola, PITR está habilitado de forma predeterminada.PITR utiliza el archivado de registro de escritura anticipada (WAL) . De forma predeterminada, PITR está habilitado para las instancias de Cloud SQL Enterprise Plus.
Al restaurar una copia de seguridad en una instancia de Cloud SQL antes de habilitar PITR, se pierden los registros archivados que permiten usar PITR. Si el tamaño de los registros de escritura anticipada en el disco está causando problemas de rendimiento en la instancia, desactive PITR y vuelva a habilitarlo. Esto garantiza que los nuevos registros se almacenen en Cloud Storage en lugar de en el disco.Para obtener instrucciones paso a paso sobre cómo realizar PITR, consulte Usar recuperación de punto en el tiempo (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, puede usar la API para verificar la última hora a la que puede restaurarla y realizar la recuperación a esa hora. Si la zona en la que está configurada la instancia no es accesible, puede restaurarla a una zona principal o secundaria diferente proporcionando valores para las zonas preferidas.
Supongamos que una instancia de Cloud SQL deja de estar disponible a las 16:00 EST. Si la última hora de recuperación es a las 15:55 EST, podrá recuperar la instancia hasta esa hora.
Consejos generales sobre cómo realizar una restauración
Al restaurar una instancia desde una copia de seguridad, ya sea en la misma instancia o en una instancia diferente, tenga en cuenta lo siguiente:
- La operación de restauración sobrescribe todos los datos en la instancia de destino.
- La instancia de destino no está disponible para las conexiones durante la operación de restauración; se pierden las conexiones existentes.
- Si está restaurando una instancia con réplicas de lectura, debe eliminar todas las réplicas y volver a crearlas una vez que se complete la operación de restauración.
- La operación de restauración reinicia la instancia.
Para obtener instrucciones paso a paso sobre cómo realizar una restauración, consulte:
Consejos y requisitos para restaurar a una instancia diferente
Al restaurar una copia de seguridad en una instancia diferente, tenga en cuenta las siguientes restricciones y prácticas recomendadas:
La instancia de destino debe tener la misma versión de base de datos que la instancia desde la cual se realizó la copia de seguridad.
Cloud SQL siempre establece la capacidad de almacenamiento de la instancia de destino al valor máximo del tamaño del disco configurado y del disco de respaldo. El disco de respaldo tiene el tamaño del disco al momento de realizar la copia de seguridad.
La capacidad de almacenamiento de la instancia de destino debe ser al menos igual a la capacidad de la instancia de la que se va a realizar la copia de seguridad. La cantidad de almacenamiento utilizada no importa. Puede consultar la capacidad de almacenamiento de la instancia en la página de instancias de Cloud SQL de la consola.
La instancia de destino debe estar en estado
RUNNABLE.La instancia de destino puede tener una cantidad de núcleos o de memoria diferente a la instancia desde la cual se realizó la copia de seguridad.
La instancia de destino puede estar en una región diferente de la instancia de origen.
Durante una interrupción, aún puede recuperar una lista de copias de seguridad de un proyecto específico. Consulte "Ver copias de seguridad durante una interrupción" .
Restablecer limitaciones de velocidad
Se permite un máximo de tres operaciones de restauración cada 30 minutos por instancia, por región y por proyecto. Si una operación de restauración falla, no se contabiliza para esta cuota. Si se alcanza el límite, la operación falla y se muestra un mensaje de error que indica cuándo se puede volver a ejecutar.
Veamos cómo Cloud SQL realiza la limitación de velocidad para las restauraciones.
Cloud SQL usa tokens de un bucket para determinar cuántas operaciones de restauración están disponibles en un momento dado. Para cada copia de seguridad, hay un bucket para cada proyecto y región de destino. Las instancias de destino del mismo proyecto comparten un bucket si se encuentran en la misma región. Hay un máximo de tres tokens en cada bucket que se pueden usar para operaciones de restauración. Cada 10 minutos, se añade un nuevo token al bucket. Si el bucket está lleno, el token se desborda.
Cada vez que se ejecuta una operación de restauración, se otorga un token del depósito. Si la operación se realiza correctamente, el token se elimina del depósito. Si falla, se devuelve al depósito. El siguiente diagrama muestra cómo funciona:
Por ejemplo, en la siguiente figura, Backup1, Backup2 y Backup3 son las 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 contenedor de tokens para operaciones de restauración dirigidas a diferentes instancias del Proyecto 1 en la Región A (Cubo 11A, Cubo 21A y Cubo 31A). Dado que cada copia de seguridad tiene su propio contenedor, puede restaurar cada copia de seguridad en la misma instancia tres veces cada treinta minutos.
- Cada copia de seguridad tiene un contenedor para un proyecto y una región distintos. Por ejemplo, si hay cinco proyectos en una región, hay cinco contenedores 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 grupos de tokens para operaciones de restauración en la Región A. Un grupo para el Proyecto 1 (Bucket11A) y un grupo para el Proyecto n (Bucket1nA).
- De manera similar, Backup3 tiene dos depósitos para operaciones de restauración en la Región A. Uno para el Proyecto 1 (Bucket31A) y otro para el Proyecto n (Bucket3nA).
- Backup3 tiene un depósito en la Región B, para el Proyecto1, porque todas las instancias en el mismo proyecto de destino y la misma región de destino comparten un depósito.
¿Qué sigue?
- Realizar una restauración desde una copia de seguridad
- Utilice la recuperación en un punto determinado del tiempo (PITR)
Esta página proporciona información para revisar antes de restaurar una instancia desde una copia de seguridad o realizar una recuperación de un punto en el tiempo (PITR).
¿Qué sucede durante una restauración?
En las ediciones Cloud SQL Enterprise y Cloud SQL Enterprise Plus, puede restaurar una instancia a partir de una copia de seguridad. También puede restaurar copias de seguridad entre instancias de diferentes ediciones.
Cuando se restaura una instancia, los siguientes datos de la instancia principal se restauran a la nueva instancia:
- Bases de datos
- Usuarios
La operación de restauración hace que la instancia se reinicie.
Recuperación en un punto en el tiempo (PITR)
La recuperación a un punto en el tiempo (PITR) le ayuda a recuperar una instancia a un punto específico. Por ejemplo, si un error provoca una pérdida de datos, puede recuperar una base de datos a su estado anterior al error.
PITR siempre crea una nueva instancia; no se puede ejecutar PITR en una instancia existente. La nueva instancia hereda la configuración de la instancia de origen, de forma similar a cómo funciona la creación de clones .
Cuando crea una instancia de Cloud SQL en el Google Cloud consola, PITR está habilitado de forma predeterminada.PITR utiliza el archivado de registro de escritura anticipada (WAL) . De forma predeterminada, PITR está habilitado para las instancias de Cloud SQL Enterprise Plus.
Al restaurar una copia de seguridad en una instancia de Cloud SQL antes de habilitar PITR, se pierden los registros archivados que permiten usar PITR. Si el tamaño de los registros de escritura anticipada en el disco está causando problemas de rendimiento en la instancia, desactive PITR y vuelva a habilitarlo. Esto garantiza que los nuevos registros se almacenen en Cloud Storage en lugar de en el disco.Para obtener instrucciones paso a paso sobre cómo realizar PITR, consulte Usar recuperación de punto en el tiempo (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, puede usar la API para verificar la última hora a la que puede restaurarla y realizar la recuperación a esa hora. Si la zona en la que está configurada la instancia no es accesible, puede restaurarla a una zona principal o secundaria diferente proporcionando valores para las zonas preferidas.
Supongamos que una instancia de Cloud SQL deja de estar disponible a las 16:00 EST. Si la última hora de recuperación es a las 15:55 EST, podrá recuperar la instancia hasta esa hora.
Consejos generales sobre cómo realizar una restauración
Al restaurar una instancia desde una copia de seguridad, ya sea en la misma instancia o en una instancia diferente, tenga en cuenta lo siguiente:
- La operación de restauración sobrescribe todos los datos en la instancia de destino.
- La instancia de destino no está disponible para las conexiones durante la operación de restauración; se pierden las conexiones existentes.
- Si está restaurando una instancia con réplicas de lectura, debe eliminar todas las réplicas y volver a crearlas una vez que se complete la operación de restauración.
- La operación de restauración reinicia la instancia.
Para obtener instrucciones paso a paso sobre cómo realizar una restauración, consulte:
Consejos y requisitos para restaurar a una instancia diferente
Al restaurar una copia de seguridad en una instancia diferente, tenga en cuenta las siguientes restricciones y prácticas recomendadas:
La instancia de destino debe tener la misma versión de base de datos que la instancia desde la cual se realizó la copia de seguridad.
Cloud SQL siempre establece la capacidad de almacenamiento de la instancia de destino al valor máximo del tamaño del disco configurado y del disco de respaldo. El disco de respaldo tiene el tamaño del disco al momento de realizar la copia de seguridad.
La capacidad de almacenamiento de la instancia de destino debe ser al menos igual a la capacidad de la instancia de la que se va a realizar la copia de seguridad. La cantidad de almacenamiento utilizada no importa. Puede consultar la capacidad de almacenamiento de la instancia en la página de instancias de Cloud SQL de la consola.
La instancia de destino debe estar en estado
RUNNABLE.La instancia de destino puede tener una cantidad de núcleos o de memoria diferente a la instancia desde la cual se realizó la copia de seguridad.
La instancia de destino puede estar en una región diferente de la instancia de origen.
Durante una interrupción, aún puede recuperar una lista de copias de seguridad de un proyecto específico. Consulte "Ver copias de seguridad durante una interrupción" .
Restablecer limitaciones de velocidad
Se permite un máximo de tres operaciones de restauración cada 30 minutos por instancia, por región y por proyecto. Si una operación de restauración falla, no se contabiliza para esta cuota. Si se alcanza el límite, la operación falla y se muestra un mensaje de error que indica cuándo se puede volver a ejecutar.
Veamos cómo Cloud SQL realiza la limitación de velocidad para las restauraciones.
Cloud SQL usa tokens de un bucket para determinar cuántas operaciones de restauración están disponibles en un momento dado. Para cada copia de seguridad, hay un bucket para cada proyecto y región de destino. Las instancias de destino del mismo proyecto comparten un bucket si se encuentran en la misma región. Hay un máximo de tres tokens en cada bucket que se pueden usar para operaciones de restauración. Cada 10 minutos, se añade un nuevo token al bucket. Si el bucket está lleno, el token se desborda.
Cada vez que se ejecuta una operación de restauración, se otorga un token del depósito. Si la operación se realiza correctamente, el token se elimina del depósito. Si falla, se devuelve al depósito. El siguiente diagrama muestra cómo funciona:
Por ejemplo, en la siguiente figura, Backup1, Backup2 y Backup3 son las 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 contenedor de tokens para operaciones de restauración dirigidas a diferentes instancias del Proyecto 1 en la Región A (Cubo 11A, Cubo 21A y Cubo 31A). Dado que cada copia de seguridad tiene su propio contenedor, puede restaurar cada copia de seguridad en la misma instancia tres veces cada treinta minutos.
- Cada copia de seguridad tiene un contenedor para un proyecto y una región distintos. Por ejemplo, si hay cinco proyectos en una región, hay cinco contenedores 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 grupos de tokens para operaciones de restauración en la Región A. Un grupo para el Proyecto 1 (Bucket11A) y un grupo para el Proyecto n (Bucket1nA).
- De manera similar, Backup3 tiene dos depósitos para operaciones de restauración en la Región A. Uno para el Proyecto 1 (Bucket31A) y otro para el Proyecto n (Bucket3nA).
- Backup3 tiene un depósito en la Región B, para el Proyecto1, porque todas las instancias en el mismo proyecto de destino y la misma región de destino comparten un depósito.
¿Qué sigue?
- Realizar una restauración desde una copia de seguridad
- Utilice la recuperación en un punto determinado del tiempo (PITR)