La réplication de base de données et les sauvegardes sont deux mécanismes complémentaires, mais ne se remplacent pas. Voici les distinctions critiques et les raisons pour lesquelles la réplication ne suffit pas :

Objectifs distincts

Réplication :
But : Assurer la disponibilité et la redondance en temps réel (ou quasi réel) pour des besoins de haute disponibilité (HA) ou de répartition de charge.
Portée : Copie les modifications (transactions) vers un ou plusieurs nœuds secondaires en continu.
Limites :
Ne protège pas contre les corruptions logiques (ex. : suppression accidentelle, DROP TABLE, données corrompues par une application).
Ne permet pas de restaurer un état antérieur (ex. : avant une erreur humaine ou une attaque).
Vulnérable aux erreurs synchronisées (ex. : une requête malveillante ou une mise à jour erronée sera répliquée).

Sauvegardes :
But : Permettre la restauration à un point dans le temps (Point-in-Time Recovery, PITR) et protéger contre les pertes de données (corruption, suppression, attaque).
Portée : Capture un instantané cohérent des données à un moment donné, souvent avec des journaux de transactions pour restaurer entre deux sauvegardes.
Avantages :
Permet de remonter dans le temps (ex. : avant une suppression accidentelle).
Protège contre les corruptions logiques (si les sauvegardes sont isolées).
Indépendante de l'infrastructure principale (peut être stockée hors ligne ou dans un coffre immuable).

Scénarios où la réplication échoue seule

Scénario Réplication seule Sauvegarde nécessaire

Suppression accidentelle (DELETE FROM clients) (répliquée) (restauration possible)
Corruption de données (bug applicatif) (répliquée) (rétablissement)
Attaque par ransomware (répliquée et chiffrée) (si sauvegardes hors ligne)
Panne matérielle du nœud principal (bascule possible) (mais pas de PITR)
Erreur de migration de schéma (répliquée) (retour arrière)

Bonnes pratiques combinées

Stratégie minimale viable :

Réplication pour la haute disponibilité (ex. : réplica synchrone ou asynchrone).
Sauvegardes automatiques :

Complètes (hebdomadaires) + incrémentielles (quotidiennes).
Journaux de transactions pour le PITR.
Stockage isolé (hors du réseau de production, idéalement immuable ou WORM).

Tests de restauration réguliers pour valider l'intégrité des sauvegardes.

Exemple d'architecture :
Réplication synchrone entre deux nœuds en production (pour la disponibilité).
Sauvegardes nocturnes envoyées vers un stockage objet (S3, Swift) avec versioning.
Un nœud de réplication en lecture seule pour les requêtes analytiques (sans écriture).

Risques de se fier à la réplication seule

Fausse sécurité : Croire que la redondance = protection contre les pertes.
Amplification des erreurs : Une corruption ou une suppression est dupliquée instantanément.
Non-conformité : Certaines réglementations (ex. : RGPD, HIPAA) exigent des sauvegardes pour la récupération des données.

Correction de la phrase initiale
« Une réplication de base ne remplace pas les sauvegardes : elle en est un complément essentiel pour la disponibilité, tandis que les sauvegardes restent indispensables pour la récupération après incident et la protection contre les corruptions logiques. »