 |
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. |
|
|
While this is not reproducible on a perfect setup of Bareos, would you test the following rules at least. Use the most recent PostgreSQL server you can 15 being the best as of today. Setup the DB server to use 25% of the ram as shared buffer, and/or checking if you can set that to handle all table indexes in ram. Let PostgreSQL having the same amount of data as free space (help maintenance and tmp creation), if using harddrive, move the db to ssd. next use the console command ".bvfs_update" regularly (see documentation, can be after each job, or globally) to precreate paths and files tree needed when doing restores. In the case of AlwaysIncremental, maybe you will be interested to adjust the following new parameters in the webui configuration ; Merge jobs on client selection ; Default: ;merge_jobs=true ; Merge filesets on client selection ; Default: ;merge_filesets=true Where if you have a lot of different fileset used on the same client you can avoid to merge them all. |
|
|
Specific installation can be adjusted with new parameters. |
- Anonymous
