MariaDB vs Percona Server : vitesse de sauvegarde/restauration sur un petit VPS

La réponse pratique (qui gagne)

Sur un petit VPS, la vitesse de sauvegarde/restauration est dominée par votre goulot d’étranglement — généralement les E/S disque, parfois le CPU (compression/chiffrement), occasionnellement le réseau (stockage distant), et fréquemment « votre processus » (mauvais outil ou mauvaises hypothèses).

Si vous comparez MariaDB + mariabackup versus Percona Server + xtrabackup sur le même jeu de données InnoDB et une configuration similaire, le « vainqueur » est rarement la saveur du serveur. La différence tient le plus souvent à :

• Quel outil de sauvegarde physique vous utilisez vraiment, et sa compatibilité avec la version du serveur.
• Quelle quantité de redo doit être appliquée pendant la phase de prepare, et à quel point votre VPS bride les écritures aléatoires.
• Le choix de l’algorithme de compression (lié au CPU) vs « pas de compression » (lié aux E/S).
• La méthode de restauration : copie de fichiers vs streaming vs import logique.

Mon point de vue opérationnel : pour les restaurations sur petit VPS, Percona XtraBackup a tendance à être le chemin le plus prévisible et « assez rapide » quand vous êtes dans un environnement MySQL/Percona et que vous voulez des sauvegardes physiques avec des outils solides pour le streaming et l’incrémentiel. Pour les environnements MariaDB, mariabackup est l’outil adapté et peut être tout aussi rapide — mais il faut rester aligné sur les versions MariaDB et comprendre ce que la phase « prepare » impose à votre petit disque.

Si vous faites des sauvegardes logiques (mysqldump), il n’y a pas de « gagnant » : vous avez déjà perdu, vous ne vous en êtes juste pas rendu compte. Les restaurations logiques sur petit VPS sont l’endroit où le temps vient mourir.

Faits intéressants et contexte historique (parce que le passé explique le présent)

1. MariaDB existe à cause de l’acquisition de MySQL par Oracle (ère 2009–2010) ; Monty Widenius et d’autres ont forké MySQL pour préserver un développement ouvert et communautaire.
2. Percona a construit une activité sur la douleur opérationnelle : leur serveur et leurs outils se sont tôt concentrés sur le diagnostic des performances, l’instrumentation et des paramètres par défaut sensés pour la production.
3. XtraBackup est devenu l’outil de sauvegarde physique « à chaud » de référence pour MySQL/Percona pendant des années car il évitait les verrous globaux longs et ne nécessitait pas d’extensions enterprise coûteuses.
4. mariabackup de MariaDB est une lignée fork de XtraBackup, créée pour suivre la divergence interne de MariaDB et éviter les pièges de compatibilité.
5. Le modèle de récupération après crash d’InnoDB (redo logs + pages sales) est la raison pour laquelle les sauvegardes physiques exigent une phase de « prepare » : vous rejouez essentiellement les redo pour rendre la copie cohérente.
6. Le comportement des undo tablespaces et d’ibdata a évolué au fil des ans ; des dispositions plus récentes peuvent rendre les restaurations plus prévisibles mais aussi plus faciles à mal configurer lors d’un déplacement entre hôtes.
7. La compression dans les outils de sauvegarde est passée de « agréable » à « obligatoire » une fois que les gens ont commencé à envoyer des sauvegardes vers du stockage objet ; cela a déplacé de nombreuses restaurations d’un profil lié aux E/S vers un profil lié au CPU sur les petites machines.
8. « Flush tables with read lock » faisait autrefois partie des scripts de sauvegarde normaux ; aujourd’hui c’est le signe que vous faites des sauvegardes logiques ou que votre playbook n’a pas été mis à jour depuis une décennie.
9. Les petits fournisseurs de VPS limitent souvent les E/S soutenues d’une manière qui n’apparaît pas dans les benchs en rafale ; votre première minute est rapide, les dix suivantes sont tragiques.

Ce qui contrôle réellement la vitesse de sauvegarde/restauration sur un VPS

1) Le pattern d’E/S prime sur le débit brut

Restaurer une sauvegarde physique n’est pas juste « copier des fichiers ». C’est : copier des fichiers, puis appliquer les redo (écritures aléatoires), puis démarrer InnoDB qui peut faire d’autres récupérations, puis reconstruire les caches et les statistiques à mesure que votre charge revient.

Sur le stockage d’un petit VPS, le débit séquentiel peut sembler correct, mais les IOPS d’écriture aléatoire sont là où se cachent les cadavres. La phase d’application des redo et le réchauffement post-restauration sont gourmands en IOPS. C’est là que « la restauration a pris 7 minutes la dernière fois » devient « la restauration a pris 45 minutes aujourd’hui » après que votre fournisseur a silencieusement déplacé votre disque virtuel vers un autre backend.

2) CPU : compression et chiffrement ne sont pas gratuits

La compression des sauvegardes est séduisante : fichiers plus petits, uploads plus rapides. Sur un VPS à deux cœurs, c’est aussi une taxe de performance que vous payez deux fois : une fois à la sauvegarde, une fois à la restauration. Si votre pipeline de restauration inclut décompression + prepare + copy-back, vous avez construit un triathlon CPU sur une machine qui s’essouffle à décompresser des logs.

3) Mémoire : le buffer pool n’accélère pas directement la restauration, mais change le comportement de récupération

Plus de RAM aide le serveur à mieux se comporter après la restauration (moins de lectures, réchauffement plus rapide), mais la vitesse brute de restauration dépend surtout des écritures disque et de l’application des redo. Toutefois : un buffer pool trop petit peut rendre la période « le système est up mais inutilisable » plus longue, ce qui est fonctionnellement équivalent à une restauration lente.

4) L’alignement des versions est le tueur silencieux

Percona Server et MariaDB respectent de nombreuses conventions MySQL, mais les sauvegardes physiques sont sensibles aux formats internes et aux versions des outils. Un décalage entre outil et serveur peut vous forcer vers une restauration logique, le pivot le plus lent en pleine panne.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : tout échoue tout le temps, donc vous concevez des systèmes en supposant que la défaillance est normale. Les restaurations sont la partie « supposer que la défaillance est normale » que vous avez soit répétée en pratique — soit pas du tout.

Méthodes de sauvegarde importantes (physique vs logique)

Sauvegardes logiques : portables, lentes et pleines de surprises

mysqldump est une exportation en texte. C’est pratique quand vous avez besoin de portabilité entre versions, ou quand vous exportez un sous-ensemble. C’est aussi l’équivalent sauvegarde d’imprimer la base, de se faxer le tout, puis de tout retaper plus tard.

La performance de la restauration dépend du parsing SQL, de la création d’index et du coût transactionnel. Sur un petit VPS, cela prend généralement des heures pour des jeux de données non triviaux. Si vous avez besoin de restaurations rapides, n’utilisez les dumps logiques que pour de petites bases ou pour une récupération « dernier recours ».

Sauvegardes physiques : restauration la plus rapide quand c’est bien fait

Les outils de sauvegarde physique (mariabackup, xtrabackup) copient les fichiers de données InnoDB et les logs pendant que le serveur tourne, puis « préparent » la sauvegarde à un point cohérent. La restauration consiste surtout à recopier les fichiers et à laisser le serveur récupérer. Sur un petit VPS, c’est la seule approche qui scale sans vous transformer en archéologue à temps partiel de vieux dumps SQL.

Ce que signifie vraiment « prepare »

Pendant --prepare, l’outil applique les redo logs capturés pendant la sauvegarde pour amener les fichiers à un état cohérent. Si votre charge était intense, l’arriéré de redo peut être important. Un gros arriéré de redo signifie plus d’écritures aléatoires. Les écritures aléatoires sur disque VPS signifient dilatation temporelle.

Blague #1 : Les sauvegardes sont comme des parachutes — si vous en avez besoin et qu’il ne fonctionne pas, vous n’en aurez probablement pas besoin à nouveau.

Mode d’emploi pour un diagnostic rapide

Quand la restauration est lente sur un petit VPS, vous n’avez pas le temps de débattre de théologie. Il vous faut une liste courte et un ordre d’opérations impitoyable.

Première étape : confirmez quelle phase est lente

• Téléchargement/transfert (réseau, throttling du stockage distant, surcoût du chiffrement)
• Décompression/déchiffrement (lié au CPU)
• Prepare/appliquer les logs (lié aux IOPS d’écriture aléatoire)
• Copy-back (surtout lié aux écritures séquentielles)
• Premier démarrage (récupération InnoDB, permissions, incompatibilité de config)

Deuxième étape : identifiez votre limite dure (disque vs CPU vs réseau)

• Disque saturé avec faible débit : vous êtes limité par les IOPS.
• CPU saturé pendant décompression/prepare : choisissez une compression différente ou plus de cœurs.
• Réseau saturé mais CPU/disque inactifs : envisagez le streaming en pipeline ou rapprochez le stockage.

Troisième étape : appliquez le plus petit changement qui fasse bouger l’aiguille

• Désactivez la compression (ou utilisez un algorithme plus léger) si vous êtes CPU-bound.
• Réduisez le volume de redo en améliorant le calendrier des sauvegardes ou la stratégie de vidage si le prepare est lent.
• Utilisez I/O direct et un parallélisme raisonnable si le copy-back est lent.
• Cessez de faire des restaurations logiques pour de gros jeux de données.

Tâches pratiques : commandes, sorties et décisions (la partie qui sauve votre week-end)

Voici des vérifications réalistes à exécuter sur un VPS Linux. Le but n’est pas d’accumuler des trivia ; c’est de prendre une décision après chaque commande.

Task 1: Identifier ce que vous exécutez réellement (MariaDB vs Percona vs Oracle MySQL)

cr0x@server:~$ mysql --version
mysql  Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

Ce que cela signifie : Il s’agit de MariaDB 10.11.x. Vous devriez privilégier mariabackup pour les sauvegardes physiques.

Décision : Si vous aviez prévu d’utiliser XtraBackup, arrêtez-vous et confirmez la compatibilité. Le mauvais outil est un piège fréquent auto-infligé.

Task 2: Confirmer Percona Server (si c’est ce que vous pensez avoir installé)

cr0x@server:~$ mysqld --version
mysqld  Ver 8.0.35-27 for Linux on x86_64 (Percona Server (GPL), Release 27, Revision 1f4b4a6)

Ce que cela signifie : Percona Server pour MySQL 8.0. XtraBackup est le partenaire naturel.

Décision : Utilisez xtrabackup qui correspond à la branche majeure. Ne bricolez pas avec un paquet plus ancien.

Task 3: Vérifier le type de disque et les options de montage (la vitesse de restauration vit ici)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINT,FSTYPE
NAME   TYPE SIZE ROTA MOUNTPOINT FSTYPE
vda    disk  80G    0
├─vda1 part  79G    0 /          ext4
└─vda15 part  1G    0 /boot/efi  vfat

Ce que cela signifie : ROTA=0 suggère un stockage SSD (ou du moins présenté comme tel).

Décision : Si ROTA=1 ou si vous êtes sur un stockage en bloc réseau, attendez-vous à des douleurs sur les écritures aléatoires ; planifiez pour minimiser le temps de prepare/appliquer les logs et évitez la compression lourde.

Task 4: Vérifier si le fournisseur bride votre disque (vite et sale)

cr0x@server:~$ iostat -xm 1 5
Linux 6.1.0-18-amd64 (server) 	12/30/2025 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.20    0.00    4.60   52.40    0.30   36.50

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
vda              4.00    120.0     0.00   0.00    8.50    30.00   220.0   22000.0    15.00   6.38  130.00   100.00   30.20  99.80

Ce que cela signifie : Le disque est à ~100% d’utilisation et le write await est énorme. Vous êtes lié par les E/S ; le stockage VPS est le limitateur.

Décision : Arrêtez d’ajouter du parallélisme et de la compression. Vous avez besoin de moins d’écritures aléatoires (optimisation du prepare) ou d’un meilleur stockage (plan supérieur, VPS local NVMe ou volume plus rapide attaché).

Task 5: Vérifier le steal CPU (votre « vCPU » pourrait être une suggestion)

cr0x@server:~$ mpstat 1 5
Linux 6.1.0-18-amd64 (server) 	12/30/2025 	_x86_64_	(2 CPU)

12:10:01 AM  CPU    %usr   %nice    %sys %iowait   %irq   %soft  %steal  %guest  %gnice   %idle
12:10:02 AM  all   18.00    0.00    6.00   10.00   0.00    0.00   22.00    0.00    0.00   44.00

Ce que cela signifie : Un fort %steal signifie que l’hyperviseur vous prend du temps CPU. La compression va ramper et des timeouts risquent d’arriver.

Décision : Si le steal est constamment élevé pendant les restaurations, payez pour du CPU dédié ou déplacez le travail de restauration vers une machine moins contencieuse.

Task 6: Confirmer le répertoire de données et l’espace libre (les restaurations échouent quand les disques se remplissent)

cr0x@server:~$ mysql -Nse "SELECT @@datadir, @@tmpdir;"
/var/lib/mysql	/tmp

cr0x@server:~$ df -h /var/lib/mysql /tmp
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        79G   62G   13G  83% /
/dev/vda1        79G   62G   13G  83% /

Ce que cela signifie : Seulement 13G de libre. Une restauration physique plus des fichiers temporaires peut faire exploser ceci.

Décision : Si vous ne pouvez pas garantir de l’espace pour la sauvegarde + la copie préparée + les logs, restaurez sur un nouveau volume ou une nouvelle instance.

Task 7: Vérifier les paramètres InnoDB qui affectent le comportement de restauration/récupération

cr0x@server:~$ mysql -Nse "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_log_at_trx_commit','sync_binlog','innodb_doublewrite','innodb_log_file_size','innodb_buffer_pool_size');"
innodb_buffer_pool_size	1073741824
innodb_doublewrite	ON
innodb_flush_log_at_trx_commit	1
innodb_log_file_size	268435456
sync_binlog	1

Ce que cela signifie : Paramètres de durabilité conservateurs. Excellents pour la sécurité des données, plus lents pour les pics d’écriture intensifs et certains workflows de restauration.

Décision : Pendant une fenêtre de restauration (pas en opération normale), envisagez d’assouplir temporairement sync_binlog et innodb_flush_log_at_trx_commit si vous faites des imports logiques. Pour une restauration physique copy-back, cela a moins d’importance ; pour la rattrapage post-restauration, cela peut compter.

Task 8: Mesurer la taille de la sauvegarde et le ratio de compression (prévoir CPU vs E/S)

cr0x@server:~$ du -sh /backups/full-2025-12-29
18G	/backups/full-2025-12-29

cr0x@server:~$ du -sh /backups/full-2025-12-29.tar.zst
6.2G	/backups/full-2025-12-29.tar.zst

Ce que cela signifie : Compression 3x. Sympa. Aussi : le coût de décompression est réel.

Décision : Si vous êtes limité par le CPU, choisissez un niveau de compression plus léger ou aucun ; si vous êtes limité par le réseau, gardez la compression et acceptez le coût CPU.

Task 9: Vérifier la disponibilité de mariabackup/xtrabackup et la correspondance des versions

cr0x@server:~$ mariabackup --version
mariabackup based on MariaDB server 10.11.6-MariaDB Linux (x86_64)

Ce que cela signifie : L’outil est aligné avec la famille MariaDB 10.11.

Décision : Procédez avec la sauvegarde/restauration physique. Si l’outil indique une famille majeure différente de votre serveur, corrigez cela d’abord.

Task 10: Chronométrer la phase de prepare et surveiller les E/S en direct (trouver le goulot)

cr0x@server:~$ /usr/bin/time -v mariabackup --prepare --target-dir=/backups/full-2025-12-29 2>&1 | tail -n 8
	User time (seconds): 132.10
	System time (seconds): 88.55
	Percent of CPU this job got: 92%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 4:12.33
	Maximum resident set size (kbytes): 612340
	File system outputs: 9483216
	Exit status: 0

Ce que cela signifie : Temps réel 4 minutes avec de fortes sorties système : écritures intensives. Le CPU est élevé mais pas complètement saturé ; probablement mix CPU + disque.

Décision : Si le temps réel est énorme et que iostat montre un fort await, vous êtes limité par les IOPS. Atténuez en réduisant le volume de redo (moins de churn d’écriture pendant la sauvegarde), ou restaurez sur un stockage meilleur.

Task 11: Valider l’intégrité de la sauvegarde avant de parier votre incident dessus

cr0x@server:~$ mariabackup --check-privileges --target-dir=/backups/full-2025-12-29
mariabackup: Starting to check privileges
mariabackup: All required privileges are granted

Ce que cela signifie : L’utilisateur de sauvegarde a les permissions requises ; moins de surprises pendant les restaurations d’urgence.

Décision : Si la vérification des privilèges échoue, corrigez cela maintenant. N’acceptez pas « ça marche habituellement ». C’est comme ça que l’on reçoit des pages au milieu de la nuit.

Task 12: Restaurer avec copy-back et vérifier la propriété (la partie ennuyeuse mais importante)

cr0x@server:~$ systemctl stop mariadb

cr0x@server:~$ mariabackup --copy-back --target-dir=/backups/full-2025-12-29
mariabackup: Starting to copy back
mariabackup: Copying ./ibdata1 to /var/lib/mysql/ibdata1
mariabackup: completed OK!

cr0x@server:~$ chown -R mysql:mysql /var/lib/mysql

Ce que cela signifie : Les fichiers de données sont en place. La propriété est critique ; systemd ne le corrigera pas pour vous.

Décision : Si vous sautez le chown, vous risquez des erreurs de permission, un démarrage raté et une longue nuit à regarder les logs en se demandant « pourquoi c’est down ».

Task 13: Surveiller le temps de récupération au premier démarrage (le mensonge « la restauration est terminée »)

cr0x@server:~$ systemctl start mariadb

cr0x@server:~$ journalctl -u mariadb -n 30 --no-pager
Dec 30 00:22:12 server mariadbd[12988]: InnoDB: Starting crash recovery from checkpoint LSN=234887123
Dec 30 00:22:20 server mariadbd[12988]: InnoDB: 2 out of 2 rollback segments are active.
Dec 30 00:22:34 server mariadbd[12988]: InnoDB: Crash recovery finished.
Dec 30 00:22:35 server mariadbd[12988]: mariadbd: ready for connections.

Ce que cela signifie : Il y a eu du travail de récupération, mais il s’est terminé rapidement.

Décision : Si la récupération après crash traîne, votre prepare n’a pas complètement géré l’application des redo, ou votre système est à court d’IOPS. Vérifiez le disque et les paramètres de logs InnoDB.

Task 14: Mesurer la vitesse de copie lors de la restauration (séparer « copie » de « prepare »)

cr0x@server:~$ rsync -aHAX --info=progress2 /backups/full-2025-12-29/ /var/lib/mysql/
      9,732,145,152  62%  42.31MB/s    0:03:12

Ce que cela signifie : ~42 MB/s en copie plutôt séquentielle. C’est correct pour un petit VPS.

Décision : Si la vitesse de copie est correcte mais que la restauration globale est lente, le problème vient du prepare ou de la récupération, pas du transfert de fichiers.

Task 15: Si vous devez utiliser une restauration logique, rendez-la moins atroce

cr0x@server:~$ mysql -e "SET GLOBAL innodb_flush_log_at_trx_commit=2; SET GLOBAL sync_binlog=0;"

cr0x@server:~$ pv /backups/db.sql | mysql --max-allowed-packet=1G
1.58GiB 0:03:41 [7.30MiB/s] [=====================>     ] 62% ETA 0:02:15

Ce que cela signifie : Vous améliorez le débit en assouplissant la durabilité pendant l’import ; pv affiche la progression et le débit.

Décision : Ne faites cela que dans une fenêtre de restauration contrôlée. Après l’import, restaurez des paramètres sûrs.

Task 16: Confirmer les positions de réplication/binlog après restauration (éviter la dérive silencieuse)

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

Ce que cela signifie : Vous avez un fichier/position de binlog. Si ce serveur est un réplica ou doit en semer d’autres, vous avez besoin de cohérence.

Décision : Enregistrez ces coordonnées et alignez les réplicas. Une restauration rapide qui crée une incohérence des données n’est qu’un incident lent plus tard.

Trois micro-histoires d’entreprise (anonymisées, douloureusement plausibles)

Incident causé par une mauvaise hypothèse : « SSD = SSD »

Une petite équipe SaaS utilisait MariaDB sur un VPS bon marché parce que la burn rate en début d’activité était « maîtrisée ». Leurs restaurations prenaient historiquement ~10 minutes avec des sauvegardes physiques. Ils pratiquaient trimestriellement. Ce n’était pas idéal, mais c’était supportable.

Un lundi, un problème de système de fichiers a forcé une restauration. La phase de copy-back de la sauvegarde s’est déroulée normalement. Puis --prepare et le premier démarrage ont commencé à ralentir. L’on-call a supposé que « c’est juste une grosse sauvegarde » et a attendu. Quarante minutes plus tard ils regardaient encore les messages de récupération InnoDB avancer à reculons comme un mauvais film d’horreur.

La mauvaise hypothèse : « Le disque est SSD, donc les écritures aléatoires devraient être OK. » En réalité, leur VPS avait été migré vers un backend avec un throttling IOPS agressif. Les écritures séquentielles allaient bien ; la latence d’écriture aléatoire était brutale. Les phases de prepare et de récupération ont martelé les écritures aléatoires et se sont fait throttler jusqu’à l’oubli.

Correctif : ils ont reconstruit sur un autre type de VPS avec des IOPS prévisibles, puis ajouté un simple pré-check : exécuter iostat pendant un test de prepare planifié et alerter si le write await dépasse un seuil pendant plusieurs minutes. Les restaurations ne sont pas devenues instantanées. Elles sont devenues prévisibles. La prévisibilité est ce que vous vendez à votre futur vous.

Optimisation qui s’est retournée contre eux : « compressons tout plus fort »

Une entreprise de taille moyenne utilisait Percona Server et streamait des sauvegardes nocturnes vers une autre région. Les coûts de stockage grimpaient, alors quelqu’un a proposé d’augmenter fortement la compression et d’encrypter en même temps. Les artefacts de sauvegarde sont devenus plus petits. Le tableur des coûts s’est mieux présenté. Tout le monde a célébré et a repris le développement.

Deux mois plus tard, une restauration a été nécessaire après une erreur opérateur. Le pipeline de restauration a tiré le flux compressé/chiffré, puis a passé des âges à déchiffrer et décompresser sur un petit VPS standby. Le CPU était saturé, le %steal non négligeable, et tout a pris tellement de temps que la direction a commencé à demander s’il ne fallait pas reconstruire la base à partir des événements applicatifs.

Le retour de bâton : ils ont optimisé la taille des sauvegardes et les coûts de transfert, mais ont déplacé la douleur côté restauration — exactement là où vous avez le moins de patience et le plus de pression. Sur les petites machines, « meilleure compression » signifie souvent « récupération plus lente ».

Correctif : ils ont changé pour un niveau de compression plus léger, et déporté la décompression/déchiffrement lourds sur un hôte utilitaire plus puissant. Les sauvegardes restaient plus petites que le brut, mais les restaurations sont redevenues prédictibles. Ils ont aussi documenté une règle simple : « Le temps de restauration est une exigence produit. » Dès que vous le formulez ainsi, les gens arrêtent de le traiter comme un hobby.

Pratique ennuyeuse mais correcte qui a sauvé la mise : répétitions de restauration avec budgets temporels

Une autre équipe — aussi sur un petit parc de VPS — avait une règle : chaque mois, faire une restauration complète dans une instance fraîche et mesurer le temps de chaque phase : téléchargement, déchiffrement, décompression, prepare, copy-back, démarrage initial et un test smoke applicatif basique.

Ce n’était pas glamour. Cela ne produisait aucune fonctionnalité visible client. Cela signifiait aussi que lorsqu’un incident de corruption disque est survenu, ils savaient déjà que la restauration serait liée au CPU pour la décompression et aux IOPS pour le prepare. Ils avaient un contournement documenté : tirer la sauvegarde sur un VPS temporaire optimisé compute, la préparer là-bas, puis rsync le répertoire préparé vers la cible.

Ils ont exécuté le plan. Pas d’improvisation. Pas de « on essaie peut-être… » en plein incident. Le service est revenu dans la fenêtre attendue, et le postmortem a été court parce que le résultat était ennuyeux.

Blague #2 : La seule chose plus coûteuse que tester des restaurations est de ne pas les tester — votre futur incident vous facturera en heures.

MariaDB vs Percona : leviers de vitesse et pièges qui comptent vraiment

Outils : mariabackup et xtrabackup sont cousins, pas jumeaux

On parle de « XtraBackup » comme si c’était un terme générique pour les sauvegardes physiques. C’est comme appeler chaque aspirateur un « Dyson ». Pratique, faux, et parfois coûteux.

mariabackup de MariaDB existe parce que MariaDB s’est éloigné des internes MySQL/Percona. xtrabackup de Percona est réglé pour la compatibilité avec Percona Server/MySQL. Sur le papier, les deux font des sauvegardes physiques InnoDB à chaud. En production, des incompatibilités de version et des différences de format subtiles peuvent transformer « restauration rapide » en « pourquoi ça ne démarre pas ? ».

La vitesse de restauration est dictée par le churn de redo, pas par la marque

Si votre charge génère beaucoup de redo (fort taux d’écriture, grosses transactions, mises à jour massives d’index secondaires), la phase de prepare fera plus de travail. Ce travail consiste essentiellement à écrire des pages — de manière aléatoire. Sur un petit VPS aux IOPS médiocres, votre temps de restauration est une fonction de l’amplification d’écriture.

Vous pouvez parfois réduire le churn de redo en programmant les sauvegardes pendant les périodes à faible écriture, ou en vous assurant que la base n’exécute pas des patterns pathologiques (comme de grosses updates multi-lignes sans batching). Mais il n’existe pas de bouton magique « Percona est plus rapide » pour ça.

Les choix de compression créent des profils « restauration CPU » vs « restauration disque »

La restauration la plus rapide sur un petit VPS est souvent : sauvegarde non compressée stockée localement, préparée une fois, copiée rapidement. Mais c’est gourmand en stockage. Si vous stockez hors hôte, vous allez compresser. Votre restauration inclut alors la décompression, et le CPU devient le limitateur.

Si vous êtes lié par le CPU, MariaDB et Percona « perdront » de la même manière, car la saveur du serveur ne fait pas la décompression — c’est l’outil et le pipeline qui le font. Le gain vient du choix des niveaux de compression et de l’endroit où effectuer le calcul.

Binlogs et réplication : des restaurations qui « fonctionnent » peuvent quand même vous trahir

Les environnements Percona ont souvent des topologies de réplication plus élaborées et des habitudes de récupération point-in-time, en partie parce que l’écosystème Percona vous y incite. Les environnements MariaDB varient beaucoup. Dans les deux cas, la restauration ne se limite pas à copier des données : il faut que le serveur retrouve la réalité — coordonnées de réplication, GTID, binlogs, attentes applicatives.

Sur un petit VPS, la restauration la plus rapide est parfois « remplacer l’instance » plutôt que « restaurer in place ». Nouvelle VM, attacher les données préparées, démarrer, swap IP/DNS. Ce n’est pas une fonctionnalité de base de données ; c’est un pattern opérationnel.

Ce que je choisirais sur un petit VPS

• Si vous êtes déjà sur Percona Server (MySQL 8.0) : utilisez XtraBackup, gardez les versions alignées et concevez votre pipeline pour minimiser la douleur CPU pendant la restauration.
• Si vous êtes déjà sur MariaDB 10.6+ : utilisez mariabackup, entraînez-vous à restaurer chaque mois et considérez le temps de prepare comme votre KPI central.
• Si vous choisissez une pile à partir de zéro sur un petit VPS et que la vitesse de restauration est primordiale : choisissez la stack que vous pouvez exploiter proprement, puis payez pour un stockage à IOPS prévisibles. La facture est moins chère que le downtime.

Erreurs courantes (symptôme → cause racine → correctif)

1) Symptom : la phase de prepare prend une éternité, disque à 100% d’utilisation

Cause racine : Limite d’IOPS d’écriture aléatoire du stockage VPS ; application lourde des redo.

Correctif : Restaurer/préparer sur une instance plus grande/plus rapide, puis copier les fichiers préparés ; ou passer à un plan avec IOPS prévisibles. Réduire le churn de redo en programmant les sauvegardes pendant les fenêtres à faible écriture.

2) Symptom : la restauration est « rapide » mais le premier démarrage prend des heures avec la récupération

Cause racine : La sauvegarde n’a pas été correctement préparée, ou le serveur effectue une récupération additionnelle due à une incompatibilité de config (tailles de log, fichiers manquants), ou le stockage est throttlé.

Correctif : Assurez-vous que --prepare s’est terminé avec succès ; vérifiez la compatibilité des paramètres de logs InnoDB ; contrôlez la propriété et l’intégrité des fichiers ; surveillez les logs de récupération et corrélez avec iostat.

3) Symptom : la restauration logique est plus lente que prévu, le CPU n’est pas saturé, le disque n’est pas saturé

Cause racine : Goulot d’import mono-thread, coût de reconstruction des index secondaires, ou paramètres fsync forçant une latence par commit.

Correctif : Utilisez des sauvegardes physiques pour les grands jeux de données. Si vous êtes coincé avec du logique : désactivez autocommit pendant l’import, utilisez --single-transaction dans le dump, assouplissez sync_binlog/innodb_flush_log_at_trx_commit pendant la fenêtre de restauration, et chargez schéma + données dans un ordre sensé.

4) Symptom : la sauvegarde se termine, la restauration échoue avec « permission denied » ou datadir illisible

Cause racine : Mauvaise propriété/SELinux/AppArmor après le copy-back.

Correctif : chown -R mysql:mysql du datadir, vérifiez les politiques de sécurité et confirmez que l’unité systemd a accès.

5) Symptom : le serveur restauré démarre, mais l’application voit des tables manquantes ou erreurs bizarres

Cause racine : Vous avez restauré le mauvais jeu de sauvegardes, ou vous avez mélangé artefacts logiques + physiques, ou restauré une sauvegarde partielle.

Correctif : Validez le manifeste de sauvegarde, conservez des sauvegardes immuables et exécutez des requêtes de vérification post-restauration (comptes de lignes, échantillonnage de checksum, test smoke applicatif).

6) Symptom : la restauration est rapide localement mais douloureusement lente en tirant depuis le stockage distant

Cause racine : Débit/latence réseau, limites de taux, ou chiffrement/déchiffrement sur un petit CPU.

Correctif : Récupérez sur un hôte de staging proche du stockage, préparez-y la sauvegarde, puis déplacez les fichiers préparés ; ou conservez une sauvegarde récente locale si votre RTO l’exige.

7) Symptom : xtrabackup/mariabackup signale une erreur de version serveur non supportée

Cause racine : Incompatibilité outil/serveur ; tentative d’utiliser l’outil de « l’autre » écosystème.

Correctif : Installez la bonne version de l’outil depuis le même écosystème et famille de version majeure que le serveur ; retestez les sauvegardes.

8) Symptom : après restauration, la réplication casse ou les données divergent

Cause racine : Coordonnées binlog/GTID non capturées ou non appliquées de manière cohérente ; restauration depuis une sauvegarde sans état de réplication assorti.

Correctif : Capturez et stockez les coordonnées de réplication avec chaque sauvegarde ; après restauration, reconfigurez explicitement la réplication et vérifiez avec des checks de statut.

Checklists / plan étape par étape

Plan A : Restauration physique rapide sur le même VPS (moins de pièces mobiles)

1. Confirmer l’alignement serveur + outil (MariaDB→mariabackup, Percona→xtrabackup).
2. Vérifier l’espace disque libre : vous avez besoin de place pour la sauvegarde préparée et les opérations de copy-back.
3. Arrêter proprement le service de base de données.
4. Préparer la sauvegarde (appliquer les redo) et chronométrer.
5. Copier en retour vers le datadir et corriger la propriété.
6. Démarrer le service et surveiller les logs pour la fin de la récupération.
7. Exécuter une vérification : requêtes basiques, comptages de lignes, test smoke applicatif.

Plan B : Restauration physique rapide en utilisant un hôte de staging (quand le disque du VPS est le goulot)

1. Provisionner une instance temporaire optimisée compute avec meilleur CPU/IOPS que la cible VPS.
2. Télécharger + déchiffrer + décompresser là-bas (éviter de brûler le CPU sur la cible minuscule).
3. Exécuter le prepare là-bas ; c’est l’étape lourde en écritures aléatoires.
4. Rsync le datadir préparé vers le VPS cible (plus séquentiel, plus prévisible).
5. Démarrer MySQL/MariaDB sur la cible et valider.
6. Mettre hors service le staging après succès (et documenter le processus pour la prochaine fois).

Plan C : Vous êtes coincé avec des dumps logiques (comment survivre)

1. Restaurer le schéma d’abord (tables, index, contraintes), mais envisagez de différer les index lourds si possible.
2. Assouplir temporairement la durabilité pendant l’import si acceptable dans votre fenêtre de récupération.
3. Importer en grosses transactions (éviter les commits par ligne).
4. Surveiller la progression avec pv et les métriques du serveur ; ne pas piloter à l’aveugle.
5. Rétablir les paramètres de durabilité immédiatement après l’import.
6. Reconstruire ou analyser les tables au besoin pour les performances.

Règles de décision (imprimez-les mentalement)

• Si prepare domine le temps : vous êtes IOPS-bound ou redo-heavy → staging sur meilleur stockage/hôte.
• Si la décompression domine le temps : vous êtes CPU-bound → compression plus légère ou offload du calcul.
• Si le transfert domine : pipeline de streaming ou conserver une copie locale récente.
• Si vous restaurez via mysqldump pour de gros jeux de données : vous n’avez pas d’objectif RTO, vous avez un souhait.

FAQ

1) Alors qui est plus rapide : MariaDB ou Percona Server ?

Si vous utilisez des sauvegardes physiques avec l’outil correct (mariabackup pour MariaDB, xtrabackup pour Percona/MySQL), ils sont généralement dans la même fourchette. Votre disque VPS et vos choix de compression décident du résultat réel.

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

Une sauvegarde physique préparée copiée en place (ou rsync depuis un hôte de staging) est typiquement la plus rapide. Les restaurations logiques sont presque toujours plus lentes pour tout ce qui n’est pas trivial.

3) Pourquoi la phase « prepare » prend-elle parfois si longtemps ?

Le prepare rejoue les redo et rend la copie cohérente. Cela peut impliquer beaucoup d’écritures aléatoires. Sur un stockage VPS limité en IOPS, les écritures aléatoires sont le percepteur.

4) Dois-je compresser les sauvegardes sur un VPS 2 vCPU ?

Compressez si vous êtes contraint par le réseau/le stockage, mais attendez-vous à ce que la décompression pénalise le temps de restauration. Si le temps de restauration est prioritaire, conservez au moins une sauvegarde récente non compressée ou préparée sur un hôte plus puissant.

5) Puis-je restaurer une sauvegarde MariaDB avec xtrabackup (ou vice versa) ?

Parfois cela fonctionne sur des plages de versions étroites, mais c’est un piège de fiabilité. En cas de panne, vous voulez « supporté et testé », pas « ça a marché une fois en staging ».

6) Restaurer sur un VPS tout neuf est-il plus rapide que restaurer sur place ?

Souvent, oui — surtout si vous pouvez préparer la sauvegarde ailleurs puis attacher/rsync les données. Remplacer l’instance évite de lutter contre des problèmes de disque résiduels, la dérive des paquets et la pression sur le système de fichiers racine.

7) Quelles métriques surveiller pendant une restauration ?

Utilisation disque et await (iostat -xm), steal CPU (mpstat), espace libre (df -h), et logs de base de données pour la progression de la récupération (journalctl). Si vous ne pouvez pas dire si vous êtes CPU- ou I/O-bound, vous ne pourrez pas corriger rapidement.

8) Augmenter innodb_buffer_pool_size accélère-t-il les restaurations ?

Rarement pour la copie brute ou le prepare directement. Cela peut réduire la douleur post-restauration en améliorant le hit rate du cache et en accélérant le retour à la normale. C’est une mesure de stabilité, pas un accélérateur magique de restauration.

9) Qu’en est-il des snapshots (LVM/ZFS) ?

Les snapshots peuvent être très rapides pour un rollback local, mais sur un petit VPS vous ne contrôlez souvent pas la couche de stockage. De plus, la performance des snapshots peut se dégrader sous charge d’écriture. Traitez les snapshots comme un complément, pas comme votre unique plan de récupération.

10) Comment rendre le temps de restauration prévisible ?

Exécutez des restaurations de répétition, enregistrez les temps par phase et alertez sur les changements. La prévisibilité vient de la répétition et d’une infrastructure qui n’étrangle pas vos E/S de manière aléatoire.

Conclusion : prochaines étapes pour vraiment réduire le temps de restauration

MariaDB contre Percona Server n’est pas votre principal levier de vitesse de restauration sur un petit VPS. C’est un choix d’outillage et d’écosystème, et les deux peuvent être rapides si vous utilisez correctement leurs outils de sauvegarde physique. Le vrai combat est contre les limites d’écriture aléatoire du disque, la pénurie CPU due à la compression, et les habitudes opérationnelles qui traitent la restauration comme une théorie.

Faites ceci ensuite :

1. Choisissez les sauvegardes physiques comme défaut (mariabackup ou xtrabackup), et arrêtez de prétendre que les dumps logiques sont une stratégie RTO pour de gros volumes.
2. Effectuez une répétition de restauration mensuelle et enregistrez les temps pour transfert, décompression, prepare, copy-back et premier démarrage.
3. Décidez où s’exécute le prepare. Si le stockage de votre VPS est faible, exécutez le prepare sur un hôte de staging avec de meilleurs IOPS et expédiez les fichiers préparés.
4. Ajustez la compression en fonction de la contrainte réelle : CPU, réseau ou disque.
5. Budgetez un stockage prévisible. Si le temps de restauration compte, les IOPS « burstables » ne constituent pas un vrai plan.

Lorsque le prochain incident surviendra — parce qu’il surviendra — vous restaurerez soit depuis un pipeline testé, soit vous apprendrez sous pression. L’un est moins cher.