Restored files are missing when suggested restore path is used
Closed this issue · 7 comments
When restoring a folder, if the proposed path is accepted, the restored files and folders cannot be found on that path.
Inside the container, I can find them under /root/Downloads/ directory inside the container, probably due to the new download function.
I see this as the restore result in Backrest interface:
If I customize the path where the restore will be stored, the restore works as expected, and the path shown in Backrest interface is the desired one.
It seems that if the restore path is accepted by default, Backrest is adds /root/Downloads/ to the suggested path
To Reproduce
Steps to reproduce the behavior:
- Go to a plan
- Try to restore something
- Accept the default path suggested in the restore window
- Start the restore
- Once restore search for the target path on the disk and notice it's missing
Expected behavior
Expecting to find the restore files and folders on the proposed path.
Platform Info
- OS and Architecture Docker
- Backrest Version 1.2.0
Is the suggestion essentially that inferring a downloads directory e.g. /root/Downloads is a bad default? Re: missing files, this is the expected behavior if /root/Downloads isn't mounted as a directory on the host (and I can see it's confusing in docker -- makes much more sense on an interactive linux machine installed non-containerized).
Would defaulting to a subfolder of the original location of the files be a more expected behavior? Open to community feedback on the right default here.
For me, the suggestion starts with /raid/ so I would expect to see the restored files there, not under /root/Download/.
And in case of Docker, usually the root folder is not mapped on the host, so the files are restored inside the container.
And in case we specify the restore folder, they are properly restored on the expected path, which I find inconsistent and confusing.
Ah, thanks for filing this. That's definitely unintended, looks like there's some bug going on with the form submission -- the target path isn't actually getting to the request made to the backend. I'll get a patch release out this week addressing this.
Partially fixed in a patch release tonight, noticed after I pushed that there's still a more minor bug: the initially populated value isn't respected, restore path will still default to downloads. You must enter an explicit path to restore to a custom location.
Will put out another patch release combined with the hook refactoring I'm working on to followup on this later in the week.
I added the /root/Downloads path to docker-compose.yml to get the restored files on the server filesystem (outside the Docker container) and it works fine. I have just a couple of question:
- Is the '/root/Downloads' path configurable? I cannot find it in the config
- Is it possible to delete the restore operation record from the Operation Lists once the restored files are used and consumed? I mean, if I move or delete the directory from their position in /root/Downloads/... a subsequent click on the 'Download file(s)' link in the Operation List window throws an error. It would help to be able to delete that specific restore operation record from the list
Example
Restore creates this directory in /root/Downloads:
restic-restore-2024-07-07T16-28-27/
Then, after restoring the files, I delete the directory to save space. If I click on the 'Download file(s)' link in the Operation List I get this error in the new browser tab:
Impossibile raggiungere il sito
La pagina web all'indirizzo [HTTPS ADDRESS} potrebbe essere temporaneamente non disponibile oppure è stata permanentemente spostata a un nuovo indirizzo web.
ERR_INVALID_RESPONSE
which is normal, as the path doesn't exist anymore. It would help to be able to delete that specific restore operation record from the list.
Thanks for this awesome platform!
In the next release my plan is to split restore operations into a new entry in the operation history and have their title include the snapshot they relate to. This way the restore operations can also be deleted directly when you've removed the files they depend on -- agreed that it'd also be neat to have some mechanism to show whether or not the files are still available.
I'll give that some thought as a UI improvement.
I think this is resolved in the last few releases! Feel free to give a ping if you're still running into a problem here, marking as resolved for now.