interactive restore feature

[armhold]

Have you considered implementing an interactive restore feature?

For those old enough to remember, the old fashioned Unix dump/restore tools supported a shell-like restore, where one could interactively navigate the archive viacd, ls, etc.

The user could select files/dirs with add, and then finally restore them with extract.

I realize that restic mount provides part of this functionality already, but it would be nice to have it without requiring FUSE. I have a proof-of-concept at https://github.com/armhold/restic/blob/interactive/cmd/restic/cmd_interact.go

Curious to get your thoughts on this potential feature, thanks.

[flamingm0e]

I think an ncurses based interface for restore would be good.

[armhold]

ncurses (or maybe termio?) is an interesting idea, but I had something far simpler in mind.

I found that I was able to implement simple shell-like navigation just using the already existing deps. Mostly I just needed raw mode (for tab completion) and a simple readline(), both of which ssh/terminal provides.

Here's a recording of how it works so far:

https://asciinema.org/a/l5TqUNCgLgTap38gIKLLV1ZaY

[flamingm0e]

personally, I want to be able to go down a tree structure of some sort and select (space bar?) the files I want restored. manually typing in the filenames will become tedious, even with auto complete

[fd0]

Hm, nice idea! I don't have time to look at it right now though, I'll probably do that later. Thanks for reporting the idea!

I'm aware that the restore command is a bit awkward to use if you don't want a full restore though.

[rawtaz]

@armhold Not to dismiss your idea or feedback, but can you elaborate on why the current solution isn't a good fit for what you need?

I mean, there's FUSE which is designed to be used for mounting various types of filesystems/backends/whatever, a perfect match for a snapshot in your restic repository.

By utilizing it and mounting your snapshot, you can use any user interface you want, to browse the files in it. I don't really see what the point is to implement some kind of specific user interface in restic - that will give you one such interface, when as I said you already have the choice of many other ones.

Specifically, navigation using cd, ls, etc, is already doable. Selecting some of the files/folders that you then restore is also doable, via whatever user interface you want - indeed you might not have the add you mentioned, but you can simulate that in many ways, e.g. by adding files/folders to an environment variable or some file, as you navigate around in your FUSE mounted snapshot.

Is the thing that you don't want to use/install FUSE? Just trying to understand.

[armhold]

Hi @rawtaz.

I have nothing specifically against FUSE. To me, requiring the user to install a kernel extension is quite the opposite of Go's philosophy of "everything in a single static binary".

I'm on macOS, and when I see that a kernel extension is required, here is what goes through my mind: will it destabilize my OS? Will it write files in weird places on my system? Will I be able to un-install it easily? Will it cause problems when the next version of macOS comes out and I have this thing installed (that I have perhaps forgotten about)?

Again, nothing in particular against the FUSE project. For those willing to install it, I think it's is a fine solution. And no amount of code will beat a live mounted filesystem as FUSE provides.

But it seemed like it ought to be possible to provide a minimal interactive tool right inside of restic. I tried, and ~600 lines later I had something that worked well enough for my needs.

I do understand the need to keep codebases small & prevent feature-creep, so if you feel this is a narrow use-case, please feel free to close the issue.

Thanks!

[rawtaz]

@armhold Thanks, that clarified it a lot, I see where you're coming from.

Let me be very clear on one thing; I am not an official person of this project, I'm just a user like anyone else. So I would never dream of closing this ticket, that's entirely not my say :)

I think you have a point in that if there's a somewhat more flexible/interactive restore option, at a low cost in terms of the code quality, then why not! And since you're the one who brought it up and know how you envision it, your code might be a good starting point.

Thanks for clarifying.

[rawtaz]

Upon a second look at this I like it quite a lot 👍

@armhold Is it something you are using? Is it something you're intending to continue working on?

[armhold]

@rawtaz I was using it in a private branch for a while, but since there seemed to be no interest beyond me I haven't pursued it. I'm trying to be sensitive to feature bloat and maintainer overload. 😄

But if there really is a quorum of interest I'd be happy to pick it up again. I consider the cmd_interact.go above as a PoC or perhaps a starting point for such a feature.

[rawtaz]

@armhold Is the code available anywhere?

[armhold]

Hi @rawtaz, it's linked in the first comment of this issue (I mistakenly said "private branch" a couple comments ago, but I believe you should be able to access my fork; please let me know if that's not the case).

[rawtaz]

I'm an idiot.

[jtagcat]

Chronologically switching between backups would be great for finding an item.
I'd think ncdu-style browsing would be great - replace delete function with restore. Symmetrical/syncronized browsing with directory comparison could be also great (specify local directory or a backup and as argument 2 a backup (none=latest). (see FileZilla for what I mean) Chronological order backup switching for the 2nd can also work there.

[rawtaz]

@armhold I'm thinking this command should be named browse. It would complement restore which does a direct restore of files, and mount which mounts the repo in the filesystem using FUSE. Browse seems like a more natural name for what you would do with this feature, rather than interact.

Would you still be interested in polishing the code and making a PR out of it? If so, perhaps we can get @fd0's opinion on whether to pursue this or not. It would be a cool and useful addition I think, so one doesn't have to install FUSE.