Datos en Google Cloud: bases, almacenamiento, mensajería y respaldos

Los datos son la parte difícil de cualquier plan de resiliencia, y la que menos se traduce de una nube a otra. Esta lección compara las bases, el almacenamiento, la mensajería y los respaldos de Google Cloud con sus pares de AWS, con foco en tres preguntas: qué pasa si cae una zona, qué pasa si cae una región y cuántos datos perderías.

Cloud SQL: alta disponibilidad no es recuperación regional

Cloud SQL administra MySQL, PostgreSQL y SQL Server, como RDS. La configuración de alta disponibilidad pone un primario y una espera en otra zona de la misma región, con replicación síncrona: ante una falla, la espera toma el control sin perder transacciones confirmadas. La espera no atiende lecturas, como en RDS Multi-AZ con una sola espera. Para leer, agregas réplicas de lectura.

Cloud SQL es regional: si cae la región, cae la base. El plan básico es una réplica de lectura entre regiones, asíncrona, que promueves durante la caída. Promover rompe la replicación para siempre; volver a la región original es una migración aparte. En Enterprise Plus, la recuperación ante desastres avanzada designa una réplica de DR: el replica failover la promueve ante una caída (puede perder lo que tuviera de retraso) y luego convierte el primario viejo en réplica; el switchover invierte los papeles sin pérdida para simulacros; y el write endpoint es un nombre DNS que siempre apunta al primario vigente.

AlloyDB y Spanner

AlloyDB es PostgreSQL compatible con almacenamiento propio, el par de Aurora PostgreSQL. Su instancia primaria con alta disponibilidad tiene un nodo activo y uno en espera en zonas distintas, con conmutación automática, y grupos de lectura para escalar lecturas. Entre regiones usa clústeres secundarios asíncronos, hasta cinco por primario, como Aurora Global Database. Puedes promover un secundario durante una caída o hacer un switchover sin pérdida para un simulacro.

Spanner es otra categoría. Replica cada escritura de forma síncrona con un protocolo de consenso y usa relojes sincronizados (TrueTime) para dar consistencia externa: las transacciones se ven en el orden en que ocurrieron, en cualquier región. Una configuración regional tiene tres réplicas en tres zonas (SLA de 99,99 %); las configuraciones dual-region y multirregión reparten réplicas y un testigo entre regiones (SLA de 99,999 %). Perder una región no pierde datos confirmados, pero cada escritura paga la latencia del consenso entre regiones.

Criterio	Spanner	Aurora DSQL	DynamoDB global tables
Modelo	Relacional, SQL (GoogleSQL o interfaz PostgreSQL)	Relacional, subconjunto de PostgreSQL	Clave-valor y documentos
Escrituras entre regiones	Síncronas, con región líder por defecto	Activo-activo con consistencia fuerte	Activo-activo; por defecto el último en escribir gana; opción de consistencia fuerte multirregión
RPO ante caída regional	Cero en configuraciones multirregión	Cero en clústeres multirregión	Segundos con replicación asíncrona; cero con consistencia fuerte
Madurez	Años en producción	Servicio reciente, con funciones de PostgreSQL que faltan	Años en producción
Cuándo vale la pena	Escrituras globales con consistencia fuerte y escala horizontal	Aplicaciones PostgreSQL nuevas que aceptan sus límites	Acceso por clave a escala con latencia de un dígito

No elijas Spanner por defecto. Si tu aplicación cabe en un primario y tolera un RPO de segundos entre regiones, Cloud SQL o AlloyDB con réplica cuestan menos y se portan mejor a PostgreSQL en AWS. Spanner vale cuando el negocio no acepta perder ni una transacción ante la caída de una región y el volumen de escritura no cabe en un solo nodo.

Firestore y Memorystore

Firestore es la base de documentos sin servidores, el par de DynamoDB. Se crea en una ubicación regional (SLA de 99,99 %) o multirregión como nam5 o eur3 (SLA de 99,999 %), con dos regiones de lectura y escritura y un testigo. A diferencia de las global tables, ofrece consistencia fuerte en multirregión, a cambio de más latencia de escritura. La ubicación no se cambia después.

Memorystore ofrece Valkey y Redis administrados, como ElastiCache. En Memorystore for Valkey cada shard tiene un primario y hasta cinco réplicas repartidas entre zonas, y la replicación entre regiones crea instancias secundarias de solo lectura que puedes promover con un switchover. Trata la caché como reconstruible: el plan de DR no debería depender de que la caché sobreviva.

Cloud Storage: ubicación, clases e inmutabilidad

La ubicación se elige al crear el bucket y define su resiliencia. Un bucket regional guarda datos en al menos dos zonas. Uno dual-region los guarda en dos regiones que eliges. Uno multirregión los reparte dentro de un área geográfica que Google elige. Con la replicación por defecto, el RPO entre regiones es de 12 horas, aunque la mayoría de objetos se copia en menos de una. Con turbo replication el RPO es de 15 minutos, y solo existe en dual-region.

Criterio	Cloud Storage	S3
Copia en otra región	Dual-region o multirregión, sin configurar replicación	Replicación entre regiones a otro bucket
RPO con garantía	15 minutos con turbo replication	15 minutos con Replication Time Control
Clases frías	Nearline, Coldline, Archive: lectura en milisegundos	Glacier Flexible Retrieval y Deep Archive: restauración en horas
Borrado recuperable	Soft delete: 7 días por defecto, de 7 a 90	Versionado
Inmutabilidad del bucket	Política de retención + Bucket Lock	Object Lock con retención por defecto
Inmutabilidad por objeto	Object Retention Lock: modo Unlocked o Locked	Object Lock: modo Governance o Compliance

Las clases Standard, Nearline, Coldline y Archive tienen duraciones mínimas de 30, 90 y 365 días para las tres frías, pero todas leen en milisegundos; no hay restauración en horas como en Glacier. Bucket Lock bloquea la política de retención del bucket para siempre: nadie, ni un Owner, la acorta ni borra el bucket mientras tenga objetos retenidos. Es el equivalente del modo Compliance de S3, y como él no tiene vuelta atrás. Lo verás a fondo en respaldos inmutables.

1. 1

   Elige la ubicación por el RPO

   Regional si basta con sobrevivir a una zona; dual-region con turbo replication si necesitas 15 minutos de RPO entre regiones; multirregión si priorizas disponibilidad de lectura y aceptas 12 horas de RPO.
2. 2

   Cierra el acceso

   Acceso uniforme a nivel de bucket y prevención de acceso público, como Block Public Access en S3.
3. 3

   Protege contra borrados

   Object Versioning y soft delete para recuperar lo que alguien borró o sobrescribió.
4. 4

   Haz inmutables los respaldos

   Política de retención y Bucket Lock, u Object Retention Lock en modo Locked, en un proyecto aparte con otros administradores.

# Bucket dual-region con turbo replication (RPO de 15 minutos)
gcloud storage buckets create gs://pagos-respaldos-7f3a \
  --location=NAM4 --rpo=ASYNC_TURBO \
  --uniform-bucket-level-access --public-access-prevention

# Versionado y retención de 30 días
gcloud storage buckets update gs://pagos-respaldos-7f3a \
  --versioning --retention-period=30d

# Bloquear la retención: irreversible, ni un Owner podrá acortarla
gcloud storage buckets update gs://pagos-respaldos-7f3a --lock-retention-period

Pub/Sub y Backup and DR Service

Pub/Sub es global: un tema con varias suscripciones hace de SNS con colas SQS detrás, y aguanta volúmenes de streaming como Kinesis. La entrega es al menos una vez, así que tus consumidores deben ser idempotentes. Las claves de orden garantizan orden por clave. La entrega exactamente una vez existe en suscripciones pull, con una condición: la garantía vale cuando los suscriptores se conectan a la misma región, y la latencia es mayor. Compara con SQS y SNS.

Backup and DR Service centraliza respaldos de Compute Engine, discos, Filestore, Cloud SQL y AlloyDB en bóvedas de respaldo. Una bóveda fija una retención mínima forzada, de 1 día a 99 años: durante ese tiempo nadie, ni Google, puede borrar el respaldo. Puedes bloquear esa retención con una fecha efectiva; después solo se puede alargar. Las bóvedas pueden ser regionales, entre regiones o multirregión, aunque AlloyDB y Filestore no admiten multirregión. Desde el 1 de noviembre de 2026, un proyecto con respaldos bajo retención forzada recibe automáticamente un bloqueo (lien) que impide borrarlo. Es el par de AWS Backup con Vault Lock en modo Compliance.