Google ACE: Fiabilidad, copias de seguridad y recuperación ante desastres — Guía de estudio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Forma parte de la Google Associate Cloud Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La fiabilidad, las copias de seguridad y la recuperación ante desastres en Google Cloud requieren un diseño intencionado que abarque los dominios de fallo, los mecanismos de protección de datos, la gestión del tráfico y la preparación operativa. Esta sección explica cómo estructurar los servicios entre zonas y regiones, cómo proteger y restaurar datos con estado, y cómo validar los objetivos de recuperación con runbooks disciplinados y pruebas de resiliencia continuas. También describe las contrapartidas de la estrategia de DR y la planificación de capacidad para garantizar que la plataforma pueda recuperarse dentro de los objetivos definidos de tiempo de recuperación (RTO) y punto de recuperación (RPO).

Dominios de fallo y diseño regional

• Zonas, regiones y servicios multirregionales

  • Las zonas son los dominios de fallo independientes más pequeños. Un único fallo zonal no debería interrumpir un servicio regional.
  • Las regiones agrupan zonas independientes con enlaces de baja latencia. Los diseños regionales sobreviven a fallos zonales, pero no necesariamente a eventos regionales completos.
  • Los servicios multirregionales se replican entre regiones, protegiendo contra la pérdida de una región a un coste mayor y con una latencia de escritura potencialmente más alta.
  • Principio de diseño: evite los puntos únicos de fallo en el dominio de fallo más pequeño que le interese. Si su RTO/RPO requiere sobrevivir a un fallo zonal, despliegue en al menos dos zonas. Para la supervivencia regional, despliegue componentes activos en múltiples regiones o consuma servicios multirregionales.

• Grupos de instancias gestionados (MIG) y autorreparación

  • Prefiera los MIG regionales para distribuir instancias entre zonas en una misma región. Esto mitiga las interrupciones zonales sin necesidad de herramientas adicionales.
  • Las comprobaciones de estado del balanceador de carga eliminan las VM en mal estado del tráfico. La autorreparación del MIG reemplaza las VM en mal estado o que no responden. Use ambos.
  • Utilice comprobaciones de estado HTTP(S) a nivel de aplicación que verifiquen los endpoints de preparación y las dependencias. Una comprobación TCP solo valida la alcanzabilidad del puerto.
  • Modo de fallo por mala configuración de la autorreparación: usar solo una comprobación de estado del balanceador de carga impide el tráfico a una instancia defectuosa, pero no la recrea. Configure la propia comprobación de estado del MIG para el reemplazo y un retraso inicial para evitar reinicios prematuros durante el arranque.

Ejemplo:

• Crear una comprobación de estado de la aplicación con intervalos de 10 segundos y 3 umbrales de no saludable para activar la autorreparación después de ~30 segundos: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Adjuntar la comprobación de estado a un MIG regional para la autorreparación: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Consideraciones multirregionales

  • El Balanceo de carga HTTP(S) externo y global admite backends en múltiples regiones con conmutación por error automática basada en comprobaciones de estado.
  • La sincronización del estado entre regiones es la contrapartida crítica. El rendimiento activo-activo es alto, pero la consistencia y la resolución de conflictos deben diseñarse. El modo activo-pasivo es más simple, pero tiene una conmutación por error más lenta y un RPO potencialmente mayor.

Protección de datos: bases de datos, almacenamiento y computación

• Alta disponibilidad y réplicas de Cloud SQL
  • La configuración de alta disponibilidad ubica una instancia de reserva (standby) en una zona diferente con replicación síncrona. La conmutación por error (failover) automática ocurre si falla la instancia principal. El RTO suele ser de minutos; el RPO es ≈ 0 dentro de una región, pero se deben considerar las transacciones en curso.
  • Las réplicas de lectura descargan las operaciones de lectura y pueden estar en otras regiones para recuperación ante desastres (DR). Son asíncronas; es de esperar un retraso en la replicación y un RPO distinto de cero.
  • Copias de seguridad y PITR
    • Habilita las copias de seguridad automatizadas y la recuperación a un momento específico (point-in-time recovery). Para MySQL, habilita el registro binario (binary logging); para PostgreSQL, habilita la retención para PITR.
    • Flujos de restauración: en caso de corrupción o error del usuario, restaura a una nueva instancia en una marca de tiempo específica, apunta las aplicaciones o réplicas a la instancia restaurada y valida los datos.
  • Modos de fallo y contrapartidas
    • La alta disponibilidad (HA) no protege contra la corrupción lógica de datos; las copias de seguridad y el PITR sí lo hacen.
    • Las réplicas entre regiones protegen contra la pérdida de una región, pero pueden tener retrasos; prueba tu RPO aceptable.

Ejemplo:

• Habilitar el registro binario (MySQL) y las copias de seguridad automatizadas: gcloud sql instances patch my-mysql
  –enable-bin-log
  –backup-start-time=03:00 –retained-backups=7

• Instantáneas (snapshots) de Persistent disk (PD) e imágenes de máquina

  • Las instantáneas de PD son copias de seguridad incrementales y consistentes ante fallos (crash-consistent) de los discos. Su ubicación de almacenamiento es configurable y se pueden usar para crear nuevos discos en cualquier zona dentro del ámbito de la ubicación de la instantánea.
  • Para lograr copias de seguridad consistentes a nivel de aplicación, pon en reposo (quiesce) el sistema de archivos y la aplicación, o coordina las instantáneas con los mecanismos de copia de seguridad específicos de la base de datos.
  • Las imágenes de máquina capturan los discos y los metadatos de la instancia (discos de arranque, discos adjuntos, propiedades de la instancia). Usa imágenes de máquina para una recuperación más rápida de la flota o para clonar una configuración de servidor de referencia (golden server).
  • Las políticas de programación de instantáneas automatizan las copias de seguridad, aplican la retención y etiquetan los discos críticos en consecuencia.
  • Flujo de trabajo de restauración: crea un disco a partir de una instantánea, adjúntalo a una nueva instancia, actualiza los scripts de inicio y las cuentas de servicio, y luego valida la integridad de la aplicación antes de reintroducir el tráfico.

Ejemplo:

• Crear una instantánea y restaurarla en un nuevo disco: gcloud compute disks snapshot vm-boot –snapshot-names=boot-2024-09-01 gcloud compute disks create restored-boot –source-snapshot=boot-2024-09-01 –zone=us-central1-a

• Replicación, versionado y retención en Cloud Storage

  • Opciones de clase de almacenamiento: Standard para datos de acceso frecuente (hot); Nearline para acceso mensual poco frecuente; Coldline para acceso trimestral (recomendado para copias de seguridad y DR); Archive para datos a largo plazo y de acceso muy esporádico.
  • Los buckets regionales, birregionales (Dual-Region) y multirregionales ofrecen durabilidad mediante la replicación. Dual-Region con replicación turbo puede limitar el RPO de replicación para objetos recién escritos; Multi-Region ofrece una amplia resiliencia geográfica.
  • El versionado de objetos protege contra eliminaciones y sobrescrituras accidentales al mantener versiones no actuales. Combínalo con políticas de retención y el bloqueo de bucket (bucket lock) para aplicar una retención de tipo WORM.
  • Protección contra borrado accidental: habilita el versionado de objetos (Object Versioning), usa una política de retención con bloqueo, implementa retenciones basadas en eventos para fines legales o de procesamiento, y restringe las eliminaciones a través de IAM y el acceso uniforme a nivel de bucket. Para acceso externo con límite de tiempo, usa URL firmadas (signed URLs) con vencimientos estrictos.

Ejemplo de ciclo de vida para mover a Coldline después de 90 días y eliminar después de 365 días:

• lifecycle.json { “rule”: [ { “action”: { “type”: “SetStorageClass”, “storageClass”: “COLDLINE” }, “condition”: { “age”: 90 } }, { “action”: { “type”: “Delete” }, “condition”: { “age”: 365 } } ] }
• Aplicar: gsutil lifecycle set lifecycle.json gs://my-bucket

Resiliencia de tráfico, capacidad y dependencias

• DNS y conmutación por error en la gestión de tráfico

  • Prefiere el balanceo de carga HTTP(S) externo global para servicios expuestos a Internet; utiliza IPs anycast y realiza una conmutación por error basada en verificaciones de estado entre regiones.
  • Para servicios privados, utiliza balanceadores de carga internos HTTP(S) o TCP/UDP. Diseña para la independencia zonal con múltiples backends.
  • Compromisos del TTL de DNS: los TTL bajos permiten una conmutación por error más rápida, pero aumentan la carga de consultas y pueden ser ignorados por algunos resolutores debido al comportamiento de la caché. La conmutación por error de un balanceador de carga basada en verificaciones de estado es más rápida y determinista que una conmutación por error basada únicamente en DNS.
  • Las políticas de DNS ponderadas o de conmutación por error pueden ser un plano de control de último recurso para la evacuación de una región, pero dependen de la expiración de la caché.

• Planificación de capacidad y diseño de cuotas

  • Identifica la capacidad mínima saludable por zona y región. Aplica márgenes de capacidad adicionales (headroom buffers) para la conmutación por error (capacidad de “zona N+1”).
  • Utiliza reservas regionales para tipos de máquinas (shapes) críticos de Compute Engine para garantizar la capacidad durante eventos de escalado o conmutación por error.
  • Preaprovisiona direcciones IP, reglas de reenvío, capacidad de Cloud NAT, seguimiento de conexiones y certificados SSL para evitar retrasos en el plano de control durante la recuperación.
  • Solicita aumentos de cuota con suficiente antelación; valida las cuotas en las regiones secundarias y para todas las dependencias (p. ej., instancias de Cloud SQL por región, reglas de reenvío por VPC, rendimiento de Pub/Sub, QPS de Cloud KMS).
  • Consideraciones sobre el autoescalado: configura períodos de enfriamiento (cooldowns), autoescalado predictivo si es necesario, y establece límites mínimos/máximos para mantener exactamente una instancia cuando la política lo requiera.

• Resiliencia de dependencias

  • Haz un inventario de los servicios ascendentes (upstream) y descendentes (downstream). Para cada uno, define el comportamiento ante fallos y los mecanismos de respaldo: configuración en caché, modos degradados, disyuntores (circuit breakers), colas con temas de mensajes fallidos (dead-letter topics) y contrapresión (backpressure).
  • Valida el alcance de IAM y de las cuentas de servicio en las regiones de recuperación. La falta de roles suele causar fallos silenciosos durante los eventos de DR.
  • Claves de encriptación: asegúrate de que las réplicas de claves de Cloud KMS o las claves multirregionales se alineen con la ubicación de los datos. Planifica la localidad del llavero de claves (key-ring) y el IAM en las regiones secundarias.

Operaciones de resiliencia y mejora continua

• RTO, RPO, planes de recuperación y runbooks

  • El RTO define la rapidez con la que debe reanudarse un servicio; el RPO define la pérdida de datos aceptable. Estos se derivan del análisis de impacto en el negocio.
  • Asigna cada componente del sistema a mecanismos específicos que satisfagan el RTO/RPO: alta disponibilidad (HA) para fallos zonales, replicación entre regiones para fallos regionales, copias de seguridad para la corrupción de datos y clases de almacenamiento/replicación para la durabilidad.
  • Mantén runbooks: pasos precisos, comandos, acceso a credenciales, comprobaciones de validación de estado y árboles de decisión. Almacénalos en un repositorio versionado con control de acceso y practícalos regularmente.
  • Validación de la recuperación: programa simulacros para medir el RTO/RPO real, validar la integridad de los datos y recopilar acciones de mejora. Prueba tanto restauraciones de alcance limitado (tabla, disco) como recuperaciones completas del sitio.

• Estrategias de recuperación ante desastres (DR) y sus contrapartidas

  • Activo-activo: todas las regiones atienden tráfico; RTO mínimo y RPO bajo si la sincronización de datos está diseñada correctamente. Mayor complejidad y coste; requiere resolución de conflictos y balanceo de carga global.
  • Activo-pasivo: la región primaria está activa; la secundaria está en espera (warm) y recibe datos replicados. Coste moderado; RTO de minutos a decenas de minutos; RPO no nulo dependiendo de la replicación.
  • Luz piloto (Pilot-light): servicios críticos mínimos se ejecutan en la región secundaria (replicación de base de datos, huella mínima de la aplicación). RTO de horas; eficiente en costes; se necesita una orquestación cuidadosa para escalar la computación durante la conmutación por error (failover).
  • Espera en frío (Cold-standby): infraestructura definida como código pero no aprovisionada. RTO de días; el coste más bajo; riesgo de sorpresas por desviaciones (drift), cuotas y escasez de capacidad.

• Pruebas de caos y simulaciones de fallos

  • Simula regularmente caídas de instancias, procesos colgados, fallos en las comprobaciones de estado, condiciones de disco lleno y caídas de dependencias. Utiliza herramientas o scripts para terminar instancias, bloquear el tráfico de salida (egress) a los backends o inyectar latencia en la capa de proxy.
  • Valida la autorreparación del MIG y la eliminación por parte del LB fallando intencionadamente el endpoint de estado. Confirma el comportamiento de reemplazo y los plazos de recuperación.
  • Practica la evacuación regional: drena los backends en una región, observa la conmutación por error (failover) del balanceador de carga global y verifica las dependencias con estado (stateful) en la región secundaria.
  • Mejora continua: registra métricas como el tiempo medio de detección, el tiempo de conmutación por error y la pérdida de datos durante las pruebas. Prioriza las correcciones que reducen el RTO/RPO y eliminan los pasos manuales.

Escenario de problema práctico

Brightlane Retail opera una plataforma de comercio electrónico en us-central1 con una disponibilidad estricta y un RPO de cuatro horas para los datos de pedidos. La dirección exige sobrevivir a una interrupción zonal sin tiempo de inactividad y a una interrupción regional con un impacto mínimo para el cliente.

Enfoque:

1. Implementar un MIG regional con autorreparación HTTP y un HTTP(S) Load Balancer global

   • Justificación: Un MIG regional distribuye las instancias entre zonas, y las comprobaciones de estado HTTP a nivel de aplicación permiten la autorreparación tras tres comprobaciones fallidas de 10 segundos cada una. El balanceador de carga global elimina automáticamente las VM en mal estado y conmuta el tráfico a las zonas sanas.
   • Comandos: gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –unhealthy-threshold=3 –request-path=/healthz gcloud compute instance-groups managed update web-rmig –region=us-central1 –health-check=app-hc –initial-delay=60

2. Habilitar la alta disponibilidad (HA) de Cloud SQL con una réplica de lectura entre regiones y PITR

   • Justificación: La HA regional proporciona supervivencia zonal con conmutación por error automática. Una réplica de lectura en us-east1 proporciona DR regional con un RPO no nulo pero acotado. Habilitar PITR (registro binario para MySQL) soluciona la corrupción lógica al permitir la restauración a un punto en el tiempo.
   • Comandos: gcloud sql instances patch orders-mysql –enable-bin-log –backup-start-time=03:00 gcloud sql instances create orders-replica –master-instance-name=orders-mysql –region=us-east1

3. Proteger los activos de objetos con Cloud Storage de doble región y políticas de ciclo de vida

   • Justificación: Las imágenes de productos y los activos estáticos se almacenan en un bucket de doble región para la resiliencia regional. Las transiciones del ciclo de vida mueven los artefactos más antiguos a Coldline para optimizar costes, y el control de versiones junto con las políticas de retención evitan la eliminación accidental de activos críticos.
   • Pasos: Habilitar el control de versiones de objetos (Object Versioning), establecer una política de retención de 30 días para los buckets críticos y aplicar reglas de ciclo de vida para la transición a Coldline después de 90 días y la eliminación después de un año para los artefactos de compilación no críticos.

4. Programar instantáneas de PD y crear imágenes de máquina para servicios con estado (stateful)

   • Justificación: Las instantáneas incrementales de los discos de VM proporcionan opciones de restauración rápidas y consistentes ante caídas. Las imágenes de máquina capturan el arranque y la configuración para acelerar la rehidratación de los servidores de aplicaciones durante una conmutación por error regional. La programación de instantáneas garantiza copias de seguridad consistentes y basadas en políticas.
   • Comandos: gcloud compute resource-policies create snapshot-schedule daily-2am –max-retention-days=14 –on-source-disk-delete=apply-retention-policy –start-time=02:00 gcloud compute disks add-resource-policies app-disk-1 –resource-policies=daily-2am gcloud compute machine-images create app-mi-2024-09-01 –source-instance=app-vm-template

5. Definir RTO/RPO y codificar los runbooks de DR y la IaC

   • Justificación: Establecer un RTO a nivel de servicio de 15 minutos para la web/API y un RPO de cuatro horas para los pedidos. Los runbooks especifican los procedimientos de conmutación por error del tráfico, la promoción de la réplica de lectura de Cloud SQL, las contingencias de DNS y los pasos de verificación. La infraestructura como código (Terraform/Deployment Manager) garantiza reconstrucciones deterministas y reduce el error manual.

6. Aprovisionar capacidad y cuotas en la región secundaria

   • Justificación: Crear reservas para las formas de VM críticas, preaprovisionar un backend de balanceador de carga en espera, certificados SSL, capacidad de NAT y verificar las cuotas para Compute, SQL, reglas de reenvío y KMS en us-east1. Esto evita la falta de capacidad durante una conmutación por error.

7. Validar la recuperación mediante simulacros de caos y documentar las mejoras

   • Justificación: Los simulacros trimestrales de fallos zonales validan el comportamiento del MIG y del LB; la evacuación regional semestral promueve la réplica de lectura en us-east1, apunta el LB global a los backends de us-east1 y mide el RTO/RPO. Los hallazgos impulsan mejoras como la reducción de pasos manuales o el aumento de la capacidad de la réplica.

Siguiendo estos pasos, Brightlane Retail logra una alta disponibilidad zonal con autorreparación automatizada y una postura de DR regional con runbooks definidos y probados, asegurando que los datos de los pedidos cumplan con un RPO de cuatro horas y que los servicios de la aplicación se recuperen dentro de los límites de RTO establecidos.

← Seguridad · Todos los dominios · Gestión de costos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →