Re: bscan to update the last missing job

Am 02.06.26 um 20:45 schrieb Arno Lehmann via Bacula-users:
> Hi Pierre,
> 
> after reading through your messages on this topic, I wonder why you did not just use bextract to extract the latest catalog backup.
I use client encryption. I mean I'd read bextract cannot decrypt the encrypted data streams.
I'm wrong?

Here my command I tried before I realized the stream is encrypted:
bextract -v -b BackupCatalog.bsr /media/baculadisk1
It was quitted with:
02-Jun 12:34 bextract JobId 0: Error: Unknown stream=20 ignored. This shouldn't happen!
02-Jun 12:34 bextract JobId 0: Error: Unknown stream=20 ignored. This shouldn't happen!
bextract JobId 0: drwx------ 7 bacula bacula 20480 2026-06-01 02:06:37 *none*
02-Jun 12:34 bextract JobId 0: End of Volume "DISK035" at addr=1646238741360 on device "DiskStorage1" (/media/baculadisk1).2 files restored.

Would be nice by given simply the private ssl key so it can decrypt also the encrypted data.
But would be also a good workaround if the encrypted stream can be written clean on the fs
so maybe with openssl the written file can decrypt manually.

> However, I also wonder why the -m switch did not properly create the needed media records in the catalog database. I suspect that this may be due to the fact that the bootstrap file was used and did direct bscan to skip the volume header; however, at this time, this is speculation.
I used the bsr file of latest backup which i found on the filesystem in bacula's home:

# 01-Jun-2026 02:12:04 - BackupCatalog.2026-05-31_23.52.00_25 - Full
Volume="DISK035"
MediaType="Disk"
VolSessionId=22
VolSessionTime=1780252068
VolAddr=1618422790992-1629160209197
FileIndex=1-1
Volume="DISK035"
MediaType="Disk"
VolSessionId=22
VolSessionTime=1780252068
VolAddr=1629160209198-1639897627397
FileIndex=1-1
Volume="DISK035"
MediaType="Disk"
VolSessionId=22
VolSessionTime=1780252068
VolAddr=1639897627398-1646238741359
FileIndex=1-2

> In the Bacula environments I know of, we usually use a setup that uses a dedicated pool, media type and device for catalog backups, and writes each backup into its own volume, and thus such a scenario is not something I encountered recently.
I use Own Pool (Index) but media type is same (Disk) as my Daily Backups but use a different Storage Device (DiskStorage1).
But they are many jobs BackupCatalog jobs on the Media which fills up. Not the best idea but a cheap approach and could
be improved.

After realizing that bextract will not work I tried
/usr/sbin/bscan -b BackupCatalog.bsr -s -r -m  /media/baculadisk1 -V DISK035
but got update job and media errors. Wonder that the job was tried to update and not inserted in the database. Remember the database was
recovered (by a lvm snapshot merge) to an little older but consistant state so only this job for my index was missing.
So I though use a bscan with -m -s over the whole DISK035 needs some time (because bcrc is the limit).
So because runs only with round about 25 MB/s on my epyc system and bscan can use -b it should be possible to insert only
the missing job, which failed.
Here one log of my several tries:

bscan: bscan.c:440-0 Record: SessId=22 SessTim=1780252068 FileIndex=2 Stream=1 len=82
bscan: bscan.c:440-0 Record: SessId=22 SessTim=1780252068 FileIndex=-5 Stream=84813 len=194
bscan: bscan.c:1084-0 Fileset Catalog already exists.
bscan: bscan.c:1214-0 Updated Job termination record for JobId=84792 Level=Full TermStat=T
bscan: bscan.c:1299-0 Could not create JobMedia record. ERR=sql_create.c:135 Update Media record UPDATE Media SET EndFile=383, EndBlock=1266266991 WHERE MediaId=0 failed: ERR=02-Jun 13:02 bscan JobId 0: End of Volume DISK035 at addr=1646238741360 on device DiskStorage1 (/media/baculadisk1).
bscan: bscan.c:1013-0 Could not update media record. ERR=bdb.h:140 Update failed: affected_rows=0 for UPDATE Media SET VolJobs=1,VolFiles=0,VolBlocks=0,VolBytes=27812130636,VolABytes=0,VolHoleBytes=0,VolHoles=0,VolMounts=0,VolErrors=0,VolWrites=0,MaxVolBytes=0,VolStatus='',Slot=0,InChanger=0,VolReadTime=0,VolWriteTime=0,VolType=0,VolParts=0,VolCloudParts=0,LastPartBytes=0,LabelType=0,StorageId=0,PoolId=0,VolRetention=0,VolUseDuration=0,MaxVolJobs=0,MaxVolFiles=0,Enabled=0,LocationId=0,ScratchPoolId=0,RecyclePoolId=0,RecycleCount=0,Recycle=0,ActionOnPurge=0,CacheRetention=0,EndBlock=0 WHERE VolumeName=''
bscan: bscan.c:384-0 First Volume Size = 1646238741360
bscan: bscan.c:440-0 Record: SessId=0 SessTim=0 FileIndex=-6 Stream=0 len=0
bscan: bscan.c:1013-0 Could not update media record. ERR=bdb.h:140 Update failed: affected_rows=0 for UPDATE Media SET VolJobs=1,VolFiles=0,VolBlocks=0,VolBytes=27812130636,VolABytes=0,VolHoleBytes=0,VolHoles=0,VolMounts=1,VolErrors=0,VolWrites=0,MaxVolBytes=0,VolStatus='',Slot=0,InChanger=0,VolReadTime=0,VolWriteTime=0,VolType=0,VolParts=0,VolCloudParts=0,LastPartBytes=0,LabelType=0,StorageId=0,PoolId=0,VolRetention=0,VolUseDuration=0,MaxVolJobs=0,MaxVolFiles=0,Enabled=0,LocationId=0,ScratchPoolId=0,RecyclePoolId=0,RecycleCount=0,Recycle=0,ActionOnPurge=0,CacheRetention=0,EndBlock=0 WHERE VolumeName=''
bscan: bscan.c:669-0 End of all Volumes. VolFiles=0 VolBlocks=0 VolBytes=27,812,130,636 Records added or updated in the catalog: 0 Media 0 Pool 1 Job 2 File

So for example after create a bcopy -b to another fresh media on another volume
I was able to bscan the copy job and insert it in the database
but restore was not possible because of looks like missing data in the Media table.

It could be fixed than simply by recreated the empty database tables and restart the bscan of the
copied job. It than recreated all the relevant stuff correctly so I was able to restore the
backup file.

> For your sanity's sake, it might be useful to implement such an approach as well and to ensure your DR procedures work.
I think this would be great.

> On the other hand, the process you describe *does* look good to me, so the failure to create media records might be worth a bug report -- either the documentation or the bscan program needs touching, I think.
Yea, i think they are two problems:
The update instead of insert statement for the job I also
The missing read of the correct volume name and id.