On Sunday 2021-05-23 11:53:25 Joseph Zatarski wrote: > In response to Bill, Phil, and Josip, I have checked the logs to be > sure and the job is not being upgraded to full. I can't say for > certain that the files haven't been touched by anything, but I'll be > checking some attributes and doing some comparisons between what bacula > has in the DB for those files, and what they are on disk. I believe > last time I did such a thing, I came to the conclusion that the only > difference I saw was in the device number field of the stat(2) > attribute blob. I'll follow up again once I've looked at it.
So, if Bacula didn't upgrade incremental job to a full backup job and you only got suspiciously large backup, I would suspect that problem lays somewhere else. I had to check your original post to refresh my memory. You asked about the change of the device number of the storage device... I am pretty sure it doesn't affect Bacula and the way it determines which files differ from those already backed up. Bacula deals with files and directories that reside on the file system you have decided to backup and it doesn't check the device numbers of the underlaying device. But the fact that you have noticed unreasonably large amount of files retrieved by the incremental job might mean that something else is changing "attributes" of the files. Here are few things you might wan to consider: - Are you using normal file system (e.g. ext4, xfs) or some experimental file system? - Is the OS you are trying to backup hardware machine or virtual machine? - Is your system time correct and your ntpd/chronyd properly configured. Bacula is trying to take into account the time difference between server and client but still, it's worth checking the system time. You might also want to manually synchronize your hardware clock with your system clock using the command "hwclock -w" in case it is not regularly performed. - What kind of data are getting copied by the job? Are we talking about the files that belong to OS or some custom user data? - If the data that get copied belong to the OS than it would be a good thing to check if there were some unattended upgrades before the backup. - Also, prelinking (in case it's turned on and forced to run) could modify large number of system files. - Are you using selinux or some other subsystem or tools that could trigger a change of large number of files? - Have you noticed any warnings or errors in your logs and dmesg output lately? - Have you noticed any corrupted files or databases on that file system you are trying to backup? > It would also be useful to know what the default options are for the > "Accurate = " flags in the fileset. Unfortunately, I don't see any > listing of default options in the documentation, beyond when they > implemented the feature and it pops up in the change summary sections. > At least back then, it was mtime, ctime, and file size. I'll have to > work on the assumption that it has not changed since then. In the Bacula documentation of version 5..0.x https://www.bacula.org/5.0.x-manuals/en/main/main.pdf in section 4.5 it says: -----BEGIN---- In previous versions, the accurate code used the file creation and modification times to determine if a file was modified or not. Now you can specify which attributes to use (time, size, checksum, permission, owner, group, . . . ), similar to the Verify options. -----END----- -- Josip Deanovic _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
