Evolution #7431
une erreur de sauvegarde d'une base de données mysql ne provoque pas d'erreur dans Bacula
Description
Par défaut, le script /usr/share/eole/schedule/pre/mysql s'arrete s'il rencontre une erreur quelconque lors de la sauvegarde d'une base, ce qui empêche les bases suivantes d'être sauvegardée. Est-il envisageable de modifier ce comportement risqué?
MAJ : le problème est plutôt que si une base de données MySQL génère une erreur lors du dump, Bacula termine quand même avec "Backup OK".
Demandes liées
Révisions associées
modification de la signalisation d'erreur en PreBackup FIXES #7431
affichage d'une diode rouge si Prebackup ou BackupCatalog plantent FIXES #7431
ajout du Prebackup dans les agents Zéphir FIXES #7431 @1h
schedule : modification de la gestion d'erreur FIXES #7431 @2h
ajout d'une diode pour la préparation de la sauvegarde FIXES #7431
correction de l'agent de sauvegarde FIXES #7431
modification de la gestion d'affichage des erreurs de sauvegarde FIXES #7431
modification de la gestion d'erreur de sauvegarde FIXES #7431
Historique
#1 Mis à jour par Joël Cuissinat il y a environ 10 ans
- Statut changé de Nouveau à A étudier
- Version cible mis à Mises à jour 2.3.13
- Temps estimé mis à 4.00 h
#2 Mis à jour par Klaas TJEBBES il y a environ 10 ans
- Statut changé de A étudier à Ne sera pas résolu
Ne pas s'arrêter sur une erreur de sauvegarde MySQL ferait que Bacula afficherait un "Backup OK" et donc l'EAD et l'agent Zéphir une diode verte comme si tout allait bien, ce qui est Faux.
Vu depuis Zephir aucune erreur, vue depuis l'EAD aucune erreur.
Les utilisateurs (certains administrant plusieurs dizaines/centaines de serveurs) n'ayant pas l'idée d'aller voir le contenu du fichier de log Bacula ne s’apercevraient jamais qu'une ou plusieurs bases MySQL ne sont pas sauvegardées. Et le jour où ils auraient besoin de les restaurer suite à un crash ils auront tout perdu.
Ne pas s'arrêter sur une erreur de sauvegarde MySQL est trop risqué. Aucune modification ne sera donc apportée au comportement actuel.
#3 Mis à jour par Jean-Marc MELET il y a environ 10 ans
Bien sûr ce que tu dis est pertinent, cependant dans les cas que l'on a pu constater, bacula n'a pas considéré les sauvegardes comme étant en erreur (je sais ça ne devrait pas être le cas) et un seul dump qui s'est mal passé pour je ne sais quelle raison a empêché la sauvegarde du reste des bases, cela est assez rare et peut se produire sûrement dans des cas assez particuliers mais lorsque cela arrive c'est risqué aussi.
Je te propose de reformuler la demande autrement:
Pourrait-on faire en sorte que tous les dumps soient toujours effectués et qu'on renvoie un status d'erreur à Bacula si au moins une erreur est rencontrée?
#4 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Le problème est que quand la sauvegarde d'une base MySQL plante, la commande
/usr/share/eole/schedule/pre/mysql
sort avec un code différent de 0, mais la sauvegarde Bacula continue quand même alors qu'elle devrait s'arrêter avec une erreur.
D'autre part, si erreur il y a, elle n'est loggée nul part, elle est uniquement envoyé par mail. Hors si aucun mail n'est renseigné dans la configuration Bacula, l'utilisateur n'a donc aucun moyen de le savoir.
#5 Mis à jour par Klaas TJEBBES il y a environ 10 ans
- Sujet changé de forcer la sauvegarde de toutes les bases de données mysql à une erreur de sauvegarde d'une base de données mysql ne provoque pas d'erreur dans Bacula
- Description mis à jour (diff)
- Statut changé de Ne sera pas résolu à À valider
- JobSchedulePre
- JobSauvegarde
Les bases MySQL sont dumpées dans "JobSchedulePre". Hors même si ce job termine en erreur, le "JobSauvegarde" se fait quand même et termine avec "Backup OK" et comme l'EAD et Zéphir se basent sur "JobSauvegarde" pour déterminer si une sauvegarde a réussi ou non, ils affichent sauvegarde réussie même si un dump MySQL a échoué.
#6 Mis à jour par Klaas TJEBBES il y a environ 10 ans
- Statut changé de À valider à Résolu
- % réalisé changé de 0 à 100
Appliqué par commit eole-bacula:2454841b6a87dd54279bf8d979f638d0b0b667a4.
#7 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Appliqué par commit ead:6cafabf97f02fcfb7cb4ea33c97fbde1922680c8.
#8 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Appliqué par commit zephir-client:8ca3808938be535df69252489f08153622d4018e.
#9 Mis à jour par Joël Cuissinat il y a environ 10 ans
- Echéance mis à 18/04/2014
- Assigné à mis à Klaas TJEBBES
#10 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Appliqué par commit creole:a08d81f3ac5a5a713b0affbe38411463b97b5999.
#11 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Appliqué par commit zephir-client:498d1a609d0b98c1ed62bc65d83e827531d25623.
#12 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Appliqué par commit zephir-client:ef46d3e7ca952ce782e8ce204b1165e2d147bdd2.
#13 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Appliqué par commit ead:dac2201d772bb16632a336d7d15eb010ae8a2402.
#14 Mis à jour par Klaas TJEBBES il y a environ 10 ans
Appliqué par commit eole-bacula:6f4d7e1faff89a912087081ae008d6cd13b87799.
#15 Mis à jour par Laurent Flori il y a presque 10 ans
- Statut changé de Résolu à Fermé