Bacula-users

Re: [Bacula-users] Re-read of last block OK, but block numbers differ

2008-11-28 16:17:23
Subject: Re: [Bacula-users] Re-read of last block OK, but block numbers differ
From: Allan Black <Allan.Black AT btconnect DOT com>
To: Martin Simmons <martin AT lispworks DOT com>
Date: Fri, 28 Nov 2008 21:15:04 +0000
Martin Simmons wrote:
>> 23-Nov 22:06 gershwin-sd JobId 506: Error: Re-read of last block OK, but 
>> block numbers differ. Last block=4963 Current block=4963.
>> 23-Nov 22:06 gershwin-sd JobId 506: End of medium on Volume 
>> "MainCatalog-004" Bytes=28,148,843,520 Blocks=436,334 at 23-Nov-2008 22:06.
>> However: I also think that that catalog backup has actually been
>> corrupted, because I think the SD would write the data from block
>> 4963 at the beginning of the new tape, which means if I restored
>> that particular backup, I would find a block of data repeated.
> I would expect it to be OK, as long as the catalog says that block 4963 is on
> the second tape.

Thank for the reply; I am still not sure this is OK, though. Since my original
post, I have done a bit of research, and it looks like some drives actually
behave this way.

[ The block numbers refer to the physical position on the tape, BTW, rather
than being a sequence count within the backup data stream, so the first block
on the next tape will be block 0. I cannot use that to determine whether the
data has been written twice. ]

Apparently, some drives will write until they run out of tape, then they fail
the write and return EOM. However, some drives will detect *impending* end of
tape, and start giving you EOM a little bit before the physical end of the tape,
but they will still successfully write data.

> Have you tried the btape fill test?  That should check Bacula's logic for this
> case.

I admit I cannot now remember if I exhaustively tested this drive; I was
concentrating mainly on the DLT I use for the main backups. I'll dig out
a couple of blank tapes and test it though.

I will also get that catalog backup off the tape, and have a close look at
the SQL file I get back, in case there is a duplicated block of data.

I may move over to the devel list, actually, depending on how the tests work
out, just in case there is a (silent) problem with some drives. If there is,
however, the SD can easily detect the behaviour of the drive, because it gets
the block number back when it re-reads the last block on the tape.

Allan


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>