Web UI: navigate away from page during restore operation?

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.


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.


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 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 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 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 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 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

Are you using Chrome? This can be caused by budget-based timer throttling.

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

1 Like

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
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