Backup e disaster recovery per un database di decine di TB

Question

IT Interview Practice · Accepted Answer

**Combina snapshot periodici con l'archiviazione continua del WAL per il point-in-time recovery, replica offsite/cross-region, e provalo con drill di restore regolari rispetto a target RPO/RTO espliciti.** Un backup che non hai mai ripristinato è una speranza, non un piano.

## Architettura

```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
```

## Come funziona

- **Gli snapshot** sono una copia completa del volume/cluster (es. snapshot EBS giornaliero o `pg_basebackup`). Sono la base *da* cui ripristini — ma ripristinare solo a ieri sera perde un giorno di scritture.
- **L'archiviazione WAL / binlog** fa streaming continuo di ogni cambiamento dall'ultimo snapshot verso l'object store. Restore = snapshot + replay del WAL fino a qualunque secondo scelto. Questo è il **PITR (point-in-time recovery)** — recupera alle 10:32:04, l'istante prima di un `DELETE` errato.
- **Offsite / cross-region.** Un backup nella stessa region del DB muore con la region. Replica in una seconda region (S3 cross-region replication) così che un'interruzione regionale o un ransomware non prenda entrambi.
- **Drill di restore.** Ripristina periodicamente in un ambiente scratch, misura quanto ha impiegato (**RTO**) e quanti dati avresti perso (**RPO**), e fai il checksum rispetto alla prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = quanti dati puoi permetterti di perdere. Archiviazione WAL ogni 5 min → RPO ≈ 5 min. Replica sincrona → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = quanto velocemente devi tornare operativo. Ripristinare 20TB da S3 può richiedere ore; una replica warm standby riduce l'RTO a minuti.

## Prospettiva del colloquio

L'intervistatore sonda se sai che **gli snapshot da soli non bastano** (perdita di dati tra uno e l'altro), se sai **definire RPO/RTO in numeri**, e se **testi i restore**. Le risposte eccellenti sottolineano che i backup non testati falliscono esattamente quando servono, e scelgono una strategia dagli RPO/RTO di *business*, non dalla convenienza. Una trappola: assumere che una read replica sia un backup — la replica copia fedelmente anche un `DROP TABLE`.

## Compromessi e modalità di guasto

- **Costo vs RTO.** Uno warm standby cross-region dà minuti di RTO ma raddoppia il costo dell'infra; un restore cold da S3 è economico ma lento. Compra il tier di cui il business ha davvero bisogno.
- **Carico del backup.** Fare snapshot di un DB caldo da 20TB aggiunge I/O; fai gli snapshot da una replica.
- **Corruzione silenziosa.** Il WAL può archiviare una pagina corrotta; un full-restore periodico + checksum la individua.
- **Retention e compliance.** Mantieni abbastanza storia (es. 35 giorni di PITR + archivi mensili) per le esigenze legali; Glacier per il lungo termine economico.
- **Quando non farlo:** un DB minuscolo va bene con un `pg_dump` notturno su S3 — WAL completo + standby cross-region è eccessivo finché la perdita di dati non si misura in denaro reale.

Architettura

Come funziona

RPO vs RTO

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate