Martin Simmons wrote:
On Thu, 13 Apr 2006 14:27:45 -0400, Emery Guevremont <[EMAIL PROTECTED]> said:
Martin Simmons wrote:
On Wed, 12 Apr 2006 10:30:07 -0400, Emery Guevremont <[EMAIL PROTECTED]> said:
Martin Simmons wrote:
On Fri, 07 Apr 2006 10:43:30 -0400, Emery Guevremont <[EMAIL PROTECTED]> said:
I have a weird problem. I'm trying to restore some files from a tape
backup taken a few months ago.
The problem is that the files aren't on the tape. If I use the query
command in bconsole to find out which tape has the files, it says the
files are on tape GKN079. If I check the "last date written" field for
tape GKN079 it says Dec. 23rd 2005. I can also confirm the files I'm
trying to restored when backed up on dec. 18 and dec. 20.
Now when I use the bls command to list the different jobs contained on
the tape, it stops at a job done on dec. 15. This is the last entry from
my bls command:
JobId : 9417
VerNum : 11
PoolName : BDDump
PoolType : Backup
JobName : VMDBDmaitre-BDDump
ClientName : vmdbdmaitre-fd
Job (unique name) : VMDBDmaitre-BDDump.2005-12-14_20.05.11
FileSet : BDDump-fs
JobType : B
JobLevel : I
JobFiles : 531
JobBytes : 5,129,941,915
StartBlock : 0
EndBlock : 4,463
StartFile : 55
EndFile : 54
JobErrors : 0
JobStatus : T
Date written : 15-Dec-2005 08:15
bls: Got EOF at file 61 on device /dev/nst0, Volume "GKN079"
bls: End of Volume at file 61 on device /dev/nst0, Volume "GKN079"
bls: End of all volumes.
End of physical tape.
What I'm wondering is where are the jobs that were done between dec. 15,
2005 and dec. 23, 2005?
I've also used the bls command to list the files on tape and the last
file on tape dates back to dec. 15. Here's how bls end after listing my
files:
End Session Record: VolSessionId=153 VolSessionTime=1134158972
JobId=9417 DataLen=209
bls: Got EOF at file 61 on device /dev/nst0, Volume "GKN079"
bls: End of Volume at file 61 on device /dev/nst0, Volume "GKN079"
bls: End of all volumes.
Unknown Record: VolSessionId=0 VolSessionTime=0 JobId=0 DataLen=0
4417 files found.
What does unknown record mean?
Whether I look at the logs or on bconsole, no errors ever happened with
the backups between dec. 15 and dec. 23. Everything indicates my backups
should be on tape GKN079, but I don't see it on the tape. Is the tape
dying? BTW I also tried reading the tape on a different drive, and I got
the same result.
I suggest you post the output of running
select * from jobmedia where mediaid=xx;
from the bconsole sql command, where xx is the mediaid of GKN079. Also, what
is the jobid of the job you are trying to restore?
__Martin
The jobid of the job in question is 9580. I've attached a file that
contains the output from the sql query. The problem starts from jobid
9435. Every jobs after 8435 aren't available. One thing I noticed is
that there's no start or end file number 61, it skips from 60 to 62.
Could this be causing the problem?
Yes, possibly. I can think of three reasons why 61 could be missing now:
- There was an error during that job.
- There is a bug in bacula that writes junk.
- It has been pruned.
It is interesting that to see other gaps too, e.g. 39. From the numbering, it
looks like 39 might be from job 9410. Did that job run?
Yes this job ran with the termination status OK, but there was nothing
to backup so it's normal there was nothing on the tape for job 9410.
OK, perhaps it didn't record this in the database, though your dd output does
show a single 64512 byte block at that position on the tape.
Was the tape in the drive continuously for all of these jobs? If not, maybe
the discontinuities occur at the point where the tape was reinserted?
I'm using an Autoloader, and the tape is always in the drive.
If so, how do I force bextract to
skip fileid 61?
Given the "Unknown Record" error, it might not be mpossible. It could be
interesting to play with mt and dd to see what happens at various points on
the tape. Each "file" should be readable using dd and the size should be
slightly larger than reported in the job output. E.g. (parameters may need
adjusting):
mt rewind
mt fsf 38
dd if=/dev/nsa0 bs=64512 | wc -c # size of file 38
dd if=/dev/nsa0 bs=64512 | wc -c # size of file 39
dd if=/dev/nsa0 bs=64512 | wc -c # size of file 40
mt rewind
mt fsf 60
dd if=/dev/nsa0 bs=64512 | wc -c # size of file 60
dd if=/dev/nsa0 bs=64512 | wc -c # size of file 61
dd if=/dev/nsa0 bs=64512 | wc -c # size of file 62
__Martin
Size of file 38 is 894523392
Size of file 39 is 64512
Size of file 40 is 105348096
Size of file 60 is 423005184
Size of file 61 is 0
Size of file 62 is 350106624
So what can I do now?
0 is rather worrying. I think the problem might be that reading 0 bytes
(without error) is the way that the OS indicates the end of the tape, so
Bacula stops there.
That is done in Bacula's low level device handling code, so the only way to
make it read past there would be to hack the source...
Couldn't I use some other tool to extract the info from the tape? I.E.
the restore utility that comes with mt or cpio or dd?
begin:vcard
fn;quoted-printable:Emery Gu=C3=A9vremont
n;quoted-printable:Gu=C3=A9vremont;Emery
org:Croesus Finansoft
adr:;;2 Place laval, Suite 510;Laval;PQ;H7N 5N6;Canada
email;internet:[EMAIL PROTECTED]
title;quoted-printable:Administrateur des syst=C3=A8mes
tel;work:450-662-6101
tel;cell:514-513-3416
x-mozilla-html:FALSE
version:2.1
end:vcard
