Hi, On 4/19/2007 5:03 PM, Ryan Novosielski wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Arno Lehmann wrote: >> Hi, >> >> On 4/18/2007 10:37 PM, Ryan Novosielski wrote: >> Arno Lehmann wrote: >>>>> Hi, >>>>> >>>>> On 4/18/2007 9:57 PM, Ryan Novosielski wrote: >>> ... >>>>>> Have you checked that the database is ok? >> I just did a mysqlcheck -A -- another backup is currently running, and >> the only thing I got is many warnings: >> >>> Well, I don't know much about the internals of MySQL, but I don't think >>> these warnings are serious. > > They don't appear when nothing has the database open, either, so it > appears as if I have no database problems. It has since occurred to me > that there probably only SHOULD be 1 file on this tape, as there are > only about 150MB on it. Why the tape itself has a record of 5 on it, I > do not know. Can bscan see old jobs that are recycled off of the tape?
This looks like there wasn't an EOD written to tape and the drive continues to read beyond the valid tape contents, and Bacula finds valid blocks there... interesting. >>> As long as the database is ok from MySQLs point of view, I think that >>> should be ok. You might consider running dbcheck, but I really don't >>> think this will find corrupt, but consistent volume records... > > Yeah, there is a lot of trash in there (and in fact it's been looking > for orphaned Path entries for almost 30 mins now). I may clean that up, > but I do know it's unrelated to this. > >> # ./mysqlcheck -A -u bacula -p >>> ... >> Only one backup is running right now, though, so would you expect this >> is something to be concerned about? I could restore a catalog backup I >> suppose -- one theoretically kicked off at the end of the last >> successful backup. Unfortunately at this point, that would likely mean >> redoing/bscanning the backup that's currently running (~25GB). >> >>> Hmm. So it's one bscan vs. one bscan... difficult choice. > > A bscan of 25GB is a pretty big bscan -- decided to skip that one. :) > >>>>> What would you do next if you were me? Scrap the tape and do new >>>>> backups? bscan? >>>>> >>>>>> Yup, bscan and compare with what the tape should hold according to the >>>>>> catalog. > > Interestingly enough, it seemed as if running a bscan turned up all > manner of jobs on the volume that should no longer be there -- a total > of 31 jobs. Really, there are 7 since that tape was recycled on Monday. > I don't really understand 100% what's going on here. See above... I you are really interested to see what's in the tape, I'd suggest to use btape for a more detailed analysis. At least I believe btape can assist i that, but I never had a case like that to understand. >> The manual says (and I'm considering copying Kern on this, because this >> ought to be corrected regardless of what the current state is): >> >> --- >> "Using bscan to Compare a Volume to an existing Catalog >> >>> Ah, there is some misunderstanding... I would do that comparison >>> manually, i.e. finding which jobs actually are on tape, and which should >>> be, according to the catalog. >>> If the first job on tape is what the catalog says it should be, bscan >>> the tape. If it isn't, scratch it. And see if the job is known to the >>> catalog... > > Another thing I see that bscan did, and I don't see this explained in > the manual, is create new jobID's for jobs that were already in the > catalog (ie. creating new jobID 2965 for jobID 2830). Hmm... I think this is expained in the manual, but perhaps it was some list conversation. Ok, I had a look into the manual and found this, in the "bscan" section: "In the case of a Job record, the new JobId will not normally be the same as the original Jobid. For example, for the first JobId above, the new JobId is 1, but the original JobId is 2. This is nothing to be concerned about as it is the normal nature of databases. bscan will keep everything straight. Although bscan claims that it created a Client record for Client: Rufus three times, it was actually only created the first time. This is normal." > However, when you > look in the jobs listing, these new jobs don't show up. Subsequent jobs > DO start with the next ID sequentially, however. Have you tried a query for the tapes contents? Perhaps the duplicate jobs show up there. It might be possible that Bacula itselfs restricts itself to unique jobs as determined by their name. That would be ok, since today, Bacula never should see duplicate jobs. Once job copies are implemented this might change, of course... >>> I wouldn't do a more detailed analysis - too much work for just seven >>> backups :-) > > Yeah, but it's a dry run for when it happens to be quite a larger number > (or quite a more important bit of data). > >> If you wish to compare the contents of a Volume to an existing catalog >> without changing the catalog, you can safely do so if and only if you do >> not specify either the -m or the -s options. However, at this time >> (Bacula version 1.26), the comparison routines are not as good or as >> thorough as they should be, so we don't particularly recommend this mode >> other than for testing." >> --- >> >> Has this been improved any, or should I still not really consider this >> an option? >> >>>>> Thanks for your help! >>>>> >>>>>> Good luck... ok, if it's only one tape there is not much trouble :-) >> Not only just one tape, but furthermore only one night of backups (7 >> incremental backups in all). Not really worth the trouble, except I >> really should get myself an education in what to do for this type of >> circumstance should I ever really need to know. >> >>> Isn't that the reason why we all spend so much time thinking about >>> problems, how to solve them, where to store bsrs of the catalog backups, >>> etc? - Just to prepare for a moment that (hopefully) never happens, and >>> if it does, it holds surprises nobody ever expected? > > Indeed the name of the game. So far, though, it seems as if Bacula at > least is making my life easy in that department. I've never had an error > I didn't understand, at any rate. Which is more you can say about many other backup systems, in my experience... > BTW, a continuation of this problem (which is now more educational for > me than anything else)... I'm seeing these in my syslog file: > > helios scsi: [ID 107833 kern.warning] WARNING: > /[EMAIL PROTECTED],4000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (st12): > Apr 19 10:46:46 helios Error for Command: read Error > Level: Fatal > Apr 19 10:46:46 helios scsi: [ID 107833 kern.notice] Requested Block: > 0 Error Block: 2293 > Apr 19 10:46:46 helios scsi: [ID 107833 kern.notice] Vendor: HP > Serial Number: 9 $DR-1 > Apr 19 10:46:46 helios scsi: [ID 107833 kern.notice] Sense Key: Media > Error > Apr 19 10:46:46 helios scsi: [ID 107833 kern.notice] ASC: 0x3b > (sequential positioning error), ASCQ: 0x0, FRU: 0x0 > Apr 19 10:50:21 helios scsi: [ID 107833 kern.warning] WARNING: > /[EMAIL PROTECTED],4000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (st12): > Apr 19 10:50:21 helios Error for Command: read Error > Level: Fatal > Apr 19 10:50:21 helios scsi: [ID 107833 kern.notice] Requested Block: > 0 Error Block: 2293 > Apr 19 10:50:21 helios scsi: [ID 107833 kern.notice] Vendor: HP > Serial Number: 9 $DR-1 > Apr 19 10:50:21 helios scsi: [ID 107833 kern.notice] Sense Key: Media > Error > Apr 19 10:50:21 helios scsi: [ID 107833 kern.notice] ASC: 0x11 > (unrecovered read error), ASCQ: 0x0, FRU: 0x0 > > I know this is hard to tell, generally, without some further > troubleshooting, but what has failed here? Block 2293 /is/ bad, it > seems, as it will report that one every time. However, the first warning > sounds almost like a drive problem to me. Can both be caused by a bad tape? I don't see a reason why the first warning should indicate a drive problem, and so I assume it all might be caused by a bad tape. Arno > - -- > ---- _ _ _ _ ___ _ _ _ > |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III > |$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) > \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGJ4Tbmb+gadEcsb4RAgXsAJ9xrOJs7d7RvqrH9ooCiqbbJ5unMgCbBVHt > NCPoIkfmipXHAEfL1JxC/AU= > =5BEv > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
