Re: Incremental and permission changes

Hi all, Rob, Andrea and Chris in particular,

Am 16.02.2026 um 23:01 schrieb Rob Gerber:
...
> 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).

the different hashing is a bit of a problem in my opinion, because we 
should automatically adjust to use whatever hash we have in the catalog.

> 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).

I've been experimenting with the Accurate = o option recently, and had 
somewhat mixed results. Also, I'm not 100% sure that I can predict what 
happens when I restore a file which has only had attributes backed up, 
not contents. Should all be safe, but I need to actually experiment, I 
think.

> 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!)*. 

I suspect that, for your CIFS mount, the criteria
p for permissions,
i for inodes,
n number of links
are simply not working as those are not metadata CIFS provides with the 
same semantics as POSIX.

> 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 same
> as in the verify= option below with the addition of the following options:*
> ==================
> I believed that 'accurate = pinso3' would work. It did not.

Ms3o is what I would use, and by the way, the signature should only be 
used if actually necessary, i.e. a size change would trigger a backup of 
the file data even before the signature is calculated. At least that's 
my recollection from a while ago.

> 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.

Reasonable conclusion :-)

> 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 believe there was some work done in this respect recently -- you could 
probably call it a bug fix, and Eric probably thought more about his 
goal than what he's starting from :-)

> I hope this helps.

this is definitely something where a more thorough documentation 
including examples / use cases would be helpful, too. But let's see what 
we get with version 17 and then we make it shiny by adding a manual 
chapter ;-)

In any case, thanks for sharing your experience!

Cheers,

Arno


> Regards,
> Robert Gerber
> 402-237-8692
> [email protected] <mailto:[email protected]>
-- 
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück



_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users