Sauvegardes MariaDB
mysqldump vs sauvegarde binaire : que choisir, et combien de temps dure une restauration ?
La sauvegarde n'est pas le problème — c'est la restauration qui définit votre vrai RTO. Voici comment choisir entre mysqldump et sauvegarde binaire (mariabackup), quand utiliser quoi, et combien de temps prennent réellement les restaurations selon la taille de votre base.
Pourquoi cette question est cruciale
Beaucoup d'équipes héritent d'un cron quotidien avec un mysqldump qui tourne la nuit. Ça fonctionne jusqu'au jour où il faut restaurer en production une base de 500 Go. Et là, on découvre que la restauration prend 18 heures, pendant lesquelles le service est à l'arrêt.
Le choix entre sauvegarde logique (mysqldump) et sauvegarde binaire (mariabackup) ne se joue pas sur le backup — il se joue sur le RTO réel : combien de temps votre activité reste arrêtée quand quelque chose part en vrille.
mysqldump : la sauvegarde logique, format SQL
mysqldump produit un fichier texte SQL contenant les ordres CREATE TABLE et INSERT qui reconstruisent votre base. C'est le format historique, universel, qu'on peut restaurer sur n'importe quelle version de MariaDB ou MySQL.
Son grand atout : la portabilité. Un dump SQL d'une MariaDB 10.6 se restaure sans drama sur une MariaDB 11.x ou même sur du MySQL. Idéal pour les migrations, les montées de version, ou les petites bases.
Son grand défaut : la restauration rejoue chaque INSERT un par un, puis reconstruit tous les index. Sur une base avec beaucoup d'index secondaires, l'étape "reconstruction d'index" peut représenter 70% du temps de restauration.
mariabackup : la sauvegarde binaire, copie des fichiers
mariabackup (fork de Percona XtraBackup adapté à MariaDB) effectue une copie physique à chaud des fichiers InnoDB de votre base, sans bloquer les écritures applicatives. Le résultat est une copie binaire prête à être remise en place.
La restauration revient à copier les fichiers à leur place et redémarrer MariaDB. Pas de rejeu SQL, pas de reconstruction d'index. Sur une base de 1 To, on passe d'environ 40 heures (mysqldump) à environ 3 heures (mariabackup).
mariabackup supporte aussi les incrémentaux au niveau page : seules les pages InnoDB modifiées depuis le dernier backup full sont sauvegardées. Idéal pour faire un backup full hebdomadaire et des incrémentaux quotidiens.
Contrepartie : la sauvegarde binaire est liée à la version majeure et au moteur. Un backup pris sur MariaDB 10.6 ne se restaure pas sur une MariaDB 11.x sans étape intermédiaire.
Comparatif côte à côte
Aucun des deux outils n'est universellement "meilleur" — chacun répond à un besoin précis.
| Critère | mysqldump | sauvegarde binaire (mariabackup) |
|---|---|---|
| Format | Texte SQL (INSERT) | Copie physique des fichiers InnoDB / Aria |
| Impact verrous | Lock des tables (ou longue transaction avec --single-transaction) | Hot backup, aucun lock visible côté applicatif |
| Vitesse de backup (100 Go) | Heures — limité par la sérialisation SQL | Minutes — limité par le débit disque |
| Vitesse de restauration (100 Go) | Très lente — rejoue chaque INSERT, reconstruit chaque index | Rapide — copie les fichiers, pas de reconstruction d'index |
| Portabilité | Restaurable sur toute version MariaDB/MySQL | Liée à la même version majeure et au même moteur |
| Incrémental | Pas vraiment — dump complet à chaque fois | Oui, incrémentaux au niveau page |
| Restauration point-in-time | Nécessite les binlogs en plus | Nécessite les binlogs en plus |
| Pour qui | Petites bases, migrations, montées de version | Production, bases multi-To, SLA de restauration court |
Temps de restauration réels selon la taille
Estimations indicatives sur infrastructure standard (SSD NVMe, base avec indexation typique). Vos chiffres réels dépendent du nombre d'index, de la fragmentation et du débit disque.
| Taille de la base | mysqldump | sauvegarde binaire (mariabackup) | Verdict |
|---|---|---|---|
| 10 Go | ~15–30 min | ~2–5 min | Petite base, les deux méthodes restent acceptables. |
| 100 Go | ~3–6 h | ~15–30 min | L'écart commence à faire mal. Binaire préférable. |
| 1 To | ~30–60 h | ~2–4 h | mysqldump devient un risque métier : 1 jour+ d'indispo. |
| 5 To | Impraticable (jours) | ~10–20 h | Seule la sauvegarde binaire reste exploitable. |
Point-in-Time Recovery (PITR) : ni mysqldump, ni mariabackup ne suffisent seuls
Que vous fassiez mysqldump ou mariabackup, vous avez au mieux un instantané quotidien — c'est-à-dire un RPO de 24h. Si la base est corrompue à 16h, vous reperdrez tout ce qui a été écrit depuis le backup de la nuit.
La vraie protection passe par les binary logs (binlogs) MariaDB, qui enregistrent chaque transaction validée. En combinant un backup complet + les binlogs jusqu'à T-1 minute, on peut restaurer la base au timestamp exact précédant l'incident.
Concrètement, notre stack opérationnelle combine : mariabackup full hebdomadaire, mariabackup incrémental quotidien, binlogs streamés en continu hors site. RPO de quelques minutes, RTO mesuré, et test de restauration trimestriel.
RPO et RTO : les seuls chiffres qui comptent
RPO (Recovery Point Objective)
Combien de données vous acceptez de perdre. Un cron mysqldump quotidien = RPO de 24h. Streaming des binlogs = RPO de quelques minutes.
RTO (Recovery Time Objective)
Combien de temps vous restez arrêté avant d'être de nouveau opérationnel. Sur 1 To, mysqldump impose un RTO de 30+ heures. mariabackup le ramène à 3–4 heures.
Beaucoup d'entreprises affichent un RTO théorique de 4h dans leur PCA — sans jamais avoir testé. Un backup non testé n'est pas un backup, c'est un espoir.
Bonnes pratiques de sauvegarde MariaDB
- Backup binaire (mariabackup) pour la production, avec incrémentaux quotidiens.
- mysqldump en complément pour les petites bases, migrations et exports.
- Streaming continu des binlogs hors du serveur de production.
- Stockage des backups sur une infrastructure distincte (autre datacenter, idéalement).
- Test de restauration trimestriel sur un environnement isolé — pas juste vérifier que le fichier existe.
- Documentation à jour de la procédure de restauration : ce que vous voulez à 3h du matin, c'est un runbook, pas Stack Overflow.
- Chiffrement des backups au repos, transit chiffré vers le site distant.
Comment RDEM Systems opère les backups MariaDB
Chaque cluster MariaDB que nous infogérons bénéficie d'une stratégie 3-2-1 adaptée aux bases SQL : 3 copies des données, 2 supports différents, 1 copie hors-site.
Les backups binaires sont orchestrés par Signal18 Replication Manager sur le réplica pour ne pas impacter les performances du primaire. Les binlogs sont streamés en continu vers notre infrastructure de sauvegarde NimbusBackup.
Un test de restauration trimestriel est réalisé sur environnement isolé. Le résultat (durée réelle, intégrité) est documenté et partagé avec vous. Pas de "backup Schrödinger" — on sait si ça marche.
Votre stratégie de backup tient-elle la route en production ?
Un audit MariaDB inclut une revue complète de votre stratégie de sauvegarde et un test de restauration mesuré.
Démarrez votre projet MariaDB infogéré
Discutons de vos besoins en bases de données. Notre équipe DBA vous conseille sur l'architecture optimale pour votre cas d'usage.
RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise