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.
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
