Pourquoi les snapshots de VM ne sont pas sûrs pour les bases de données transactionnelles : le guide d’un DBA pour l’intégrité des données

Pour les ingénieurs DevOps et les administrateurs système, les snapshots de machines virtuelles (VM) sont un outil fondamental. Ils offrent un moyen rapide et pratique de capturer l’état d’un serveur avant un correctif risqué, un changement de configuration majeur ou le déploiement d’une application. Si quelque chose tourne mal, la restauration ne prend que quelques secondes.

Cependant, lorsque cette même méthodologie est appliquée aux bases de données transactionnelles — telles que PostgreSQL, MySQL, Oracle ou Microsoft SQL Server — les snapshots de VM passent d’un filet de sécurité à une bombe à retardement.

Se fier aux snapshots standards de l’hyperviseur pour les sauvegardes de bases de données est l’une des causes les plus fréquentes de corruption de données, de pages déchirées (torn pages) et d’interruptions de production irrécupérables. Dans cet article, nous explorerons le conflit architectural entre les hyperviseurs et les moteurs de base de données, les mécanismes de corruption des données lors des snapshots, et les meilleures pratiques d’ingénierie requises pour sauvegarder en toute sécurité les bases de données virtualisées.

Le conflit architectural : Hyperviseurs vs Moteurs de base de données

Pour comprendre pourquoi les snapshots de VM mettent en danger les bases de données, nous devons d’abord examiner comment les deux systèmes gèrent l’état et les opérations d’E/S.

Comment les hyperviseurs exécutent les snapshots

Lorsqu’un hyperviseur (tel que VMware ESXi, Microsoft Hyper-V ou KVM) effectue un snapshot, il ne copie pas le disque. Au lieu de cela, il fige le fichier de disque virtuel actuel (par exemple, .vmdk ou .vhdx) dans un état en lecture seule et crée un nouveau disque delta (disque de différenciation). Toutes les écritures ultérieures sont dirigées vers ce disque delta.

Lorsque le snapshot est supprimé, l’hyperviseur doit valider (consolider) les données du disque delta vers le disque de base. Les snapshots standards ignorent totalement les applications s’exécutant à l’intérieur du système d’exploitation invité. Ils capturent l’état du disque exactement tel qu’il existe à cette microseconde.

Comment les bases de données transactionnelles gèrent l’état

Les bases de données transactionnelles sont conçues autour des propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité). Pour atteindre des performances élevées tout en maintenant la conformité ACID, les bases de données n’écrivent pas immédiatement chaque transaction directement dans les fichiers de données primaires sur le disque. Au lieu de cela, elles utilisent une architecture complexe à plusieurs niveaux :

1. Buffer Pool / Shared Buffers : Les données sont lues et modifiées dans la mémoire système.
2. Write-Ahead Log (WAL) / Redo Logs : Les modifications sont écrites séquentiellement dans un fichier journal hautement optimisé sur le disque pour garantir la durabilité.
3. Checkpoints / Lazy Writers : Périodiquement, la base de données vide les pages modifiées (sales) de la mémoire vers les fichiers de données réels sur le disque.

En raison de cette architecture, les fichiers de données physiques sur le disque sont presque toujours désynchronisés par rapport à l’état réel de la base de données. Le véritable état de la base de données n’existe que sous la forme d’une combinaison des fichiers de données sur le disque, des journaux WAL/Redo et des données résidant actuellement en mémoire.

La zone de danger : Ce qui se passe lors d’un snapshot de VM

Lorsque vous prenez un snapshot de VM standard d’un serveur de base de données, vous capturez un état cohérent en cas de crash (crash-consistent).

Cohérence en cas de crash vs Cohérence applicative

Un snapshot cohérent en cas de crash équivaut à débrancher le cordon d’alimentation du serveur physique. L’état du disque est capturé, mais tout ce qui se trouvait en mémoire est perdu, et tout ce qui était en cours de transfert vers le contrôleur de stockage est brusquement interrompu.

Bien que les bases de données modernes soient conçues pour récupérer après une perte de puissance inattendue en rejouant le Write-Ahead Log, se fier à la récupération après crash comme stratégie de sauvegarde principale est extrêmement dangereux. Si votre base de données s’étend sur plusieurs disques virtuels (par exemple, fichiers de données sur le lecteur D: et WAL sur le lecteur E:), l’hyperviseur peut ne pas capturer les deux disques à la même microseconde exacte. Si le snapshot du disque WAL est capturé ne serait-ce qu’une fraction de seconde après celui du disque de données, la base de données ne pourra pas réconcilier les numéros de séquence lors de la restauration, ce qui entraînera une corruption fatale.

L’effet « VM Stun » sur les systèmes à haute transaction

Le processus de création de snapshot — et plus important encore, le processus de consolidation — provoque un phénomène connu sous le nom de « VM Stun » (gel de la VM).

Pour basculer en toute sécurité les E/S du disque de base vers le disque delta, l’hyperviseur doit brièvement mettre en pause (geler) la machine virtuelle. Pour un serveur web peu sollicité, ce gel peut durer 10 à 50 millisecondes et passer inaperçu. Cependant, pour une base de données à haut débit avec des E/S massives, la consolidation d’un gros disque delta peut geler la VM pendant plusieurs secondes.

Pendant un gel de VM :
* Les connexions réseau tombent, provoquant des délais d’attente (timeouts) des applications.
* Les clusters à haute disponibilité (comme SQL Server Always On, PostgreSQL Patroni ou MySQL Galera) manquent les vérifications de pulsation (heartbeat).
* Le cluster peut supposer que le nœud gelé est mort, déclenchant un basculement inutile et perturbateur (scénario split-brain).

Pages déchirées et désalignement des E/S

Les moteurs de base de données écrivent généralement les données dans des tailles de page spécifiques (par exemple, 8 Ko pour PostgreSQL et SQL Server, 16 Ko pour InnoDB). Cependant, le système d’exploitation sous-jacent et les baies de stockage traitent les E/S dans des blocs plus petits (par exemple, 4 Ko ou 512 octets).

Si un hyperviseur prend un snapshot exactement au moment où la base de données écrit une page de 8 Ko, le snapshot pourrait capturer les 4 premiers Ko des nouvelles données et les 4 derniers Ko des anciennes données. Cela crée une page déchirée (torn page). Lorsque vous tenterez de restaurer le snapshot, la base de données lira la page, échouera à la validation de la somme de contrôle (checksum) et marquera la base de données comme corrompue.

Conséquences réelles pour des moteurs de base de données spécifiques

Différents moteurs de base de données réagissent aux snapshots cohérents en cas de crash de diverses manières, mais aucun ne le gère correctement dans un environnement de production.

• PostgreSQL : PostgreSQL repose fortement sur le répertoire pg_wal. Si un snapshot capture le répertoire de données ($PGDATA) et le WAL de manière désynchronisée, PostgreSQL ne démarrera pas, renvoyant une erreur PANIC: could not locate a valid checkpoint record.
• MySQL/InnoDB : InnoDB utilise un doublewrite buffer pour éviter les pages déchirées, ce qui offre une certaine protection contre les états cohérents en cas de crash. Cependant, si le fichier ibdata1 et le ib_logfile sont capturés de manière désynchronisée, le moteur InnoDB plantera lors de la récupération.
• Microsoft SQL Server : SQL Server est très sensible au gel des E/S. Sans une intégration VSS (Volume Shadow Copy Service) appropriée, la restauration d’un SQL Server à partir d’un snapshot de VM standard entraînera souvent des bases de données suspectes et des chaînes de journaux brisées, détruisant vos capacités de récupération à un instant T (PITR).

Meilleures pratiques pour sauvegarder en toute sécurité les bases de données virtualisées

Pour protéger les bases de données transactionnelles, vous devez passer de sauvegardes cohérentes en cas de crash à des sauvegardes cohérentes au niveau applicatif. Cela nécessite que le mécanisme de sauvegarde communique avec le moteur de base de données, le forçant à vider la mémoire sur le disque et à mettre en pause les opérations d’E/S momentanément pendant la prise du snapshot.

1. Tirer parti de la mise en attente (quiescing) compatible avec les applications (VSS et fsfreeze)

Pour Windows (SQL Server) :
Assurez-vous toujours que votre solution de sauvegarde utilise le service VSS (Volume Shadow Copy Service) de Microsoft. Lorsqu’une sauvegarde compatible VSS est déclenchée, le SQL Server VSS Writer gèle les E/S de la base de données, vide les transactions en attente sur le disque et garantit que le snapshot est parfaitement cohérent au niveau applicatif.

Pour Linux (PostgreSQL / MySQL) :
Linux n’a pas d’équivalent natif à VSS. Pour obtenir une cohérence applicative, vous devez utiliser des scripts de pré-gel (pre-freeze) et de post-dégel (post-thaw) en conjonction avec les outils invités de l’hyperviseur (par exemple, VMware Tools).

Voici un exemple de pre-freeze-script VMware pour PostgreSQL 15+ qui prépare en toute sécurité la base de données pour un snapshot :

#!/bin/bash
# /usr/sbin/pre-freeze-script
# Assurez-vous que ce script est exécutable (chmod +x)

# 1. Dire à PostgreSQL de se préparer pour une sauvegarde
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""

# 2. Vider les tampons du système de fichiers sur le disque
sync

# 3. Geler le système de fichiers (en supposant que les données sont sur /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql

Et le post-thaw-script correspondant pour reprendre les opérations :

#!/bin/bash
# /usr/sbin/post-thaw-script

# 1. Dégeler le système de fichiers
fsfreeze -u /var/lib/pgsql

# 2. Dire à PostgreSQL que la sauvegarde est terminée
su - postgres -c "psql -c "SELECT pg_backup_stop();""

2. Utiliser des utilitaires de sauvegarde de base de données natifs

Bien que les snapshots cohérents au niveau applicatif soient meilleurs que les snapshots standards, ils comportent toujours le risque de gel de la VM. L’approche la plus sûre pour les sauvegardes de bases de données consiste à utiliser des utilitaires de sauvegarde natifs et en continu qui fonctionnent indépendamment de l’hyperviseur.

PostgreSQL (pg_basebackup) :

pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P

MySQL/MariaDB (Percona XtraBackup / Mariabackup) :
Ces outils effectuent des sauvegardes à chaud, sans blocage, en copiant les fichiers de données et en suivant simultanément les modifications dans le redo log.

mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass

SQL Server (T-SQL) :

BACKUP DATABASE [ProductionDB] 
TO DISK = N'Z:BackupsProductionDB.bak' 
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO

3. Implémenter la récupération à un instant T (PITR) via l’archivage des journaux

Un snapshot quotidien ou une sauvegarde complète ne vous protège que jusqu’à la minute où elle a été effectuée. Si votre base de données plante à 16h00 et que votre dernier snapshot remonte à 2h00 du matin, vous perdez 14 heures de données transactionnelles.

Pour atteindre une véritable résilience d’entreprise, vous devez combiner des sauvegardes complètes cohérentes au niveau applicatif avec un archivage continu des journaux (sauvegarde du WAL, des Redo Logs ou des journaux de transactions toutes les quelques minutes). Cela permet aux DBA de restaurer la base de données à une minute précise ou même à un ID de transaction spécifique avant un sinistre.

Stratégies de sauvegarde d’entreprise avec CloudSave

Gérer des scripts de pré-gel personnalisés, des tâches cron pour les dumps natifs et l’expédition des journaux sur des dizaines de serveurs de base de données est un cauchemar opérationnel pour les équipes DevOps. C’est là qu’une plateforme de niveau entreprise comme CloudSave devient critique.

CloudSave comble le fossé entre la virtualisation et l’architecture de base de données. Au lieu de se fier à des snapshots d’hyperviseur aveugles, CloudSave utilise des agents conscients des applications qui s’intègrent nativement à SQL Server, PostgreSQL, MySQL et Oracle.

Lorsque CloudSave initie une sauvegarde :
1. Il communique directement avec le moteur de base de données via des API natives (comme VSS pour Windows ou le streaming WAL natif pour Linux).
2. Il orchestre le vidage des tampons mémoire sur le disque sans provoquer de gels de VM perturbateurs.
3. Il capture en toute sécurité les fichiers de données et gère automatiquement la troncature des journaux de transactions.
4. Il sauvegarde en continu les journaux de transactions, permettant une récupération granulaire à un instant T (PITR) en quelques clics.

En déchargeant la complexité de la cohérence applicative vers CloudSave, les DBA et les administrateurs système peuvent garantir l’intégrité des données sans sacrifier les performances ou la disponibilité de leurs clusters de production.

Conclusion

Les snapshots de machines virtuelles sont un outil incroyable pour la gestion de l’infrastructure, mais ils sont fondamentalement incompatibles avec les exigences ACID des bases de données transactionnelles. Se fier aux snapshots d’hyperviseur cohérents en cas de crash expose votre organisation à des pages déchirées, des chaînes de réplication brisées et une perte de données catastrophique.

Pour protéger vos données critiques, vous devez implémenter une mise en attente compatible avec les applications, utiliser des méthodologies de sauvegarde de base de données natives et maintenir des archives continues des journaux de transactions. En adoptant des solutions de sauvegarde d’entreprise spécialement conçues, vous pouvez vous assurer que vos bases de données restent hautement disponibles, entièrement récupérables et totalement sécurisées.