A GUI to browse and restore restic backup repositories.

Hi @emuell

I had a need to restore from a backup recently. Restic-browser to the rescue. :)

But I noticed that the restore function in restic-browser drops a zip file, rather than extracting the files directly. On windows, zip files might be useful, but in a Linux environment, it is less than desirable, as I was unsure of filesystem metadata being restored properly, such as ownerships and file permissions from with the zip file. And having the intermediary zip file was also largely unnecessary for my use case. So ultimately, I resorted to the restic command line tool to do my restore.

Would you consider changing the defaults for Restic from dumping out a zip during restore to restoring the files directly?

Many thanks.

Damo.

Hi! Thank you for putting together this terrific tool. It's easy to install, and robust browsing a large restic archive. I'm running Restic-Browser-v0.2.2-beta-linux, on a restic archive on Backblaze B2.

I've browsed to a directory five levels deep, backed up three years ago, and now I'm attempting to either 'view' (eye icon) or 'download' (down to disk icon) a file in that folder.

On clicking either of those icons, a red toast pops up, with the text "Failed to restore file: unknown shorthand flag 'a' in -a".

On attempting to download a file, a zero-byte file with the name of the desired file is created locally.

Is there a flag I can start the binary with, to enable logging?

Thanks for the effort. I just run it to see how it works and have few small suggestions:

• Panic in gui apps, generally no-go. If the restic is not in path, exiting a bit gracefully would be better. Sorry if this issue was specific to my env.
• There is a small typo while opening repository: "respository"
• Looks like it doesn't auto-catch the existing environment variables. This could be a nice option.

Hi @emuell

This looks like an exciting project. Thanks for sharing your work.

Just reporting that when I try to run Restic-Browser on Ubuntu 20.04.4 (amd64), I get the error:

$ ./Restic-Browser
./Restic-Browser: /lib/x86_64-linux/gnu/libc.so.6: version 'GLIBC_2.34' not found (required by ./Restic-Browser)
./Restic-Browser: /lib/x86_64-linux/gnu/libc.so.6: version 'GLIBC_2.32' not found (required by ./Restic-Browser)

The version of libc.so.6 on my install is symlinked to libc-2.31.so. 😞

I suspect this will be related to wails2, so not sure how you might overcome this one. But 20.04 is a very common install base, and is supported by Canonical for another 3 years.

Damo.

Bumps vite from 2.9.12 to 2.9.13.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Something else to consider is for restic-browser to cache results when you explore the backup directory tree structure to view files. At the moment, if you return to directories you have visited already (even going back up to parent directory), the reload of the files is just as slow as the first. The delay is not trivial - at least for me and I'm working with a restic repo that is on a local disk.

It might need to be an option to enable or not, as some users may not want to cache the file listings and directory structure on disk where they are using your tool, for security/privacy reasons. They would have to endure the lag when navigating to different directories.

I do love that switching between snapshots keeps the directory view on the same directory. This is great when you need to restore a file from a particular directory, but not sure which snapshot to pull it from. Very nice! This is something that backintime does. It is a great GUI backup/restore tool to take some inspiration from.

Damo.

• Read default location passwords from RESTIC_PASSWORD_FILE when set
• Allow prefilling/reading passwords in the location dialog from a password file (see https://github.com/emuell/restic-browser/issues/13)

Show a proper error message when folder dumps are not possible because the installed restic program version is too old (see https://github.com/emuell/restic-browser/issues/22)

• set initial repository from the env's RESTIC_REPOSITORY and RESTIC_PASSWORD values, when they are set
• do not modify repo location when hitting "Cancel" in the Location chooser dialog

It should be possible to sort the snapshot and file lists by either time or name (which is the default). The vaadin grid easily allows doing so, so this should be easy to realize in the Restic Browser as well.

It should be possible to use "rclone" connections: Can be implemented by adding a new "rclone" type to the "Open Repository" dialog. Doesn't need any other credentials.

I'm not sure if this has been brought up before, but I'd love to not have to input my repo details every time I wanna view snapshots= contents.

Would there be a way to cache/save/store this info anywhere, and just have the repo kind of saved onto the client? If that's out of scope, then perhaps read from a file for all inputs, not just password?

I personally use Backblaze, so it's a lot of copy pasting every time.

Thanks!

Edit: Ideally you'd allow credentials to be saved for all types of repositories (local, S3, Backblaze), and allow for multiple repos to be saved too.

Thanks for this tool. I'm having an issue that I don't know how to solve (sorry if this is a basic question).

I have both restic and rclone (for the repository) in my $PATH, but when I run restic-browser it does not detect restic and asks me to manually set the path to the executable. Then, when I do that, and try to browse my rclone repository, I get an error saying rclone is not in the $PATH.

How do I fix this? I'm running MacOS Ventura btw and using zsh ($PATH is defined in the ~/.zshrc file).

Hi @emuell

Last idea/suggestion. :)

Search functionality would be really useful for restic-browser. Initially perhaps on the path and tags, although date/time ranges could be used too. With the introduction of #29 you could use that same text box with search syntax.

Just sharing these ideas after using restic-browser for a little while now. But they are only suggestions. I fully recognise that you are likely sharing your work in case it is useful for someone else, just scratching an itch, or having some fun hacking some code. In other words, I have no expectations, and simply appreciate an opportunity to provide feedback that may help make a good idea even better.

In any case, thank-you Eduard for sharing your work. :)

Damo.

When navigating with restic-browser, you traverse the paths of the backup by clicking through the UI on each directory at a time. Yet, when you know exactly where you need to go, or at least a pretty good idea at the start, this makes it slow and cumbersome. This is especially true because restic-browser needs to query the repo for each directory listing along the path.

To mitigate this issue, restic-browser could include a type of url bar, or a text box in which the path can be typed, thus allowing direct navigation to a known location in the backup. For example, if you needed to restore a file located in /usr/local/bin, instead of clicking on each of those directories, and waiting for the next listing to load, you would just type: /usr/local/bin and enter.

As an extension of this suggestion, restic-browser could also include tab-completion functionality for this text entry box, so when you get to a path depth, where you are no longer confident about the next directory, you can double-tab and have restic-browser look up the deepest level typed so far, and then return a drop down list (or some other UI element) so you can choose just the next level. Think just how UNIX shells work with tab completion.

With the inclusion of these two features, you can be far more productive in navigating around a backup using restic-browser.

Again, just a suggestion for consideration.

Damien.

If it is given, that restic-browser is focused entirely on restoration functions, then adding features that leverage the visual interface (as compared to restic command line) to make restoring easier should perhaps be prioritised.

At present, restic-browser is mimicking some of the command-line features of restic. When restic-browser could truly augment the command line tools is to make it even easier to locate the files you need to restore. To do this, I suggest a fundamental change to how restic-browser currently traverse a repository.

The current model of operation for restic-browser is that you select a snapshot, and then you navigate the directory structure of that snapshot to locate files.

This is great when you know which snapshot you need to restore from (e.g. the latest snapshot). But there will be times when you need to restore a known path, but its unclear from whence (which snapshot).

I am just highlighting that there are two dimensions to locating the files you wish to restore. When they were backed up (snapshot & tags), and where they are located (path), but restic-browser only currently supports navigating by one.

Instead, I would suggest that you can also navigate directory structures and files first, and in response, restic-browser then filters down the matching snapshots. Or more ideally, restic-browser should support mutating both inputs without resetting the other. You change either the snapshot, or the path, and the other input remains the same, thus helping you to triangulate on both dimensions to locate the files/directory to restore.

Just a suggestion for consideration. :)

D.