Closed damoclark closed 1 year ago
Hi @emuell I agree with @damoclark A zip is not a good way of restoring Linux files Thanks
Agree. Thanks for the feedback.
Already changed this here, making it the default restore option: https://github.com/emuell/restic-browser/pull/33
Sorry for the bump, but I think I'll need to reopen this issue and revert the change in #33
There's no way to do a restic restore
with relative paths. So restore operations always will (re)create the entire src path in the target directory. I think this is pretty confusing and may lead into even more confusion than what we had before.
An example: Let's say we have a restic repository with the following contents:
C/Users/Me/Music/GreatStuff.mp3
C/Users/Me/Music/OtherStuff.mp3
If you now do a restore of only GreatStuff.mp3
in Restic-Browser and set your user's Downloads
as target directory, it will create a directory: C/Users/Me/Music/
in your Downloads.
When using dump instead of 'restore' it will directly restore the file to the target path. Now when dumping a folder such as C/Users/Me/Music
, a file Music.zip
will be created. This isn't ideal for Linux, but at least won't recreate the entire folder structure at the target dir.
Hi @emuell
Rather than revert this change, can you support both use cases?
Reverting this change means you cannot restore ownerships, permissions, hard or soft links, or xattr on Unix-based systems using Restic-browser. It also means that you have to deal with an intermediary file, which could be problematic if the volume of data being restored is substantial - you effectively require twice the space to restore it, after extracting the zip.
What if the restore interface allows the following choices (with perhaps some defaults in the settings):
The whole point of a backup utility is to be able to get our data back. I sometimes think backup tools focus too much on the backup phase (because that is what we do the most often), and too little on the restore phase (which is the whole point of the backups). This is why I see Restic-browser as being so valuable to the Restic ecosystem.
Is this something you might consider?
Damo.
Reverting this change means you cannot restore ownerships, permissions, hard or soft links, or xattr on Unix-based systems using Restic-browser. It also means that you have to deal with an intermediary file, which could be problematic if the volume of data being restored is substantial - you effectively require twice the space to restore it, after extracting the zip.
Yes, good point about ownership, permission and co. I'll simply add both options to the GUI, so you can use whatever fits best.
Actually, restoring and dumping already can be done with shortcuts right now: Press r
key in file list for dumping, r
key for restoring, but this should be more obvious in the GUI.
This was now done in https://github.com/emuell/restic-browser/pull/38
A new version which includes this change will be released very soon.
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.