Hello,
I've been using bacula for a few years now to do backups to LTO tape.
Backups are pretty informal, but the general process is to do a full
backup every few months, and then weekly incrementals between full
backups. I am running linux here at home, mostly debian and variants at
the moment. The machine I'm backing up is debian 10, and the storage,
director, and file daemons all run on it. I have the version of bacula
that is in the debian repos, version 9.4.2. I understand it's a bit old
I've got accurate backup turned on for the job I'm running.
I notice that every once in a while, I'll have an incremental run that
seems to back up the entire file set with no regard to what files have
actually changed.
Firstly, has anybody else noticed this happening?
Secondly, I have done some investigation into this. The last time I
looked into this was a while ago, but I believe bacula uses the data
returned by the stat(2) system call on linux to check whether a file has
changed, moved, been deleted, renamed, etc. Stat(2) returns a stat
struct that includes various data like ctime, mtime, atime, etc. Most
importantly for my point, the device node information is also included
in the stat structure, a dev_t type.
I believe the last time I looked at this, I actually looked in the
bacula database to pull out the old stat2 data and compare it to one of
the files I believed to be unchanged. I will have to check my notes from
back then if I can find them, but I believe the only parameter that I
could see being changed was the dev_t entry. AKA, device major/minor
number pair.
I'm not sure where to look in the bacula source to see where it's
comparing file attributes to determine whether a file has changed, but
my suspicion is that bacula is comparing the major and minor device node
numbers. IF that's the case, I would believe that to be a flaw in
bacula's algorithm. Major and minor device node numbers are not
guaranteed to be constant between reboots, and can also change from
hotplug. In short, they are not persistent at all, and could conceivably
change despite the file having no real differences.
Now, if this is what's happening, the worst case is that you back up a
file that didn't change. Not the end of the world, but still an annoyance.
Hopefully somebody has seen the same thing, and hopefully somebody can
point me somewhere in the source to continue investigating this. Like I
said, it's not the end of the world, but it sure is annoying when I
start a backup and it takes orders of magnitude longer than I was
expecting (especially given that I have to function as a human tape
changer).
Thanks,
Joe Zatarski
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
