Re: postgres load at restore

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
   [email protected]
   [email protected]
   Landline: +1.603.293.8485
   Mobile:   +1.603.998.6958



_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users