Restic detecting (non-existing?) changes result in long backup time

Getting Help
1

Hello all,

I’m new to restic and facing a performance issue. I searched but couldn’t quite find anything related to my current problem.

My setup is the following:

  • backing up a 250GB dataset stored on a mergerfs pool (fuse filesystem)
  • repo is stored “locally” on an nfs share
  • using the (excellent) restic-runner wrapper script

I’m experiencing the following performances (crontab result, running as root):

LOG (2019-04-01 01:30:01): REPO:main SET:photos COMMAND:backup LOG (2019-04-01 01:30:03): BACKING UP…
open repository

Files: 0 new, 60107 changed, 0 unmodified
Dirs: 0 new, 2 changed, 0 unmodified
Added to the repo: 1.067 KiB

processed 60107 files, 235.411 GiB in 24:37 snapshot 852c453c saved
date: invalid date ‘Mon 1 Apr 01:30:01 CEST 2019’
date: invalid date ‘Mon 1 Apr 01:54:42 CEST 2019’
/usr/local/bin/restic-runner: line 187: - : syntax error: operand expected (error token is "- ")
LOG (2019-04-01 01:54:42): backup FINISHED. Duration: Repo size: 170.273 GB (+30 MB)

As you can see, restic detects that every single file did change for some reason - probably metadata, even though nothing actually changed.

I think that this is the reason why it takes 30 minutes.

Is there a way for me to know why restic does detect a change?

Thanks a lot!

2

Is the filesystem mounted via fuse? I’m asking because if I recall correctly fuse based filesystems don’t preserve inodes. A --ignore-inode option has been added to the backup command but hasn’t been release yet. You could build restic yourself with this commit or use one of the binaries at beta.restic.net which do get built automatically.

1 Like
3

Absolutely! the mergerfs pool is a fuse filesystem.

Thanks I will try with a beta binary!