>>>>> On Tue, 18 Apr 2006 14:25:08 -0400, Emery Guevremont <[EMAIL PROTECTED]> >>>>> said: > Martin Simmons wrote: > >>>>>> On Thu, 13 Apr 2006 17:40:02 -0400, Emery Guevremont <[EMAIL > >>>>>> PROTECTED]> said: > >> 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? > > > > Yes, you could use dd to read the raw data from the tape, but the problem > > then > > is how to use this data with Bacula. It probably requires some more source > > code hackery. > > > > Another possible idea would be to dd all the tape files into separate files > > on > > disk. Then insert a new unlabelled tape and dd them back onto the new tape, > > but replace file 61 with another copy of file 39. I think that bacula won't > > care about the contents of this file. > > > > You might not even need to copy all the files back to the tape, just the > > first > > one (which contains the label) and the ones you need. > > > > Rather a long long shot... > > > > Got it! > > I did what you suggested. I took a blank tape and dd onto it the files I > was interested in. Here's what I exactly did on the command line, then > I'll explain: > > ---------- > # Device /dev/nst0 -> Original Tape > # Device /dev/nst2 -> Blank Tape > > mt -f /dev/nst0 rewind > mt -f /dev/nst2 rewind > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 0 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 1 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 2 > mt -f /dev/nst0 rewind > mt -f /dev/nst0 fsf 208 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 208 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 209 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 210 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 211 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 212 > dd if=/dev/nst0 bs=64512 of=/dev/nst2 # Copy of file 213 > mt -f /dev/nst2 rewind > bls -v -V "GKN079" AutoLoader > /tmp/files > > ---------- > > I had to copy the first file (at least), but to make sure I copied the > first 3, which contained the bacula label. Then using the mt command I > positioned the tape to file 208 and using the dd command I copied files > 208 through 213. I ran the bls command to view the contents, and > everything was there. I also successfully restored the files I needed > and their integrity checked out.
LOL, it's amazing what can be done from a shell prompt :-) > BTW how did you know to use the "bs=64512" option with the dd command? > Where did you get the 64512 size from? It is Bacula's default block size. On FreeBSD at least, dd gives an error without bs=64512 because the default buffer is too small. __Martin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
