Sauvegarde et reprise après sinistre pour une base de données de dizaines de To

Question

IT Interview Practice · Accepted Answer

**Combinez des snapshots périodiques avec un archivage continu du WAL pour le point-in-time recovery, répliquez hors-site/cross-région, et prouvez-le avec des exercices de restauration réguliers contre des cibles RPO/RTO explicites.** Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan.

## Architecture

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

## Comment ça fonctionne

- **Les snapshots** sont une copie complète du volume/cluster (par ex. un snapshot EBS quotidien ou `pg_basebackup`). C'est la base *depuis* laquelle vous restaurez — mais restaurer seulement jusqu'à la nuit dernière perd une journée d'écritures.
- **L'archivage WAL / binlog** streame en continu chaque changement depuis le dernier snapshot vers le store objet. Restaurer = snapshot + rejouer le WAL jusqu'à n'importe quelle seconde choisie. C'est le **PITR (point-in-time recovery)** — récupérer à 10:32:04, l'instant avant un mauvais `DELETE`.
- **Hors-site / cross-région.** Une sauvegarde dans la même région que la DB meurt avec la région. Répliquez vers une seconde région (réplication cross-région S3) pour qu'une panne régionale ou un ransomware ne prenne pas les deux.
- **Exercices de restauration.** Restaurez périodiquement dans un environnement jetable, mesurez le temps que cela a pris (**RTO**) et la quantité de données que vous auriez perdue (**RPO**), et faites un checksum contre la prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = combien de données vous pouvez vous permettre de perdre. Archivage WAL toutes les 5 min → RPO ≈ 5 min. Réplica synchrone → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = à quelle vitesse vous devez être de retour. Restaurer 20To depuis S3 peut prendre des heures ; un réplica standby chaud réduit le RTO à des minutes.

## Perspective d'entretien

L'examinateur sonde si vous savez que **les snapshots seuls ne suffisent pas** (perte de données entre eux), si vous pouvez **définir RPO/RTO en chiffres**, et si vous **testez les restaurations**. Les excellentes réponses insistent sur le fait que les sauvegardes non testées échouent exactement quand nécessaire, et choisissent une stratégie à partir du RPO/RTO *métier*, non de la commodité. Un piège : supposer qu'un read replica est une sauvegarde — la réplication copie fidèlement un `DROP TABLE` aussi.

## Compromis et pannes

- **Coût vs RTO.** Un standby cross-région chaud donne un RTO de minutes mais double le coût d'infra ; une restauration cold depuis S3 est bon marché mais lente. Achetez le tier dont le métier a réellement besoin.
- **Charge de sauvegarde.** Snapshotter une DB de 20To chaude ajoute de l'I/O ; prenez les snapshots depuis un réplica.
- **Corruption silencieuse.** Le WAL peut archiver une page corrompue ; une restauration complète périodique + checksum l'attrape.
- **Rétention & conformité.** Gardez assez d'historique (par ex. 35 jours de PITR + archives mensuelles) pour les besoins légaux ; Glacier pour le long terme bon marché.
- **Quand ne pas le faire :** une petite DB se contente d'un `pg_dump` nocturne vers S3 — WAL complet + standby cross-région est excessif tant que la perte de données ne se mesure pas en argent réel.

Architecture

Comment ça fonctionne

RPO vs RTO

Perspective d'entretien

Compromis et pannes

Questions connexes