Hello, On 1/25/2007 6:53 PM, Nick Jones wrote: > I had a bad tape recently > > I have tried to verify if the tape is good or not, but I've run into > another issue. > > It now wrote the tape fine, and didn't error out at > Bytes=52,398,230,131. However, it wrote way more bytes that what > will fit on the tape. It is a 400 GB LTO-3 tape. > > | 22 | tape7 | Full | 635,479,838,715 | 636 | > 15,552,000 | 1 | 7 | 1 | LTO | 2007-01-25 > 08:52:41 > > Can anyone explain how the drive wrote so much data, or why it *thinks* it > did.
John explained this already, so I won't have to do it the 20th time now :-) > Also, I set up 2 different jobs that are meant to run on 2 different > tape sets (I have two tape sets of 7 tapes each) so I can have 2 full > backups that are in different places (to mitigate against the "grenade > in the server room" scenario :-). > > I am now getting these errors after running the second backup. > > 25-Jan 08:52 lcn-dir: There are no Jobs associated with Volume "tape1". > Marking > it purged. > > Does anyone have suggestions as to what happened to the job associated > with that backup? I purged a volume that was in the pool that was > associated with the job, because I think it has errors. I did not > think this would destroy the whole job. It does. A job is no longer usable after you removed parts of it, which you effectively did. Which doesn't matter much in this case, because when the tape might have been bad you wouldn't rely onto that backup anyway, right? Anyway, when you purge a volume all jobs associated with this volume get purged. This is probably the main reason for the informational message you get when invoking the purge command... Arno > Thanks everyone. > > Nick > > On 12/15/06, Kern Sibbald <[EMAIL PROTECTED]> wrote: > >>On Friday 15 December 2006 18:40, Nick Jones wrote: >> >>>Comments/questions inline. >>> >>>On 12/15/06, Kern Sibbald <[EMAIL PROTECTED]> wrote: >>> >>>>On Friday 15 December 2006 17:36, Nick Jones wrote: >>>> >>>>>Your explanation is correct. Here is the log which I should have looked >>>> >>>>at >>>> >>>>>and included in the original. >>>>> >>>>>12-Dec 23:19 lcn-dir: Start Backup JobId 6, Job= >>>>>BackupCatalog.2006-12-12_23.10.00 >>>>>12-Dec 23:19 lcn-sd: BackupCatalog.2006-12-12_23.10.00 Error: block.c >>>> >>>>:538 >>>> >>>>>Write error at 53:1 on device "Ultrium" (/dev/tape). ERR=Input/output >>>> >>>>error. >>>> >>>>>12-Dec 23:19 lcn-sd: BackupCatalog.2006-12-12_23.10.00 Error: Error >>>> >>>>writing >>>> >>>>>final EOF to tape. This Volume may not be readable. >>>>>dev.c:1542 ioctl MTWEOF error on "Ultrium" (/dev/tape). ERR=Input/output >>>>>error. >>>>>12-Dec 23:19 lcn-sd: End of medium on Volume "tape7" >>>> >>>>Bytes=52,398,230,131 >>>> >>>>>Blocks=812,226 at 12-Dec-2006 23:19. >>>>>12-Dec 23:24 lcn-sd: Invalid slot=0 defined, cannot autoload Volume. >>>>> >>>>>This happened after a full backup, then the backupCatalog job was >>>> >>>>running >>>> >>>>>and ran several times successfully, then this happened. Does this in >>>> >>>>fact >>>> >>>>>indicate a physical error on the tape? >>>> >>>>Yes very likely. >>>> >>>> >>>>>If so, I guess I just have to try to >>>>>get a refund or warranty on the tape which is disappointing. Ah well it >>>> >>>>is >>>> >>>>>not a big deal. >>>> >>>> >>>>>Do you know, is it possible to purge the tape, then run an incremental >>>>>backup where bacula knows (from the purge) that these files are no >>>> >>>>longer in >>>> >>>>>the catalog, and so it backs them up? >>>>> >>>>>I don't care much about leaving the tape in the pool as a 60GB volume, >>>> >>>>but I >>>> >>>>>do worry that I won't be able to recover data on this tape >>>> >>>>I wouldn't worry too much. It is very likely that all data to that point >>>>is >>>>OK. You could test that by running a Volume Verify on that JobId. >>>> >>>> >>>>>if it does in >>>>>fact have physical errors, and would like to get rid of it. >>>> >>>>I wouldn't put too much trust in such a tape myself. If you do nothing, >>>>the >>>>next time it is recycled, Bacula will start from the beginning, and if the >>>>error was temporary (possible but unlikely), Bacula will fill the whole >>>>tape. >>>> >>>> >>>>>Also I want to >>>>>avoid recreating the whole backup which takes awhile (24hr) with our >>>>>fileset. >>>>>FD Files Written: 45,422,838 >>>>>FD Bytes Written: 2,059,990,875,973 (2.059 TB) >>>>> >>>>>Can someone let me know if this is possible? >>>> >>>>You can load version 1.39.30 and use Migration to copy all the jobs on >>>>that >>>>Volume to a new Volume (or Volumes). >>> >>> >>> >>>Is there no other way to remove the tape without destroying the 'whole' >>>job?? Can't I purge the tape (I don't care about rewriting the 58GB on a >>>different tape, as long as it gets backed up on the next incremental backup >>>AFTER the data/volume has been purged) and thus bacula (via the catalog) >>>will think those files have essentially been added to the filesystem since >>>the last backup and add them to the appendable tape associated with that >>>job's pool? >>> >>>Also, I have never upgraded, can you think of any issues with this upgrade >>>that aren't mentioned in the documentation. >> >>By the way, just so it is clear, here is what I recommend doing in the order >>of my preference -- only one item needs to be done, IMO, not all: >> >>1. Immediately do a full backup. Keep the tape possibly pulling it from use >>when the volume is purged (mark it as non-recycleable). >>or >>2. Immediately do a Verify of the tape. If it is good, do nothing. If it is >>bad do item #1. Either mark the volume as non-recycleable, or chance it next >>time Bacula wants to write on it. >>or >>3. Upgrade to the current Bacula CVS code and migrate the data off that >>Volume, then return the tape for a refund. >> >> >> >>>Thanks alot >>> >>>PS. I love this product thus far. >>> >>>Nick >>> >>> >>> >>> >>>>>Thanks >>>>> >>>>>Nick >>>>> >>>>> >>>>> >>>>> >>>>>On 12/15/06, James Cort <[EMAIL PROTECTED]> wrote: >>>>> >>>>>>Nick Jones wrote: >>>>>> >>>>>>>Does anyone know why or how my tape7 could have been marked full >>>> >>>>even >>>> >>>>>>>though it is the same capacity as the other tapes and is not full >>>>>>>according to bacula. Now it is appending to tape4. Also, it is >>>> >>>>hard >>>> >>>>>>>to read but it says 0 for 'in changer' for tapes 1,2, and 4 which >>>> >>>>are >>>> >>>>>>>all in the changer and were listed as such at one time. All I did >>>> >>>>was >>>> >>>>>>>run a backup. How did these values become changed? How can I tell >>>>>>>bacula that tape7 is not full (it's pretty obvious it's not full >>>>>>>according to bacula's records). Also is it a problem that the tapes >>>>>>>are no longer 'in changer' ? >>>>>>> >>>>>>>Thanks alot for help or suggestions >>>>>> >>>>>>I've had exactly that happen when the tape media reports an error. I >>>>>>can't remember exactly where it's written, but IIRC the documentation >>>>>>says something to the effect that it's not always possible to >>>> >>>>determine >>>> >>>>>>the difference between a "tape full" message and an error on the tape. >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>Nick Jones >>>>>University of Iowa >>>>>Dept of Neurology >>>>>Systems Analyst >>>>>319-356-0451 >>>>> >>>> > > -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
