Skip to content

Very slow backup of SSHFS filesystems -- need ability to skip inode-based comparison #1631

@McKael

Description

@McKael

Output of restic version

restic 0.8.2

How did you run restic exactly?

% restic -r /tmp/restictest backup $SSHFSMOUNT/directory

The backup directory is a sshfs mounted filesystem.
The command is run several times to do several snapshots.
In mly case there is a huge amount of data (1TB+) in the remote directory.

What backend/server/service did you use to store the repository?

Local ext4 filesystem.

Expected behavior

I expect the first backup to be slow and transfer much data over LAN, while the next backups should be pretty fast and should not use much bandwidth.

Actual behavior

All backups take hours (if not days) even if no files have changed.

Steps to reproduce the behavior

  • run a backup
  • unmount sshfs filesystem
  • re-mount sshfs filesystem
  • run a new backup

It is not 100% reproducible but even with a small amount of data I could reproduce it.

The SFTP serrver logs show that files are completely retrieved even when they did not change.

Do you have any idea what may have caused this?

Yes: restic compares inodes to double-check if files have been modified (debug message "timestamp, size or inode changed", restic/node.go:551restic.(*Node).IsNewer11node).

However, inodes might change across filesystem mounts with sshfs (and probaly some other filesystems).

Do you have an idea how to solve the issue?

Commenting out the inode check solved the problem for me.

I'd like to have a way to disable this check; maybe a command-line flag?

Did restic help you or made you happy in any way?

Sure, it's a nice piece of software! I'm all the more pleased since I have found a workaround...
Keep up the good work!

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions