Clean up for better speeds?

Hi,
I was wondering if someone could shed some light on the issue im having, Before restic on the same server i was getting these speeds in November

Files:        1416 new,   158 changed, 1264728 unmodified
Dirs:            0 new,     3 changed,     0 unmodified
Data Blobs:   3902 new
Tree Blobs:      4 new
Added to the repo: 3.122 GiB

processed 1266302 files, 649.958 GiB in 1:41:22
snapshot 2dbbedea saved
There are 6 exclusion rules...

But now im getting these speeds

Files:         365 new,   185 changed, 1277113 unmodified
Dirs:            0 new,     3 changed,     0 unmodified
Data Blobs:   1721 new
Tree Blobs:      4 new
Added to the repo: 1.443 GiB

processed 1277663 files, 677.480 GiB in 10:26:39
snapshot 692a5191 saved
There are 6 exclusion rules...

im not sure if its a cache issue? or because the repo data is pretty large now but not sure why there is an extra 9 hours

Thank you

Hi there,

Which backend you’re using? Also when was the last prune?

Hi there currently backend saving the restic files to a NAS the prune is every 24 hours

Which version of restic are you using on which operating system? The performance change around November could be related to the changed detection of modified files in restic 0.9.6 . On which file system is the data stored which you are backing up?
What is the exact command line you use to run restic?

In order to pretty much verify if the cause is the change from mtime to ctime for change detection, you can run the backup command with the --ignore-inode flag, just once for testing. If this runs with your “normal” duration, it might very well be it.

Then again, you could start by just telling us what versions you were running in november and now. If you haven’t upgraded, the mtime to ctime change isn’t the cause.

Thanks for the reply, what i ended up doing is to create another repo from zero and it started to work fast again 2-3 hours tops, same version 0.9.5

So you never used a version higher than 0.9.5?