>>>>> 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. _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
