View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001189||bareos-core||configuration gui||public||2020-02-12 09:58||2020-05-08 09:21|
|Summary||0001189: Restore windows takes very long before loading, then times out|
|Description||When we go to: https://backupmaster.xxx/restore/ , the page keeps loading forever to end up with an empty screen.|
Afterwards we can restore by selecting the correct date of a specific server...
However this takes a really really long time since we have to wait for it to timeout first... :(
So all restores takes much more time as before.
It looks like it selects some invalid client or something when going to the screen the first time.
Afterwards (after waiting a long time), we can succesfully go to a client and start a restore
|Steps To Reproduce||* using always incremental scheme|
* Click on restore in the bareos web-ui
* The screen show loading, this takes up to several minutes
* The screen end up's empty (It's on "Please choose a ckient")
* Now finally we can go to a client and start the restore
* Bonus on Internet Explorer we no longer can restore
|Tags||No tags attached.|
PS: I think it does this query over and over when selecting the restore window:
2901 | bareos | localhost | bareos | Query | 43 | Sending data | DELETE FROM PathVisibility WHERE NOT EXISTS (SELECT 1 FROM Job WHERE JobId=PathVisibility.JobId) | 0 | 53298921 |
This is slow apparently with much data.
Any update on this perhaps? Loading the initial restore window really takes ages in our case, not very convenient :)
(also launching restore in IE is no longer possible atm )
|We're on postgresql now, but we notice kind of the same delay still when trying to restore. It first tries to select a non existent client (or something) which seems to be quite heavy.|
I also experienced this issue, but the file tree never loaded, nor did any of the choices populate after selecting a client. I recently upgraded from 18.2 to 19.2. I checked the release notes and it appears that a new `filetree_refresh_timeout` configuration was added to /etc/bareos-webui/configuration.ini. I confirmed this value is there but for some reason the webui php code specified below isn't reading this value and is failing to output anything, breaking the `displayBvfsCacheUpdateInfo()` call.
both `/module/Restore/view/restore/restore/index.phtml` and `./module/Restore/view/restore/restore/versions.phtml` seem to have issues around this particularly in the `timeout` specification.
by changing `timeout: <?php echo $_SESSION['bareos']['filetree_refresh_timeout']; ?>, ` to `timeout: 120000,` in both of these files I was able to use the restore feature again.