Un sinistre provoque généralement une panne, ce qui signifie un temps d'arrêt du système et une perte potentielle de données. Une fois que nous avons détecté la panne, nous déclenchons notre plan de reprise après sinistre pour y remédier. Mais ce serait une surprise, s'il n'y a pas de sauvegarde, ou après de longues heures de récupération, vous voyez que ce n'est pas celle qu'il vous faut.
Bien que les pannes puissent être coûteuses, il y a souvent un impact financier qui peut être préjudiciable à l'entreprise et la perte de données peut être une raison de fermer l'entreprise.
Pour minimiser la perte de données, nous devons disposer de plusieurs copies de données à différents endroits. Nous pouvons concevoir notre infrastructure en différentes couches et extraire chaque couche de celle qui se trouve en dessous. Par exemple, nous construisons une couche pour les clusters d'instances de base de données afin de nous protéger contre les pannes matérielles. Nous reproduisons les bases de données dans les centres de données afin de pouvoir nous défendre contre une défaillance du centre de données. Chaque couche supplémentaire ajoute de la complexité, ce qui peut devenir un cauchemar à gérer. Mais toujours, en substance, une sauvegarde occupera une place centrale dans la reprise après sinistre.
C'est pourquoi il est crucial de s'assurer que c'est quelque chose sur lequel nous pouvons compter. Mais comment y parvenir ? Eh bien, l'une des options consiste à vérifier si les sauvegardes ont été exécutées sur la base des dernières lignes du script de sauvegarde.
Un exemple simple :
#!/bin/sh
mysqldump -h 192.168.1.1 -u user -ppassword dbname > filename.sql
if [ "$?" -eq 0 ]; then
echo "Success."
else
echo "Error."
fi
Mais que se passe-t-il si le script de sauvegarde ne démarre pas du tout ? Google propose un certain nombre de résultats de recherche pour "Linux cron, not running".
Malheureusement, les bases de données open source n'offrent souvent pas de référentiel de sauvegarde.
Un autre test de sauvegarde. Vous avez peut-être entendu parler du chat de Schrödinger. Une théorie de sauvegarde de Schrödinger connue est . "L'état de toute sauvegarde est inconnu jusqu'à ce qu'une restauration soit tentée." Cela ressemble à une approche simple, mais une telle tentative signifierait que vous devez configurer un environnement de test, copier des fichiers, exécuter une restauration ... après chaque sauvegarde.
Dans cet article, nous verrons comment vous pouvez utiliser ClusterControl pour vous assurer que votre sauvegarde est exécutée pour obtenir des bases de données de niveau entreprise avec des bases de données Open Source.
Rapports de sauvegarde
ClusterControl a été conçu pour les rapports opérationnels. Le reporting opérationnel fournit un support pour la surveillance et le contrôle des activités quotidiennes de l'entreprise. Le rapport de sauvegarde est l'un des nombreux. Vous pouvez trouver des rapports tels que :
- Rapport système quotidien
- Rapport de mise à niveau du package
- Rapport de modification de schéma
- Disponibilité
- Sauvegarde
Mais pourquoi en auriez-vous besoin ?
Vous disposez peut-être déjà d'un excellent outil de surveillance avec toutes les métriques/graphiques possibles et vous avez probablement également configuré des alertes basées sur des métriques et des seuils (certains auront même des conseillers automatisés leur fournissant des recommandations ou corrigeant les choses automatiquement.) C'est bien - avoir une visibilité sur votre le système est important ; néanmoins, vous devez être capable de traiter beaucoup d'informations.
Comment cela fonctionne-t-il ? ClusterControl collecte des informations sur le processus de sauvegarde, les systèmes, les plates-formes et les périphériques de l'infrastructure de sauvegarde lorsque la tâche de sauvegarde est déclenchée. Toutes ces informations sont agrégées et stockées dans une CMON (base de données interne), il n'est donc pas nécessaire d'interroger des bases de données particulières en plus. De plus, lorsqu'il découvre que vous avez un cluster en cours d'exécution, mais qu'il n'y a pas eu de sauvegarde, cela sera également signalé.
Dans les détails du rapport, vous pouvez suivre un ID de sauvegarde avec des données détaillées sur l'emplacement, la taille, l'heure et la méthode de sauvegarde. Les modèles fonctionnent avec des données pour différents types de bases de données. Ainsi, lorsque vous gérez votre environnement mixte, vous obtenez la même sensation et la même apparence. Cela aide à mieux gérer les différentes sauvegardes de bases de données.
Rapports CLI
Pour ceux qui préfèrent l'interface de ligne de commande, une bonne option pour suivre les sauvegardes ClusterControl Command Line Interface (CLI).
CLI vous permet d'exécuter la plupart des fonctions disponibles dans ClusterControl à l'aide de commandes simples. L'exécution de la sauvegarde et les rapports de sauvegarde en font partie.
Utilisé conjointement avec la puissante interface graphique, il offre aux utilisateurs de ClusterControl d'autres moyens de gérer leurs environnements de base de données open source à l'aide du moteur de leur choix.
$ s9s backup --list --cluster-id=1 --long --human-readable
ID CID STATE OWNER HOSTNAME CREATED SIZE FILENAME
1 1 COMPLETED dba 10.0.0.5 07:21:39 252K mysqldump_2017-05-09_072135_mysqldb.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:21:43 1014 mysqldump_2017-05-09_072135_schema.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:03 109M mysqldump_2017-05-09_072135_data.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:07 679 mysqldump_2017-05-09_072135_triggerseventsroutines.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:20 252K mysqldump_2017-05-09_073016_mysqldb.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:24 1014 mysqldump_2017-05-09_073016_schema.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:44 109M mysqldump_2017-05-09_073016_data.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:49 679 mysqldump_2017-05-09_073016_triggerseventsroutines.sql.gz
À partir de la version 1.4.1, le script d'installation installera automatiquement ce package sur le nœud ClusterControl. La CLI fait partie du package s9s-tools. Vous pouvez également l'installer séparément sur une machine différente pour gérer le cluster de bases de données à distance. Semblable à ClusterControl, il utilise une communication SSH sécurisée.
Vérification de sauvegarde automatique
Une sauvegarde n'est pas une sauvegarde si nous ne sommes pas en mesure de récupérer les données. La vérification des sauvegardes est quelque chose qui est généralement négligé par de nombreuses entreprises. Voyons comment ClusterControl peut automatiser la vérification des sauvegardes et éviter les mauvaises surprises.
Dans ClusterControl, sélectionnez votre cluster et accédez à la section "Sauvegarde", puis sélectionnez "Créer une sauvegarde".
La fonction de vérification automatique de la sauvegarde est disponible pour les sauvegardes planifiées, alors choisissons l'option "Planifier la sauvegarde".
Lors de la planification d'une sauvegarde, en plus de sélectionner les options courantes telles que la méthode ou le stockage, nous devons également spécifier la planification/la fréquence. Dans cet exemple, nous allons configurer la vérification de sauvegarde MySQL. Cependant, la même chose peut être obtenue pour les bases de données PostgreSQL et Timescale.
Lorsque la vérification de la sauvegarde est cochée, un autre onglet apparaîtra.
Ici, nous pouvons définir toutes les étapes nécessaires pour préparer l'environnement. Lorsque l'adresse IP est fournie, nous sommes prêts à planifier une telle sauvegarde. Chaque fois que la sauvegarde se termine, elle sera copiée dans un environnement de vérification de sauvegarde temporaire (option "restaurer la sauvegarde sur"). Après une actualisation réussie, vous verrez l'état de la vérification dans l'onglet du référentiel de sauvegarde.
Échec des exécutions de sauvegarde et des services d'intégration
Une autre option intéressante pour obtenir plus d'indices sur l'exécution de la sauvegarde consiste à utiliser les services d'intégration ClusterControl. Vous pouvez contrôler l'état d'exécution de la sauvegarde avec des services tiers.
L'intégration d'outils tiers vous permet d'automatiser les alertes avec d'autres systèmes populaires. Actuellement, ClusterControl prend en charge ServiceNow, PagerDuty, VictorOps, OpsGenie, Slack, Telegram et Webhooks.
Ci-dessous, nous pouvons voir un exemple d'intégration du canal Slack. Chaque fois qu'un événement de sauvegarde se produit, il apparaît dans le canal de mou.
Conclusion
Les sauvegardes sont obligatoires dans n'importe quel environnement. Ils vous aident à protéger vos données et sont au centre de tout scénario de reprise après sinistre. ClusterControl peut vous aider à automatiser le processus de sauvegarde de vos bases de données et, en cas de panne, à le restaurer en quelques clics. De plus, vous pouvez être sûr qu'ils sont exécutés avec succès et de manière fiable, de sorte qu'en cas de sinistre, vous ne perdrez pas vos données.