Image backup not found on tape

[Volker Halle]

Mike,

some accidental /REWIND or $ INIT MKB400: between the BACKUP commands ? Is image accounting turned on ? If so, look at the image accounting records for BACKUP.EXE ? Does the no. of image accounting records for BACKUP.EXE match the no. of disks backed up ? Any unexpected short execution time and/or exit status ?

Volker.

[Hoff]

Please post the DCL. All of it.

Please identify the specific MKA600: device.

I'd probably only use /NOCRC on the backups I didn't ever want to restore, particularly if this is (as I suspect) a DAT/DDS. DLT is rather more reliable than DAT/DDS, and I might consider turning off CRC. (DAT/DDS is very nearly write-once archival media, in my experience.)

Those file system interlocks being ignored are there to prevent silent data corruptions in the output BACKUP saveset or output disk, too.

Ignoring the label processing is fairly benign in some environments, but can also lead to cases where the media is overwritten.

There are cases of write-only tapes (and I've met a few of these over the years), a situation which has lead me to use /VERIFY. If you need seriously faster and are skipping /VERIFY to stay in your window and you don't have an Ultrium-class (fast) tape, you might want to go disk-to-disk-to-tape.

[Mike Smith_33]

I am making progress. I have run this same backup again and gotten the remote system disks savesets to show up. The tapes are sdlt. I have found a tape from before the flood, the disks are not on it but logfiles from that time are there. I will post more once I check a few more things.

[Mike Smith_33]

Thanks for all the replies so far, I will get points in for all once i get this straight.

I was able to recover old logs from 6 weeks or so ago and it shed great light on the issue. Both those disk were getting the following error:

%backup-f-procindex, error processing index file on $3$dka0:, RVN 1
-system-f-volinv, volume is not software enabled


I need to go look this up now. That is the update for now.

[Robert Gezelter]

Mike,

An -F- error, that would likely have terminated the backup. Also check for any definitions of the symbol BACKUP (perhaps /RECORD is on?).

BACKUP/IMAGE should work without the volume being write enabled.

- Bob Gezelter, http://www.rlgsc.com

[Mike Smith_33]

I will check the backup for the /record but I am 98% sure that is not there. What we think happened at this point is that at some point the system disk maybe through a shutdown or something were dismounted but did not leave this node cleanly resulting in a mount verify state on the drive. In fact I lost two hours early this morning when that exact thing happened on one of the nodes. At this point we believe that is what happened.

If anyone thinks this is far fetched, let me know.

[Jon Pinkley]

RE:"%backup-f-procindex, error processing index file on $3$dka0:, RVN 1
-system-f-volinv, volume is not software enabled"

RVN 1 indicates the backup thought that $3$dka0: was part of a bound volume set. For normal volumes the relative volume number (RVN) will be 0. I am quite certain that bound volume sets are not valid as system disks, so is the client sure that these were really system disks?

The message just seems really odd for a backup of a system disk.

Can you post the "sanitized" version of the backup command that was used? (you are evidently protecting the clients identity, which is fine, but please give us enough information help).

Jon

[Volker Halle]

Mike,

system-f-volinv, volume is not software enabled

is a CLEAR indication, that that disk was NOT correctly MOUNTED at the time the BACKUP ran. Most likely, the disk was in MntVerifyTimeout, because the MSCP-Serving node had been down for more then MVTIMEOUT seconds and that disk had not been dismounted and re-mounted after the other node came back.

Volker.

[Jan van den Ende · Accepted solution]

Mike,

>>>
In fact I lost two hours early this morning when that exact thing happened on one of the nodes.
<<<

Sometimes, the drive gets into MOUNT_VERIFY and does not respond to any commands before the timeout expires.

If that was.is the case, next time you CAN speed up things be enring
SYSGEN
USE ACTIVE
SHOW MVTIMEOUT (>>> and remember the CURRENT value
SET MVTIMEOUT
WRITE ACTIVE

In case of MSCP served, probably needed on all involved nodes

Now MOUNT verify times out

SYSGEN reset MVTIMEOUTto remembered value (on all changed nodes)

It is quicker han waiting!

hth

Proost.

Have one on me.

jpe

[Mike Smith_33]

Sorry it took me so long to respond, I was on a plane all day yesterday. I have requested a copy of the backup com procedure so if they send me that I will sanitize and post.

Thanks for the last few posts which have been extremely helpful. I definitely believe it is mount related.