Re: [Bacula-users] postgres load at restore

Am 03.09.24 um 08:05 schrieb Stefan G. Weichinger: Am 31.08.24 um 08:25 schrieb Stefan G. Weichinger: Logs show: # journalctl -u bacula-fd Aug 28 20:07:16 samba bacula-fd[958]: samba-fd: job.c:3698-5189 Bad response from SD to Append Data command. Wanted 3000 OK data Aug 28 20:07:16 samba bac

Re: [Bacula-users] postgres load at restore

Am 31.08.24 um 08:25 schrieb Stefan G. Weichinger: Logs show: # journalctl -u bacula-fd Aug 28 20:07:16 samba bacula-fd[958]: samba-fd: job.c:3698-5189 Bad response from SD to Append Data command. Wanted 3000 OK data Aug 28 20:07:16 samba bacula-fd[958]: , got len=25 msg="3903 Error append da

Re: [Bacula-users] postgres load at restore

On Fri, 30 Aug 2024 at 19:17, Phil Stracchino wrote: > I tried running a restore of my workstation this morning, and it still > took more than four minutes to build the directory tree. > > > Does this seem as though the bvfs cache is being built correctly and > used? Is there a way I can test and

Re: [Bacula-users] postgres load at restore

On 31.08.24 07:56, Stefan G. Weichinger wrote: As mentioned I added that Runscript and it seems to work. Now I got 2 emails per job this night. For each job like: Bacula: Backup OK of samba-fd Full there is also one with Bacula: Console Unknown term code of samba-fd that's "new" ;-) That'

Re: [Bacula-users] postgres load at restore

On 8/31/24 01:56, Stefan G. Weichinger wrote: As mentioned I added that Runscript and it seems to work. Now I got 2 emails per job this night. For each job like: Bacula: Backup OK of samba-fd Full there is also one with Bacula: Console Unknown term code of samba-fd that's "new" ;-) Yes,

Re: [Bacula-users] postgres load at restore

As mentioned I added that Runscript and it seems to work. Now I got 2 emails per job this night. For each job like: Bacula: Backup OK of samba-fd Full there is also one with Bacula: Console Unknown term code of samba-fd that's "new" ;-) The backup job report looks OK. For reference one of

Re: [Bacula-users] postgres load at restore

On 8/29/24 20:28, Marcin Haba wrote: On Fri, 30 Aug 2024 at 01:22, Phil Stracchino > wrote: > 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. Well, I just test

Re: [Bacula-users] postgres load at restore

Am 30.08.24 um 10:49 schrieb Marcin Haba: On Fri, 30 Aug 2024 at 09:46, Stefan G. Weichinger > wrote: Sounds great. May I ask why this isn't enabled by default? Hello Stefan, Yes, it is a good practice and a good idea. I think it isn't enabled by default because n

Re: [Bacula-users] postgres load at restore

On Fri, 30 Aug 2024 at 09:46, Stefan G. Weichinger wrote: > > Sounds great. May I ask why this isn't enabled by default? > Hello Stefan, Yes, it is a good practice and a good idea. I think it isn't enabled by default because not every Bacula user uses the Bvfs restore. > 2nd: I add this to my

Re: [Bacula-users] postgres load at restore

At first: thanks lot for the quick and detailed reply! Great support ... Am 29.08.24 um 18:25 schrieb Marcin Haba: Bvfs cache is a great function in Bacula that has many advantages. Unfortunately it also has some disadvantages. Before this cache is created it takes some time and resources t

Re: [Bacula-users] postgres load at restore

On Fri, 30 Aug 2024 at 01:22, Phil Stracchino wrote: > > 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. > > Well, I just tested my revised dbcheck script with inline bvfs cache > clear and rebuild, and

Re: [Bacula-users] postgres load at restore

On 8/29/24 14:32, Marcin Haba wrote: On Thu, 29 Aug 2024 at 20:14, Phil Stracchino > wrote: NIGHTLY         Run all scheduled client backup jobs         Incremental rebuild bvfs cache         Run catalog backup WEEKLY         Clear bvfs c

Re: [Bacula-users] postgres load at restore

On Thu, 29 Aug 2024 at 20:14, Phil Stracchino 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 seem

Re: [Bacula-users] postgres load at restore

On 8/29/24 13:39, Marcin Haba wrote: On Thu, 29 Aug 2024 at 18:42, Phil Stracchino > wrote: 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 c

Re: [Bacula-users] postgres load at restore

On 8/29/24 14:32, Marcin Haba wrote: On Thu, 29 Aug 2024 at 20:14, Phil Stracchino > wrote: 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: The .bvfs_update without specifying

Re: [Bacula-users] postgres load at restore

On Thu, 29 Aug 2024 at 18:42, Phil Stracchino 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 jo

Re: [Bacula-users] 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

Re: [Bacula-users] postgres load at restore

On Thu, 29 Aug 2024 at 15:30, Stefan G. Weichinger wrote: > > today I had to restore 2 files from a job with ~800GB and 785318 files in > it > > this is bacula-15.0.2 and bacularis-3.2.1 on debian-12.6 > > When I tried the restore in bacularis and chose the needed Job-ID for > selection of the fi

[Bacula-users] postgres load at restore

today I had to restore 2 files from a job with ~800GB and 785318 files in it this is bacula-15.0.2 and bacularis-3.2.1 on debian-12.6 When I tried the restore in bacularis and chose the needed Job-ID for selection of the files, the postgresql-DB went to 100% (on one core) and the webserver t