Mount duplicacy snapshot as a virtual filesystem

Continuing the discussion from Use standard UI controls whenever possible:

What is duplicacy snapshot? It’s a virtual immutable filesystem, effectively, with its own internal API and a lot of code around it to access it and eventually produce just a handful few useful scenarios:

  1. copy files out of there (aka restore)
  2. copy files into a new leaf with deduplication (aka backup)
  3. delete the leaf (aka prune)

So, why not take one more step further and implement an actual user mode VFS?

This opens up tons of opportunities and elegant workflows:

For example,

  1. during restore, instead of browsing in awkward custom control user can use native OS file browser (see linked topic).
  2. Or, just click a button after selecting revision and the snapshot in mounted as readonly filesystem. As a drive letter. or into /Volumes/mybackup_r139. Then user can use all sorts of tools such as diff, “Find Duplicates”, find, grep, etc. (otherwise user would need to checkout entire repository into a temp folder and then do all of that, which is wasteful for bandwidth and time)
  3. I can imagine that this will wrap around a lot of core in restore workflow and make design simpler.

Now, I’m not an expert in user mode filesystem design, or in user mode software development for that matter, (and while I see how can this be done fairly easily as a kernel extension – I would not recommend it; it should stay in userland if possible) but quick google search yields a few vfs support libraries in goland… so maybe there is hope :slight_smile:

Perhaps something to consider for revision 3.xx.xx?

(I makes me happy to even think about possibility to mount backed up snapshot as a filesystem, it’s super cool)


This would be sort of like MacOS’s implementation of “Enter Time Machine”!

1 Like

Interesting. This would be a functionality similar to rclone mount.

The users there try to use this functionality to mount volumes and use with Plex and etc. from the cloud. I think it’s a very heavy use, and problems with latencies and cache are often reported.

But for the simple use proposed above (directly accessing the content of the revisions) is undoubtedly interesting.

I’m thinking of a command in the CLI version:

duplicacy mount P: storage:stor_name snapshot:snap_id revision:134 :yum:

1 Like

I would absolutely love love this functionality, but obviously it sounds like a lot of work (but imo, doable).

Duplicacy already has a form of chunk cache, which includes metadata, so a fuse style mount system might be able to be built around that.

This is one of the most requested features. It is on my to-do list but I don’t have a timeline for it.


I just want to +1 this feature request

1 Like

This would be killer. Another vote from me.

Even if the mount were read-only it would be great for me. I’d then have access to my 4T music collection wherever I am while still having a good, encrypted backup…


I think it has to be read-only to protect the integrity of the snapshots. I would suspect something like libfuse (GitHub - libfuse/libfuse: The reference implementation of the Linux FUSE (Filesystem in Userspace) interface) to work on Linux, MacOS (BSD) and on Windows (using WLS) would be the way to go.

1 Like

I just wanted to ask if there is an update to this? Anything on the horizon?

1 Like

There is a FUSE implementation by @andrew.heberle: Prototype FUSE implementation

1 Like

2nding this. This would greatly enhance the utility of Duplicity. Lots of other packages do this, or at least have an “Explorer” software that lets you select by versions/dates and also search by file name or contents.

Also +1 for this feature. I hope this can be integrated in the main duplicacy binary, and it would be even better if there’s a button in GUI to mount the snapshot!