Menu
▾
▴
[Bacula-bugs] [bacula 0000101]: VolumeToCatalog Verify Jobs Fail
|
From: <bac...@li...> - 2004-09-18 20:59:24
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000101 ====================================================================== Reported By: azjackfrost Assigned To: ====================================================================== Project: bacula Bug ID: 101 Category: Director Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 09-07-2004 09:38 PDT Last Modified: 09-18-2004 14:05 PDT ====================================================================== Summary: VolumeToCatalog Verify Jobs Fail Description: I run 6 Backup jobs followed by 6 VolumeToCatalog Verify jobs. I ran for weeks with only Backup jobs and no verify jobs and everything works perfectly. Now that I've started using the Verify jobs following the Backups, I've discovered a problem. Periodically, perhaps 3 or 4 days a week, the 6 Backup jobs will complete just fine, and then the very first Verify job will hang in error. What I get is a read error along with the message that the volume is not a "Bacula labeled volume". It just got through doing 6 Backup jobs and knew what the volume name was, so why when the first Verify job begins does it lose, erase, forget etc. the current volume name? The entire Backup & Verify may run 2 or 3 days with no problems, and then magically start with these volume name errors again. ====================================================================== ---------------------------------------------------------------------- kern - 09-09-2004 10:59 PDT ---------------------------------------------------------------------- Can you mount the tape that is bad, then do the following: - download beta 1.35.2 or 1.35.3, and build it -- no need to install it - using the 1.35.x bls, do - ./bls -p -j -v -c <your-conf-file> -V <the-volume-name> /dev/nst0 You might need to play with the options a bit. What I am trying to find out is if there is really data on the tape or it is blank or what. The -p option should cause bls to read past any trivial errors like missing labels, ..., but it may also die due to bad data. ---------------------------------------------------------------------- azjackfrost - 09-13-2004 07:21 PDT ---------------------------------------------------------------------- After the first Verify job fails, you are unable to mount the tape. Bconsole shows the device open but "not a Bacula labeled volume". The "bls" command doesn't work either. It just keeps prompting for the correct volume. If I perform only Backups, (no Verify jobs), the volume label stays intact and the "bls" command works just fine. Harv ---------------------------------------------------------------------- azjackfrost - 09-16-2004 10:22 PDT ---------------------------------------------------------------------- Kern, I finally got ver 1.35.3 compiled and ran the bls command you asked me to run. It appears that data IS on the tape, just no label. Not sure what happens to the tape label. I attached bls.log so you can review it. Also, I couldn't get depkgs-30Jul04 to complete. It would bail out of the make during the sqlite build and leave you sitting at a "sqlite>" prompt. I didn't know what to do, so I used depkgs-08Mar04 instead and it completed ok. regards, Harv Frost ---------------------------------------------------------------------- kern - 09-18-2004 14:05 PDT ---------------------------------------------------------------------- Well, after looking at your bls.log, I am a bit confused since it seems to have complained that the tape was not labeled but then the first thing it dumped was the tape label??????? Could you do another dump of the same tape? If that tape does not exist, please do the same bls command you did for the first dump, something like: ./bls -p -j -v -c <your-conf-file> -V <the-volume-name> /dev/nst0 Then do a second dump, which may create a huge amount of output. I only need the first few records, so please truncate the file before uploading it. The second command should be: ./bls -p -k -v -v -c <your-conf-file> -V <the-volume-name> /dev/nst0 The -v -v is important as it will dump the details of each block. I only need the details of the first two or three blocks. The output should look something like the following: bls: butil.c:168 Using device: "/dev/nst0" for reading. bls: Ready to read from volume "Test-2004-07-18:2" on device /dev/nst0. Volume Label: Id : Bacula 1.0 immortal VerNo : 11 VolName : Test-2004-07-18:2 PrevVolName : VolFile : 0 LabelType : VOL_LABEL LabelSize : 180 PoolName : Default MediaType : File PoolType : Backup HostName : rufus.sibbald.com Date label written: 18-Sep-2004 22:50 bls: block.c:81 Dump block 80926a0: size=216 BlkNum=0 Hdrcksum=c5934cbb cksum=c5934cbb bls: block.c:94 Rec: VId=1 VT=1095540643 FI=VOL_LABEL Strm=0 len=180 p=8095318 bls: block.c:94 Rec: VId=1 VT=1095540643 FI=141817983 Strm=378 len=0 p=80953d8 bls: block.c:81 Dump block 80926a0: size=378 BlkNum=0 Hdrcksum=873f87f cksum=873f87f bls: block.c:94 Rec: VId=1 VT=1095540643 FI=SOS_LABEL Strm=-7 len=147 p=8095318 bls: block.c:94 Rec: VId=1 VT=1095540643 FI=EOS_LABEL Strm=-7 len=183 p=80953b7 bls: block.c:94 Rec: VId=1 VT=1095540643 FI=879900715 Strm=1951214389 len=726814507 p=809547a bls: Got EOF at file 1 on device /dev/nst0, Volume "Test-2004-07-18:2" bls: Got EOM at file 1 on device /dev/nst0, Volume "Test-2004-07-18:2" Bug History Date Modified Username Field Change ====================================================================== 09-07-04 09:38 azjackfrost New Bug 09-07-04 09:38 azjackfrost File Added: kern 09-07-04 09:57 azjackfrost Bug Monitored: azjackfrost 09-09-04 10:59 kern Bugnote Added: 0000223 09-09-04 10:59 kern Status new => feedback 09-13-04 07:21 azjackfrost Bugnote Added: 0000230 09-16-04 10:19 azjackfrost File Added: bls.log 09-16-04 10:22 azjackfrost Bugnote Added: 0000243 09-18-04 14:05 kern Bugnote Added: 0000246 ====================================================================== |