 |
Is this still an issue with latest director and webui installed? I wasn't able to reproduce. |
|
|
I just updated all packages on the Director (bareos-dir and bareos-webui especially) to 15.2.2-33.1 (Ubuntu package). I still get the empty list. If there is something I can do to debug it further, please let me know. |
|
|
Ok, let's see if we can get the root directory of a *nix client via bvfs api from the catalog db in a bconsole session. 1. Find a jobid of a *nix clients last full backup. 2. In bconsole execute the following command, to update the cache. .bvfs_update jobid=<jobid> 3. In bconsole execute the following command with empty path argument. .bvfs_lsdirs jobid=<jobid> path= You should the see something like this: *.bvfs_lsdirs jobid=654 path= 198 0 0 0 A A A A A A A A A A A A A A . 197 0 0 0 A A A A A A A A A A A A A A / * If you only get a one-liner like following, your catalog is maybe corrupt. *.bvfs_lsdirs jobid=169964 path= 939173 0 0 0 A A A A A A A A A A A A A A . * |
|
|
Yes, I get a oneliner: Using Catalog "MyCatalog" *.bvfs_lsdirs jobid=8836 path= 78056 0 0 0 A A A A A A A A A A A A A A . Note that if I do a "restore" I am able to browse the fileset tree, so I guess all is not lost. What can I do from here? I'd loathe to throw away the catalog, especially relabeling all tapes (and losing all the backups up to now). An additional info that might be important: we are using migration jobs, and we have a prerun script that finds all 0-size jobs and deletes them from the catalog (to work around an older bug from last summer that I *think* might be fixed now). Could this be part of the problem? Can I run some cleanup/fix job? bareos-dbcheck? |
|
|
So I went ahead and did at least a read-only scan with bareos-dbcheck: Checking for Filenames with a trailing slash Found 0 bad Filename records. Checking for Paths without a trailing slash Found 1 bad Path records. Checking for duplicate Filename entries. Found 0 duplicate Filename records. Checking for duplicate Path entries. Found 0 duplicate Path records. Checking for orphaned JobMedia entries. Checking for orphaned File entries. This may take some time! Pruning orphaned Path entries isn't possible when using BVFS. Note. Index over the FilenameId column not found, that can greatly slow down dbcheck. Checking for orphaned Filename entries. This may take some time! Found 3512 orphaned Filename records. Drop temporary index. Checking for orphaned FileSet entries. This takes some time! Found 5 orphaned FileSet records. Checking for orphaned Client entries. Found 1 orphaned Client records. Checking for orphaned Job entries. Found 0 orphaned Job records. Checking for Admin Job entries. Found 0 Admin Job records. Checking for Restore Job entries. Found 8 Restore Job records. Should I set it to read-write and let it fix the problems? |
|
|
Probably do a ".bvfs_clear_cache" in bconsole first an see if the problem still exists by repeating the steps from my previous comment. |
|
|
Yeah, still the same output after clearing the bvfs. Should I do the dbcheck R/W? |
|
|
Usually this shouldn't be needed, but sure you can give bareos-dbcheck a try with the -f option and see if it solves the issue. |
|
|
YAY, success! Fixing the catalog with dbcheck gave me back the file browser. I'll try now to remove our hacky workaround for the zero-size migration jobs bug, and hope for the best. |
|
|
Great, I'll keep this open on feedback for a while, just in case. |
|
|
Same issue for me, running bareos-dbcheck does not fix the problem. |
|
|
On my side, after a full set of migration jobs ran, it looks like all is still working. |
|
|
same here-still not able to restore via webui. |
|
|
On my side I can confirm everything is still working ok: I can still browse the file tree (and didn't need to delete zero-size jobs). |
|
|
Is this still an issue? |
|
|
For windows client, problem can be in File record in FileSet. https://bugs.bareos.org/view.php?id=666 Try replace "\" to "/". Do ".bvfs_clear_cache yes" in bconsole and run "/usr/sbin/bareos-db -f". |
|
|
Bareos 15.2.2, still an issue, still the same: only filesets from windows clients are shown. |
|
|
I did a dbcheck with error fixing again, and again this (and cleaning the cache, and restarting bareos-dir) fixed it for me. Still, how is it possible that the db goes to hell so fast? If the kind of stuff the dbcheck fixes happens so frequently, those checks should be in the code and running all the time, should they not? Or, is this some side-effect of some transparent fault in my setup? The only strange thing happening lately is that some job (especially long-running, big jobs) has broken mid-way. Could this cause (for example) a ton of orphaned FileNameId, like in my db? |
- Anonymous
