Fatal Error during backups

[blaked97]

Hello all, when I tried to run our image backup procedure it generated a fatal error and hardly even got started. I was hoping someone here might have an idea what could be causing this.

Below is the log file generated by running the backup procedure:

$! Do some preliminary setup stuff.
$ SET VERIFY
$ SET NOON
$ SET PROC/PRIV=BYPASS
$ ALLOCATE MKA500: TAPE
%DCL-I-ALLOC, _BMVAX$MKA500: allocated
$!
$ show time ! Just for the fun of it.
15-DEC-2010 14:08:23
$!
$! Set today's date in YYMMDD format for journal filename and tape labels:
$ TODAY = F$CVTIME("","COMPARISON","DATE")
$ TODAY = TODAY - "-" - "-"
$ L = F$LENGTH(TODAY)
$ TODAY = F$EXTRACT(2,L-2,TODAY)
$!
$! Now lets get down to business and do the backups.
$!
$! Get tape expiration date (seven days from today):
$ EXPIRES = F$CVTIME("+0007-","ABSOLUTE","DATE")
$
$!
$ backup/ignore=(interlock,label_processing)/image -
/journal=dua0:[backup_bjl]bm_rod_data_101215.bjl/record -
disk$bm_rod_data: tape:bm_rod.bck -
/rewind/label=101215/tape_expiration=22-DEC-2010
%MOUNT-I-MOUNTED, 101215 mounted on _BMVAX$MKA500:
%BACKUP-E-OPENIN, error opening DISK$BM_ROD_DATA:[COMMUNICATION.OUTLET]UCX$FTPSE
RVER.LOG;1073 as input
-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-ACCONFLICT, DISK$BM_ROD_DATA:[RDB]ROD_DATABASE.RDB;1 is open for write
by another user
%BACKUP-E-FATALERR, fatal error on _BMVAX$MKA500:[]BM_ROD.BCK;
-SYSTEM-F-PARITY, parity error
%BACKUP-I-OPERSPEC
%BACKUP-I-OPERASSIST, operator assistance has been requested

I'd really like to get a backup done, but I'm not sure what is causing this. Any help would be much appriciated! Thanks!
-Blake

[Jan van den Ende]

Blake,

>>>

by another user
%BACKUP-E-FATALERR, fatal error on _BMVAX$MKA500:[]BM_ROD.BCK;
-SYSTEM-F-PARITY, parity error
<<<

Here is your real problem.
You have NOON in effect, so input errors are just noted and ignored.
But and error on your tape is (at least on SCSI, which is implied by MKxxx) UNrecoverable, so Operator Assistence is requested.

Firstly, use a cleaning tape.
Then, it is probably NOT wise to re-use this particular tape.

If this does not help, I fear you will need to replace the tape drive unit.

hth

Proost.

have one on me.

jpe

[GuentherF]

Blake,

your MKA500 has a problem. With PARITY it could be a media problem with a specific tape or, the SCSI bus is not proberly terminated or too long.

So either try another tape cartridge and/or check what might have changed with the SCSI cofiguration (which looks like what?)

/Guenther

[blaked97]

Well it may well be that it just needs a cleaning tape run through it! The "Use Cleaning Tape" light is on, however it seems that my last cleaning tape is no good anymore since the light stays on after the tape runs. Looks like I'll have to get some more ordered. We'll put this issue on hold until then and go from there.

Thanks for your help!

[Hoff]

Your tape is probably bad, or (in typical and decreasing order of likelihood) the tape drive heads are dirty or the tape drive is failing or there's a problem with the SCSI bus somewhere; bus termination, bus length, bad cable, problems with another device on the bus, etc.

To get an immediate failure rather than the current chatter with OPCOM that's occurring here, you can add the BACKUP qualifier /NOASSIST, or can enable and monitor the BACKUP OPCOM traffic on the operator terminals. (BACKUP with /ASSIST (the default here) can communicate with operators via the /REPLY /TO=id command/ mechanism.

There's also the discussion around the efficacy of overriding the file data consistency interlocks, and around the likelihood of getting a consistent copy of a live Rdb database via a means other than Rdb RMU. Neither of which are accomplished by the visible portion of the BACKUP procedure shown, unfortunately.

Moving to the use of READALL privilege is probably better than BYPASS here, but that's also a local decision. And whether the version of VMS here has that. You have UCX showing here, which implies something around V7 or earlier.

[John Gillings]

Blake,

Fairly obvious that if the tape drive is asking to be cleaned, it should be cleaned! If you've worn out a cleaning tape, it could also be that the drive is past its used-by date.

Personally, I think all tape drives are past use-by date. Obsolete technology. Disk storage is so cheap, I can't see the point fiddling about with media as fussy as tapes. Go spend a modest sum purchasing sufficient disk storage to make multiple copies of your data. Shadow everything and (maybe) copy one of the backup copies to tape if you're really paranoid.

The size of most VAX(?) SCSI disks is such that you could probably afford to use supermarket checkout special discounted USB sticks as single use repositories for your data.

Also, please realise that the combination of /IGNORE=INTERLOCK and an open RDB data base means you're NOT getting a reliable backup of your data base, BUT you're wasting time and tape shoveling a lot of (effectively random) bits.

>I'd really like to get a backup done,

Bluntly, there's little point in getting this backup done, as there's only a small chance you could successfully restore it (have you TESTED your restore plan?)

Add an /EXCLUDE list which bypasses the RDB data bases. Use RMU/BACKUP to get a reliable backup of your data base, then backup the resulting RBFs.

[Brad McCusker]

Blake,

Not to beat a dead horse here, but, as others have said, if you think you are backing up your database, you are not. You need to know that.

JohnG wrote:

>Add an /EXCLUDE list which bypasses the RDB
>data bases. Use RMU/BACKUP to get a
>reliable backup of your data base, then
>backup the resulting RBFs.

That's part of it, and would be an order of magnitude better than what you are doing, but there is much more to it than that, especially if you want to be sure you don't lose any data and you actually want to recover your data. See this link for more information on rdb backup strategies:

http://www.sciinc.com/remotedba/techinfo/articles/mi2a5.asp

Best Regards,

Brad McCusker
Software Concepts International
www.sciinc.com

[Bob Blunt]

While the problem is pretty clearly tape or data path related there are certainly types of tape that have longer lives than others, etc.

So, some fundamentals first, please.

What type tape drive
What type system
What O/S and what version
What patches.

We could wax rhapsodic for hours on the general behavior of certain tape types and drives. In general you and your staff need to exercise caution when it comes to tape handling and storage. Most importantly the tapes need to be stored at a temperature and humidity level near that of the place where your tape drive lives.

Your tape seems to be SCSI-based so you've got some limitations inherent in their behavior. Cartridge drives, in general, are generally not forgiving when they encounter media errors. SCSI drives and driver software are less flexible than older technology so once they encounter a problem they're generally less able to recover well.

I'm not, personally, ready to abandon some form of tape backup but my environment isn't a production shop nor is my data crucial to any business. There are many points of data that go into determining your BACKUP solution so it isn't a simple process of "throw out the XYZ tape drive and save all your data on "some cloud."" All the preceding responses make good points but you have to find the right solution for your set of circumstances. Circumstances we can't begin to guess without the right foundation.

bob