AlloyDB saca la copia de seguridad de la región y la encierra bajo llave

No debe confundirse una copia entre regiones con una réplica operativa. La replicación está pensada para reducir el tiempo de conmutación y mantener un sistema cercano al estado actual; también puede propagar errores lógicos o borrados. El backup conserva puntos históricos y suele aceptar un RTO mayor. Un diseño serio combina ambos mecanismos cuando el negocio lo exige, asigna a cada uno un objetivo de punto de recuperación y un objetivo de tiempo de recuperación, y documenta qué incidentes cubre. Comprar la función sin esa tabla de decisiones es simplemente pagar por una sensación de seguridad.

La arquitectura también obliga a mirar los límites menos comerciales. El plan de copia y el vault asociado deben residir en el mismo proyecto, aunque los datos puedan protegerse en otra región. Los permisos de creación, asociación y borrado deben separarse con IAM de mínimo privilegio. La retención mínima del vault condiciona las reglas del plan, y las copias bajo retención forzada no se eliminan a voluntad. Desde noviembre, Google aplicará además un lien al proyecto que contenga un vault con copias protegidas, con opciones de aprobación múltiple para asegurar su retirada. Es una salvaguarda útil, pero puede sorprender a procesos de cierre de proyectos poco maduros.

En costes, la región secundaria implica almacenamiento adicional y puede añadir transferencia, operaciones de recuperación y recursos temporales durante una prueba. La factura correcta no se estima sólo con gigabytes retenidos: incluye la frecuencia, la duración, el crecimiento de logs, el número de restauraciones de ensayo y el entorno donde se valida la aplicación. También hay un coste de oportunidad si el equipo nunca automatiza la comprobación. Una copia que termina con estado correcto en la consola no demuestra que la base arranque, que las extensiones estén presentes, que las identidades funcionen ni que la aplicación tolere el cambio de punto final.

La aplicación práctica debería empezar con un piloto delimitado. Elegir un clúster no crítico, crear el vault en el proyecto de protección, fijar retención, configurar la región secundaria y ejecutar una restauración completa en un proyecto o entorno aislado. Después se miden los tiempos reales, se verifican recuentos y checksums, se prueban permisos de aplicación y se destruye el entorno temporal siguiendo un procedimiento aprobado. Ese ejercicio produce el dato que interesa al negocio: cuánto se tarda en volver y qué tareas siguen siendo manuales.

Lo que conviene vigilar es la cobertura regional efectiva, el comportamiento de las claves durante una emergencia, la integración con informes de cumplimiento y el coste de las restauraciones periódicas. La disponibilidad general elimina una excusa técnica, no el trabajo de operación. La regla antigua conserva toda su vigencia: si la restauración no se ha probado, la copia es una promesa y las promesas no levantan bases de datos.