Same files are detected as modified

Hello,

I successfully wrote my first script and restic completed the initial backup :tada:

Files:       310699 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Data Blobs:  331856 new
Tree Blobs:      3 new
Added to the repo: 178.373 GiB
processed 310699 files, 210.085 GiB in 4:38:08

Then I ran it again and got this result

Files:           7 new, 205290 changed, 105407 unmodified
Dirs:            0 new,     2 changed,     0 unmodified
Data Blobs:    122 new
Tree Blobs:      3 new
Added to the repo: 138.297 MiB
processed 310704 files, 210.133 GiB in 1:42:25

I was very surprised about the long runtime since only a few files have changed on disk (~ 140 MB seems right) As you can see from the summary and the log is full of entries like:

modified  /mnt/windows-cifs/file1.txt, saved in 0.853s (0 B added)
modified  /mnt/windows-cifs/file2.jpg, saved in 0.853s (0 B added)

which means that restic detected lots of files as modified, read them and after dedup of course 0 bytes added. The problem is these files have not changed in years.

stat /mnt/windows-cifs/file1.txt

  Size: 2342946         Blocks: 4584       IO Block: 16384  regular file
Device: 10h/16d Inode: 281474976722819  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-02-08 18:51:54.502064100 +0100
Modify: 2009-12-24 20:43:48.000000000 +0100
Change: 2014-10-31 22:22:11.328678700 +0100

I have used this combination of mounted cifs network share (Windows) and dirvish (based on rsync) backup on Linux server for many years without a problem. Average backup time ~10 minutes.

What am I missing here?

Most likely the inode number is unstable, which is why restic keeps double checking the files.

Use --ignore-inode to avoid this check or make sure the file system retains it’s inodes.

3 Likes

@lukastribus awesome tip, that works perfectly!