Início / server / Perguntas / 994232
Accepted
Nikita Kipriyanov
Asked: 2019-12-04 22:53:12 +0800 CST

Trabalho BareOS BackupCatalog preso no Director como encerrado, RunAfterJob não foi executado

  • 772

Isso parece muito estranho. Eu uso o Bacula e agora o BareOS há mais de 10 anos, mas agora um sistema apresenta um comportamento estranho e não consigo descobrir por que e como corrigir.

Quando executa backups diários, funciona bem, até chegar ao trabalho BackupCatalog, que está configurado para ser executado após todo o resto.

Este trabalho parece ter sido finalizado com sucesso (JobStatus=T na list jobstabela):

*list jobs
...
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+
| JobId | Name          | Client       | StartTime           | Type | Level | JobFiles | JobBytes        | JobStatus |
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+
...
| 5,475 | BackupCatalog | kantor-fd    | 2019-12-04 02:56:40 | B    | F     |       21 |      27,364,860 | T         |
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+

No entanto, no messagesarquivo de log não vejo o resumo usual para este último trabalho. O arquivo de log termina assim:

19-Nov 02:32 kantor-dir JobId 5398: shell command: run BeforeJob "/usr/lib/bareos/scripts/make_catalog_backup.pl Kantor"
19-Nov 02:33 kantor-dir JobId 5398: Start Backup JobId 5398, Job=BackupCatalog.2019-11-18_23.10.00_10
19-Nov 02:33 kantor-dir JobId 5398: Using Device "FileStorage" to write.
19-Nov 02:33 kantor-sd JobId 5398: Volume "Kantor-2018-01-08_08:48:50" previously written, moving to end of data.
19-Nov 02:33 kantor-sd JobId 5398: Ready to append to end of Volume "Kantor-2018-01-08_08:48:50" size=4716094462
19-Nov 02:33 kantor-sd JobId 5398: Elapsed time=00:00:05, Transfer rate=5.663 M Bytes/second

E isso é tudo. Observe que o script RunAfterJob parece não ter sido executado. Mas se eu executá-lo manualmente, ele funciona (o arquivo de banco de dados do catálogo exportado é removido). No entanto, este não é o único trabalho com o script RunAfterJob.

Eu esperava que ele mostrasse algo assim no final. Todos os outros trabalhos têm:

19-Nov 02:32 kantor-dir JobId 5397: Bareos kantor-dir 16.2.6 (02Jun17):
  Build OS:               x86_64-pc-linux-gnu debian Debian GNU/Linux buster/sid
  JobId:                  5397
  Job:                    FTP.2019-11-18_23.05.00_09
...
  FD termination status:  OK
  SD termination status:  OK
  Termination:            Backup OK

19-Nov 02:32 kantor-dir JobId 5397: Begin pruning Jobs older than 1 month 10 days .
...

Além disso, o status do diretor parece estranho:

*status dir
kantor-dir Version: 16.2.6 (02 June 2017) x86_64-pc-linux-gnu debian Debian GNU/Linux buster/sid
Daemon started 03-Dec-19 11:10. Jobs: run=4, running=1 mode=0 db=mysql
 Heap: heap=135,168 smbytes=222,459 max_bytes=236,758 bufs=543 max_bufs=594

Scheduled Jobs:
...
====

Running Jobs:
Console connected at 04-Dec-19 09:03
 JobId Level   Name                       Status
======================================================================
  5475 Full    BackupCatalog.2019-12-03_23.10.00_08 has terminated
====

Terminated Jobs:

 JobId  Level    Files      Bytes   Status   Finished        Name 
====================================================================
...
  5471  Incr      6,591    7.499 G  OK       03-Dec-19 23:15 termsrv
  5472  Incr        427    11.37 G  OK       03-Dec-19 23:44 1C
  5473  Incr          3    3.198 G  OK       04-Dec-19 02:56 Oracle
  5474  Incr      5,797    2.600 G  OK       04-Dec-19 02:56 FTP


Client Initiated Connections (waiting for jobs):
...
====

ou seja, o referido trabalho listado nos "trabalhos em execução", mas diz que foi encerrado. Não está listado nos "trabalhos encerrados", como se o diretor ainda tivesse algo para terminar.

Ele ficou pendurado neste estado por seis horas. Também vejo alguma estranheza com os tempos (StartTime para ele na tabela e no arquivo de log difere em meia hora, porém, o sistema datee o MySQL select NOW();estão em sincronia).

Após a reinicialização do diretor, o status do diretor parece mais apropriado:

Running Jobs:
Console connected at 04-Dec-19 09:06
No Jobs running.
====
No Terminated Jobs.

Tudo isso começou há duas semanas. Se eu deixá-lo suspenso, todos os trabalhos agendados a seguir aguardarão indefinidamente por esse trabalho travado, ou seja, nenhum backup será executado.

Eu sinto que isso pode ser um problema com o script RunAfterJob deste trabalho, mas é um script enviado padrão. Se eu correr pela mão, funciona. A definição do trabalho em si também é enviada padrão, a única modificação é que adicionei compressão=GZIP no FileSet, mas faço isso sempre e isso nunca causou problemas.

O que procurar? Como consertar?

Atualizar:

O problema desapareceu. Não entendo, por quê. Os backups funcionam por pelo menos dois dias. Nada parece estar preso.

bareos

1 respostas

  1. Best Answer

    Parece que foi configurado para enviar arquivo de bootstrap por e-mail no final do backup no BackupCatalogtrabalho:

    Write Bootstrap = "|/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \" -s \"Bootstrap for Job %j\" root@localhost"

    Se o envio de e-mail no servidor não estiver configurado, ele ficará travado. Se o envio de e-mail foi obstruído, mas corrigido posteriormente fora do servidor, ele será desbloqueado repentinamente sem indicação visível do que mudou. Esse parece ser o meu caso.

    Ao remover isso Write Bootstrap, o problema é completamente evitado. (O trabalho gravará o arquivo de bootstrap local conforme configurado no modelo JobDefs-referenced DefaultJob.)

    Esta é uma deficiência no BareOS que não explica o que pode dar errado e não registra isso como o problema e vai além. Só trava. Isso é péssimo. Não é uma pena que também esteja configurado dessa maneira por padrão .

    • 0

relate perguntas