Anomalie #4282
Arrêt du service bacula-sd en cours de sauvegarde
100%
Description
Bonjour,
Sur nos horus 2.3, j'ai le service bacula qui s'arrête en pleine sauvegarde.
Avez vous une idée ce qui peut être la cause de l'arrêt du service bacula-sd ?
Pour le moment, ce que je fais pour ne pas bloquer les sauvegardes, c'est de supprimer le verrou bacula (/var/lock/eolesauvegarde), mais cela devient récurrent :-(.
Extrait de /var/log/rsyslog/local/bacula-dir/bacula-dir.err.log :
...
13-Oct 22:10 127.0.0.1-sd JobId 21: New volume "127.0.0.1-dir-full-0026" mounted on device "FileStorage" (/mnt/sauvegardes) at 13-Oct-2012 22:10.
13-Oct 22:12 127.0.0.1-sd JobId 21: User defined maximum volume capacity 2,000,000,000 exceeded on device "FileStorage" (/mnt/sauvegardes).
13-Oct 22:12 127.0.0.1-sd JobId 21: End of medium on Volume "127.0.0.1-dir-full-0026" Bytes=1,999,936,695 Blocks=31,001 at 13-Oct-2012 22:12.
13-Oct 22:12 127.0.0.1-fd JobId 21: Fatal error: backup.c:1019 Network send error to SD. ERR=Broken pipe
13-Oct 22:12 127.0.0.1-sd JobId 21: JobId=21 Job="JobSauvegarde.2012-10-13_22.00.00_54" marked to be canceled.
13-Oct 22:12 127.0.0.1-dir JobId 21: Error: Bacula 127.0.0.1-dir 5.0.1 (24Feb10): 13-Oct-2012 22:12:24
...
extrait de /var/log/rsyslog/local/bacula-sd/bacula-sd.err.log :
...
Oct 12 01:56:39 horus bacula-sd: Shutting down Bacula service: 127.0.0.1-sd ...
Oct 13 22:12:14 horus bacula-sd: Shutting down Bacula service: 127.0.0.1-sd ...
...
Cordialement,
Yoni
Demandes liées
Révisions associées
L'interruption de connexion peut être la cause des broken pipe.
- bacula-dir.conf : option Heartbeat Interval à 10 s pour que le
director maintienne artificiellement la connexion en la ravivant
toutes les dix secondes.
- bacula-fd.conf : option Heartbeat Interval à 10 s pour que le
fd recontacte le director si il n'a pas eu de nouvelles depuis
dix secondes.
Ref #4282
Subordonner le démontage du support à un job particulier.
Le volume en cours d'utilisation par bacula-sd est passé en
argument de la fonction démontant le support. Le démontage ne sera
effectué que si ce volume a un nom spécifique.
Le test du support n'est plus effectué au moment de la pose du verrou.
Ce test était effectué par le client bacula-fd, potentiellement sur
une machine différente que bacula-sd.
Ref #4282
Historique
#1 Mis à jour par Yoni Baude il y a presque 14 ans
- Version cible changé de Mises à jour 2.3.7 Stable à Mises à jour 2.3.7 RC
#2 Mis à jour par Fabrice Barconnière il y a presque 14 ans
- Statut changé de Nouveau à En attente d'informations
- Version cible changé de Mises à jour 2.3.7 RC à Mises à jour 2.3.8
On n'arrive pas à reproduire le problème (plusieurs raisons combinées).
#3 Mis à jour par Benjamin Bohard il y a plus de 13 ans
L'erreur
broken pipeest assez dure à diagnostiquer.
L'ajout de l'option
Heartbeat Intervaldoit permettre d'exclure la variable interruption de connexion de l'équation.
#4 Mis à jour par Joël Cuissinat il y a plus de 13 ans
- Version cible changé de Mises à jour 2.3.8 à Mises à jour 2.3.9
#5 Mis à jour par Luc Bourdot il y a plus de 13 ans
- Version cible changé de Mises à jour 2.3.9 à 48
#6 Mis à jour par Klaas TJEBBES il y a plus de 13 ans
Ajout de l'option "Heartbeat Interval = 300" aux endroits indiqués par le dev Bacula :
http://dev-eole.ac-dijon.fr/projects/eole-bacula/repository/revisions/1a34940b6cec0f37eb1ad83ef879ea7375e43629
#7 Mis à jour par Yoni Baude il y a plus de 13 ans
- Statut changé de En attente d'informations à Nouveau
- Version cible changé de 48 à Mises à jour 2.3.10
L'ajout de l'option "Heartbeat Interval = 300" ne règle pas les problèmes "Broken Pipe".
Sur Caen, nous testons les sauvegardes avec un montage manuel des volumes. Les premiers tests sont plutôt concluant, 2 semaines de suite sans d'erreur "broken pipe", reste à voir comment modifier la conf de bacula pour ne pas rester en mode manuel.
Exemple d'une procédure pour le mode manuel :
- Activation de la configuration manuel
=> /usr/share/eole/bacula/baculaconfig.py -a --support=manual
- Création du fichier /usr/share/eole/schedule/pre/mount
#!/bin/bash
/bin/mount /dev/disk/by-uuid/<$uuid> /mnt/sauvegardes
- Création du fichier /usr/share/eole/schedule/post/umount
#!/bin/bash
/bin/umount /mnt/sauvegardes
- Rendre exécutable les fichiers
=> chmod +x /usr/share/eole/schedule/pre/mount
=> chmod +x /usr/share/eole/schedule/post/umount
- Activation du montage/démontage du disque dur externe
=> /usr/share/eole/schedule/manage_schedule pre mount daily add
=> /usr/share/eole/schedule/manage_schedule post umount daily add
Pour compléter l'exemple, le gestionnaire de tâche d'eole1 est utilisé bien sûr pour les sauvegardes programmées de bacula mais aussi lors des sauvegardes instantanées.
[1] http://eoleng.ac-dijon.fr/documentations/2.3/partielles/HTML/EOLE/co/09a-schedule.html
Cordialement,
Yoni Baude
DSI5-RAIP
Rectorat de Caen
#8 Mis à jour par équipe eole Academie d'Orléans-Tours il y a environ 13 ans
En ayant voulu mettre en place cette méthode avec deux scribes 2.3, j'ai constaté que bacula passait en timeout :
> 10-Jul 11:03 127.0.0.1-dir JobId 1550: Warning: FileSet MD5 digest not found. > 10-Jul 11:03 127.0.0.1-dir JobId 1550: Start Backup JobId 1550, Job=JobSchedulePre.2013-07-10_11.03.08_51 > 10-Jul 11:03 127.0.0.1-dir JobId 1550: Using Device "FileStorage" > 10-Jul 11:03 127.0.0.1-fd JobId 1550: shell command: run ClientRunBeforeJob "/usr/share/eole/schedule/schedule_bacula pre"
[le temps d'attente est ici, environ 30mn comme le montre les logs]
> 10-Jul 11:31 127.0.0.1-fd JobId 1550: shell command: run ClientRunBeforeJob "/usr/share/eole/bacula/baculaconfig.py --lock --backup_progress --jobType=cron" > 10-Jul 11:31 127.0.0.1-sd JobId 1550: Job JobSchedulePre.2013-07-10_11.03.08_51 is waiting. Cannot find any appendable volumes. > Please use the "label" command to create a new Volume for: > Storage: "FileStorage" (/mnt/sauvegardes) > Pool: PoolDefault > Media type: File > 10-Jul 11:41 127.0.0.1-dir JobId 0: 2001 Job JobSchedulePre.2013-07-10_11.03.08_51 marked to be canceled. > 10-Jul 11:41 127.0.0.1-sd JobId 1550: JobId=1550 Job="JobSchedulePre.2013-07-10_11.03.08_51" marked to be canceled. > 10-Jul 11:41 127.0.0.1-sd JobId 1550: Job JobSchedulePre.2013-07-10_11.03.08_51 canceled while waiting for mount on Storage Device ""FileStorage" (/mnt/sauvegardes)". > 10-Jul 11:41 127.0.0.1-dir JobId 0: 3000 Job JobSchedulePre.2013-07-10_11.03.08_51 marked to be canceled. > 10-Jul 11:41 127.0.0.1-dir JobId 1550: Fatal error: Max wait time exceeded. Job canceled.
Et en effet, sur mes scribes, l’exécution seule de /usr/share/eole/schedule/schedule_bacula pre prends environ 30mn à chaque essais.
Si l'on lance à la main le script de montage durant ce temps d'attente, bacula continue sans soucis.
D'après les tests que j'ai pu faire, il semble que les appels aux scripts dans /usr/share/eole/schedule/daily/pre/ se font par ordre alphabétique car en renommant le lien symbolique /usr/share/eole/schedule/daily/pre/mount créé par la commande /usr/share/eole/schedule/manage_schedule pre mount daily add en /usr/share/eole/schedule/daily/pre/0mount, le montage du partage est immédiat suite à l’exécution de /usr/share/eole/schedule/schedule_bacula pre.
Je propose donc dans la procédure donnée par Yoni de renommer /usr/share/eole/schedule/pre/mount en /usr/share/eole/schedule/pre/00-mount par exemple.
Je ne sais pas pourquoi l’exécution de /usr/share/eole/schedule/schedule_bacula pre est si longue sur les scribes en test et que je suis le 1er à être gêné par cet ordre d’exécution...
Pour info :
/usr/share/eole/schedule/manage_schedule pre
activate script: [('daily', 'cron-trash'), ('daily', 'mount'), ('daily', 'annuaire'), ('daily', 'fichier'), ('daily', 'mysql'), ('daily', 'cron-clamav')]
#9 Mis à jour par équipe eole Academie d'Orléans-Tours il y a environ 13 ans
Ignorer mon post en #8...
Vu sur l'irc avec Icephale, un problème de volume utilisé par le job baculaschedulpre sur mon 1er scribe, et la lenteur des schedules "pre" sur l'ensemble des scribes m'a fait penser à ce problème de montage, mais il n'en n'est rien.
Le montage, même à la fin de "/usr/share/eole/schedule/schedule_bacula pre" se fait avant que la sauvegarde débute...
Pour Orléans la modification de Yoni en #7 est donc fonctionnelle, la commande de montage est à adapter suivant si on a un disque local ou un partage distant.
Exemple de notre partage :
#!/bin/bash /bin/mount //<ip_nas>/savbacula/ /mnt/sauvegardes -o credentials=/root/.nas -o uid=bacula
Je vais regarder si ça évite les broken pipe sur la durée chez nous.
#10 Mis à jour par Benjamin Bohard il y a environ 13 ans
- Statut changé de Nouveau à Accepté
- Assigné à mis à Benjamin Bohard
La solution expérimentée par Yoni (entre autres), gestion du montage et du démontage du support en local, n'est fonctionnelle que si le service bacula-sd est sur la même machine que le service bacula-director.
Sa mise en place va apporter une contrainte pour les autres types d'infrastructure : la nécessité de disposer d'un montage permanent pour les sauvegardes sur la machine distante hébergeant le service bacula-sd ou de s'assurer du montage par d'autres moyens que les outils EOLE.
#11 Mis à jour par Joël Cuissinat il y a environ 13 ans
- Statut changé de Accepté à Résolu
- Début
15/10/2012supprimé - % réalisé changé de 0 à 100
Solution poussée, en attente de retour d'expérience :
root@scribe:~# grep Heartbeat /etc/bacula/* /etc/bacula/bacula-dir.conf: Heartbeat Interval = 300 /etc/bacula/bacula-dir.conf: Heartbeat Interval = 300 /etc/bacula/bacula-fd.conf: Heartbeat Interval = 300 /etc/bacula/bacula-sd.conf: Heartbeat Interval = 300
#12 Mis à jour par Benjamin Bohard il y a environ 13 ans
- configuration du support manuelle du point de vue de bacula, montage et démontage en RunBeforeJob et RunAfterJob ;
- dans le cas de l'utilisation d'un sd distant, démontage uniquement à la fin du job.
Appliqué par les commits c87f86ba952dde60105f1f1fa15ed6007ef55565, 3677dd0a5d6653dc62972e9b56037f745214dbc5, 65f194be4566f0aa68fe6c783ce5999cd5fcfec5 et 722e8ddf5c8030b1de516bef2b54a1a406af1929
#13 Mis à jour par Joël Cuissinat il y a environ 13 ans
- Statut changé de Résolu à Fermé