On Tue, Jan 23, 2024, at 11:16 AM, Martin Simmons wrote: >>>>>> On Wed, 17 Jan 2024 09:54:23 -0500, Dan Langille said: >> >> 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? > > The change to the numbering is probably irrevocable (changing it back would > create a new set of incompatibilities), but some hack might be possible using > the jcr->FDVersion. > > >> 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. > > I suggest you create a bug report about it at > https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/issues > so it can tracked.
And there we go: https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/issues/2704 -- Dan Langille d...@langille.org _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
