Hello everyone, I have run into a problem similar to the one Andrea and Chris are describing. I want to share what worked for me and a couple of tips to avoid problems.
In my case, I had 100TB of files with incorrect mtime and ctime stamps. I corrected those stamps from a mirror of those files (using a touch script). Bacula saw all the times change and recommended backing up the entire 100TB again. I knew the hashes of those files shouldn't have changed, so I experimented with the 'accurate' 'o' option flag. FYI, this is a strange NAS situation, where I only have access to the NAS appliance via SMBv3 (works better than you'd think), and permissions are fairly flat, and controlled by the NAS, not by my SMB client. So I only really care about backing up the files, and their modified dates. >From the bacula 13.x + manual, fileset 'accurate' option: ======================== o Save only the metadata of a file when possible (Available from version 13.0.0) . The ’o’ option should be used in conjunction with one of the signature checking options (1, 2, 3, or 5). When the option is specified, the signature is computed only for files that have one of the other accurate options specified triggering a backup of the file (for example an inode change, a permission change, etc...). In cases where only the file’s metadata has changed (ie: the signature is identical), only the file’s attributes will be backed up. If the file’s data has been changed (hence a different singature), the file will be backed up in the usual way ======================== In the end, I found: 1. I ultimately used 'accurate = Mo3'. 'M' means "check mtime and ctime". Anyone using this option should obviously select whichever hash algorithm they specified in 'signature=xyz' (or probably 5 for the default, md5). 2. I was previously using 'accurate = yes' for this fileset. When I changed the option to 'accurate = Mo3', this did not constitute a fileset change that would trigger a new full backup (so you don't have to turn on the potentially dangerous 'ignore fileset changes = yes' to avoid provoking a new full backup). 3. I used the 'estimate' command to verify whether bacula was going to do what I wanted, before running the job. Once I changed to use the accurate 'o' flag, the estimate processes took a very long time, because they had to hash all the files with changed metadata. I originally thought I'd use something like 'accurate = pinso3'* (this didn't work!)*. The bacula manual said: ================== accurate=<options> The options letters specified are used when running a Backup Level=Incremental/Differential in Accurate mode. *The options letters are the sameas in the verify= option below with the addition of the following options:* ================== I believed that 'accurate = pinso3' would work. It did not. The bacula director did not throw an error when I reloaded the config, BUT an estimate said I would have 100TB of files to back up, which tells me it did not work correctly. It did take several days to estimate, so I think it hashed the files. I changed the option to 'accurate = Mo3', and ran the estimate again. This time, bacula thought it would have to back up 30TB of files. This is the result I expected. I didn't check before making the mtime changes to my files, but it's pretty plausible that we could have had 30TB of new files on disk waiting for a backup. 4. Please note that in bconsole, the estimate command defaults to level=full. You need to specify level=incremental in order to see comparisons of how much data would be backed up in an incremental backup. 5. Eric posted some text from the manual about the 'accurate' 'o' feature. Towards the end he said "This feature will be available in the next 17.0 that is still cooking in our lab." 'Accurate = Mo3' is definitely working in bacula 13.x. I think right now the only options supported by this feature are 'M' or maybe 'mc' before 'o(hash algorithm). I think he means that bacula CE 17.x will support more expanded options like ’pinug2o’, not that the feature doesn't work at all in bacula CE right now. I hope this helps. Regards, Robert Gerber 402-237-8692 [email protected]
_______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
