[Borgbackup] (too) many modified files

[Thomas Waldmann]

>> https://borgbackup.readthedocs.io/en/stable/faq.html#why-is-backup-slow-for-me
>>
>> "Also, the --debug-topic=files_cache option of borg create provides a
>> lot of debug output helping to analyse why the files cache does not give
>> its expected high performance."


> there are two types of reportings in the log file. The first one 
> concerns to files that are probably changed, e.g.:
> 
>> UNKNOWN: no file metadata in cache for: 

No, that does not mean a changed file.
It is saying that it has no file metadata in the (files) cache.

So either that file has never been seen before and is therefore not in 
the files cache (new file).

Or, that file's metadata was intentionally not included into the files 
cache (see FAQ, files with newest timestamp in backup).

Or, that file's metadata already has "aged out" of the files cache (see 
FAQ, files cache TTL).

> The second type concerns to files that are for sure not touched for 
> years, e.g.:
> >> KNOWN-CHANGED: file ctime has changed: 
>> b'/home/boris/Dokumente/Sicherungen/Joerg/SAMSUNG_SP0842N_581230084282/I386/G711CODC.AX_'

The kernel / filesystem does not share your opinion:
That file HAS been touched, that is the reason why it has a modified 
ctime timestamp.

A modified ctime means that either the file metadata (like mode, owner, 
group, xattrs, ACLs, ...) OR the file content has changed.

If the file content had changed, that could be seen via an updated mtime 
(but borg does not log that if it is configured to look at ctime, which 
is the default).

> So maybe the Synology box does something like refreshing on it's own or 
> something similar, if this could lead to these effects -don't know. What 
> could cause this, and how to avoid? Or can I tell borg to ignore these 
> files?

I have no idea about what synology boxes might do behind the scenes.
But if the mtime did not change, but the ctime did, it is for sure a 
file metadata change (assuming that the kernel and fs works normally).

>> borg create -v --debug-topic=files_cache --files-cache=mtime,size 
>> --list --filter=AMCE --stats --show-rc -C zstd 
>> $CRYPTDIR/Boris::'{now:%Y-%m-%d_%H-%M}' /home/boris 

Ehrm, do you have this --files-cache=mtime,size since longer?

If so, ctime changes should not lead to files being detected as changed.

But, after switching --files-cache from default to that non-default 
value, you'll need one backup to update the files cache and another one 
to see the files cache operating normally again.

> If so, --files-cache=mtime,size should to the job?

Yes.

That doesn't solve the problem of your weird ctime of course, but stops 
using it. Using mtime is a bit less safe, as weird applications can set 
it to arbitrary values.