You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
damoclark
changed the title
Provide search functionality
Possible redesign for navigation of snapshots and paths
Sep 1, 2022
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.
The text was updated successfully, but these errors were encountered: