Sauvegarde et restauration de MariaDB

Sauvegardes cohérentes et hautement performantes pour les environnements MariaDB en production

Le module MariaDB de Bacula Enterprise permet de sauvegarder et de restaurer les environnements MariaDB plus rapidement, de manière plus sécurisée et plus efficace, tout en réduisant considérablement la charge administrative. MariaDB est un serveur de base de données en production qui, dans les environnements d’entreprise, traite en continu des transactions de lecture et d’écriture. Comme pour tout serveur de base de données actif, une sauvegarde effectuée pendant que des transactions sont en cours interceptera certaines de ces transactions en cours d’écriture, et ces données incomplètes rendront la sauvegarde peu fiable et fragmentée pour la restauration.

À cette fin, le module MariaDB de Bacula est conçu pour sauvegarder un serveur MariaDB en production sans perturber les transactions actives, avec plusieurs approches adaptées à différentes exigences en matière de délai de restauration et de performances. Tout administrateur de sauvegarde peut l’utiliser sans connaissance préalable de scripts complexes ou du fonctionnement interne de MariaDB.

Ce que prend en charge le module MariaDB de Bacula

Le module MariaDB de Bacula prend en charge les techniques de sauvegarde Dump et Binary pour les environnements MariaDB à haut débit de transactions. Le module sauvegarde automatiquement les données au niveau du serveur, telles que les définitions d’utilisateurs, les autorisations globales et les fichiers de configuration. La restauration à un instant donné (PITR) est disponible dans chaque mode, et le module prend en charge le filtrage d’objets pendant les opérations de sauvegarde et de restauration.

Pour les organisations exploitant de grandes bases de données MariaDB à fort taux de transactions, les temps d’arrêt paralysent le traitement des transactions et réduisent directement le chiffre d’affaires. Plus la base de données reste hors ligne longtemps, plus les pertes financières sont importantes. Le module MariaDB de Bacula a été spécialement conçu pour réduire au minimum cette fenêtre.

Télécharger l’essai gratuitTélécharger MariaDB whitepaper

Restauration plus rapide de MariaDB grâce à l’étape « Prepare »

Avec le module de sauvegarde binaire MariaDB de Bacula, les bases de données sont restaurées dans un emplacement temporaire avant que la base de données en production ne soit modifiée. L’étape « Prepare » de Mariabackup applique ensuite les modifications du journal de reprise à ces données et génère un point de restauration entièrement cohérent. Ce n’est qu’une fois ce processus terminé que la modification effective de la base de données en production peut commencer.

Par défaut, l’étape « Prepare » s’exécute au moment de la restauration. Bacula peut également l’exécuter automatiquement pendant la phase de sauvegarde. Lorsqu’elle s’exécute pendant la sauvegarde, le traitement de cohérence est déjà terminé avant même qu’une restauration ne soit déclenchée, et la restauration peut commencer immédiatement sans aucun délai de préparation. Pour les grandes organisations soumises à des RTO serrés, des restaurations plus rapides réduisent les temps d’arrêt. La réduction des temps d’arrêt permet de maintenir l’activité opérationnelle et de garantir la continuité des revenus.

*Le module fonctionne sur les plateformes Linux 32 bits et 64 bits.

Outil de sauvegarde à chaud pour MariaDB sans verrouillage ni compromis en matière de chiffrement

Le module MariaDB de Bacula Enterprise s’intègre à Mariabackup (mariadb-backup), un utilitaire open source de sauvegarde à chaud issu à l’origine d’un fork de Percona XtraBackup, afin de fournir des sauvegardes rapides et cohérentes des serveurs MariaDB en production. Contrairement à Percona XtraBackup, Mariabackup gère nativement les tables MariaDB chiffrées et compressées, ce qui en fait l’outil idéal pour les déploiements MariaDB modernes où le chiffrement est une exigence standard. Mariabackup élimine la nécessité de verrouiller la base de données pendant la sauvegarde, et les transactions actives se poursuivent sans interruption. Les environnements critiques avec des objectifs de temps de récupération (RTO) stricts peuvent effectuer des sauvegardes sans aucun impact sur le trafic de production.

• Sauvegarde par base de données – Par défaut, l’agent MariaDB effectue une sauvegarde de chaque base de données séparément. Chaque sauvegarde est un fichier SQL en texte brut contenant toutes les commandes nécessaires pour reconstituer cette base de données exactement telle qu’elle était au moment de la sauvegarde.
• Sauvegarde de toutes les bases de données – L’option all_databases génère un seul fichier all-databases.sql regroupant toutes les bases de données du serveur en une seule opération. Les journaux binaires générés avant la fin de la tâche sont inclus dans la sauvegarde, et la tâche incrémentielle suivante reprend là où la sauvegarde complète s’est arrêtée.
• Sauvegarde binaire via Mariabackup – Le mode binaire utilise Mariabackup, un utilitaire open source de sauvegarde à chaud issu à l’origine d’un fork de Percona XtraBackup 2.3.8. Mariabackup effectue des sauvegardes physiques en ligne des tables InnoDB, Aria et MyISAM. Il gère nativement les tables chiffrées et compressées, s’exécute sans verrouiller la base de données et ne nécessite pas de fichiers temporaires volumineux pendant le processus de sauvegarde.
• Sauvegarde des journaux binaires – L’agent MariaDB enregistre les fichiers de journaux binaires générés lors de chaque tâche de sauvegarde. Les journaux binaires enregistrent chaque événement de modification de la base de données, y compris les opérations de création de tables, les modifications de données et la durée d’exécution de chaque instruction. Ces journaux constituent la base de la restauration à un instant donné.
• Sauvegarde incrémentielle – Chaque tâche incrémentielle effectuée après une sauvegarde complète n’enregistre que les nouveaux journaux binaires générés depuis la tâche précédente. L’option « Accurate » empêche l’apparition de fichiers journaux en double dans les jeux de sauvegarde et garantit la propreté des chaînes de restauration.

Options de restauration de MariaDB

• Restauration à un instant donné – La restauration PITR est disponible en modes Dump et Binaire. L’agent MariaDB suit et gère les fichiers journaux binaires pour les tâches complètes, incrémentielles et différentielles, puis rejoue ces journaux afin de restaurer la base de données à un instant précis.
• Restauration d’une seule base de données – Le mode Dump stocke chaque base de données dans son propre ensemble de fichiers SQL. Les bases de données individuelles peuvent être restaurées à partir de ces fichiers sans toucher au reste du serveur. Une seule table ou un objet de schéma peut également être restauré en modifiant directement le fichier de sauvegarde, restauré localement.
• Restauration des utilisateurs et des rôles – Les autorisations globales et les autorisations utilisateur par base de données sont stockées dans des fichiers distincts pour chaque tâche de sauvegarde. Les administrateurs peuvent restaurer les comptes utilisateurs et les autorisations indépendamment des données de la base de données.
• Restauration complète du serveur à partir du mode binaire – L’agent Bacula utilise Mariabackup pour restaurer un serveur MariaDB complet à partir d’une sauvegarde binaire. Les données du serveur sont d’abord restaurées vers un emplacement temporaire. L’étape de préparation amène ensuite ces données à un état pleinement cohérent avant que la base de données en production ne soit touchée.
• Préparation au moment de la sauvegarde – L’étape de préparation peut s’exécuter automatiquement pendant la phase de sauvegarde plutôt qu’au moment de la restauration. Dans ce cas, le traitement de cohérence est déjà terminé au moment où la restauration est déclenchée, ce qui accélère le processus.
• Restauration à partir de sauvegardes ou de journaux binaires – Les administrateurs peuvent effectuer une restauration à partir de fichiers de sauvegarde SQL ou de sauvegardes binaires Mariabackup. Les deux méthodes sont disponibles via l’interface de restauration de Bacula, en fonction du scénario de restauration.

Outil d’administration et de contrôle des sauvegardes MariaDB

• Commande « estimate » – La commande « estimate » interroge l’agent Bacula avant l’exécution de toute tâche et affiche toutes les bases de données détectées sur le serveur. En mode « Dump », l’agent indique la taille de la base de données plutôt que la taille estimée de la sauvegarde, car la taille finale de la sauvegarde ne peut être calculée avant l’exécution de la tâche.
• Détection automatique des bases de données – L’agent Bacula détecte automatiquement toutes les bases de données présentes sur le serveur. Des bases de données spécifiques peuvent être ciblées par leur nom dans la configuration du Fileset sans intervention manuelle d’inventaire.
• Filtrage d’objets – Les administrateurs peuvent inclure ou exclure des bases de données et des tables spécifiques lors des opérations de sauvegarde et de restauration à l’aide de paramètres de plugin. Aucune modification manuelle des fichiers de sauvegarde n’est requise.
• Mode Précis – L’activation de l’option Précis sur les tâches incrémentielles et différentielles garantit que chaque fichier de journal binaire n’apparaît qu’une seule fois dans l’ensemble des jeux de sauvegarde. Sans cette option, un même fichier de journal pourrait être inclus dans plusieurs tâches, ce qui crée une ambiguïté dans les chaînes de restauration.
• Format mbstream – Mariabackup prend en charge mbstream, un format de streaming personnalisé introduit pour gérer simultanément la compression et le streaming. Il est disponible parallèlement au format TAR standard.
• Fonctionnement sans script – L’agent Bacula gère toutes les opérations de sauvegarde via l’interface de Bacula. Les administrateurs n’ont pas besoin d’écrire de scripts spécifiques à MariaDB ni de comprendre le fonctionnement interne de Mariabackup pour l’utiliser correctement.

Stockage de sauvegarde et maîtrise des coûts

Bacula Enterprise permet aux administrateurs de contrôler directement les coûts de stockage grâce à la réduction des données et à un routage flexible vers les destinations.

• Déduplication au niveau des blocs – Tout bloc de données apparaissant plus d’une fois dans le catalogue de sauvegarde n’est écrit qu’une seule fois sur le stockage. La consommation de stockage diminue sans aucune modification de la politique ou du calendrier de sauvegarde.
• Compression adaptative – Les algorithmes de compression sont configurables pour chaque tâche. Les administrateurs ajustent la compression en fonction du type de données et des ressources disponibles.
• Plusieurs types de cibles de stockage – Les sauvegardes s’écrivent sur un disque local, un NAS, un SAN, des bibliothèques de bandes, un stockage objet dans le cloud (notamment S3, Azure et Google Cloud), ou toute combinaison de ces options au sein d’une même politique.
• Stockage objet compatible S3 – Bacula se connecte à n’importe quel fournisseur compatible S3 pour une conservation à long terme sans dépendance vis-à-vis d’un fournisseur.
• Workflows de stockage à plusieurs niveaux – Les données de sauvegarde peuvent être configurées pour passer automatiquement d’un niveau de stockage à un autre à mesure qu’elles vieillissent. Les points de restauration fréquemment consultés restent sur un stockage rapide, tandis que les données plus anciennes sont transférées vers des destinations moins coûteuses.
• Incrémental à vie – Après une première sauvegarde complète, chaque tâche suivante ne capture que les modifications. Les fenêtres de sauvegarde complète récurrentes ne sont plus nécessaires.
• Transferts respectueux de la bande passante – Seules les données modifiées transitent par le réseau entre les exécutions de sauvegarde. La charge du réseau de production reste faible sans limitation manuelle ni contournements de planification.

Sécurité et conformité des sauvegardes

La sécurité et la conformité réglementaire sont intégrées à chaque couche de la plateforme, du chiffrement du transport et du stockage des données au contrôle d’accès et à la journalisation des audits.

• Chiffrement AES-256 – Le chiffrement AES-256 couvre l’intégralité du chemin des données, du client source à la destination de stockage finale. La gestion des clés est configurable pour s’adapter aux politiques de sécurité de l’organisation.
• Copies de sauvegarde immuables – Le stockage compatible WORM verrouille les données de sauvegarde contre toute modification ou suppression une fois celles-ci écrites. Les ransomwares et les menaces internes n’ont aucun accès au point de restauration.
• Contrôles d’accès granulaires – Les autorisations des utilisateurs s’appliquent à des tâches spécifiques, des workflows de restauration et des fonctions de gestion. Chaque administrateur n’accède qu’aux éléments requis par son rôle.
• Audit complet des activités – Chaque sauvegarde, restauration et modification de configuration est consignée avec l’identité de l’utilisateur et l’horodatage. Les équipes chargées de la conformité et de la sécurité disposent d’une piste d’audit complète et ininterrompue.
• Prise en charge du cadre réglementaire – Les contrôles de la plateforme sont conformes aux exigences du RGPD, de la loi HIPAA et de la norme SOC 2 grâce au chiffrement, à des politiques de conservation configurables et à des journaux d’audit détaillés.
• Architectures préservant la confidentialité – Des options de déploiement en « zéro connaissance » permettent à l’infrastructure de sauvegarde de fonctionner sans accorder aux administrateurs aucune visibilité sur les données protégées.

Gestion et administration des sauvegardes

Deux interfaces complémentaires et une suite complète d’outils de gestion offrent une visibilité et un contrôle sur l’ensemble des opérations de sauvegarde.

• Double interface – BWeb fournit une console graphique pour la gestion et la surveillance quotidiennes des tâches. La B console (agent utilisateur) offre aux opérateurs un contrôle total via la ligne de commande pour la création de scripts, l’automatisation et la configuration avancée.
• Évolutivité sans limites – La même architecture de plateforme gère des environnements allant d’une poignée de serveurs à des déploiements comptant des milliers de serveurs, le tout sous un seul plan de gestion.
• Isolation des locataires – Les MSP et les grandes entreprises partitionnent l’environnement de sauvegarde en unités administrées indépendamment. Chaque unité dispose de sa propre configuration, de ses propres politiques et de ses propres contrôles d’accès.
• Détection automatique des ressources – La plateforme analyse l’infrastructure pour identifier et répertorier automatiquement les cibles de sauvegarde. La couverture de protection reste à jour à mesure que l’environnement s’étend.
• Rapports détaillés – Des rapports planifiés couvrent les résultats des tâches, les tendances en matière de capacité, l’état de conformité et les performances opérationnelles à une fréquence définie.
• Intégration de systèmes externes – Bacula se connecte à des outils de surveillance, à des systèmes de tickets informatiques et à des services d’annuaire, notamment LDAP et Active Directory. Aucun développement personnalisé n’est requis.

Couverture de sauvegarde multi-environnements

Les serveurs physiques, les machines virtuelles, les conteneurs et l’infrastructure cloud sont tous intégrés dans une stratégie de sauvegarde unique et unifiée.

• Virtualisation multi-plateforme – Intégration native pour VMware vSphere, Hyper-V, KVM, Red Hat Virtualization, Xen, Azure VM, Proxmox et Nutanix AHV, avec une application cohérente des politiques sur toutes les plateformes.
• Convergence physique et virtuelle – Les serveurs physiques, les postes de travail et les machines virtuelles sont protégés via la même interface de gestion avec des politiques de sauvegarde unifiées.
• Prise en charge des conteneurs et des environnements cloud natifs – Protection complète pour les environnements Docker, Kubernetes, et OpenShift avec des sauvegardes de volumes persistants et des instantanés cohérents au niveau des applications.
• Intégration du stockage multicloud – Prise en charge native du stockage dans le cloud public, privé et hybride, y compris les interfaces S3, S3-IA, Azure, Google Cloud, Oracle Cloud et Glacier, avec la fonctionnalité Minimal Restore Cost (MRC)
• Intégration des bases de données et des applications – Prise en charge de la sauvegarde à chaud pour Oracle, SQL Server, MySQL, PostgreSQL, SAP HANA et d’autres applications critiques, avec une cohérence transactionnelle totale.

Licences de sauvegarde prévisibles

Les licences sont calculées en fonction de la taille de l’environnement, et non du volume de données. Les bases de données MariaDB peuvent s’étendre sans entraîner d’augmentation des coûts de licence.

• Licences indépendantes du volume – L’augmentation de la capacité de sauvegarde n’entraîne pas de hausse des frais de licence. Les coûts de protection des données restent stables à mesure que les volumes de données augmentent.
• Structure de coûts prévisible – Un modèle de tarification fixe permet aux équipes de planifier les budgets d’infrastructure sans tenir compte des coûts variables liés à la croissance du stockage ou aux changements de charge de travail.
• Tarification indépendante de la charge de travail – La taille des bases de données, le nombre de serveurs et les volumes de stockage n’ont aucune incidence sur les coûts de licence.
• Avantages financiers à grande échelle – Les organisations qui protègent des bases de données MariaDB volumineuses ou en forte croissance paient les mêmes frais de licence, quelle que soit la quantité de données ajoutées. L’avantage financier par rapport aux concurrents pratiquant une tarification à la capacité s’accroît à mesure que les volumes de données augmentent.
• Économie des fournisseurs de services – Les MSP acceptent des clients disposant d’ensembles de données volumineux ou en forte croissance sans absorber les augmentations des coûts de licence qui érodent les marges dans le cadre des modèles de tarification au téraoctet.

Récupération et continuité des activités

Chaque scénario de récupération suit un parcours défini, de la restauration d’un seul fichier à la reconstruction complète d’un site.

• Restauration complète au niveau du système – Bacula restaure un serveur complet à partir de zéro, y compris le système d’exploitation, les applications, la configuration et les données, sans nécessiter d’installation manuelle préalable.
• Transfert de données multiplateforme – Les données de sauvegarde peuvent être restaurées sur un système d’exploitation différent de celui d’origine. Les équipes disposent de plusieurs options lorsque du matériel équivalent n’est pas disponible ou qu’une migration est en cours.
• Réplication géographique des sauvegardes – Les jeux de sauvegarde sont copiés vers des emplacements de stockage géographiquement distincts. Une panne à l’échelle du site n’entraîne pas la perte des points de restauration.
• Planification de sauvegardes fréquentes – Les intervalles de sauvegarde peuvent être réduits à quelques minutes. La fenêtre de perte potentielle de données se réduit ainsi à quelques minutes.
• Validation automatisée de la restauration – La restaurabilité est confirmée par des tests automatisés, sans intervention de l’administrateur ni processus de validation distinct.

Décharge

Interaction entre les sauvegardes et les journaux binaires

MariaDB génère en permanence des journaux binaires tout au long du cycle de vie d’une base de données. Ces journaux permettent la restauration à un instant donné (PITR) et les tâches de réplication. Le mode de sauvegarde MariaDB de Bacula sauvegarde par défaut chaque base de données séparément. Lors de la restauration d’un serveur complet comportant plusieurs bases de données, chaque base de données est cohérente individuellement, mais comme les bases de données ne sont pas sauvegardées exactement au même moment, le serveur n’est pas cohérent dans son ensemble.

Le module MariaDB de Bacula Enterprise enregistre les fichiers de journaux binaires générés lors de chaque tâche de sauvegarde. Ces fichiers de journaux peuvent être relus ultérieurement pour ramener l’ensemble du serveur à un état cohérent à un moment précis.

Interaction entre l’option « all_databases » et les journaux binaires

L’option all_databases est destinée aux administrateurs qui ont besoin d’un instantané global cohérent de l’ensemble du serveur en une seule opération. Elle effectue une sauvegarde de toutes les bases de données du serveur en une seule opération, et la cohérence absolue est assurée dès le début de la tâche. Le module conserve les journaux binaires générés avant la fin de la sauvegarde complète, et chaque tâche incrémentielle suivante capture les journaux générés après l’achèvement de la tâche précédente.