Mount duplicacy snapshot as a virtual filesystem

planned
restore

#1

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)


#2

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


#3

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:


#4

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.


#5

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


#7

I just want to +1 this feature request