Anomalie #4282
Arrêt du service bacula-sd en cours de sauvegarde
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 plus de 11 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 plus de 11 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 11 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 environ 11 ans
- Version cible changé de Mises à jour 2.3.8 à Mises à jour 2.3.9
#5 Mis à jour par Luc Bourdot il y a environ 11 ans
- Version cible changé de Mises à jour 2.3.9 à 48
#6 Mis à jour par Klaas TJEBBES il y a presque 11 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 presque 11 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 presque 11 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 presque 11 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 presque 11 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 presque 11 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 presque 11 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 plus de 10 ans
- Statut changé de Résolu à Fermé