MySQL vs MariaDB : la guerre des sauvegardes sur VPS — mysqldump vs sauvegardes physiques

Le vrai combat : temps de restauration, cohérence et E/S

La plupart des équipes débattent des sauvegardes comme si c’était une dispute théologique : les dumps logiques sont portables contre les sauvegardes physiques sont rapides. Sur un VPS, le combat est plus vilain et plus pragmatique :

• Objectif de temps de restauration (RTO) : combien de temps vous pouvez être hors service pendant que vous reconstruisez les données.
• Objectif de point de restauration (RPO) : combien de données vous pouvez perdre (minutes ? heures ?).
• Cohérence : si la sauvegarde peut être restaurée sans corruption ni relations manquantes.
• Impact : si le temps de sauvegarde devient une « panne planifiée » parce que les E/S saturent.
• Friction opérationnelle : si quelqu’un teste vraiment les restaurations, parce que le processus est trop pénible.

mysqldump l’emporte sur la simplicité et la portabilité. Les sauvegardes physiques l’emportent sur la vitesse et, lorsqu’elles sont faites correctement, sur la cohérence sous charge. Mais sur le stockage VPS — souvent réseau‑backé, en rafales et partagé — les sauvegardes physiques peuvent aussi être la manière la plus rapide de découvrir le plafond de votre allocation IOPS.

Voici la règle que j’applique en production : choisissez la méthode de sauvegarde que vous pouvez restaurer rapidement et de façon répétée. Tout le reste est de la trivia.

Faits et histoire qui comptent plus que vous ne le pensez

Ce ne sont pas des anecdotes pour un quiz au bar. Chacun explique pourquoi un plan de sauvegarde « simple » casse à 03:00.

1. MariaDB a débuté comme un fork de MySQL après qu’Oracle a acquis Sun (et donc MySQL). Cette histoire de fork réapparaît encore dans des outils et des valeurs par défaut différents.
2. InnoDB est devenu le moteur de stockage par défaut dans MySQL 5.5. Beaucoup d’approches de sauvegarde partent du principe de la récupération après crash d’InnoDB et des journaux de redo ; MyISAM ne suit pas les mêmes règles.
3. XtraBackup de Percona a popularisé les sauvegardes physiques à chaud pour InnoDB. Cela a façonné les attentes : « une sauvegarde physique doit être en ligne ».
4. MariaDB livre MariaBackup (mariabackup), issu de la lignée XtraBackup, mais la compatibilité de version compte plus que les noms marketing.
5. MySQL 8 a fortement poussé vers les GTID et une réplication plus structurée. Cela change la façon de concevoir la restauration point‑in‑time et la rétention des binlogs.
6. Le mode file‑per‑table (innodb_file_per_table) est devenu courant, réduisant le problème du « gros ibdata1 » — mais augmentant aussi la charge sur les métadonnées du système de fichiers pendant les sauvegardes.
7. Le format des journaux redo et les changements du dictionnaire de données ont rendu certaines restaurations physiques inter‑versions pénibles. Les dumps logiques sont plus lents, mais souvent plus indulgents entre grosses versions.
8. Le « SSD local » d’un VPS est souvent réseau‑attaché en coulisse. Votre stratégie de sauvegarde doit supposer des voisins bruyants et une latence variable.

Une idée paraphrasée de Werner Vogels (fiabilité/ops) : Tout échoue, tout le temps ; concevez des systèmes qui supposent l’échec et récupèrent rapidement. C’est la philosophie à adopter pour les sauvegardes aussi.

Types de sauvegarde sur VPS : logique, physique et snapshots

Sauvegardes logiques (mysqldump, mysqlpump)

Les sauvegardes logiques exportent le schéma et les données sous forme SQL (ou parfois formats délimités). Avantages :

• Portables entre OS/systèmes de fichiers et souvent entre versions.
• Sélectives : une base, une table, ou même des lignes filtrées (avec de la douleur).
• Faciles à inspecter avec des outils standards.

Inconvénients :

• Lentes à restaurer à grande échelle.
• Génèrent des E/S temporaires et une charge CPU importantes ; peuvent écraser un petit VPS.
• La cohérence dépend du moteur et des options. Les valeurs par défaut ne sont pas votre amie.

Sauvegardes physiques (mariabackup, xtrabackup, copie brute)

Les sauvegardes physiques copient les fichiers de la base plus les métadonnées/journaux nécessaires pour les rendre cohérents. Avantages :

• Restauration rapide (copie de fichiers + phase de préparation).
• Mieux adaptées aux grands jeux de données InnoDB.
• Peuvent être à chaud/en ligne avec les bons outils.

Inconvénients :

• Contraintes de compatibilité de version souvent strictes.
• Les outils peuvent être délicats sur des distributions VPS « minimales ».
• Les sauvegardes sont moins lisibles par un humain ; la vérification est différente.

Snapshots système/bloc (LVM, ZFS)

Les snapshots ne sont pas des sauvegardes en soi. Ce sont un mécanisme de capture. Vous devez encore exporter les données du snapshot vers un autre emplacement et avoir un plan de restauration.

Sur un VPS, vous avez peut‑être LVM ou ZFS, peut‑être pas. Si oui, les snapshots peuvent réduire (ou éviter) les temps d’arrêt en prenant une copie quasi instantanée pendant que MySQL est brièvement verrouillé ou au moins flushé.

MySQL vs MariaDB : outils de sauvegarde et pièges

Au niveau de « l’API de sauvegarde », MySQL et MariaDB se ressemblent : tous deux parlent SQL, ont des binlogs, peuvent dumper des schémas. Les différences pratiques apparaissent dans la maturité des outils, le packaging et la sévérité des versions pour les restaurations physiques.

MariaDB : mariabackup est généralement la réponse évidente

Si vous utilisez MariaDB et que vos données sont majoritairement InnoDB, mariabackup est en règle générale le choix physique par défaut. Il est conçu pour être l’outil officiel de sauvegarde à chaud et suit généralement les fonctionnalités de MariaDB.

MySQL : les sauvegardes physiques dépendent de votre écosystème

MySQL d’Oracle propose une solution de sauvegarde d’entreprise, mais dans la réalité des flottes VPS vous verrez :

• mysqldump (partout, pour le meilleur et pour le pire)
• Percona XtraBackup (courant, surtout pour les charges InnoDB)
• Snapshots lorsque le stockage et la maturité ops le permettent

Compatibilité croisée : arrêtez de supposer que c’est « quasiment pareil »

Les dumps logiques sont généralement plus portables entre MySQL et MariaDB que les sauvegardes physiques. Les sauvegardes physiques sont liées aux formats sur disque, aux implémentations redo/undo et aux comportements spécifiques aux versions. Si vous prévoyez de migrer de moteur ou de faire un saut de version majeur, les dumps plus les binlogs (ou des basculements basés sur la réplication) sont habituellement plus sûrs que d’essayer de « déplacer » des fichiers bruts.

mysqldump : ce à quoi il sert, où il vous trompe

mysqldump est l’équivalent d’un ruban adhésif pour les outils de sauvegarde : pas joli, pas toujours adapté, mais présent dans tous les tiroirs. Sur un petit VPS, c’est souvent le moindre mal parce qu’il est prévisible et ne nécessite pas de paquets exotiques.

Utilisez mysqldump quand

• Votre jeu de données est suffisamment petit pour être restauré dans votre RTO.
• Vous avez besoin de portabilité entre versions ou entre MySQL et MariaDB.
• Vous avez besoin de sauvegardes sélectives (bases/tables spécifiques).
• Vous pouvez accepter une surcharge CPU et E/S plus élevée pendant la fenêtre de sauvegarde.

Méfiez‑vous de ces modes d’échec

• Sauvegardes incohérentes si vous n’utilisez pas les bons flags pour InnoDB.
• Verrous de table (ou verrous de métadonnées) qui bloquent le trafic applicatif.
• Temps de restauration gigantesques mono‑thread qui transforment un incident en week‑end prolongé.
• Objets manquants si vous oubliez routines, triggers, events ou utilisateurs.

Blague #1 : Une sauvegarde que vous n’avez jamais testée s’appelle « optimisme », ce qui n’est pas une classe de stockage.

Cohérence du dump : les flags qui comptent

Pour des bases majoritairement InnoDB, le minimum est --single-transaction. Mais cela n’est pas une protection totale. Les transactions longues peuvent gonfler undo/redo et transformer votre dump en accident au ralenti.

Ce que j’utilise typiquement sur un VPS :

• --single-transaction pour la cohérence InnoDB sans verrous globaux.
• --routines --triggers --events pour capturer les éléments non‑tables.
• --set-gtid-purged=OFF dans de nombreux environnements mixtes pour éviter les surprises GTID (au cas par cas).
• --hex-blob pour éviter les dégâts d’encodage.
• --master-data=2 (ou au moins les coordonnées du binlog) si vous voulez PITR.

Sauvegardes physiques : mariabackup, xtrabackup et copies brutes

Les sauvegardes physiques consistent à copier les pages InnoDB plus les journaux nécessaires pour les rendre cohérentes. La promesse : la restauration est rapide parce que vous ne rejouez pas du SQL ; vous restaurez des fichiers et laissez InnoDB faire une réconciliation de type récupération après crash.

mariabackup (MariaDB)

mariabackup peut effectuer des sauvegardes à chaud d’InnoDB et inclut une étape de « préparation » pour appliquer les journaux redo. Il peut aussi streamer et compresser, ce qui compte sur des réseaux VPS et des disques limités.

xtrabackup (courant dans l’écosystème MySQL)

XtraBackup est le cheval de trait pour les sauvegardes physiques à chaud dans de nombreuses équipes. Le modèle opérationnel est similaire : backup → prepare → restore (copy‑back) → corriger les permissions → démarrer le serveur.

Copies brutes : seulement avec les garde‑fous appropriés

Copier /var/lib/mysql avec rsync pendant que MySQL tourne, c’est fabriquer des sauvegardes corrompues. Les copies brutes ne sont sensées que si vous pouvez garantir la cohérence au niveau du système de fichiers (snapshot) ou si vous arrêtez MySQL proprement.

Blague #2 : « Je vais juste rsync le datadir en live » est l’équivalent base de données de « je vais juste jongler avec des couteaux pour gagner du temps ».

Douleurs spécifiques au VPS : rafales d’E/S et voisins bruyants

Les sauvegardes physiques peuvent être extrêmement consommatrices d’E/S. Ce n’est pas forcément mauvais — jusqu’à ce que le stockage du VPS vous bride. Le résultat ressemble à un problème de base de données mais est en réalité une contrainte plate‑forme : fort iowait, requêtes bloquées, réplication en retard et sauvegardes qui prennent plus de temps au fur et à mesure que vous « les optimisez ».

Sur les VPS, planifiez la possibilité de throttling : limitez le parallélisme de sauvegarde, compressez en tenant compte du compromis CPU vs E/S, et lancez avec ionice/nice quand c’est approprié.

Binary logs : la différence entre « sauvegarde » et « récupération »

Une sauvegarde complète nocturne n’est pas une stratégie de récupération si votre RPO est inférieur à 24 heures. Les binary logs (binlogs) sont le moyen le plus simple de combler cet écart : vous restaurez la dernière sauvegarde complète, puis vous rejouez les binlogs jusqu’à un timestamp/position/GTID.

Sur un VPS, les binlogs vous évitent aussi de faire des dumps complets trop souvent. Les sauvegardes complètes sont lourdes ; la récupération incrémentale via les binlogs est bon marché en comparaison.

Conseils pratiques

• Activez les binlogs si le PITR vous importe.
• Dimensionnez la rétention selon le temps qu’il vous faut pour remarquer les mauvaises données et réagir.
• Sauvegardez les binlogs hors‑hôte. La rétention locale n’est pas une sauvegarde ; c’est une commodité.
• Exercez une restauration PITR. C’est toujours plus étrange que vous ne l’imaginez.

Tâches pratiques : 14 commandes, sorties et décisions

Voici les contrôles que j’exécute réellement sur des systèmes VPS. Chaque tâche inclut : commande, sortie d’exemple, ce que la sortie signifie et la décision suivante.

Task 1: Confirm which server you’re actually running

cr0x@server:~$ mysql -e "SELECT VERSION() AS version, @@version_comment AS comment\G"
*************************** 1. row ***************************
version: 10.11.6-MariaDB-0+deb12u1
comment: Debian 12

Meaning: Version and distro packaging. This matters for physical backup compatibility and default settings.

Decision: If MariaDB, prefer mariabackup. If MySQL 8, check whether you’ll use mysqldump, snapshots, or XtraBackup.

Task 2: Check data size and file layout

cr0x@server:~$ sudo du -sh /var/lib/mysql
18G	/var/lib/mysql

Meaning: Rough size of your restore footprint.

Decision: If this is >10–20 GB on a small VPS, dumps will restore slowly. Start planning physical backups or at least faster restore workflows (parallel import, larger instance for restore, etc.).

Task 3: Identify storage engine mix (InnoDB vs MyISAM)

cr0x@server:~$ mysql -e "SELECT ENGINE, COUNT(*) tables FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys') GROUP BY ENGINE;"
ENGINE		tables
InnoDB		312
MyISAM		4

Meaning: --single-transaction protects InnoDB consistency; MyISAM may still require locks for consistent dumps.

Decision: If you have MyISAM tables you care about, either accept table locks during dump or migrate them to InnoDB.

Task 4: Verify binlog and GTID settings

cr0x@server:~$ mysql -e "SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'gtid_mode'; SHOW VARIABLES LIKE 'server_id';"
Variable_name	Value
log_bin		ON
Variable_name	Value
gtid_mode	OFF
Variable_name	Value
server_id	1

Meaning: Binlogs enabled, GTIDs off (common in MariaDB or older MySQL setups), server_id set.

Decision: If log_bin=OFF and you need PITR, turn it on (with disk planning). If GTIDs are on, tune dump flags and recovery steps accordingly.

Task 5: Get current binlog position for PITR anchoring

cr0x@server:~$ mysql -e "SHOW MASTER STATUS\G"
*************************** 1. row ***************************
File: binlog.000214
Position: 90123318
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:

Meaning: This is your “starting line” for replay if you take a snapshot or physical backup right now.

Decision: Record this with the backup metadata. If you can’t tie backups to binlog coordinates (or GTID set), PITR becomes guesswork.

Task 6: Measure I/O pressure during backup windows

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 	12/31/2025 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.21    0.00    2.33   41.18    0.72   49.56

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
vda              9.00  210.00  512.0  6144.0   12.40  58.30  99.80

Meaning: 40%+ iowait, 99% disk utilization, and high await. This is storage saturation, not “slow SQL.”

Decision: Throttle backups, move backup target off-host, schedule differently, or upgrade disk/I/O class. Also consider physical backups with controlled parallelism vs huge logical dump writes.

Task 7: See if backups are blocked on metadata locks

cr0x@server:~$ mysql -e "SHOW PROCESSLIST;"
Id	User	Host	db	Command	Time	State	Info
42	root	localhost	NULL	Query	12	Waiting for table metadata lock	FLUSH TABLES WITH READ LOCK
87	app	10.0.2.10:51234	prod	Query	12	Sending data	SELECT ...

Meaning: A locking backup step is waiting, likely blocked by DDL or long query.

Decision: Avoid FTWRL for hot paths. Prefer --single-transaction for dumps and hot physical backups for InnoDB. If you must lock, schedule a DDL freeze window.

Task 8: Run a safe-ish mysqldump with minimal foot-guns

cr0x@server:~$ mysqldump --single-transaction --routines --triggers --events --hex-blob --master-data=2 --databases prod | gzip -1 > /backups/prod.sql.gz
cr0x@server:~$ ls -lh /backups/prod.sql.gz
-rw-r--r-- 1 root root 1.9G Dec 31 02:14 /backups/prod.sql.gz

Meaning: Backup created. Size gives you a hint about restore time and compression ratio. --master-data=2 embeds binlog coordinates as a comment.

Decision: If this takes too long or clobbers performance, move to physical backups and/or run dumps from a replica.

Task 9: Validate that the dump includes what you think it includes

cr0x@server:~$ zgrep -m1 -E "MASTER_LOG_FILE|CHANGE MASTER" /backups/prod.sql.gz
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000214', MASTER_LOG_POS=90123318;

Meaning: Binlog coordinates are recorded.

Decision: If missing, you can’t do clean PITR from this dump. Fix flags and rerun.

Task 10: Create a physical backup with mariabackup (MariaDB)

cr0x@server:~$ sudo mariabackup --backup --target-dir=/backups/mariabackup/full --user=backup --password='***'
[00] 2025-12-31 02:10:11 Backup created in directory '/backups/mariabackup/full'
[00] 2025-12-31 02:10:11 Writing backup-my.cnf
[00] 2025-12-31 02:10:11 Completed OK!

Meaning: Raw files plus metadata captured.

Decision: Immediately run prepare. An unprepared physical backup is not ready to restore.

Task 11: Prepare the physical backup (apply redo logs)

cr0x@server:~$ sudo mariabackup --prepare --target-dir=/backups/mariabackup/full
[00] 2025-12-31 02:13:52 Starting to apply redo log
[00] 2025-12-31 02:14:20 Redo log applied
[00] 2025-12-31 02:14:20 Completed OK!

Meaning: Backup is now consistent and ready for copy-back.

Decision: If prepare is slow, you’re I/O bound; consider faster disks for backup staging or offloading prepare to a restore host.

Task 12: Inspect InnoDB health and checkpointing pressure

cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,60p'
=====================================
2025-12-31 02:15:02 INNODB MONITOR OUTPUT
=====================================
...
Log sequence number          128392001928
Log flushed up to            128392001928
Last checkpoint at           128391771200
...

Meaning: If checkpoint lags badly, backups and heavy writes can create recovery/flush pressure.

Decision: If you see chronic checkpoint lag, tune redo log size (engine/version-specific), buffer pool, and flush behavior; also avoid running backups at peak write load.

Task 13: Check for replication lag (if backing up a replica)

cr0x@server:~$ mysql -e "SHOW SLAVE STATUS\G" | egrep "Seconds_Behind_Master|Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 57

Meaning: Replica is lagging by ~1 minute.

Decision: If lag is acceptable within your RPO, taking backups from the replica reduces production load. If lag spikes during backup, you’re saturating I/O or CPU; throttle.

Task 14: Dry-run a restore on the same box (sanity check)

cr0x@server:~$ zcat /backups/prod.sql.gz | head -n 20
-- MySQL dump 10.13  Distrib 8.0.36, for Linux (x86_64)
--
-- Host: localhost    Database: prod
-- ------------------------------------------------------
-- Server version	10.11.6-MariaDB-0+deb12u1
...

Meaning: You’re verifying you can read the backup and it contains expected headers. This is not a full test, but it catches “empty file” and “wrong target” mistakes.

Decision: Schedule a real restore test to a disposable instance. If you never do, you’ll learn during an incident when adrenaline makes you bad at typing.

Playbook de diagnostic rapide : trouver le goulot en minutes

Quand les sauvegardes sont lentes ou que l’appli plante pendant les sauvegardes, ne commencez pas par changer d’outil. Commencez par déterminer quelle ressource vous épuisez.

Premier : prouver s’il s’agit d’une saturation du stockage

• Vérifiez iowait et disk await (iostat -xz). Await élevé et %util proche de 100% signifient que vous êtes lié par les E/S.
• Vérifiez l’espace disque et la pression sur les inodes (df -h, df -i).
• Vérifiez si le VPS bride vos IOPS (symptôme : stalls périodiques, débit en dents de scie).

Que faire ensuite : limitez la compression/le parallélisme, déplacez la destination de sauvegarde hors du disque principal, ou montez le stockage du VPS. Si vous ne pouvez pas, utilisez un réplica pour les sauvegardes.

Second : vérifier les verrous et les transactions longues

• SHOW PROCESSLIST pour les verrous de métadonnées.
• Statut du moteur pour une longue history list / purge lag (InnoDB).
• Rechercher des DDL exécutés pendant les sauvegardes.

Que faire ensuite : planifiez les sauvegardes à l’écart des migrations, imposez des fenêtres DDL et évitez les approches FTWRL sauf si vous tolérez les blocages.

Troisième : vérifier la contention CPU (compression et dumps mono‑thread)

• Vérifiez top ou pidstat pour mysqldump et gzip qui saturent le CPU.
• Sur les petits VPS, le niveau de compression est un paramètre de production.

Que faire ensuite : baissez le niveau de compression, compressez hors‑hôte ou passez à des sauvegardes physiques en streaming avec contrôle de l’usage CPU.

Quatrième : vérifier le réseau (sauvegardes hors‑hôte et streaming)

• Si vous streamiez des sauvegardes vers un stockage objet ou un autre nœud, confirmez que le débit est stable.
• La perte de paquets et les retransmissions transforment un « streaming backup » en « throttling accidentel ».

Erreurs courantes : symptôme → cause → correction

1) La sauvegarde réussit, la restauration échoue avec routines/triggers manquants

Symptôme : Erreurs applicatives après restauration : procédures stockées manquantes, triggers qui ne s’exécutent pas, events planifiés absents.

Cause : Dump exécuté sans --routines --triggers --events.

Correction : Ajoutez les flags, relancez les sauvegardes et testez la restauration. Incluez aussi les objets système mysql si vous dépendez des utilisateurs/privileges.

2) mysqldump provoque des blocages en production

Symptôme : Requêtes bloquées ; vous voyez « Waiting for table metadata lock ».

Cause : DDL pendant le dump, ou options de dump qui forcent des verrous (ou tables MyISAM).

Correction : Imposer des fenêtres de migration, convertir MyISAM en InnoDB, utiliser --single-transaction et envisager de faire les sauvegardes depuis un réplica.

3) La sauvegarde physique restaure mais InnoDB ne démarre pas

Symptôme : MySQL/MariaDB ne démarre pas après le copy‑back ; InnoDB se plaint des fichiers de log ou du dictionnaire de données.

Cause : Mismatch de version, étape de préparation oubliée, permissions incorrectes, ou mélange de fichiers provenant de serveurs différents.

Correction : Assurez‑vous que la version de l’outil de sauvegarde correspond aux attentes de la version majeure du serveur, exécutez la préparation, utilisez la bonne propriété (mysql:mysql) et restaurez le datadir complet de façon cohérente.

4) Les sauvegardes sont « rapides » mais la réplication explose en retard

Symptôme : Seconds_Behind_Master augmente pendant la fenêtre de sauvegarde.

Cause : Les E/S de la sauvegarde rivalisent avec l’application des réplications ; le disque VPS atteint son plafond IOPS.

Correction : Limitez la sauvegarde, changez l’horaire, déplacez les sauvegardes vers un autre disque/volume ou améliorez la classe I/O. Si possible, placez les relay logs sur un stockage séparé.

5) Vous pouvez restaurer, mais cela prend une éternité et les applis expirent

Symptôme : La restauration d’un dump prend des heures ; les applications expirent même après que la BD soit « up ».

Cause : La restauration logique est en grande partie mono‑thread, les index se reconstruisent, le buffer pool est froid et vous êtes sur un petit VPS.

Correction : Préférez les restaurations physiques pour de grands jeux de données ; sinon restaurez sur une instance temporaire plus grosse, réchauffez les caches, puis basculez.

6) « Nous avons des sauvegardes », mais elles sont sur le même VPS

Symptôme : Le disque du VPS meurt ; les sauvegardes meurent avec lui.

Cause : Stockage de sauvegarde uniquement local.

Correction : Copies hors‑hôte. Domaine de défaillance différent. Toujours.

7) Les snapshots restaurés contiennent des données incohérentes

Symptôme : La BD restaurée est corrompue ou des commits récents manquent.

Cause : Snapshot pris sans flush/lock approprié ; vous avez capturé un état de crash sans couverture redo.

Correction : Associez les snapshots à une coordination MySQL (flush, stratégie de lock adaptée au moteur), ou utilisez des outils de sauvegarde physique à chaud qui incluent les étapes redo/prepare.

Trois mini‑histoires d’entreprise issues du terrain des sauvegardes

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Ils faisaient tourner un SaaS de taille moyenne sur un seul VPS « costaud ». Les sauvegardes étaient un mysqldump nocturne vers un second disque monté sur /backups. L’équipe se sentait responsable. Ils avaient même une rétention : sept jours. C’est la partie qui sonne toujours rassurante en réunion.

Puis l’hébergeur a eu un incident de stockage. L’instance a redémarré, est revenue, et MySQL ne démarrait pas. Leur réponse fut calme : « Pas de problème, restore depuis hier soir. » Sauf que le disque de backup était le même dispositif de blocs virtuel sur le même pool de stockage. Il était attaché, mais le système de fichiers était détruit. Les fichiers de sauvegarde existaient comme un bâtiment démoli « existe ».

L’hypothèse erronée était subtile : ils pensaient qu’un second volume monté était un second domaine de défaillance. Chez ce fournisseur, ce n’était pas le cas. C’était juste une autre tranche du même pool sous‑jacent. Le postmortem n’était pas dramatique. Il était pire : discrètement humiliant et totalement évitable.

La correction fut ennuyeuse : les sauvegardes furent poussées hors‑hôte après création, et des restaurations furent répétées chaque mois vers une instance jetable. Ils commencèrent aussi à tracer où vivaient les données chez le fournisseur — région, pool et type d’attachement — parce que « volume » peut signifier n’importe quoi dans le monde VPS.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une autre société voulait des sauvegardes plus rapides. Ils sont passés des dumps aux sauvegardes physiques avec compression en streaming. L’ingénieur en charge était compétent et agressif, le meilleur genre jusqu’à ce que ce ne soit plus le cas. Ils ont activé des threads parallèles et monté la compression parce que le stockage était « cher ». Sur le papier, c’était génial : backups plus petits, transfert plus rapide, moins de coûts.

En production, le VPS avait deux vCPU. La compression a commencé à bouffer le CPU comme si on lui devait de l’argent. MySQL a commencé à lutter pour le CPU, puis pour les E/S parce que la sauvegarde lisait aussi agressivement le datadir. La latence a augmenté. La réplication a pris du retard. Leurs workers de queue ont expiré. Incident déclaré.

La leçon douloureuse : « sauvegarde plus rapide » peut signifier « consommation plus rapide de vos seules ressources ». L’optimisation était rationnelle localement et désastreuse globalement. Sur un VPS, il n’y a pas de « CPU supplémentaire » caché derrière un rideau.

La correction fut mesurée : ils réduisirent le parallélisme, baissèrent le niveau de compression et lancèrent les sauvegardes depuis un réplica avec un peu plus de CPU. Ils introduisirent aussi du throttling I/O et cessèrent de chercher la gratuité des sauvegardes. Les sauvegardes coûtent des ressources. Vous décidez où payer : pendant la fenêtre de sauvegarde, pendant les restaurations ou pendant les incidents.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe fit quelque chose d’impopulaire : des exercices de restauration complets trimestriels. Pas un exercice sur table. Une vraie restauration vers une VM propre, l’application pointée dessus, des requêtes d’intégrité de base exécutées et une validation humaine. Personne n’en parlait parce que ce n’est pas un diagramme d’architecture brillant.

Puis un déploiement applicatif a introduit une migration destructive. Une colonne a été supprimée, et l’ORM a joyeusement écrit des nulls dans l’univers. Ils l’ont remarqué en une heure. La question n’était pas d’avoir des sauvegardes — c’était combien de temps pour rembobiner sans perdre les écritures légitimes après le déploiement.

Ils ont restauré la sauvegarde complète de la nuit précédente sur un hôte de test, rejoué les binlogs jusqu’à cinq minutes avant l’heure du déploiement, et exporté uniquement les tables affectées vers la production. Ce fut sale, mais maîtrisé. L’équipe connaissait les étapes parce qu’elle avait exercé la mémoire musculaire quand ce n’était pas en feu.

Ils ont tout de même rédigé un postmortem et amélioré les revues de migrations. Mais la vraie raison pour laquelle ce n’est pas devenu un désastre de plusieurs jours, c’est que leur processus de sauvegarde était répété, documenté et ennuyeux. En exploitation, l’ennuyeux est une fonctionnalité.

Listes de contrôle / plan pas à pas

Pas à pas : choisir votre approche de sauvegarde sur un VPS

1. Mesurez la taille du jeu de données (datadir et taille logique). Si la restauration depuis SQL dépasse le RTO, priorisez le physique.
2. Confirmez le mix de moteurs. Si majoritairement InnoDB, les outils physiques à chaud sont viables ; si MyISAM significatif, planifiez des verrous ou une migration.
3. Décidez votre RPO. Si vous avez besoin de <24h de perte de données, activez et conservez les binlogs hors‑hôte.
4. Choisissez une sauvegarde complète primaire :
   • Petite BD : mysqldump + binlogs convient.
   • BD moyenne/grosse : mariabackup/xtrabackup + binlogs.
5. Choisissez un mécanisme de capture :
   • Outil‑based hot backup (recommandé pour InnoDB).
   • Snapshot + coordination (seulement si vous pouvez le faire correctement).
6. Choisissez un stockage hors‑hôte. Domaine de défaillance différent. Chiffrez si nécessaire.
7. Rédigez un runbook de restauration avec commandes, temps attendus et requêtes de validation.
8. Planifiez des exercices de restauration au moins trimestriels. Mensuels si la BD est critique pour le business.

Checklist opérationnelle : chaque job de sauvegarde doit faire ceci

• Écrire les métadonnées de la sauvegarde (version du serveur, fichier/pos du binlog ou set GTID, timestamp, version de l’outil).
• Vérifier l’intégrité des fichiers (checksum) après transfert.
• Alertes sur échecs et sur durées/taille anormales.
• Aligner la rétention sur le temps de détection (combien de temps avant de remarquer une corruption ou des suppressions).
• Valider la viabilité de la restauration via des exercices périodiques.

Checklist de validation de restauration (minimum)

• Le serveur démarre proprement ; la récupération InnoDB se termine.
• Les comptes de lignes correspondent pour les tables clés (approximatif acceptable comme premier contrôle).
• Les index critiques existent ; l’état des migrations est correct.
• L’application peut s’authentifier et exécuter ses 3 principaux workflows.
• La réplication (si utilisée) peut être rétablie depuis l’état restauré.

FAQ

1) Est‑ce que mysqldump est « suffisant » en production ?

Oui, si votre base est petite, si vous pouvez tolérer le temps de restauration et si vous l’exécutez avec les bons flags. Non, si le temps de restauration se mesure en heures et que votre entreprise mesure le downtime en minutes.

2) Quel est le flag mysqldump le plus important pour InnoDB ?

--single-transaction. Il vous donne une vue cohérente sans verrouiller les tables (pour InnoDB). Il ne résout pas la cohérence MyISAM et peut quand même stresser undo/redo si les transactions sont longues.

3) Puis‑je sauvegarder en copiant /var/lib/mysql pendant que MySQL tourne ?

Pas en toute sécurité, sauf si vous utilisez une méthode de snapshot coordonnée qui garantit la cohérence, ou si vous arrêtez MySQL. Un rsync live du datadir est une manière classique d’obtenir des sauvegardes qui restaurent en tristesse.

4) Dois‑je compresser les sauvegardes sur le VPS ?

Parfois. La compression échange CPU contre E/S et réseau. Sur de petits VPS, utilisez des niveaux de compression faibles et mesurez. Si la contention CPU provoque des pics de latence, compressez hors‑hôte ou compressez moins.

5) Les sauvegardes physiques remplacent‑elles les binlogs ?

Non. Les sauvegardes physiques vous donnent un point de restauration complet rapide. Les binlogs vous donnent la récupération point‑in‑time entre les sauvegardes complètes. Si vous avez besoin d’un faible RPO, vous voulez les deux.

6) Les sauvegardes physiques sont‑elles portables entre MySQL et MariaDB ?

Généralement non. Les sauvegardes physiques sont liées aux formats sur disque et aux versions. Les dumps logiques sont l’option portable pour les migrations inter‑moteurs, même si elles sont plus lentes.

7) Dois‑je prendre les sauvegardes depuis un réplica ?

Oui si vous le pouvez. Cela réduit la charge sur le primaire et vous donne un endroit plus sûr pour exécuter des lectures lourdes. Mais surveillez le retard de réplication : un réplica en retard peut violer silencieusement votre RPO.

8) À quelle fréquence dois‑je tester les restaurations ?

Au moins trimestriellement pour les bases « importantes », mensuellement pour les bases critiques pour le business, et après des montées de version majeures ou des changements d’outils de sauvegarde. Tester les restaurations transforme des fichiers de backup en capacité de récupération.

9) Quelle est la méthode de restauration la plus rapide sur un VPS ?

La restauration physique (sauvegarde préparée + copy‑back) est généralement la plus rapide pour les jeux de données InnoDB. Le facteur limitant réel est souvent le débit disque pendant la restauration, pas l’élégance de l’outil.

10) Comment savoir si mon goulot est CPU, disque ou verrous ?

Disque : iowait/await/%util élevés dans iostat. CPU : processus de sauvegarde/compression qui saturent les cœurs dans top. Verrous : attentes de metadata lock dans SHOW PROCESSLIST.

Étapes suivantes : quoi faire cette semaine

• Définissez RTO/RPO par écrit. Si vous ne pouvez pas les définir, vous ne pouvez pas choisir rationnellement entre dump et sauvegarde physique.
• Activez les binlogs (si vous avez besoin de PITR) et planifiez leur rétention hors‑hôte.
• Exécutez la Tâche 2 et la Tâche 6 sur votre VPS pendant une fenêtre de sauvegarde. Si vous saturez les E/S, arrêtez de deviner et commencez à limiter ou à déplacer les sauvegardes hors du disque primaire.
• Si MariaDB et jeu de données moyen/gros : implémentez mariabackup + prepare + copie hors‑hôte, en capturant les métadonnées avec les coordonnées binlog.
• Si vous restez sur mysqldump : standardisez les flags, capturez les coordonnées du binlog et faites un exercice complet de restauration sur une VM propre.
• Planifiez un test de restauration et faites‑en la responsabilité récurrente de quelqu’un, pas un acte héroïque.

Les sauvegardes ne portent pas sur la sauvegarde. Elles portent sur la restauration. Construisez la restauration que vous voulez, puis sauvegardez de la manière qui rend cette restauration ennuyeuse.