La llamada siempre suena igual. Alguien corrió un UPDATE contra la base de producción sin WHERE, o un script de despliegue borró una tabla que debía renombrar, y unos miles de registros quedaron mal. La base corre en Cloud SQL, el respaldo está activado, y la calma dura unos cuatro minutos. Después alguien hace la pregunta de verdad: ¿aquí alguien ha restaurado alguna vez uno de esos respaldos?
Casi siempre la respuesta es no. Los respaldos se activaron cuando se creó la instancia, nadie volvió a tocar la configuración, y la retención es la que venía por defecto. Eso no es un plan de recuperación. Es una esperanza con una casilla marcada al lado. Lo que sigue es la lista que revisamos antes de dar por segura la base de un cliente.
Paso 1: averiguar qué significa aquí "los respaldos están activados"
Dos configuraciones se confunden todo el tiempo y hacen cosas distintas. Los respaldos automáticos te dan un conjunto de puntos de restauración, uno por día. La recuperación a un momento específico (PITR) guarda los registros de transacciones entre esos puntos, para que puedas caer en un instante concreto en lugar de en anoche. Necesitas las dos para recuperarte de un error cometido a las 11:40 de esta mañana, y la documentación de Google es explícita: PITR requiere que la instancia de origen tenga respaldos automáticos y registro de transacciones activados.
Cómo se creó la instancia define qué te tocó gratis. Los respaldos automáticos vienen activados por defecto cuando creas la instancia en la consola de Google Cloud, pero si la instancia salió de la CLI de gcloud, de Terraform o de la API de administración de Cloud SQL, tienes que activarlos tú (consultado el 20 de octubre de 2026). PITR viene activado por defecto en las instancias de Cloud SQL Enterprise Plus, sin importar el método de creación, y hay que desactivarlo a propósito. En la edición Enterprise es una decisión que alguien tuvo que tomar. Muchas bases provisionadas con Terraform que heredamos no tienen ninguna de las dos.
Después leemos tres valores en lugar de confiar en la casilla:
- Retención de respaldos. Va de 7 a 365 días, y el valor por defecto depende de la edición: 7 días en Cloud SQL Enterprise y 15 en Enterprise Plus. Las páginas por motor no coinciden del todo en el mínimo, así que revisa la página de tu motor y no la nuestra.
- Retención de registros de transacciones. Esta es la que nadie ha visto nunca. En Enterprise Plus el rango válido es de 1 a 35 días con 14 por defecto. En Enterprise es de 1 a 7 días con 7 por defecto. Ese número, y no la cantidad de respaldos, es hasta dónde puede llegar hacia atrás una recuperación a un momento específico.
- Ventana y ubicación del respaldo. Defines una hora de inicio en formato de 24 horas UTC, y esa hora abre una ventana de cuatro horas dentro de la cual puede empezar el respaldo. Los respaldos van a la multirregión geográficamente más cercana a la instancia salvo que fijes una ubicación personalizada, y la recomendación de Google es dejar el valor por defecto a menos que una regulación exija una región específica. Si alguien cambia la ubicación después, los respaldos ya tomados se quedan donde estaban.
Digamos una empresa de 12 personas con una sola base de pedidos. La lectura honesta suele ser siete puntos de restauración diarios y siete días de registros, heredados por accidente, y nadie ha revisado si esa ventana cubre el error que el equipo comete de verdad.
Paso 2: elegir la opción de recuperación antes de necesitarla
"Respaldado" no es una sola cosa. Cada opción cubre una falla distinta, y el error más caro de toda esta área es suponer que la que tienes cubre la que te toca. Ponemos las opciones frente al cliente y elegimos de forma explícita.
| Opción | De qué te recupera | Qué no cubre |
|---|---|---|
| Respaldo automático (estándar) | Un cambio malo que detectas dentro de la ventana de retención, hasta un punto de restauración diario | Todo lo que pasó entre puntos; el borrado del proyecto completo |
| Recuperación a un momento específico | Un instante dentro del periodo de retención de registros, por ejemplo justo antes de que corriera el script malo | Cualquier cosa más vieja que esos días de registros; restaurar en el mismo lugar, porque PITR siempre crea una instancia nueva |
| Respaldo mejorado en una bóveda | Borrado o manipulación, incluso por alguien con acceso al proyecto, con retención de hasta 10 años según las páginas de MySQL y PostgreSQL | Pérdida de datos reciente con granularidad fina; es una bóveda, no un reemplazo de PITR |
| Alta disponibilidad | La falla de una zona, con conmutación automática dentro de la región | Errores lógicos: un UPDATE malo se replica al instante en la instancia en espera |
| Réplica de lectura en otra región | Una caída de toda una región | Errores lógicos, por la misma razón |
| Exportación a Cloud Storage | Necesitar una copia fuera de Cloud SQL, para una auditoría o para mover la base a otra plataforma | Recuperación rápida; una exportación no es un punto de restauración ni se programa por ti |
Lee dos veces la columna de la derecha. La alta disponibilidad y las réplicas son las opciones que los equipos pequeños confunden con su respaldo, y ninguna protege contra lo que más rompe bases de datos: una persona corriendo SQL correcto contra las filas equivocadas.
Paso 3: hacer la prueba de restauración
Este es el paso que convierte una configuración en una garantía, y es el que nadie hace. Agendamos una hora, restauramos en una instancia nueva y revisamos los datos. Que sea una instancia nueva importa: restaurar sobre una instancia existente sobrescribe todos sus datos actuales, incluidos los registros de PITR anteriores, así que una restauración hecha con prisa contra el destino equivocado destruye la recuperación fina que todavía tenías.
La prueba, en orden:
- Lista lo que de verdad tienes. No la casilla, los respaldos. Confirma que el último respaldo exitoso es de anoche y no de la última vez que alguien cambió una marca de la instancia.
- Restaura el respaldo más reciente en una instancia nueva. Con gcloud es
gcloud sql backups restore, y cuando el respaldo viene de otra instancia tienes que decirlo con--backup-instance. - Haz una restauración a una marca de tiempo. Elige un momento de ayer por la tarde. Eso prueba que los registros de transacciones están ahí de verdad, que es un hecho aparte de que estén los respaldos.
- Consulta la copia restaurada como lo haría la aplicación. Conteos de filas en las tres tablas que importan, el pedido más nuevo, el usuario más nuevo. Una restauración que arranca y una restauración que contiene tus datos son dos eventos distintos.
- Anota el tiempo de reloj. Desde "arrancamos" hasta "la aplicación ya podría apuntar aquí", en minutos. Ese número es tu tiempo real de recuperación, y es la única versión que vale la pena decirle a un cliente.
- Borra la instancia de prueba. Las instancias restauradas se cobran como cualquier otra, y una abandonada es un cargo recurrente que nadie recuerda haber aprobado.
gcloud sql backups restore BACKUP_ID \
--restore-instance=prueba-restauracion-20261020 \
--backup-instance=prod-db
gcloud sql instances patch prod-db \
--enable-bin-log \
--retained-transaction-log-days=7La marca que activa el registro de transacciones se llama distinto según el motor, así que lee la página de tu motor antes de copiar ese segundo comando. La prueba también saca a la luz las restricciones que solo muerden en un incidente real: un respaldo solo se restaura en una instancia con la misma versión de base de datos con la que se tomó; el destino no puede ser una réplica de lectura, y si el destino existente tiene réplicas hay que borrarlas primero; las marcas de la instancia no se traen del origen; y las restauraciones tienen límite de tasa, con un balde de tokens pequeño que se recarga cada diez minutos aproximadamente, lo cual sorprende cuando reintentas bajo presión.
También revisamos quién puede ejecutar la restauración, porque revisarlo es barato. Una restauración entre proyectos necesita cloudsql.instances.restoreBackup en el proyecto destino y cloudsql.backupRuns.get en el de origen, y un respaldo retenido o final también necesita cloudsql.instances.create. Si la única persona con esos permisos está en un avión, el respaldo es teórico.
Paso 4: decidir cuándo la base tiene permiso de reiniciarse
Administrado significa que Google parcha la instancia, y parchar significa un reinicio. Para una base detrás de una tienda, la diferencia entre una buena política de mantenimiento y ninguna es si ese reinicio cae a las 3 de la mañana de un martes o en medio de la facturación del viernes.
Dos controles hacen esto. La ventana de mantenimiento fija el día y la hora que prefieres. Un periodo de denegación de mantenimiento es un bloque de días, hasta 90, en los que Cloud SQL no programa mantenimiento, y tiene precedencia sobre la ventana cuando las dos chocan. Fijar un periodo de denegación en la instancia primaria también deniega el mantenimiento de sus réplicas, que es el comportamiento que quieres y no el que la gente espera.
Tres detalles que planteamos a los clientes. No se puede fijar un periodo de denegación en una instancia cuya versión de mantenimiento tiene más de 12 meses, así que el comercio que quiere diciembre protegido tiene que aceptar una actualización en noviembre. Si omites el año, el periodo se repite cada año, que suele ser lo correcto para una temporada alta. Y las páginas por motor no coinciden en si un periodo de denegación sobrevive a detener y arrancar la instancia, así que en algo crítico lo verificamos en el motor que tenemos enfrente en lugar de citar una regla.
gcloud sql instances patch prod-db \
--deny-maintenance-period-start-date=11-15 \
--deny-maintenance-period-end-date=01-15 \
--deny-maintenance-period-time=00:00:00El mantenimiento por autoservicio no queda bloqueado por un periodo de denegación, así que el equipo puede aplicar una actualización a propósito cuando le convenga.
Paso 5: ponerle precio honesto a la protección
Cada opción de arriba cuesta algo, y a los equipos pequeños les venden primero la más cara. La documentación de precios de Google dice que una configuración de alta disponibilidad cuesta el doble que una instancia individual, e incluye CPU, RAM y almacenamiento (consultado el 20 de octubre de 2026). Ese es el gasto correcto para una base cuya caída detiene los ingresos, y la compra equivocada como primera decisión para una base de reportes internos que nadie toca un domingo. Hemos visto el segundo caso pagando por el primero.
Los movimientos baratos van primero. Más retención de registros compra más historia recuperable, y la documentación señala que los registros guardados en la instancia exigen más almacenamiento, mientras que los guardados en Cloud Storage no agregan cargo por instancia hasta la duración máxima de PITR. Una bóveda compra protección contra el borrado desde dentro del proyecto, con el intercambio de que los respaldos bajo retención forzada no se pueden eliminar antes y se siguen cobrando todo el periodo. El almacenamiento de respaldos se cobra aparte del de la instancia, así que revisa la tarifa vigente en la página de precios de Google y no en el blog de nadie, incluido este.
El orden que recomendamos para una pyme: las dos configuraciones activas y la retención definida a propósito, la prueba de restauración, la ventana de mantenimiento y un periodo de denegación para tu temporada alta, y después la decisión de alta disponibilidad con un número enfrente. Gastar en ese orden es como la protección termina correspondiendo al riesgo.
Cómo ayuda Guanacos Tech
Lo hacemos como un trabajo cerrado: leer la configuración actual de respaldos y de recuperación a un momento específico, hacer una restauración real en una instancia desechable y tomarle el tiempo, fijar la ventana de mantenimiento y el periodo de denegación alrededor del calendario de tu negocio, y dejarte una nota de recuperación de una página que diga qué ejecutar, quién puede ejecutarlo y cuánto tarda. Cuando la base de datos es una parte de algo más grande, se atiende junto con el resto del proyecto en nuestra consultoría de Google Cloud. Agenda una llamada de 30 minutos si quieres saber si tu base de datos regresaría, y te decimos qué encontramos.
Fuentes
- Google Cloud: descripción general de los respaldos de Cloud SQL
- Google Cloud: configurar la recuperación a un momento específico (PITR)
- Google Cloud: restaurar una instancia desde un respaldo
- Google Cloud: elegir tu opción de respaldo
- Google Cloud: actualizaciones de mantenimiento en instancias de Cloud SQL
- Google Cloud: acerca de la alta disponibilidad en Cloud SQL
- Google Cloud: precios de Cloud SQL