System disk backup

[Martin P.J. Zinser]

Well, the problem about "forgetting" to remount the second shadow disk after patch/upgrade can be easily solved.

1.) Break the shadow set, remove one disk and put it in a save place
2.) Mount another spare disk as the second shadow disk partner.
3.) After you are sure the patch/upgrade worked ok move the saved disk into your spare pool.

[John Gillings]

A few things to keep in mind...

(do html tags work here?)
First, never reduce a shadow set to less than 2 members. The purpose of shadowing is to protect you from hardware errors, NOT to assist in backups. The most likely recoverable hardware error you will encounter is a bad block. If your shadowset remains with 2 or more members, you are virtually immune to bad blocks. As soon as you reduce the shadow set to 1 member you DOUBLE your exposure to bad blocks over the risk of a single physical disk volume. If you care about your data...

Second, any backup of a file taken while the file is open, without the cooperation of the active process is suspect. That includes /IGNORE=INTERLOCK and files from broken shadowsets. You *MAY* get a good copy, but then again you might not. If your business matters, do not trust any file which generated an interlock warning.

I accept that some people have gotten away with this, and their backup savesets have successfully restored, but I've seen cases where they've failed. OpenVMS engineering does not guarantee you will get a useable backup.

Most of the files on the system disk are static. It's a waste of time and tape to take another copy of all of SYS$HELP every day or week.

The files that matter on a system disk are always open. You must therefore cooperate with the active processes to get a clean backup copy. CONVERT/SHARE is the simplest way.

See the Technical Journal article referenced in previous replies for more details (including using 3 member shadow sets).