Logical log backups

Logical log fans, This is an update on the logical log backup failures I reported to the net on November 3rd. First of all, a thank you to those who sent responses. Unfortunately, I have to report that the problem still exists. I will give a brief recap of the problem below for those who might not have noted it the last time. AND a slightly refined question at the end On several occasions, we have had tape drive failures on our 8mm drive dedicated to backing up our logical logs. The unix errno displayed by the Continuous backup process is usually 005. In addition it reports the following. "Please label as #1 in the log tape sequence.." followed by the range of logical log numbers supposedly covered on the current tape. When we examine the backup tape we find that it is missing one or more of the last logs that was supposed to have been written to it. The fact that it (they) were supposed to have been written is corroborated in the online.log file. A normal series of "Checkpoint Completed", "Logical Log nnnnn Complete" and "Logical Log nnnnn Backed Up" messages appears. Among the responses to my last posting were questions about tape capacity, tape quality, tape drive condition, and our tape parameter specifications. We have done what we can in that areas. We are running on-line 5.0 on IBM 6000 MOdel 580. We are using Memorex Data Catridges labeled 112 meters/367 feet Part Number 3202-3016. This is supposed to be good quality stuff we hear and I don't think we can be exceeding any rated capacity. Online we have 52 logical logs of 1 megabyte each and we specify unbuffered logging. We have had the failure occur with a tape holding as many as 567 logs and as few as seven. The only change we have made--as a result of a response from our posting--from the difficulties we reported earlier was in the tape parameters where we modified the the specification to no-rewind by changing the logical log specification from /dev/rmt1 to /dev/rmt1.1. With that change in place we have had the error occur twice in the last four days. That might suggest that we have some difficulty with the tape hardware, but it doesn't seem to change what appears to be a bug. The continuous logical log back-up is reporting erroneously that it is backing up some of logical logs. The documentation "Online Administration Guide", 3-38 states "If a logical log backup fails the next logical log backup session begins with the logical log file that was being backed up when the failure occurred." As nearly as I can tell, that is precisely our situation and we are not getting that logical log file backed up on either tape. Last time my question was fairly general. This time I would like to ask if any of you have definite experience with the process WORKING as documented. Specifially, have you ever had a tape drive failure while backing up logical logs? If so, have you reviewed the contents of the tape to verify that all the logical logs had actually been backed up? The only way I know is tblog with a command like this tblog -d /dev/mytape |grep number which will produce a series of "line number" lines listing the log ids on the tape. If you run -d /dev/mytape -n xxx where xxx is the number of the last log that should be on the tape, you should get a tblog output on the screen that ends with an error statement like "error trying to read from tape." This will tell you whether the log that was running during the failure was actually backed up. As documented, you should also get that same log backed up on the next tape you use for continuous backup. In our case we don't get that log in either place and on a couple of occasions, we have been missing more than one log. By the way, be a little cautious with tblog. without the -d switch it will try to read the on line logs which haven't been backed up yet which can affect performance. Also, tblog has a tape mount prompt in it. If you should try to redirect the output you don't see the prompt. Just hit enter a second time after entering the command if you are redirecting. If it has continuous back up has correctly survived a tape failure, please reply with a description of what you do that is "righter" than what we are doing. Many thanks in advance. -- ********************************************************* Con Woodall * "You can do anything Colorado State University * with a computer, but Veterinary Teaching Hospital * you might not want to." Fort Collins, CO 80523 * --Larry Whatshisname 303-491-1244, FAX 303-491-4414 * or Lauri Whatshername cwoodall@vth1.vth.colostate.edu * (1968) *********************************************************