Sauvegarder un cluster MariaDB Galera vers Proxmox Backup Server
Publié le 18 mai 2026 — Pattern utilisé en interne sur l'infra RDEM
Cas appliqué en interne RDEM. Le pattern décrit ci-dessous est celui qu'on utilise pour sauvegarder le cluster Galera qui sert plusieurs services internes (PKI, MariaDB d'applications métier, données de supervision). Il est aussi celui qu'on déploie chez les clients en infogérance MariaDB qui veulent externaliser leur backup vers Nimbus PBS sans bricoler le flow control WSREP.
Le défi technique
Un cluster Galera, c'est trois nœuds (ou plus) en réplication synchrone via WSREP. Couper un nœud du flow control pour le sauvegarder n'est pas anodin — sur un cluster chargé, ça peut déclencher des stalls de réplication, voire des évictions. La pratique courante consiste à utiliser mariabackup avec l'option --galera-info, parfois avec un wsrep_desync=ON manuel. Ça marche, mais ça impacte le cluster pendant la fenêtre de backup.
Notre contrainte : le cluster prod doit avoir zéro impact pendant la sauvegarde, le backup doit être physiquement cohérent (pas seulement logique), et le tout doit pousser vers un PBS externe sans interaction avec la stack DB.
L'architecture qu'on a retenue
Plutôt que de toucher au cluster Galera lui-même, on ajoute un quatrième nœud, dédié au backup, qui n'est pas membre du cluster Galera mais réplica asynchrone multi-source des trois nœuds prod. C'est lui qu'on arrête pour faire le snapshot — le cluster prod ne sait même pas qu'un backup a lieu.
Cluster prod — Galera 3 nœuds MariaDB 10.11 LTS
Réplication synchrone WSREP entre les 3 nœuds. Couplé en option à Signal18 Replication Manager pour le failover et le monitoring. Communication chiffrée via PKI Galera maison.
Nœud backup — réplica multi-source des trois nœuds
Un MariaDB indépendant, configuré en multi-source replication avec trois canaux (CHANGE MASTER TO ... FOR CHANNEL ...) — un par nœud Galera. Il consomme les binlogs de manière asynchrone et reste en permanence quelques millisecondes derrière. Il n'est jamais lu par l'application : son seul rôle est d'être un témoin sauvegardable.
Halt propre de la VM backup pendant le snapshot
Chaque nuit, on stoppe proprement MariaDB sur le nœud backup, puis on arrête la VM (qm shutdown). Le datafile InnoDB est alors dans un état cohérent sur disque — pas besoin de crash-recovery à la restauration. Le snapshot Proxmox est pris en mode stop, qui garantit une image fidèle du disque virtuel.
Push vers Nimbus PBS, chiffré côté client
L'hyperviseur Proxmox écrit le backup chunked vers le datastore Nimbus PBS distant. Le chiffrement est fait côté client, avant transmission — le datastore ne voit jamais les données en clair, pattern décrit dans notre article compte backup ≠ compte admin.
Redémarrage et resync automatique
À la fin du backup, la VM redémarre, MariaDB relance les trois canaux de réplication, et rattrape le delta accumulé pendant l'arrêt. Le retard moyen qu'on observe est de quelques secondes : aucune supervision applicative n'est jamais déclenchée par cette opération.
Pourquoi ce pattern plutôt que mariabackup ?
- Zéro contact avec le cluster prod. Pas de
wsrep_desync, pas de bascule de donor, pas de risque de déclencher un flow control intempestif. Le cluster ne sait pas qu'un backup a lieu. - Backup physique, pas logique. On sauvegarde le disque de la VM, donc on capture le datafile InnoDB tel qu'il est sur disque. Le restore est plus simple et plus rapide qu'un import SQL — comparatif détaillé sur notre fiche mysqldump vs mariabackup.
- Stack PBS standard. On bénéficie de toute la mécanique PBS : déduplication, chunks 4 Mo, verify automatique, immutabilité — sans rien réinventer côté DB.
- Restauration testable sans toucher au cluster. On peut restaurer le nœud backup à part, l'allumer dans un réseau isolé, vérifier les données, sans jamais impacter la prod. Test mensuel automatisé.
- Pas de licence supplémentaire. MariaDB Community, Proxmox VE, PBS — toute la pile est open-source. La facture, c'est le stockage Nimbus, point.
Chiffres mesurés sur notre infra
| Métrique | Valeur |
|---|---|
| Volume DB consolidé | ~60 Go (datafile InnoDB compris) |
| Taille du disque VM backup | 120 Go (datadir + binlogs + marge OS) |
| Durée halt → resync complet | ~12 minutes hors heures ouvrées |
| Retard moyen post-backup | < 10 secondes avant retour à 0 lag |
| Impact sur le cluster prod | 0 (le cluster ignore l'existence du nœud backup pendant l'opération) |
| Retention PBS configurée | 10 daily + 5 weekly + 6 monthly |
Le datastore PBS est répliqué sur un second site Equinix Paris — pattern décrit dans notre article réplication PBS : sync-job, verify, snapshot. C'est ce qui transforme un backup local en stratégie 3-2-1 réellement opposable.
Stack RDEM mobilisée
- MariaDB 10.11 LTS sur 3 nœuds Galera + 1 nœud backup en multi-source replication — souvent couplé à un Remote DBA en astreinte.
- Proxmox VE sur hyperviseurs internes, opéré en infogérance Proxmox 24/7 pour les clients.
- Proxmox Backup Server hébergé par Nimbus, datastore multi-DC, chiffrement client-side, immutabilité disponible (voir sauvegarde immuable contre ransomware).
- Réseau AS206014 pour le transit entre l'hyperviseur source et le datastore PBS distant — fibres noires inter-Equinix Paris, pas de transit Internet pour les backups internes.
- Bonnes pratiques PBS : voir notre guide complet backup Proxmox 2026.
Limites honnêtes du pattern
- RPO de 24h par défaut (la fenêtre nocturne). Pour descendre à quelques minutes, il faut conserver les binlogs en plus du snapshot VM et faire du point-in-time recovery au moment du restore.
- Le nœud backup est un coût de stockage supplémentaire sur l'hyperviseur — pas adapté aux clusters > quelques To où le ratio stockage/valeur change. Au-delà, on bascule sur mariabackup avec donor desync.
- Réplica asynchrone : si le nœud backup prend du retard, le snapshot reflète ce retard. On surveille le lag en permanence pour ne jamais sauvegarder une copie déjà décalée de plusieurs minutes.
Pour aller plus loin
- → Backup Windows 1 To vers Nimbus PBS — l'équivalent côté workstation/serveur Windows, autre angle de la même stack PBS.
- → Tous nos use cases Managed Services
Vous opérez un cluster Galera à sauvegarder ?
On déploie ce pattern (nœud backup multi-source + halt VM + PBS distant) en prestation, ou on accompagne votre équipe en Remote DBA. Stockage Nimbus au volume, pas de licence par VM ni par instance MariaDB.
01 77 62 42 42