System disk backup

[Patrick_42]

Dear all,

I am now thinking of backing up system disk (sys$sysdevice) for my vms system.

The system disks are in general software shadowed (ie SYS$SYSDEVICE is pointing to DSAn: device)

Is it a correct practice by dissolving one member disk from the shadow set and then performing image backup from it?

Thanks,
Patrick.

[Guy Peleg]

Hello Patrick,

In theory you should not remove one member
and backup it. Data consistency is not guaranteed in this case, however in real life
this method is very popular and heavily used
by many users. In 99.9% of the times it works.

As long as you understand the potential risk,
I think it is fine.

Guy

[Patrick_42]

Thanks,

But, what should be the backup option when i am doing the backup?

Is the following series of commands ok(say $1$dua100) is the dismounted shadow copy?

$ mount /ov=id $1$dua100:
$ init $1$mkc100:
$ backup /image/ignore=interlock $1$dua100: $1$mkc100:system.bck /save
$ dismount $1$dua100:
$ dismount /unload $1$mkc100:

Sorry to bother, but, i have left VMS fields for 3 years...

Patrick.

[Mac Lilley]

Hello Patrick

To mount the former shadow member disk I think you need to include shadow_member in your override list

$ mount /ov=(id,shadow) $1$dua100:

Mac

[Ian Miller.]

You should perform occational standalone backups. For suggestions on what to backup on your system disk see the OpenVMS Journal Article
http://h71000.www7.hp.com/openvms/journal/v1/backup.html

There is no point in backing up most of the disk except when it changes and as pointed out in the article above using backup may not be the best way of backing up some things.

[Henk Hofman]

Patrick,

I have some suggestions for your backup.

$ mount /ov=id $1$dua100:
==> This is fine, adding the shadow option will
allow you to write to the disk but that
comes into play when you need to restore
for now I would leave it out.

$ init $1$mkc100:
==> use /media=comp if the drive supports it

$ backup /image/ignore=interlock $1$dua100: $1$mkc100:system.bck /save
==> No need ot add /ignore=interlock, you have
the disk mounted to your process only.
==> add /block=65024 for DLT drives, this saves
a lot of time
==> add /media=comp if the drive supports it,
used both on the init and the backup cmd.
==> If you can afford the time I would use
/verify to make sure your backup can be
read, after all that is the general idea.

$ dismount $1$dua100:
$ dismount /unload $1$mkc100:

[Rob Buxton]

A couple of people have already posted suggestions.
I use the method you're suggesting.
I do NOT use the /over=id when mounting it for the backup. There's no need as you're only reading from the device.
You do NOT need the /ignore=interlock as you've got exclusive access.

In addition I have migrated many of the files off the System Disk (e.g. the UAF Files) and I use a script to do a Convert/Share of these files to a backup location. Convert/share gets a cleaner copy of these files.
There was an item in one of the VMS Technical Journals the (wrapped) URL may be of interest.
http://h71000.www7.hp.com/openvms/journal/v1/backup.html

[Martin Johnson]

I very rarely perform a standalone backup of the system disk. I usually do a full or incremental with the ignore=interlock qualifier. The only data you will not capture is data in logfiles that are being updated.

We do a Disaster Recovery testing twice a year at SunGard. For the last ten years, I have never had a problem recovering my system disk from my backups.

HTH
Marty

[ShyGuy]

As been pointed out dissolving the shadow set or using /ignore=interlock are two ways to get a backup of a running system. But please make sure that you understand the risks with any of these options, even if the risk of getting a bad backup is small, that risk is still real.

Also, one of the later replies pointed out that all he ever lost by using /ignore=interlock was some updates to logfiles. It might however be different if you for example have additional applications installed on the system disk.

I've used both of these methods and standalone backup at different times and not had any problem. But test any backup-restore procedure before you put it into production, remember that it isn't the backup that is important - it is the ability to restore it into a working system...

/ShyGuy

[Terry Yeomans]

And don't forget to remount the shadow set:
MOUNT/SYSTEM DSAn: /SHADOW=($1$DUA100:) label
We have dismounted shadow sets to load patches onto the system as a security measure on disks with 2 shadow disks, and left this way for a couple of days to prove the patches. It is a risk, but we have not had any problems so far (touch wood!)

[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).