Prevously backed up files added again to backup even though they have not changed (or have they?)

[sunknudsen]

Hey,

I am using a Borg 1.4.0 client on macOS Sequoia to back up files to a Borg 1.2.8 server at rsync.net.

For a while now, I have noticed that many files have status A even through they have not changed (at least not intentionally) on the filesystem and have already been backed up.

Looking at Activity Monitor, it appears that little data is transferred while these files are processed… way more data is transferred when Borg processes newly created files.

Is anyone else noticing this? Perhaps I am doing something wrong.

Worried about the integrity of my backups.

Thanks for helping out,

Sun

[sunknudsen]

Btw, have read https://borgbackup.readthedocs.io/en/stable/faq.html#i-am-seeing-a-added-status-for-an-unchanged-file, but this doesn’t appear to be what I am experiencing.

The archive I am backing up contains over 12,000 files.

[sunknudsen]

Borg just finished backing up archive and running same command again without changing anything on filesytem results in one file having A status consistently (ran command multiple times).

[ThomasWaldmann]

@sunknudsen hey! :-)

What you described in last post sounds pretty much like what the FAQ entry from 2nd last post refers to.

First post is likely something else, maybe check the FAQ for the --files-cache debugging. A is a bit unusual if you say the file is unchanged, because A means a file not known to the files cache (the lookup into that cache is via the full absolute path in borg 1.x).

Do you back up multiple data sets using different borg invocations so you maybe have more different backups than the TTL of the files cache (IIRC also covered in FAQ)? That would explain a lot of A, because the cache entries maybe have exceeded the TTL in that case and thus are gone.

Don't think there is a reason to worry about integrity - even if something "failed" to work at best performance, I think it failed to the safe side.

[sunknudsen]

Hey @ThomasWaldmann!

Thanks for helping out and for Borg.

What you described in last post sounds pretty much like what the FAQ entry from 2nd last post refers to.

Interesting, that file is indeed the most recent file in the archive… does this mean that Borg will always show at least one A per run?

First post is likely something else, maybe check the FAQ for the --files-cache debugging. A is a bit unusual if you say the file is unchanged, because A means a file not known to the files cache (the lookup into that cache is via the full absolute path in borg 1.x).

Unfortunately, I cannot reproduce issue now that all these A files have been processed. Do you have a specific way I could troubleshoot this next time issue presents itself?

Do you back up multiple data sets using different borg invocations so you maybe have more different backups than the TTL of the files cache (IIRC also covered in FAQ)?

I have two datasets… one that backs up important files located on the internal disk of my Mac (using {user}-macbook-air-{now:%F-%H%M%S} prefix) and another that backs up my photo and video archive located on an external disk (using {user}-archive-{now:%F-%H%M%S} prefix).

Not sure I understand how the cache TTL works… what do you mean by “more different backups than the TTL of the files cache”?

I was somehow assuming that Borg would cache all files synced to remote. If this isn’t the case, that could explain why older entries are purged from cache and processed again.

Don't think there is a reason to worry about integrity - even if something "failed" to work at best performance, I think it failed to the safe side.

That’s reassuring, thanks. That said, would love to deterministically understand expected behaviour.

[ThomasWaldmann]

Yes, borg will always show at least one "A", see the FAQ.

Debugging the files cache: https://borgbackup.readthedocs.io/en/1.4.0/faq.html#why-is-backup-slow-for-me - use the --debug --debug-topic=files-cache options.

2 datasets is not a problem, the TTL is much higher (20?). borg can't keep an infinite files cache of all files it has ever seen, thus this memory is limited to the last <TTL> borg runs. You will usually only notice this if you have more datasets (different borg create invocations) than the TTL.

[sunknudsen]

Yes, borg will always show at least one "A", see the FAQ.

👍

Debugging the files cache: https://borgbackup.readthedocs.io/en/1.4.0/faq.html#why-is-backup-slow-for-me - use the --debug --debug-topic=files-cache options.

👍

You will usually only notice this if you have more datasets (different borg create invocations) than the TTL.

Say I run {user}-macbook-air more than 20 times in a row and then run {user}-archive, will previous runs of {user}-macbook-air have exhausted cache triggering removal of {user}-archive files from cache triggering the A behaviour I experienced (file processed with A status while not being uploaded to remote given identical chunks)?

Referring to docs:

Every time you do a backup (on the same machine, using the same user), the cache entries’ ttl values of files that were not “seen” are incremented by 1 and if they reach BORG_FILES_CACHE_TTL, the entry is removed from the cache.

I perhaps misunderstood “not seen” as deleted on the client… not seen means file is not part the paths provided to borg create in the past run (and when this occurs 20 times, file is removed from cache)?

[ThomasWaldmann]

Hmm, yeah guess it doesn't need many different datasets to produce this problem, it is already sufficient if you have a few and run N-1 of them often enough to get the entries of the remaining dataset dropped from the files cache due to exceeding the TTL.

"not seen" can be either because it is deleted or because it is not part of the data set.

[sunknudsen]

Curious, if TTL applies per file, backing up one dataset often (more than 20 times) and another once in a while (once per 20+ runs of frequent dataset) would trigger this even if number of files in frequent dataset is low (while total files in cache could be low if both datasets have low file counts)?

Very appreciative of Borg as-is and I realize that suggestions can be naive and/or overwhelming so just dropping this here for reference purposes… using an alternative to file TTL equivalent to a queue could perhaps solve this problem implementing a max cache size rather than TTL per file.

When cache size is maxed out, oldest file in “queue” could be dropped.

[ThomasWaldmann]

in borg2, the files cache name will be derived from the backup series name, so each dataset has its own files cache.

[sunknudsen]

Thanks for helping out @ThomasWaldmann.