 |
As a note, from the 16.2.7 notes, I cannot create index bareos=# CREATE INDEX file_jpfnidpart_idx ON File(PathId,_JobId, _FilenameId) WHERE FileIndex = 0; ERROR: column "_jobid" does not exist Not sure if this is required or not. |
|
|
I stand corrected, I see the expected indexes that were created during the 2171 migration |
|
|
I updated the cache manually. backup01:~$ time echo ".bvfs_update" | sudo bconsole Connecting to Director localhost:9101 1000 OK: backup01 Version: 17.2.4 (21 Sep 2017) Enter a period to cancel a command. .bvfs_update Automatically selected Catalog: MyCatalog Using Catalog "MyCatalog" You have messages. real 1m59.716s user 0m0.053s sys 0m0.020s After only taking 2 minutes, the restore list is still taking 20 minutes to populate. |
|
|
There are at least two problems here: 1. the result delivered by .bvfs_lsdirs is not correct. It misses an entry for "/". 2. the bareos-webui does not behave right. The newly introduced looping through the result set continues looping until it receives the full result. In your case this results in an endless loop. I assume, after 20 minutes some browser, ajax or php timeout triggers. About 2: this will be fixed soon. About 1: I'm not sure, what triggers the problem in the first place. A few questions to limit the scope: * does this happen for all restore jobs or just for a specific one? * what database backend do you use? * have you used bareos-dbcheck? If not, don't use it now. There is another bug in there, at least when using sqlite. This will also be resolved soon. |
|
|
1) I have 6 clients backup01, centos7.2 - lists fine catalog, centos 7.2 - lists fine dc01, windows 2016 core - lists fine dc02, windows 2016 core - lists fine fmp01, windows 2016 - slow - 301975 files, 294GB size fps01, windows 2016 - slow - 181855 files, 14.11GB size Both slow servers took 20 minutes to list. After 20min, the webui displays an error box "Oops, something went wrong, probably too many files" 2) Postgresql 9.6.6 3) I have not used that, should I try it since I'm using postgresql? |
|
|
about 3: not now. I'll first check what exactly the problem with dbcheck is. about 1: interesting. I've not assumed this. What you could do is to recreate the full bvfs cache. Please be aware, that this will take quite a long time. On bconsole type: .bvfs_clear_cache yes .bvfs_update The first command will be quick, the second will take a lot of time and is normally not required (it will normally be called for specific jobids that you are interested in). However, you should give it a try. For details about bvfs see http://doc.bareos.org/master/html/bareos-developer-guide.html#sec:bvfs |
|
|
.bvfs_clear_cache yes ran for 2 seconds .bvfs_update ran for 16 minutes Same slowness and error after the update command. |
|
|
Okay, that is the result of list files jobid=<last full job of fmp01> |
|
|
It list all the files on C: and D:, which I would expect. |
|
|
fmp01 listing took 28 seconds. fps01 last full lists all it's C: and D: files as expected also. this listing took 27 seconds, even though it has almost 2 times the number of files. |
|
|
But how are they displayed? /C:/... or somehow else? |
|
|
C:/Users/ D:/Users/ there is a block of whitespace before each letter. dc01 is displayed the same way. One other way these two servers are different, they have a D:/, dc01 and 02 do not. |
|
|
Note: A fix regarding the endless loop in case of receiving rubish BVFS output has been pushed internal to the webui bareos-17.2 branch and is going public with the next push to GitHub as well. |
|
|
In my Linux only test environment, I was able to create a similar problem by using dbcheck on my sqlite database. Following steps did resolve this issue: # clear cache .bvfs_clear_cache yes # restart the bareos-dir systemctl restart bareos-dir # update cache .bvfs_update The reason is some internal director cache. |
|
|
Fix committed to bareos-webui bareos-17.2 branch with changesetid 7444. |
|
|
Hi, it's not working for me. I have a tousen folders in directory and if i want to restore some files i have the error. |
|
|
Снимок экрана от 2018-01-15 09-51-07.png (184,466 bytes) |
|
|
Same here, cannot restore our machines :( We're using MySQL and it's sooooo slow again. Don't know what happened. |
|
|
Ok server reboot fixed it here for us, no idea why it was so damn slow before the reboot. |
|
|
I assume, the problems are fixed with Bareos 17.2.5. Note: updating both the webui and the director is required. Did anybody have other experiences with bareos-17.2.5? |
|
|
Is anyone still able to reproduce this problem? |
|
|
working fine atm, main solution I think is proper indexing in MySQL and we also run .bvfs_update automatically. An INSANELY fast disk with high iops for the database tends to help as well for the overall performance, also during backups. |
|
|
If everything works, I'm going to set this to resolved. |
- Anonymous
