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".
Related issues
Associated revisions
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
History
#1 Updated by Joël Cuissinat over 9 years ago
- Status changed from Nouveau to A étudier
- Target version set to Mises à jour 2.3.13
- Estimated time set to 4.00 h
#2 Updated by Klaas TJEBBES over 9 years ago
- Status changed from A étudier to 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 Updated by Jean-Marc MELET over 9 years ago
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 Updated by Klaas TJEBBES over 9 years ago
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 Updated by Klaas TJEBBES over 9 years ago
- Subject changed from forcer la sauvegarde de toutes les bases de données mysql to une erreur de sauvegarde d'une base de données mysql ne provoque pas d'erreur dans Bacula
- Description updated (diff)
- Status changed from Ne sera pas résolu to À 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 Updated by Klaas TJEBBES over 9 years ago
- Status changed from À valider to Résolu
- % Done changed from 0 to 100
Appliqué par commit eole-bacula:2454841b6a87dd54279bf8d979f638d0b0b667a4.
#7 Updated by Klaas TJEBBES over 9 years ago
Appliqué par commit ead:6cafabf97f02fcfb7cb4ea33c97fbde1922680c8.
#8 Updated by Klaas TJEBBES over 9 years ago
Appliqué par commit zephir-client:8ca3808938be535df69252489f08153622d4018e.
#9 Updated by Joël Cuissinat over 9 years ago
- Due date set to 04/18/2014
- Assigned To set to Klaas TJEBBES
#10 Updated by Klaas TJEBBES over 9 years ago
Appliqué par commit creole:a08d81f3ac5a5a713b0affbe38411463b97b5999.
#11 Updated by Klaas TJEBBES over 9 years ago
Appliqué par commit zephir-client:498d1a609d0b98c1ed62bc65d83e827531d25623.
#12 Updated by Klaas TJEBBES over 9 years ago
Appliqué par commit zephir-client:ef46d3e7ca952ce782e8ce204b1165e2d147bdd2.
#13 Updated by Klaas TJEBBES over 9 years ago
Appliqué par commit ead:dac2201d772bb16632a336d7d15eb010ae8a2402.
#14 Updated by Klaas TJEBBES over 9 years ago
Appliqué par commit eole-bacula:6f4d7e1faff89a912087081ae008d6cd13b87799.
#15 Updated by Laurent Flori over 9 years ago
- Status changed from Résolu to Fermé