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!)