Aller au contenu

Backups Mis à jour le 2025-08-01

Sauvegardes cohérentes avec l''application vs cohérentes au crash : la distinction qui compte

Ce que les deux niveaux de cohérence signifient réellement, comment chaque outil de sauvegarde les atteint (ou non), et l''arbre de décision qu''on applique au design d''une stratégie de sauvegarde.

« Cohérent avec l”application » vs « cohérent au crash » est une de ces expressions qui sonnent comme du jargon marketing mais qui est en fait la distinction la plus conséquente opérationnellement dans le travail de sauvegarde. La différence décide si votre sauvegarde se restaure proprement ou se restaure avec innodb_force_recovery=4, si votre réplica reprend la réplication ou doit être reconstruit, si votre application démarre immédiatement ou a besoin de réparation de base. Cet article définit les termes précisément, mappe chaque motif de sauvegarde courant au niveau de cohérence qu”il atteint, et parcourt l”arbre de décision qu”on applique au design d”une stratégie de sauvegarde pour un nouveau mandat.

Comment vérifier

Pour tout outil de sauvegarde déjà en production, posez trois questions à sa configuration :

# 1. L''outil émet-il une quiescence de base avant l''instantané/copie ?
grep -i "pre-backup\|hook\|freeze" /etc/<outil-sauvegarde>/config

# 2. La couche de stockage garantit-elle des instantanés atomiques des répertoires de données + logs ensemble ?
mount | grep -E '(mysql|postgres|mongo)'
lvs -o name,vg_name,attr

# 3. Après restauration dans un environnement d''essai, le moteur démarre-t-il sans messages de récupération ?
journalctl -u postgresql | grep -i 'recovery'
journalctl -u mysql | grep -i 'recovery\|crash'

Si les réponses sont « pas de quiescence / données et journaux sur des volumes séparés sans instantané atomique / messages de récupération à chaque restauration », vous avez au mieux une sauvegarde cohérente au crash — parfois pire.

Ce qui se passe

Cohérent au crash signifie : un instantané de la couche de stockage à un instant, comme si quelqu”un avait débranché le courant. L”application est au milieu d”une transaction ; son état en mémoire est perdu ; seul ce qui était écrit sur disque persiste. L”application démarre de cette image comme si elle avait crashé — son propre code de récupération crash s”exécute (journaux redo, journaux, fsck) et réussit ou échoue selon que l”état du disque s”est avéré récupérable.

Cohérent avec l”application signifie : on dit à l”application d”arrêter d”écrire, de vider son état en mémoire sur disque, et de reconnaître qu”elle est à un point cohérent connu. Ensuite l”instantané a lieu. Quand l”application redémarre de cette image, elle saute la récupération — il n”y a rien à récupérer parce que l”état du disque est intérieurement cohérent.

La différence n”est pas académique :

  • Une sauvegarde cohérente au crash de MySQL avec innodb_flush_log_at_trx_commit=1 se restaurera presque toujours via la récupération crash d”InnoDB. « Presque toujours » n”est pas la même chose que « toujours » ; on a vu des cas 1-sur-200 où une écriture de page déchirée au moment de l”instantané a fait échouer la récupération, exigeant innodb_force_recovery et perte de données.
  • Une sauvegarde cohérente au crash d”une base avec plusieurs tablespaces sur volumes séparés (où l”instantané n”était pas atomique entre volumes) se restaure dans un état incohérent et peut corrompre silencieusement.
  • Une sauvegarde cohérente au crash d”une application qui écrit ses propres fichiers (pensez Git, Maildir, entrepôts de documents) restaure des fichiers que l”application peut lire, mais la notion d”« écrit » de l”application peut ne pas correspondre à l”état des fichiers.

Cohérent avec l”application est atteint par trois mécanismes :

  1. Quiescence de base : FLUSH TABLES WITH READ LOCK (MySQL), pg_backup_start() (PostgreSQL), db.fsyncLock() (MongoDB), arrêt de l”écrivain (certains entrepôts NoSQL).
  2. Gel de système de fichiers : fsfreeze -f bloque les nouvelles écritures et attend que les écritures en vol se terminent, puis l”instantané tire, puis fsfreeze -u le relâche.
  3. VSS sur Windows : le Volume Shadow Copy Service coordonne avec les applications VSS-conscientes (SQL Server, Exchange, IIS) pour mettre en pause et vider avant l”instantané.

Le compromis : les sauvegardes cohérentes avec l”application exigent une coordination avec l”application, ce qui signifie temps d”arrêt (FTWRL bloque les écritures pour la durée de l”instantané) ou verrous d”écriture (pg_backup_start ne bloque pas mais coordonne différemment). Les sauvegardes cohérentes au crash peuvent être prises sans toucher à l”application mais échangent cette simplicité contre le risque de restauration.

La décision

Notre arbre de décision pour un nouveau mandat :

  1. Charge de base ? Si oui, l”outil de sauvegarde doit émettre une capture cohérente avec l”application via le propre protocole de la base. Pour MySQL : Percona XtraBackup, mysqldump, ou instantané LVM + FTWRL. Pour PostgreSQL : pgBackRest, WAL-G, ou instantané LVM + pg_backup_start. Pour MongoDB : mongodump ou instantané de système de fichiers avec db.fsyncLock(). Cohérent au crash n”est pas acceptable pour les bases.

  2. Données seulement sur système de fichiers (contenu web, téléversements d”utilisateurs, entrepôts de documents) ? Cohérent au crash est acceptable mais seulement quand l”application peut être redémarrée proprement après une coupure. Si l”application a son propre journal d”écriture anticipée (Git, Bazaar) la cohérence crash va habituellement bien. Si l”application emploie beaucoup-de-petits-fichiers avec mises à jour atomiques par renommage (Maildir, files style qmail), la cohérence crash va généralement parce que l”application est elle-même conçue pour survivre aux crashs.

  3. Instantanés au niveau VM (instantanés de volumes infonuagiques, instantanés ESXi) ? Ce sont des instantanés cohérents au crash sauf si l”agent de quiescence du guest participe (qemu-guest-agent sur KVM, VMware Tools, AWS Backup avec quiescence). On ne fait jamais confiance à un instantané VM d”une base sans confirmer que la quiescence de l”agent s”est exécutée.

  4. PV Kubernetes ? Les hooks de sauvegarde Velero permettent de scripter la quiescence côté pod avant l”instantané de volume. On les emploie pour les bases ; pour les charges sans état, l”instantané seul va bien.

  5. L”argumentaire « on prend des instantanés chaque heure ». Chaque fois qu”un client dit cela, on demande « et qu”est-ce qui met en quiescence l”application ? ». La réponse est presque toujours « rien ». C”est une sauvegarde cohérente au crash ; on ajoute la quiescence ou on remplace l”outil.

Notes opérationnelles

  • Exécutez toujours un essai de restauration dans un environnement d”essai. L”essai est le seul test qui distingue une chaîne saine d”un rapport de « sauvegarde réussie » qui ne se restaure pas. On le fait trimestriellement pour les bases de production.
  • Les bases multi-volumes (données + WAL sur volumes séparés, plusieurs tablespaces) exigent des instantanés atomiques entre tous les volumes. Les fonctionnalités « instantané multi-volumes » de fournisseur infonuagique existent (AWS Snapshot Lock, Azure Snapshot Sets) mais vérifiez la prétention de cohérence avec un essai de restauration.
  • « Cohérent au crash » ne signifie pas « inutile ». Pour tout sauf les moteurs de base et les applications à journal d”écriture anticipée, cohérent au crash est le bon point coût/valeur. Réservez cohérent avec l”application aux charges où le coût de récupération serait plus grand que le coût de quiescence.
  • Le cas le plus dur est les microservices avec plusieurs bases. Chaque base a besoin de sa propre capture cohérente avec l”application ; les instantanés doivent être coordonnés à un seul horodatage logique si l”intégrité référentielle inter-base compte. On emploie les hooks Velero + l”outillage par base pour cela.
  • Les sauvegardes cohérentes avec l”application ont encore besoin des journaux WAL/transaction pour la récupération complète, pas seulement de l”instantané. Un instantané à T0 plus WAL jusqu”à T0+5 permet de restaurer à T0+5 ; l”instantané seul ne restaure qu”à T0.

Dans les mandats que nous menons, le niveau de cohérence de chaque palier de sauvegarde est une décision qu”on consigne explicitement — la sauvegarde quotidienne est cohérente avec l”application (le seul niveau acceptable pour les bases), le palier horaire est cohérent au crash (acceptable pour la moitié système de fichiers de la charge), la copie hors site préserve le niveau de cohérence de ce qu”elle copie. La stratégie complète qu”on enroule est à /en/services/managed-operations/, et le modèle d”opération pour les bases en grappe est dans Environnements en grappe.