On Fri, Dec 29, 2023, at 6:26 PM, Martin Simmons wrote:
>>>>>> On Fri, 29 Dec 2023 12:35:59 -0500, Dan Langille said:
>> 
>> On Fri, Dec 29, 2023, at 12:10 PM, Martin Simmons wrote:
>> > 9.6.6 certainly displayed them for me, so I suspect a config issue.
>> >
>> > The messages would be omitted if !notsaved is in the Messages resource (but
>> > they would still be counted as "Non-fatal FD errors" which makes it add 
>> > "with
>> > warnings" to the status).
>> >
>> > Maybe that changed in the client's bacula-fd.conf when you upgraded it?
>> 
>> That's a good idea.
>> 
>> [17:29 r730-01 dvl ~] % sudo ls -l /usr/local/etc/bacula/bacula-fd.conf
>> -rw-r-----  1 root bacula 1497 Feb 25  2023 
>> /usr/local/etc/bacula/bacula-fd.conf
>> 
>> [17:31 r730-01 dvl ~] % sudo md5 /usr/local/etc/bacula/bacula-fd.conf
>> MD5 (/usr/local/etc/bacula/bacula-fd.conf) = e41a7d835766f563253c0a93418a1c61
>> 
>> 
>> No change since February.
>> 
>> Let's look at snapshots taken before Dec 25, the date of the job in question.
>> 
>> [17:32 r730-01 dvl /.zfs/snapshot] % cd autosnap_2023-12-20_00:00:09_daily
>> [17:32 r730-01 dvl /.zfs/snapshot/autosnap_2023-12-20_00:00:09_daily] % sudo 
>> md5 usr/local/etc/bacula/bacula-fd.conf 
>> MD5 (usr/local/etc/bacula/bacula-fd.conf) = e41a7d835766f563253c0a93418a1c61
>> 
>> 
>> I'm confident this file has not changed.
>
> Hmm, looking at src/lib/message.h, I suspect this change broke version
> compatibility in the message filtering infrastructure:
>
> commit fd926fc4671b054234fd3d5957bc05d303d87763
> Author: Eric Bollengier <e...@baculasystems.com>
> Date:   Fri Nov 6 21:27:05 2020 +0100
>
>     Fix unexpected connection event sent by the FD when the Message 
> resource is not configured
>
> The problem is that the message types have been renumbered by moving M_EVENTS
> higher up, but messages sent to the Director from other daemons use the
> numeric value of the type so this is an incompatible change in the wire
> protocol.
>
> Dispite the date of this change, it looks like it first appeared in Bacula 13,
> so will cause problems if a Client < 13 sends a message to a Director >= 13 as
> in your case.

That is concerning. It means backups may be incomplete and you don't know it.

This has happened at home, and today I noticed it at $WORK.

It is no longer the case that versions can follow the rule:

  bacula-dir=bacula-sd>bacula-fd

That rule has been in effect as long as I've been associated with the project 
(about 20 years). Is there any possibility of this being fixed? Or is this 
change irrevocable?

If irrevocable, the users really need to be notified via an announcement. 
Clients must be upgraded or the risk of data loss is present. In my case, 
things I expected to be backed up were not being backed up. I could not tell 
because the warnings were not presented to me.

-- 
  Dan Langille
  d...@langille.org


_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to