I’ve Nextcloud running in a (Snap) container. To do a backup I export the entire data to outside the container (all on an ext4 file system), run Restic (0.17.3) on it and throw the export folder away. On every subsequent run Restic indentifies all files and directories in the export folder as changed, because certainly all inodes have changed. I tried --ignore-inode with no success. I wonder what else may have changed on the files and folders or what’s my misconception with --ignore-inode? I’ve already read a few even very similar topics here but found no solution. How else can I achieve that only those files and folders that really have changed get saved?
Only truly changed data is saved (thx to deduplication). Worst case restic does have to scan everything again to check for changes.
Problem might be with your “export” step - if for example files/directories’ timestamps change then they are treated as potentially new data.
To investigate it further get some sample data and compare in subsequent exports - should tell you where the issue is.
But as said already it is not the end of the world - restic will scan everything if not sure and will save only changed data anyway. Only downside is that it takes longer to run backup.
thanks a lot for your reply. Of course I’ve tested with a smaller bunch of test data (~500 MB) which I’ve just copied to the export folder. And of course I can see that not all files are stored again. In case of a real 10 GB backup, Restic initially added ~5,5 GB to the repo (which is neat ), the subsequent run only added ~13 MB to it. I’ll investigate further and try Restic’s diff tool/command. In the end it’s just a little pity that the summary tells that all files/folders have changed, so I’ll never see the actual happenings.
I did subsequent Restic backup, knowing that 5 files are new and 1 has changed. Restic’s summary claims that all files and folders have changed. Restic diff instead correctly reports 5 files changed and 1 new. Is the backup summary just wrong/misleading? And after thinking for a while I still wonder what --ignore-inode does, if it doesn’t ignore the inode.
On Unix (including Linux and Mac), given that a file lives at the same location as a file in a previous backup, the following file metadata attributes have to match for its contents to be presumed unchanged:
Modification timestamp (mtime).
Metadata change timestamp (ctime).
File size.
Inode number (internal number used to reference a file in a filesystem).
So did you investigate the dates of your “export” files as @kapitainsky suggested?
What is your issue in the current situation, the reporting?
You may have to change your “export” step and/or have restic directly read the container content. Or script some post processing based on restic diff to get you the information you want.
thanks for your reply. It’s very likely that the file times changed, but since I neither have any influence on the export result nor can/want just let Restic read the container content, I didn’t investigate any further. When I started with the backup the result was unexpected, but now I’m happy with how it works and Restic’s diff tells me what I want to know.
), the subsequent run only added ~13 MB to it. I’ll investigate further and try Restic’s diff tool/command. In the end it’s just a little pity that the summary tells that all files/folders have changed, so I’ll never see the actual happenings.