On Thu, 29 Aug 2024 at 18:42, Phil Stracchino <ph...@caerllewys.net> wrote:
> 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?
>
Hello Phil,
I think that it's due to the nature of the Bvfs cache. In the Bvfs
'pathhierarchy' table is stored the directory tree structure in form pathid
-> parent pathid (ppathid). If some paths are orphaned, it means that
theoretically they could to be removed from Bvfs cache as well. But it is
hard to remove any path from the 'pathhierarchy' without rebuilding the
cache because otherwise the cache will be incomplete.
For example, we have the following path hierarchy relation written in the
'pathhierarchy' table (I use pathids):
1 => 2 => 3 => 4 => 5
If the path with pathid 3 is orphaned and removed, then in the Bvfs cache
we have the path relation:
1 => 2 => ??? => 4 => 5
In this meaning the dbcheck behavior and block removing orphaned paths for
me is understandable to avoid rebuilding everything.
BTW: When the cache is manually cleared by '.bvfs_clear_cache yes' it will
be completely (re)built anyway.
Best regards,
Marcin Haba (gani)
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
