Décision : quelle stratégie de sauvegarde ?
Une stratégie de sauvegarde se choisit en équilibrant trois facteurs : la perte de données tolérable (RPO), la taille des données et la rapidité de reprise exigée (RTO). Aucune méthode ne convient à tous les scénarios. En partant de l'objectif de RPO, cet arbre vous oriente entre dumps logiques, sauvegardes physiques + PITR et snapshots, et vous rappelle que la règle 3-2-1 et la vérification ne sont pas négociables.
Quel est votre objectif de perte de données (RPO) ?
Commencez par la contrainte la plus décisive : en cas de sinistre, combien de minutes/heures de données pouvez-vous vous permettre de perdre ? Si une perte quasi nulle est exigée, l'archivage continu des journaux (PITR) est obligatoire ; si une tolérance de sauvegarde quotidienne/hebdomadaire est acceptable, des méthodes plus simples suffisent. Le RPO définit le cadre de la stratégie.
- Quasi nulle — je dois pouvoir revenir à n'importe quel instant
- Des sauvegardes quotidiennes/périodiques (quelques heures de perte) sont acceptables
- Rappelez-moi d'abord les bonnes pratiques générales (3-2-1 / vérification)
Quelles sont la taille des données et les exigences de portabilité ?
Si des sauvegardes périodiques suffisent, la question suivante porte sur l'échelle et l'objectif : la base est-elle petite/moyenne et voulez-vous une sauvegarde portable vers un autre environnement/une autre version, ou les données sont-elles volumineuses et votre priorité est-elle de revenir en quelques minutes ? Cela tranche entre un dump logique et un snapshot.
- Petite/moyenne, portable et compatible entre versions
- Données volumineuses, reprise très rapide requise (RTO faible)
Recommandation : dump logique
Exporte les données au niveau logique (définitions de schéma + lignes) ; la sortie est soit du SQL/texte (format plain de pg_dump, mysqldump), soit un dump binaire propre à l'outil (pg_dump -Fc, Oracle Data Pump). Une méthode flexible et portable pour les bases petites et moyennes, les migrations, les montées de version et la restauration de tables/objets choisis.
Recommandation : sauvegarde physique + WAL/journaux archivés (PITR)
Vous effectuez régulièrement des sauvegardes physiques de base et archivez en continu les journaux de transactions (WAL/redo/binlog). Cela permet une Point-in-Time Recovery à n'importe quel instant et réduit la perte de données à presque zéro.
Recommandation : snapshot
Prend un snapshot au niveau bloc des données dans la couche de stockage ou de virtualisation. Sauvegarde et restauration sont très rapides, même pour de très grandes bases ; il dépend toutefois de l'infrastructure et exige une utilisation prudente.
Recommandation : règle 3-2-1 + hors site + vérification obligatoire
Quelle que soit la méthode choisie, ces principes doivent chapeauter la stratégie. La simple existence d'une sauvegarde ne suffit pas ; elle doit être sur un support différent, dans un lieu différent et testée régulièrement. C'est un cadre qui complète toutes les options ci-dessus.