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