Semana 5 · Módulo 5 de 12

Almacenamiento y bases de datos

Aprenderás a elegir entre almacenamiento de objetos, bloque y ficheros, y entre Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, Memorystore y BigQuery según los requisitos. También verás cómo mover datos a Google Cloud y protegerlos. Es uno de los bloques con más preguntas de «¿qué servicio eliges?» del examen.

Reparto de la semana

Por qué importa

Casi todas las arquitecturas del examen guardan datos en algún sitio, y la pregunta típica no es «¿cómo se configura X?», sino «¿qué servicio eliges?». El enunciado te da cuatro o cinco pistas (volumen, patrón de acceso, consistencia, alcance geográfico, esquema, coste, operativa mínima) y tienes que traducirlas a un producto. Si dominas las palabras clave de este módulo, muchas preguntas de los casos de estudio se resuelven en segundos.

El apartado 1.3 pide «elegir tipos de almacenamiento adecuados (objeto, fichero, bases de datos)» y el 2.2 cubre la configuración: asignación del almacenamiento, seguridad y acceso, transferencia y latencia, retención y ciclo de vida, crecimiento y protección (copias de seguridad y recuperación). Todo eso está aquí.

Tipos de almacenamiento: objeto, bloque y fichero

Antes de ver productos, fija los tres modelos de almacenamiento. Cada uno responde a una forma distinta de acceder a los datos.

Encima de estos modelos están las bases de datos gestionadas, que ya no te exponen el almacenamiento: te exponen tablas, documentos o claves. El examen mezcla los cuatro grupos en la misma pregunta, así que conviene pensar primero «¿qué modelo de acceso necesita la aplicación?» y después «¿qué producto?».

Cloud Storage

Cloud Storage es el almacenamiento de objetos de Google Cloud. Guardas objetos (cualquier fichero más sus metadatos) dentro de buckets. Ideas base:

• El nombre del bucket es único a nivel global (compartes espacio de nombres con todos los clientes de Google Cloud) y la ubicación se fija al crearlo: no se puede cambiar después; hay que crear otro bucket y copiar.
• Los objetos son inmutables: «modificar» un objeto es sustituirlo por una versión nueva.
• La capacidad es ilimitada, sin tamaño mínimo de objeto, y la durabilidad de diseño es del 99,999999999 % (once nueves) anual en todas las clases.
• La consistencia es fuerte: tras escribir un objeto, cualquier lectura o listado posterior lo ve.
• Se accede por la consola, gcloud storage, las bibliotecas cliente y la API JSON/XML. gsutil es la herramienta heredada: sigue apareciendo en la guía del examen, pero hoy se recomienda gcloud storage.

Clases de almacenamiento

La clase determina el precio de almacenamiento frente al precio de acceso. Cuanto más «fría», más barato guardar y más caro leer, y además hay una duración mínima de almacenamiento: si borras, sustituyes o cambias de clase un objeto antes de ese plazo, pagas igualmente los días que faltan (early deletion fee).

Fíjate en dos detalles que el examen explota:

1. Todas las clases tienen latencia de milisegundos. Archive no es una «cinta» con horas de espera, como Glacier Deep Archive: lees el objeto al momento, solo que pagas más por leerlo.
2. La clase es una propiedad del objeto. El bucket tiene una clase por defecto, pero en un mismo bucket puede haber objetos Standard y Archive a la vez.

Existe además una clase Rapid para buckets zonales (Rapid Bucket), pensada para cargas de IA/ML y analítica muy intensivas en E/S. Es un caso especializado; para el examen basta con saber que existe y que es zonal.

Ubicaciones: región, dual-región y multirregión

La replicación entre regiones es asíncrona. Por defecto, Google diseña el servicio para replicar el 99,9 % de los objetos nuevos en menos de una hora y el 100 % en menos de 12 horas. Si necesitas un RPO de 15 minutos, activa turbo replication, que solo existe en dual-región y tiene coste adicional.

Autoclass

Autoclass mueve cada objeto automáticamente de clase según su uso real, sin que tengas que escribir reglas:

• Un objeto sin accesos pasa a Nearline a los 30 días; si configuras Archive como clase terminal, sigue a Coldline a los 90 días y a Archive a los 365. La clase terminal por defecto es Nearline.
• Si se vuelve a leer un objeto frío, vuelve a Standard.
• No se cobran tarifas de recuperación ni de borrado anticipado (salvo en la activación). A cambio hay una tarifa de gestión por objeto.
• Los objetos de menos de 128 KiB no bajan de clase.
• Es incompatible con reglas de ciclo de vida que usen SetStorageClass o matchesStorageClass.

Usa Autoclass cuando no conoces o no puedes predecir el patrón de acceso. Si lo conoces (p. ej. «los logs se consultan solo el primer mes y hay que guardarlos siete años»), las reglas de ciclo de vida son más baratas y explícitas.

Gestión del ciclo de vida (Object Lifecycle Management)

Las reglas de ciclo de vida se definen por bucket y combinan acciones y condiciones:

• Acciones: Delete, SetStorageClass y AbortIncompleteMultipartUpload.
• Condiciones: age (días desde la creación), createdBefore, isLive (versión actual o no), numNewerVersions, daysSinceNoncurrentTime, matchesStorageClass, matchesPrefix/matchesSuffix, daysSinceCustomTime y tamaño (sizeAboveBytes/sizeBelowBytes).

Las transiciones de clase solo van «hacia abajo»: Standard → Nearline → Coldline → Archive. Los cambios en la configuración pueden tardar hasta 24 horas en aplicarse. Un ejemplo típico (logs que se enfrían y se borran a los 7 años):

{
  "lifecycle": {
    "rule": [
      { "action": { "type": "SetStorageClass", "storageClass": "NEARLINE" }, "condition": { "age": 30 } },
      { "action": { "type": "SetStorageClass", "storageClass": "ARCHIVE" }, "condition": { "age": 365 } },
      { "action": { "type": "Delete" }, "condition": { "age": 2555 } }
    ]
  }
}

gcloud storage buckets update gs://mi-bucket-logs --lifecycle-file=lifecycle.json
gcloud storage buckets describe gs://mi-bucket-logs --format="default(lifecycle_config)"

Versionado y soft delete

Con el versionado de objetos (Object Versioning) activado, al sobrescribir o borrar un objeto la versión anterior no desaparece: pasa a ser una versión no actual (noncurrent) identificada por su número de generación. Protege contra borrados y sobrescrituras accidentales, pero cada versión ocupa (y cuesta) espacio. Lo habitual es combinarlo con reglas de ciclo de vida como numNewerVersions: 3 o daysSinceNoncurrentTime: 30 para limitar cuántas versiones se conservan.

Aparte existe el soft delete, activado por defecto en los buckets con una retención de 7 días (configurable entre 7 y 90 días, o 0 para desactivarlo). Durante ese periodo, los objetos borrados se pueden restaurar, incluso si no había versionado. Ten en cuenta que los objetos en soft delete se facturan: en buckets con muchos datos temporales conviene desactivarlo.

Retención, Bucket Lock y Object Retention Lock

Para cumplimiento normativo (WORM, write once, read many: «los registros no se pueden borrar durante 7 años») tienes estas herramientas:

• Política de retención del bucket (retention policy): ningún objeto del bucket se puede borrar ni sustituir hasta que cumpla la edad indicada. Mientras la política no esté bloqueada, se puede reducir o quitar.
• Bucket Lock: bloquear la política de retención. Es irreversible: ya no puedes reducir ni eliminar la política (solo ampliarla), y el bucket no se puede borrar hasta que todos los objetos hayan cumplido su retención. Es la respuesta a «requisito regulatorio de inmutabilidad» (p. ej. SEC 17a-4).
• Object Retention Lock: fija una fecha de retención por objeto. Tiene dos modos: Unlocked (equivalente a «governance»: usuarios autorizados pueden cambiarla o quitarla) y Locked (equivalente a «compliance»: solo se puede ampliar). Una vez activada en un bucket, la función no se puede desactivar. Si un objeto tiene a la vez retención de bucket y de objeto, debe cumplir ambas.
• Retenciones temporales y basadas en eventos (object holds): impiden borrar un objeto mientras el hold esté puesto, útil en litigios.

gcloud storage buckets update gs://registros-fiscales --retention-period=2557d   # unos 7 años
gcloud storage buckets update gs://registros-fiscales --lock-retention-period   # irreversible

Control de acceso: acceso uniforme, ACL y URLs firmadas

Hay dos modelos de permisos en Cloud Storage:

• Uniform bucket-level access (acceso uniforme a nivel de bucket): solo cuenta IAM, aplicado al bucket (o a carpetas gestionadas). Las ACL de objeto quedan desactivadas. Es la opción recomendada; permite además IAM Conditions y es requisito de funciones como carpetas gestionadas. Tras activarlo tienes 90 días para volver atrás.
• Fine-grained (detallado): IAM más ACL por objeto. Solo se justifica si de verdad necesitas permisos distintos objeto a objeto, por compatibilidad con Amazon S3 o con aplicaciones antiguas.

Otras piezas clave:

• Public access prevention: impide que nada del bucket se haga público (a allUsers o allAuthenticatedUsers). Se puede forzar en toda la organización con una política de organización.
• URL firmada (signed URL): una URL con una firma criptográfica que da acceso temporal a un objeto concreto a quien la tenga, sin necesidad de cuenta de Google. Con firma V4 la validez máxima es de 7 días. Es la respuesta a «un cliente externo sin cuenta debe descargar (o subir) un fichero durante 24 horas».
• Signed policy document: parecido, pero para subidas desde un formulario HTML con restricciones (tamaño, tipo de contenido).

# Firma una URL de descarga válida 1 hora suplantando una cuenta de servicio
gcloud storage sign-url gs://mi-bucket/informe.pdf \
  --duration=1h \
  --impersonate-service-account=firmador@mi-proyecto.iam.gserviceaccount.com

Cifrado

Todo se cifra en reposo siempre. Tú eliges quién controla las claves:

En la semana 7 verás Cloud KMS, Cloud HSM y Cloud External Key Manager (EKM) a fondo.

Rendimiento y otras funciones útiles

• Cloud CDN delante de un bucket (con un balanceador de carga de aplicaciones externo) para servir contenido estático con baja latencia global.
• Anywhere Cache: caché SSD zonal delante de un bucket para cargas de lectura intensiva (p. ej. entrenamiento de IA en una zona).
• Hierarchical namespace (espacio de nombres jerárquico): carpetas reales con renombrado atómico, útil para analítica y IA con muchos ficheros.
• Cloud Storage FUSE: monta un bucket como sistema de ficheros en VMs o GKE. Útil para IA/ML y lectura masiva, pero no es un sistema de ficheros POSIX completo (no hay bloqueos de fichero ni escrituras parciales eficientes).
• Notificaciones Pub/Sub y eventos de Eventarc cuando se crea o borra un objeto: la base de muchas arquitecturas orientadas a eventos («al subir una imagen, procesarla con Cloud Run»).

Almacenamiento en bloque y de ficheros

Persistent Disk, Hyperdisk y Local SSD

Son los discos de las VMs de Compute Engine (y los volúmenes persistentes de GKE).

Las snapshots son incrementales, se guardan por defecto en una ubicación multirregional y sirven como copia de seguridad y para clonar discos en otra zona o región. Programa snapshots con una snapshot schedule o, para gobierno centralizado, con Backup and DR Service.

Filestore, NetApp Volumes y Managed Lustre

Bases de datos relacionales

Cloud SQL

Cloud SQL es el servicio gestionado de MySQL, PostgreSQL y SQL Server. Google se encarga de parches, copias de seguridad, replicación y conmutación por error; tú eliges el tamaño de la instancia y la configuración. Escala verticalmente (más CPU y memoria) y en lectura con réplicas, pero la escritura va siempre a un único primario. Es la respuesta por defecto para «base de datos relacional regional, lift-and-shift de MySQL/PostgreSQL/SQL Server, aplicación web tradicional».

Tiene dos ediciones:

Alta disponibilidad (HA regional)

Una instancia con HA (--availability-type=REGIONAL) tiene un primario en una zona y un standby en otra zona de la misma región. Las escrituras se replican de forma síncrona a los discos de ambas zonas antes de confirmarse, así que no se pierden transacciones confirmadas (RPO ≈ 0).

• Si el primario deja de responder a los latidos (heartbeats) durante varios segundos, Cloud SQL conmuta automáticamente al standby. La conmutación tarda del orden de 60 segundos.
• La instancia conserva la misma IP, así que la aplicación solo tiene que reconectar.
• El standby no sirve lecturas. Si quieres descargar lecturas, necesitas réplicas de lectura.
• La HA protege frente a la caída de una zona, no de una región. Para DR regional necesitas una réplica entre regiones.

flowchart LR
  App["Aplicación"] --> IP["IP de la instancia"]
  IP --> P["Primario (zona A)"]
  P -- "replicación síncrona" --> S["Standby (zona B)"]
  P -- "replicación asíncrona" --> R1["Réplica de lectura (misma región)"]
  P -- "replicación asíncrona" --> R2["Réplica entre regiones (DR)"]

Réplicas de lectura

• Son copias asíncronas (pueden ir unos segundos por detrás) que solo admiten lecturas.
• Pueden estar en la misma región o en otra (cross-region replica), lo que sirve para acercar las lecturas a los usuarios y como plan de DR: ante la pérdida de la región, promocionas la réplica a instancia independiente (o, con la función de DR avanzada de Enterprise Plus, haces un switchover controlado).
• Se pueden encadenar (réplicas en cascada) y tener HA propia.
• La réplica no es una copia de seguridad: un DROP TABLE se replica al instante.

Copias de seguridad y PITR

• Copias automáticas diarias (por defecto se conservan 7) y copias bajo demanda antes de operaciones arriesgadas.
• Point-in-time recovery (PITR): usa las copias automáticas más los logs de transacciones para restaurar el estado de un momento concreto (p. ej. «justo antes del borrado accidental de las 10:42»). La restauración PITR crea una instancia nueva (un clon), no sobrescribe la original.
• Restaurar una copia sobre una instancia existente sobrescribe sus datos. Si la instancia tiene réplicas, hay que eliminarlas antes.
• Al borrar una instancia, las copias automáticas se van eliminando; puedes pedir una copia final (--enable-final-backup) que se conserva 30 días por defecto.
• Las copias mejoradas (enhanced backups) se gestionan con Backup and DR Service, con retención forzada de hasta 10 años.

Conexión: por IP privada (acceso a servicios privados o Private Service Connect) o IP pública con Cloud SQL Auth Proxy o los conectores de lenguaje, que cifran la conexión y autentican con IAM sin gestionar listas de IPs autorizadas.

AlloyDB for PostgreSQL

AlloyDB es una base de datos compatible con PostgreSQL con arquitectura propia de Google: cómputo y almacenamiento separados y escalables por separado. Aspectos clave:

• Mucho más rendimiento transaccional que PostgreSQL estándar y un motor columnar que acelera las consultas analíticas sobre los mismos datos (cargas HTAP, transaccionales y analíticas a la vez).
• HA por defecto en el primario, read pools con balanceo de lecturas, copia continua y PITR, replicación entre regiones.
• AlloyDB AI (vectores, búsqueda semántica, llamadas a modelos) y AlloyDB Omni (versión descargable para ejecutar en tu centro de datos u otras nubes).

Palabras clave: «PostgreSQL de alto rendimiento», «informes analíticos sobre datos transaccionales sin ETL», «migrar Oracle o PostgreSQL exigente sin pasar a una base global». Si el enunciado exige escala global de escrituras, la respuesta es Spanner, no AlloyDB.

Spanner

Spanner es una base de datos relacional distribuida con consistencia fuerte (consistencia externa, gracias a los relojes TrueTime) y escalado horizontal de lecturas y escrituras. Combina lo que normalmente es incompatible: SQL y transacciones ACID con escala prácticamente ilimitada y distribución multirregional.

• Capacidad en unidades de procesamiento: desde 100 PU; 1 nodo son 1.000 PU. Escala sin parada añadiendo capacidad (hay autoescalado gestionado en las ediciones superiores).
• Configuraciones regionales, dual-región y multirregión.
• Ediciones: Standard (solo regional), Enterprise (añade Spanner Graph, búsqueda de texto y vectorial, autoescalado gestionado) y Enterprise Plus (añade dual y multirregión, geoparticionado y hasta 99,999 % de SLA). Standard y Enterprise ofrecen 99,99 %.
• Dialectos GoogleSQL y PostgreSQL.
• Diseño: evita claves primarias monótonas (autoincrementales o que empiezan por timestamp), porque concentran las escrituras en un único split (hotspot). Usa UUID v4 o secuencias con bits invertidos. Las tablas intercaladas (interleaved) guardan juntas las filas padre e hijas para acelerar los joins.

Palabras clave: «global», «consistencia fuerte», «SQL», «escala horizontal de escrituras», «99,999 %», «inventario o transacciones financieras en varios continentes», «superamos los límites de Cloud SQL».

Bases de datos NoSQL

Firestore

Firestore es una base de datos documental serverless: documentos (similares a JSON) organizados en colecciones, escalado automático, transacciones ACID, índices y pago por operaciones y almacenamiento.

• Modo nativo: sincronización en tiempo real y soporte sin conexión en los SDK móviles y web (Firebase). Es la respuesta a «aplicación móvil con sincronización en tiempo real y modo sin conexión».
• Modo Datastore: compatible con la API del antiguo Cloud Datastore, para aplicaciones de servidor.
• Ediciones: Standard (modo nativo o Datastore, consultas con índices) y Enterprise (almacenamiento en SSD, consultas más flexibles con o sin índice, y compatibilidad con MongoDB). «Migrar una aplicación MongoDB a un servicio gestionado y serverless» apunta a Firestore Enterprise con compatibilidad MongoDB.
• Ubicación regional o multirregional (SLA de 99,99 % y 99,999 % respectivamente).

Firestore no está pensado para analítica masiva ni para cientos de miles de escrituras por segundo sobre el mismo documento: para eso hay otros servicios.

Bigtable

Bigtable es una base de datos NoSQL de columnas anchas (wide-column) para volúmenes enormes (terabytes a petabytes) con latencia de milisegundos de un dígito y un rendimiento que escala linealmente con el número de nodos. Es compatible con la API de Apache HBase.

• Modelo: una sola clave indexada, la clave de fila (row key); las filas se ordenan lexicográficamente por ella. Columnas agrupadas en familias; celdas con versiones por timestamp.
• Solo hay transacciones por fila (atomicidad de una fila). No hay joins ni transacciones multifila; hoy admite consultas GoogleSQL, pero no es un almacén analítico.
• Almacenamiento SSD (lo normal) o HDD (más barato, para datos poco leídos); los datos viven en Colossus, así que añadir o sustituir nodos es rápido.
• Replicación entre clústeres (incluso en regiones distintas) con perfiles de aplicación: enrutamiento a un único clúster (consistencia fuerte) o multiclúster (consistencia eventual, más disponibilidad).
• Key Visualizer para detectar hotspots.

Casos típicos: series temporales, IoT, adtech, datos financieros de mercado, personalización, grafos de gran tamaño. Palabras clave: «millones de escrituras por segundo», «petabytes», «baja latencia», «sensores», «HBase».

Diseño de la clave de fila

Es lo más preguntado de Bigtable. Las consultas eficientes leen por clave, por prefijo o por rango de claves, así que la clave se diseña a partir de las consultas:

• No empieces la clave por un timestamp ni por un valor secuencial: todas las escrituras recientes caerían en el mismo nodo (hotspot).
• Coloca primero un valor de alta cardinalidad que reparta la carga (ID del dispositivo, ID del usuario) y después el timestamp: sensor#4711#20261001T1030. Esto se llama promoción de campos (field promotion).
• Si necesitas leer lo más reciente primero, usa un timestamp invertido (valor máximo menos el timestamp).
• Salting (prefijo con un hash) reparte aún más, pero complica las lecturas por rango: úsalo solo si hace falta.
• Mantén las claves cortas (máximo 4 KB), rellena los números con ceros a la izquierda (el orden es lexicográfico) y evita filas enormes (límite duro de 256 MB, recomendado menos de 100 MB).
• Para series temporales, prefiere tablas «altas y estrechas» (una fila por evento o por intervalo) a filas con millones de columnas.

Memorystore

Memorystore es el almacén en memoria gestionado (caché, sesiones, tablas de clasificación, colas ligeras), con latencias de submilisegundo. Hoy hay estas variantes:

Palabras clave: «caché», «reducir la carga de lectura de la base de datos», «almacenar sesiones de usuario», «latencia de submilisegundo», «ranking en tiempo real». Recuerda que una caché no es la fuente de verdad: los datos deben estar también en una base de datos.

BigQuery como almacén analítico (introducción)

BigQuery es el almacén de datos analítico (data warehouse) serverless de Google Cloud. Almacena datos en formato columnar y ejecuta SQL sobre terabytes o petabytes en segundos, separando almacenamiento y cómputo. Es OLAP (analítica), no OLTP (transacciones): no lo uses como base de datos de una aplicación que hace miles de lecturas y escrituras de filas individuales por segundo.

Ideas mínimas para esta semana (la semana 6 lo amplía):

• Organización: proyecto → dataset (con ubicación regional o multirregional) → tablas y vistas.
• Pagas por almacenamiento (más barato si una tabla o partición no se modifica en 90 días: long-term storage) y por cómputo: bajo demanda por TiB escaneado (el primer TiB al mes es gratis) o por capacidad (slots) con las ediciones.
• Palabras clave: «analítica», «data warehouse», «informes con SQL sobre petabytes», «sin gestionar infraestructura», «BI».

Tabla de decisión: ¿qué almacenamiento o base de datos elijo?

flowchart TD
  A["¿Qué tipo de datos?"] --> B["Ficheros u objetos"]
  A --> C["Datos estructurados o semiestructurados"]
  B --> B1{"¿Acceso por API o sistema de ficheros?"}
  B1 -- "API / HTTP" --> GCS["Cloud Storage"]
  B1 -- "NFS o SMB compartido" --> FS["Filestore / NetApp Volumes"]
  B1 -- "Disco de una VM" --> PD["Persistent Disk / Hyperdisk"]
  C --> C1{"¿Analítica u operacional?"}
  C1 -- "Analítica (OLAP)" --> BQ["BigQuery"]
  C1 -- "Operacional" --> C2{"¿Relacional (SQL, transacciones)?"}
  C2 -- "Sí" --> C3{"¿Escala global o escrituras horizontales?"}
  C3 -- "Sí" --> SP["Spanner"]
  C3 -- "No" --> C4{"¿PostgreSQL muy exigente o HTAP?"}
  C4 -- "Sí" --> AL["AlloyDB"]
  C4 -- "No" --> SQL["Cloud SQL"]
  C2 -- "No" --> C5{"¿Patrón de acceso?"}
  C5 -- "Documentos, apps móviles" --> FSDB["Firestore"]
  C5 -- "Enorme volumen, baja latencia, series temporales" --> BT["Bigtable"]
  C5 -- "Caché en memoria" --> MS["Memorystore"]

Transferencia de datos a Google Cloud

La herramienta depende del volumen, del ancho de banda disponible, del origen y de si la transferencia es única o recurrente.

Tiempos teóricos al 100 % de uso del enlace (en la práctica, cuenta con un 20-30 % más; la guía de Google estima 12 días para 100 TB a 1 Gbps):

La regla práctica: si por red no llegas en el plazo del proyecto (o tardarías más de una semana), piensa en Transfer Appliance; si llegas y es desde otra nube o se repite, Storage Transfer Service; si es poco volumen y puntual, gcloud storage. Si el problema es el ancho de banda de forma permanente, la solución de fondo es Cloud Interconnect (semana 4).

Planificación del crecimiento

El apartado 2.2 pide «planificar el crecimiento de los datos». Traducido a servicios:

• Cloud Storage y BigQuery: capacidad ilimitada; el crecimiento se controla con ciclo de vida, Autoclass, expiración de tablas y particiones.
• Persistent Disk / Hyperdisk: se amplían en caliente (no se pueden reducir); con Hyperdisk ajustas IOPS y rendimiento sin cambiar de disco.
• Cloud SQL: activa el aumento automático de almacenamiento para no quedarte sin disco (no se puede reducir después). Si el cuello de botella son las escrituras y ya estás en la máquina más grande razonable, es la señal para pasar a AlloyDB o Spanner.
• Spanner y Bigtable: escalan añadiendo capacidad (nodos o unidades de procesamiento), con autoescalado.
• Firestore y Memorystore for Valkey/Redis Cluster: escalado automático o por nodos sin parada.
• Revisa cuotas y límites antes de un crecimiento previsto (se piden ampliaciones desde la consola).

Protección de datos: copias de seguridad y recuperación

Diseña la protección con dos métricas: RPO (cuántos datos puedes perder) y RTO (cuánto puedes tardar en recuperar). Herramientas por servicio:

Por encima de todo eso está Backup and DR Service, el servicio centralizado de copias de seguridad:

• Backup vaults (almacenes de copias): almacenamiento aislado y gestionado por Google donde las copias son inmutables e imborrables hasta que vence su retención forzada (hasta 99 años). Protegen incluso frente a un administrador malicioso o un ransomware que haya comprometido el proyecto.
• Backup plans: políticas con reglas de frecuencia (de cada hora a anual) y retención que se asocian a los recursos.
• Protege VMs de Compute Engine, discos, Filestore, Cloud SQL, AlloyDB, VMs de Google Cloud VMware Engine y bases de datos autogestionadas (Oracle, SQL Server, SAP HANA, MySQL, PostgreSQL), con copias incrementales para siempre.

Trampas típicas del examen

• Cloud Storage Archive no es lento: la latencia es de milisegundos. Lo que cuesta es la tarifa de recuperación y la duración mínima de 365 días.
• Duraciones mínimas 30/90/365 días (Nearline/Coldline/Archive). Standard no tiene mínimo.
• Ubicación del bucket inmutable: para cambiarla, nuevo bucket y copia (Storage Transfer Service).
• Turbo replication solo en dual-región (RPO 15 minutos). Multirregión no la tiene.
• Bucket Lock es irreversible; la retención sin bloquear, no. Retención por objeto → Object Retention Lock.
• URL firmada = acceso temporal sin cuenta de Google. Si el usuario tiene identidad, usa IAM.
• Acceso uniforme es lo recomendado; las ACL solo si hace falta granularidad por objeto.
• HA de Cloud SQL ≠ réplica de lectura ≠ copia de seguridad. El standby de HA no sirve lecturas y la HA es zonal, no regional.
• PITR crea una instancia nueva; restaurar una copia sobre una instancia la sobrescribe.
• Spanner: «global + consistencia fuerte + SQL + escala horizontal». Si falta lo global o la escala, probablemente sea Cloud SQL o AlloyDB.
• Bigtable: nunca claves que empiecen por timestamp. No es para SQL ad hoc ni para transacciones multifila, y no compensa con volúmenes pequeños (unos pocos GB).
• Firestore para móviles con sincronización y sin conexión; Bigtable para enorme volumen de escrituras; BigQuery para analítica.
• Memorystore for Memcached está obsoleto: si aparece, la alternativa moderna es Memorystore for Valkey.
• Local SSD es efímero: nunca como único almacén de datos que importen.
• Filestore (NFS) vs NetApp Volumes (también SMB): Windows apunta a NetApp Volumes.
• Transfer Appliance cuando la red no llega a tiempo; Storage Transfer Service desde otra nube o de forma recurrente.

Resumen

• Objeto (Cloud Storage), bloque (Persistent Disk, Hyperdisk, Local SSD) y fichero (Filestore, NetApp Volumes, Managed Lustre) responden a formas distintas de acceso.
• Cloud Storage: clases Standard/Nearline/Coldline/Archive con mínimos de 0/30/90/365 días, todas con latencia de milisegundos; ubicación región, dual-región o multirregión; turbo replication para RPO de 15 minutos.
• Ciclo de vida para patrones conocidos, Autoclass para patrones impredecibles; versionado y soft delete frente a borrados; retención, Bucket Lock y Object Retention Lock para WORM.
• Acceso uniforme con IAM como norma; URLs firmadas (máximo 7 días) para usuarios sin cuenta; CMEK cuando necesitas controlar las claves.
• Cloud SQL para relacional regional (HA regional síncrona, réplicas asíncronas, copias y PITR); AlloyDB para PostgreSQL exigente y HTAP; Spanner para relacional global con escala horizontal.
• Firestore para documentos y apps móviles; Bigtable para series temporales e IoT con clave de fila bien diseñada; Memorystore (Valkey recomendado) para caché; BigQuery para analítica.
• Transferencias: gcloud storage (poco volumen), Storage Transfer Service (otras nubes, recurrente, más de 1 TiB), Transfer Appliance (offline, cuando la red no llega).
• Protección: define RPO y RTO; Backup and DR Service con backup vaults para copias inmutables y centralizadas.

Practica lo aprendido

Documentación oficial para ampliar

• Cloud Storage – Storage classes
• Cloud Storage – Bucket locations
• Cloud Storage – Object Lifecycle Management
• Cloud Storage – Autoclass
• Cloud Storage – Object Retention Lock
• Hyperdisk overview
• Filestore service tiers
• Cloud SQL editions
• Cloud SQL high availability
• Spanner editions overview
• Firestore editions
• Bigtable schema design
• Transferring large datasets
• Backup and DR Service