Backup y disaster recovery para una base de datos de decenas de TB

Question

IT Interview Practice · Accepted Answer

**Combina snapshots periódicos con archivado continuo del WAL para point-in-time recovery, replica offsite/cross-region, y demuéstralo con simulacros de restauración regulares contra objetivos explícitos de RPO/RTO.** Un backup que nunca has restaurado es una esperanza, no un plan.

## Arquitectura

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## Cómo funciona

- **Los snapshots** son una copia completa del volumen/cluster (p. ej. un snapshot diario de EBS o `pg_basebackup`). Son la base *desde la que* restauras — pero restaurar solo a anoche pierde un día de escrituras.
- **El archivado de WAL / binlog** transmite cada cambio desde el último snapshot al object store de forma continua. Restaurar = snapshot + replay del WAL hasta cualquier segundo elegido. Esto es **PITR (point-in-time recovery)** — recupera a las 10:32:04, el momento antes de un `DELETE` malo.
- **Offsite / cross-region.** Un backup en la misma región que la DB muere con la región. Replica a una segunda región (S3 cross-region replication) para que una caída regional o un ransomware no se lleve ambas.
- **Simulacros de restauración.** Restaura periódicamente en un entorno scratch, mide cuánto tardó (**RTO**) y cuántos datos habrías perdido (**RPO**), y haz checksum contra prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = cuántos datos puedes permitirte perder. Archivado de WAL cada 5 min → RPO ≈ 5 min. Réplica síncrona → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = qué tan rápido debes volver. Restaurar 20TB desde S3 puede tardar horas; una réplica warm standby recorta el RTO a minutos.

## Perspectiva de la entrevista

El entrevistador sondea si sabes que **los snapshots por sí solos no bastan** (pérdida de datos entre ellos), si puedes **definir RPO/RTO en números**, y si **pruebas las restauraciones**. Las respuestas excelentes recalcan que los backups no probados fallan justo cuando se necesitan, y eligen una estrategia a partir del RPO/RTO del *negocio*, no de la conveniencia. Una trampa: asumir que una read replica es un backup — la replicación copia fielmente un `DROP TABLE` también.

## Compensaciones y modos de fallo

- **Coste vs RTO.** Un warm standby cross-region da minutos de RTO pero duplica el coste de infra; una restauración fría desde S3 es barata pero lenta. Compra el nivel que el negocio realmente necesita.
- **Carga del backup.** Hacer snapshot de una DB caliente de 20TB añade I/O; toma los snapshots desde una réplica.
- **Corrupción silenciosa.** El WAL puede archivar una página corrupta; una restauración completa periódica + checksum lo atrapa.
- **Retención y compliance.** Mantén suficiente historial (p. ej. 35 días de PITR + archivos mensuales) para necesidades legales; Glacier para largo plazo barato.
- **Cuándo no:** una DB diminuta está bien con un `pg_dump` nocturno a S3 — WAL completo + warm standby cross-region es excesivo hasta que la pérdida de datos se mide en dinero real.

Arquitectura

Cómo funciona

RPO vs RTO

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas