You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[The borg user asking copied existing data to a new filesystem.]
Should I move to "--files-cache=mtime,size,inode" (Modify) to avoid long initial backup times when I resume my daily backups over ssh?
The problem is that ctime and inode number of all files have changed due to the copying to a new filesystem.
So, what's left is only "size", which [if it is the only criteria used] is rather weak.
If you are absolutely sure that all the files are identical as before (so even a weak "--files-cache=size" would be no problem), you could use that for the first backup.
Note: it is also important that the absolute paths of the files do not change.
The code there deals with a change of the inode number in case of "cache hits" (read the comment above that line).
It does not deal with the ctime change though, but we could think about whether it makes sense to add some "C" and "M" modes that ignore the ctime/mtime for change detection, but update the cmtime value in the cache to either the current ctime ("C") or the current mtime ("M") of the file. With that, the 2nd backup from the new filesystem could go back to the usual --files-cache=size,ctime,inode without triggering a full backup.
Sadly, without that change and in a situation like yours, you could not enable ctime/mtime for change detection without triggering a full backup, but only --files-cache=inode,size (which also is a bit weak).
The text was updated successfully, but these errors were encountered:
As a side note: C and M options are only needed because we need to decide whether to update ctime or mtime, so it is not as easy as with the existing code for the inode number.
From a mailing list post of mine:
[The borg user asking copied existing data to a new filesystem.]
The problem is that ctime and inode number of all files have changed due to the copying to a new filesystem.
So, what's left is only "size", which [if it is the only criteria used] is rather weak.
If you are absolutely sure that all the files are identical as before (so even a weak "--files-cache=size" would be no problem), you could use that for the first backup.
Note: it is also important that the absolute paths of the files do not change.
https://github.com/borgbackup/borg/blob/1.1.9/src/borg/cache.py#L970
The code there deals with a change of the inode number in case of "cache hits" (read the comment above that line).
It does not deal with the ctime change though, but we could think about whether it makes sense to add some "C" and "M" modes that ignore the ctime/mtime for change detection, but update the cmtime value in the cache to either the current ctime ("C") or the current mtime ("M") of the file. With that, the 2nd backup from the new filesystem could go back to the usual --files-cache=size,ctime,inode without triggering a full backup.
Sadly, without that change and in a situation like yours, you could not enable ctime/mtime for change detection without triggering a full backup, but only --files-cache=inode,size (which also is a bit weak).
The text was updated successfully, but these errors were encountered: