Restic fuse mount read-write support

Features and Ideas
1

I’ve used a Restic mount to restore some individual files, and it worked great. But it’s read only. Could it be possible to add write support? The use case is I’d like to use Restic on an intermediary server between cloud storage and machines that use rsync or a sshfs mount on the local network. Ideally a file saved into the restic mount would be stored in the cloud without any permanent disk usage on the intermediate box.

2

I don’t think this is possible, AFAIK. Restic writes data when using backup. So if you want to “sync” the changes made in one host you just need to use backup command when you’re done with the file you’re editing so you can access and restore the file when you’re in another host. Being restic a backup solution, I don’t see why it is necessary write support when using mount because this command is just an “easier” solution for restoring files.

1 Like
3

This isn’t technically feasible, because a snapshot is conceptually an immutable collection of files. Consider the following problems:

  • Modifying the contents of a file, or adding/removing a file changes the identifier for the tree (directory) it is contained in. This necessarily cascades all the way up to the root tree, changing all ancestor tree IDs.
  • Modifying the tree ID that is the root of a snapshot changes the ID of the snapshot.
  • This means that changing the contents of a snapshot produces a new snapshot, but the filesystem won’t reflect this change in the directory where you made the change because the change would cause a new mount-toplevel snapshot directory to be created instead.
  • The fuse kernel interface does not provide any mechanism to “batch” operations into a single atomic operation. This means that restic can’t tell if it should create a new snapshot for each change, or wait until you have made several changes to create a new snapshot.
  • It’s not clear exactly how the new snapshot should be created – what are the host, timestamp, tags, paths, etc.? This information can’t be inferred from a mutation of the mounted filesystem.
1 Like
4

I see, that all makes sense. I guess those issues could be overcome, but they would require a lot of development and wouldn’t be a priority for restic (wrong tool for the job). Thanks!