already saved file treated as new

[e-ferrari]

Have you checked borgbackup docs, FAQ, and open GitHub issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Question

Your borg version (borg -V).

1.2.4

Operating system (distribution) and version.

SLES 15 SP5

Hardware / network configuration, and filesystems used.

image files from vm's reside on a FC SAN with OCFS2 and are saved to a CIFS share (NetApp)

How much data is handled by borg?

~5TB

Full borg commandline that lead to the problem (leave away excludes and passwords)

create -v --debug-topic=files_cache --files-cache=mtime,size,inode --list --stats ::{now} repository

Describe the problem you're observing.

I'm saving each evening the image files from vm's to a CIFS NAS. I create snapshots from the vm's (in OCFS2 called reflinks) and the snapshots are saved via borg to a CIFS NAS.

For whatever reason a file which was saved before is now treated as not been in the file cache.

Here is the excerpt from my log:

One day before:

KNOWN-CHANGED: file mtime has changed: b'/mnt/domains/reflinks/vm_geneious-license-mcd.raw'
M /mnt/domains/reflinks/vm_geneious-license-mcd.raw
FILES-CACHE-UPDATE: put FileCacheEntry(age=0, inode=858797446, size=30000000000, cmtime=1699991999675344006, chunk_ids='[7611 entries]') [has mtime] <- b'/mnt/domains/reflinks/vm_geneious-license-mcd.raw'

Next day:

UNKNOWN: no file metadata in cache for: b'/mnt/domains/reflinks/vm_geneious-license-mcd.raw'
A /mnt/domains/reflinks/vm_geneious-license-mcd.raw
FILES-CACHE-UPDATE: put FileCacheEntry(age=0, inode=858797446, size=30000000000, cmtime=1700078399414387394, chunk_ids='[7696 entries]') [has mtime] <- b'/mnt/domains/reflinks/vm_geneious-license-mcd.raw'

Why is the file treated as new although it was saved the day before ?

Thanks.

Bernd

Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.

Include any warning/errors/backtraces from the system logs

[ThomasWaldmann]

The logs show some things:

• mtime changed from 1699991999675344006 to 1700078399414387394. that means that the file's content was modified.
• UNKNOWN: no file metadata in cache for: b'/mnt/domains/reflinks/vm_geneious-license-mcd.raw' - it seems that the files cache entry from previous day was not in the cache any more. see the faq about why this might be the case.
• On the previous day, it showed KNOWN-CHANGED - obviously that UNKNOWN problem did not happen on that day.
• at least the inode number was stable, so no issue related to that.

[ThomasWaldmann]

https://borgbackup.readthedocs.io/en/stable/faq.html#i-am-seeing-a-added-status-for-an-unchanged-file

https://borgbackup.readthedocs.io/en/stable/faq.html#it-always-chunks-all-my-files-even-unchanged-ones

[e-ferrari]

Hi, is there a chance to see the ttl value of a file ? Or is it the "age" we see in the log (FILES-CACHE-UPDATE: put FileCacheEntry**(age=0**, inode=858797446, ...) ?

Bernd

[e-ferrari]

Hi, is there a way to read the files cache ? It's a binary file ...

Bernd

[ThomasWaldmann]

The age starts with 0 (== fresh, 0 generations old) and increases per backup run. If a file is not seen, the age of its files cache entry increases. If age goes beyond max TTL, the cache entry is discarded.

BTW, there should be no need to look at the files cache contents, because the debug log already provides all information that could be seen.

[e-ferrari]

If it is not seen, its age increases. If age goes beyond max TTL, the cache entry is discarded.

"not seen" means not read, chunked and saved in the repository ? Let's assume a file isn't changed for some weeks. Every backup run it's TTL increments by 1. So, when it's not modified for 20 backup runs its entry is deleted from the cache ? But the file itself is not deleted. Will the chunks of that file be deleted ? And what happens on the 21. run ? It is seen as new, chunked and saved ? But because the chunks are already in the repository the backup of that file is very quick ?

Bernd

[ThomasWaldmann]

Not seen means it was not present in the source files of a backup run, e.g.:

• the file was deleted or moved elsewhere
• the backup run intentionally did not include that file as a source file
• the file's full path did not match (e.g. because the path of the mountpoint changed)

[ThomasWaldmann]

@e-ferrari could you solve your issue?