On 2020-09-30 12:32, Radosław Korzeniewski wrote:
Hello,
Radosław, I apologize, it seems that I have sent the message to you
directly instead of sending it to the mailing list.
It happens sometimes when I use my webmail and forget that I need
to send the response to the mailing list.
śr., 30 wrz 2020 o 12:01 <djosip+n...@linuxpages.net> napisał(a):
> No, SD does not handle this kind of messages. It is a Director
> responsibility only.
Yes but if you check the messages I have pasted, you will see that
the message lines cover only the tasks covered by Storage daemon
such as spooling, despooling and probably all other Storage specific
tasks not shown in my example.
Message lines show that they were generated by the Storage daemon
and most probably sent to the Director which does whatever is needed
with those messages.
In this case, instead of combining them, it decides to relay them to
the configured e-mail addresses.
I don't think so.
From what I understood, all Bacula daemons have their own message
handlers but by default it is convenient for people to send messages
back to the Director where they get combined into a single report
message for the related Job.
For a standard job, yes. For a copied job, no.
Apparently but why would there be a difference?
Is it a deliberate decision or slight oversight in the source?
And indeed, messages in the second e-mail which correspond to the
original Job seems to be sent by the Storage daemon.
It is technically impossible as SD does not store job termination
status
messages for the original job. So it cannot send it to the user. These
messages are stored in the catalog and simply copied by the Director
during
copy job execution.
Storage daemon sends it to the Director which sends it to the user
after it combines the messages if it finds the corresponding Job IDs.
The messages in the Catalog are not stored by the Storage daemon and
as far as I know, they are not used for anything else but for manual
browsing by some tools like BAT.
Storage daemon does not make a connection to the database, only
Bacula Dir can do that.
Additionally, those logs in the Catalog are getting stored in the
Catalog only in case one is using Postgres. In case of MySQL the log
table is empty.
I am currently using Postgres but when I used MySQL Bacula behaved
exactly the same (in regard to the issue we are discussing here)
except the log table was empty.
Here is the example of one such additional e-mail message:
30-Sep 06:18 bkp1-dir JobId 5132: Using Device "tape1-dev1" to write.
30-Sep 06:18 bkp1-sd JobId 5132: Spooling data ...
30-Sep 06:21 bkp1-sd JobId 5132: Committing spooled data to Volume
"tapevol-0011". Despooling 901,424,162 bytes ...
30-Sep 06:21 bkp1-sd JobId 5132: Despooling elapsed time = 00:00:05,
Transfer rate = 180.2 M Bytes/second
30-Sep 06:21 bkp1-sd JobId 5132: Elapsed time=00:02:16, Transfer
rate=6.621 M Bytes/second
30-Sep 06:21 bkp1-sd JobId 5132: Sending spooled attrs to the
Director.
Despooling 580 bytes ...
Is it an original job message or a copy job message? What job ids are
for
an original job and its clone? Could you check, please. You have to
distinguish between an original backup job message and message
generated during copy.
The original (normal Full Backup) job ID was: 4997
The ID of the first Copy job which started the copy was 4999
The ID that actually copied JobID 4997 from disk to tape was 5132
That Job 5132 was the one whose messages are getting sent in the
separate e-mail message and I believe it would make more sense if
its messages would be combined with the messages that belong to the
job with the JobID 4999 which started it.
They ended in the approximately the same time: 06:21
Prev Backup JobId: 4997
New Backup JobId: 5132
Current JobId: 4999
which is ok.
That job was the last one so I have checked another one just to check
that everything looks as it should because the Copy job with the ID
of 4997 is the first Copy job which also processes he Selection Type
directive from the Job configuration.
So, the IDs of another job:
The original (normal Full Backup) job ID was: 4996
The ID of the first Copy job which started the copy was 5130
The ID that actually copied JobID 4997 from disk to tape was 5131
They ended in the approximatelly the same time: 06:18
In the message it says:
Prev Backup JobId: 4996
New Backup JobId: 5131
Current JobId: 5130
which all correct and expected.
I dislike using ugly workarounds and I would either solve it in the
Bacula configuration or look into devising a patch that solves the
problem properly.
I'm not sure if Bacula has configuration parameters with this kind of
behavior.
I also think there is no way it could be solved in the configuration
but I wanted to ask anyway, in case I missed something.
It was some time since I looked into the Bacula relations in the
database but I am sure it can be fixed in the source, probably using
the "priorjobid/priorjob" column in catalog as you said.
I am not 100% sure if those messages should be combined (it looks
like it would be a good idea) but I was hoping for a solution
including
Bacula configuration so that we don't have to look into the source.
I think Kern should elaborate on how he designed this functionality.
I hope he will notice this message and find some time to respond.
Bacula is huge and complex project.
Regards!
--
Josip Deanovic
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
