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?
That question is way too complicated for me to understand much less answer. Perhaps the list can help you. > > Also, I have never upgraded, can you think of any issues with this upgrade > that aren't mentioned in the documentation. If you are talking about upgrading to BETA 1.39.30 to be able to use Migration, you may need what is in the CVS and not yet released as I have recently corrected a few (minor) problems with Volume migration. Concering upgrade issues: almost surely there are issues that are not documented, but I don't know what they are otherwise I would have already documented them :-) Good luck. > > 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 > > > > > > ------------------------------------------------------------------------- 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
