Re: postgres load at restore

On Thu, 29 Aug 2024 at 20:14, Phil Stracchino <[email protected]> wrote:

> > In this meaning the dbcheck behavior and block removing orphaned paths
> > for me is understandable to avoid rebuilding everything.
>
> Oh yeah, the consistency problem is fully understandable, it just seems
> an oversight that dbcheck seems unable to fully handle the presence of a
> populated bvfs cache.  It seems like a part of dbcheck should be
> checking and updating the bvfs cache if present.
>
>
> > BTW: When the cache is manually cleared by '.bvfs_clear_cache yes' it
> > will be completely (re)built anyway.
>
>
> Gotcha.
>
> If I do a .bvfs_update WITHOUT specifying a jobid, will it do a full
> rebuild?  I'm thinking what I'd LIKE to do is the following:
>

Hello Phil,

The .bvfs_update without specifying a jobid does update for all jobs :-) I
mean all jobs for which the cache has not been created yet. It is still the
incremental process.


> NIGHTLY
>         Run all scheduled client backup jobs
>         Incremental rebuild bvfs cache
>         Run catalog backup
>
> WEEKLY
>         Clear bvfs cache
>         Run dbcheck
>         Full rebuild bvfs cache


Yes, I see your idea. This full rebuild will cost creating all cache from
scratch. For many jobs and paths it will take lots of resources.

I have to admit I don't see an easy solution to run dbcheck for paths and
keep Bvfs cache.

Best regards,
Marcin Haba (gani)

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