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.
5 Likes
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.
2 Likes
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.
3 Likes
Has there been any update to this? I’ve got a large restore which looks like it’ll take 6 hours to run. I’ve tried twice in the browser and it’s failed on both times. While I’d prefer to have it continue to run if i navigate away, I’d be happy to have it run as a schedule (not currently an option).
The schedule will be fiddly for those where a recovery takes more than a week, but fortunately that’s not me.
3 Likes
Bumping this.
Restoring a large directory via the Web GUI I had to try 4 times before it finally worked (failed and ultimately successful attempt below.) It seems not only must the page be left open but it has to be in the foreground. Every time it was backgrounded (by opening a new browser window or another app) it eventually failed.
This is on the latest version of MacOS and Safari.
It’s the only real “show-stopper” with the web version as far as I’m concerned because it goes to core functionality. I can imagine the frustration of having to repeat this process over several days with a larger backup and slower storage.
EDIT: to add this isn’t a storage-connection issue. This restore was from local storage and I’ve never had a connection issue despite frequent hours-long backup and verify operations over several months.
2020/12/16 21:45:56 10.0.1.3:61569 POST /start_restore
2020/12/16 21:45:56 Created log file /logs/restore-20201216-214556.log
2020/12/16 21:45:56 Created restore session 5bl47
2020/12/16 21:45:56 Running /home/duplicacy/.duplicacy-web/bin/duplicacy_linux_x64_2.7.2 [-log restore -r 8 -storage USB -overwrite -stats -- Windows 10.pvm/*]
2020/12/16 21:45:56 Set current working directory to /cache/localhost/restore
2020/12/16 21:49:27 Deleted listing session ovuta
2020/12/16 21:49:27 Invalid session
2020/12/16 22:01:00 Stopping the restore operation in session 5bl47
2020/12/16 22:01:00 Failed to restore files for backup Parallels revision 8 in the storage USB: Duplicacy was aborted
2020/12/16 22:01:00 closing log file restore-20201216-214556.log
2020/12/16 22:01:20 Deleted restore session 5bl47
2020/12/16 22:09:06 10.0.1.3:61808 POST /start_restore
2020/12/16 22:09:06 Created log file /logs/restore-20201216-220906.log
2020/12/16 22:09:06 Created restore session 4ljb4d
2020/12/16 22:09:06 Running /home/duplicacy/.duplicacy-web/bin/duplicacy_linux_x64_2.7.2 [-log restore -r 8 -storage USB -overwrite -stats -- Windows 10.pvm/*]
2020/12/16 22:09:06 Set current working directory to /cache/localhost/restore
2020/12/16 22:16:37 Stopping the restore operation in session 4ljb4d
2020/12/16 22:16:37 Failed to restore files for backup Parallels revision 8 in the storage USB: Duplicacy was aborted
2020/12/16 22:16:37 closing log file restore-20201216-220906.log
2020/12/16 22:16:57 Deleted restore session 4ljb4d
2020/12/16 22:17:38 10.0.1.3:61876 POST /start_restore
2020/12/16 22:17:38 Created log file /logs/restore-20201216-221738.log
2020/12/16 22:17:38 Created restore session deo1vf
2020/12/16 22:17:38 Running /home/duplicacy/.duplicacy-web/bin/duplicacy_linux_x64_2.7.2 [-log restore -r 8 -storage USB -overwrite -stats -- Windows 10.pvm/*]
2020/12/16 22:17:38 Set current working directory to /cache/localhost/restore
2020/12/16 22:41:40 Stopping the restore operation in session deo1vf
2020/12/16 22:41:40 Failed to restore files for backup Parallels revision 8 in the storage USB: Duplicacy was aborted
2020/12/16 22:41:40 closing log file restore-20201216-221738.log
2020/12/16 22:42:00 Deleted restore session deo1vf
2020/12/17 03:31:01 10.0.1.3:63551 POST /start_restore
2020/12/17 03:31:01 Created log file /logs/restore-20201217-033101.log
2020/12/17 03:31:01 Created restore session wwj1v
2020/12/17 03:31:01 Running /home/duplicacy/.duplicacy-web/bin/duplicacy_linux_x64_2.7.2 [-log restore -r 8 -storage USB -overwrite -stats -- Windows 10.pvm/*]
2020/12/17 03:31:01 Set current working directory to /cache/localhost/restore
2020/12/17 03:33:02 10.0.1.3:63551 GET /assets/img/product-icon.png
2020/12/17 04:22:56 Restored 70 files for backup Parallels revision 8 in the storage USB
2020/12/17 04:22:56 closing log file restore-20201217-033101.log
2020/12/17 04:23:16 Deleted restore session wwj1v
1 Like
The latest Safari on MacOS.
It looks like you can disable background tab throttling in Safari by running this command in Terminal:
defaults write com.apple.safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2HiddenPageDOMTimerThrottlingEnabled -bool NO
Reference: sleep wake - Preventing Safari background tabs disconnecting from server - Ask Different
2 Likes
Thanks, disabling background throttling fixed it.
I still think a background task (like backup and verify) would be ideal. Too many ways for a browser task to fail during a long restore.
I didn’t follow your instructions (which may work) exactly.
For reference:
Quit Safari.
Enable the debug menu:
defaults write com.apple.Safari IncludeInternalDebugMenu 1
Open Safari
Check:
Debug -> Miscellaneous flags -> Disable Hidden Page Timer Throttling
And begin restore.
The same procedure to reverse it with:
defaults write com.apple.Safari IncludeInternalDebugMenu 0
1 Like
Is there any other workaround for this? I have a 6hr restore job to do and don’t trust that my browser (Firefox OSX) will keep the tab running to complete the restore. I have used Duplicacy CLI for years and a restore job run in a tmux session has worked fine for this type of restore but trialing the web version at present and this issue is a show stopper.
1 Like
+1 for this feature request. Preferably would have some index of running restore operations which were started/managed by web UI. My use-case also makes the current behavior a pain to work with.
I agree this is not a fix nor a viable workaround. It’s a bug in duplicacy-web and needs to be fixed in duplicacy-web. Breaking browser behavior to walk on eggshells around misbehaving software is not a consideration worthy option.
Fortunately this is on a roadmap
3 Likes
As a workaround for this issue as I am doing a month+ long restore, I’m currently running the P3R Firefox Browser docker container on the same server as Duplicacy is running.
It works as a bandaid solution, but is definitely not ideal and I am looking forward to the change being implemented so that this is no longer needed.
1 Like