On 8/29/24 12:25, Marcin Haba wrote:
1) This is an incremental process. It means that the cache is not
re-created for jobs and paths that already exist there. Added are only
new ones. Because of that for newly configured backup jobs this cache
can take longer than for others.
2) This process can be triggered asynchronously to the restore process.
There is possible to update this cache not in a moment when the files
from restore are urgently needed, but in a moment when the backup job
finishes work. This way when you go to the restore wizard, the cache is
ready. It can be done in the Job Runscript directives like these:
Runscript {
Runs When = After
Runs On Client = no
Console = ".bvfs_update jobid=%i"
}
In older Director versions there was a bug in running the .bvfs_update
command in the Runscript Console directive:
https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/issues/2419
<https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/issues/2419>
but I think in newer Bacula versions it should be fixed already. For
older Director versions it can be done by using script and putting the
.bvfs_update command inside it, like this:
Runscript {
Runs When = After
Runs On Client = no
Command = "/path/to/script/script.sh %i"
}
The bvfs cache DOES greatly improve restore performance, but the one
showstopper drawback I found (beyond the runscript bug) was that if you
pre-populate the bvfs cache, dbcheck will refuse to clear orphaned Path
entries unless you clear the bvfs cache first.
Marcin, do you have any insights on this issue?
--
Phil Stracchino
Fenian House Publishing
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
