During long restore operations, I wanted to navigate away from the Restore tab of the Web UI to check something else. Seems like this halts the restore operation. Since the web UI is decoupled from the CLI under the hood, shouldn’t it be possible to allow the restore operation to continue in the background? Hopefully this would be considered for the future.
It is possible but I don’t know it is a good idea. You may inadvertently leave the restore operation running in the background which is going to consume a lot of resources and may cause unexpected consequences.
I agree with @luckman212, since this is a client-server configuration the client maintaining UI connection to a server should not be a requirement for a pure server-side work — client is not even involved in that other than pressing a button “yes, go ahead restore 12TB of data”. It is not reasonable to expect that the client will keep uninterrupted connection to the server for the duration of several days.
This is the case for backup and should be the case for restore.
If the user inadvertently starts restore and gets disconnected and/or/interrupted and/or/ forgets about it would then login back and see the operation is progress and will cancel it.
I was thinking about this a bit, would it be possible for the GUI to store the PID and related commandline parameters from the backup/restore commands in a simple config file? Then, if the user navigates away from the page and later returns, the gui could just scan that config file, and look for any PIDs that still existed. If the PID was still there, then “reconnect” to that log file to continue watching the progress of it, otherwise delete any nonexistent PIDs from the config. This is a very “dumb” setup but still would be safer I think than the current way where the process dies immediately on leaving the page.