topic Re: BACKUP/IMAGE in Operating System - OpenVMS

BACKUP/IMAGE

IFX_1 — Sun, 21 May 2006 23:10:51 GMT

Hi All,
Is it possible to do backup/image of a system disk in already mounted disk? For example, I would like to do image backup of my system disk to this folder disk$backup:[backup]. What will be the correct DCL command?

Re: BACKUP/IMAGE

Steven Schweda — Sun, 21 May 2006 23:36:30 GMT

Sure, but you have all the worries about the
value of the BACKUP of open/busy files.

I'd start with something like:

BACKUP /IMAGE [ /VERIFY ] sys$sysdevice: -
disk$backup:[backup]save_set_name /SAVE_SET

Re: BACKUP/IMAGE

Karl Rohwedder — Sun, 21 May 2006 23:49:49 GMT

Ronald,

you may use the qualifier /IGNORE=INTERLOCK to allow backup to backup also files which are otherwise not treated due to lock conflicts.
But this does NOT mean, that the backup of such files is correct. Backup has no knowledge about data being held in buffers..., so this is NOT supported by OpenVMS engineering.

So much depends on your kind of 'open files', if it is just the OPERATOR.LOG you may loose some records at the end, if it is the queue file, the result could be worse.

On the other hand, in more than 20 years I havn't had a probem with it, but thats's no guarantee.

regards Kalle

Re: BACKUP/IMAGE

Vladimir Fabecic — Mon, 22 May 2006 01:15:23 GMT

I agree with Karl. Once I had to recreate queues after restore. But that was not a big problem.
Remember, having backup with IGNORE=INTERLOCK is much better than having no backup at all.
So, if doing standalone backup is not possible, do "online" backup rather than nothing.
Regards

Re: BACKUP/IMAGE

Martin Vorlaender — Mon, 22 May 2006 09:08:41 GMT

>>>
Once I had to recreate queues after restore. But that was not a big problem.
<<<

It can be if you have hundreds of queues, and haven't saved the commands to create them...

As a workaround, see http://h18000.www1.hp.com/support/asktima/operating_systems/0095D437-BBF6EF20-1C0097.html for DCL code that generate DCL procedures from the queue database.

cu,
Martin

Re: BACKUP/IMAGE

John Donovan_4 — Tue, 23 May 2006 06:10:09 GMT

Here at work, we have always looked upon the online IMAGE backup of the system disk as INCREMENTAL and only a system down, backup from CD (on the DS25s) FULL backup is the "go to" backup in an emergency. IMO if you look at online IMAGE this way you should be safe, however I HIGHLY recommend performing a periodic system down FULL backup. As stated above /IGNORE=INTERLOCK does the trick on an online backup, which are done daily here.

Re: BACKUP/IMAGE

comarow — Wed, 24 May 2006 14:31:57 GMT

As stated, /ignore=interlock is very commonly used.

In addition, I wanted to comment on losing queues. This is just one of the many ways queues can be lost. There's many ways the queue file can be corrupt.

It is a great insurance policy to maintain a file that will rebuild all the queues and forms on the system, thus if you have to rebuild your queue file, you are not under pressure. And, you won't have to restore an otherwise healthy disk.

Re: BACKUP/IMAGE

Jan van den Ende — Wed, 24 May 2006 17:44:42 GMT

Ronald,

Standalone Backup becomes a little bit problematic if you have a "Never-down" configuration.
We circumvent the /IGNORE=INTERLOCK problem by preceding our /IMAGE backups with a
$ CONVERT/SHARE of the open files to .BAK files.
And if we need to restore the disk, if any of the files should not look good, we can use the .BAK file, which is only a few minutes more stale than the backup itself.

Not often, but it DID get us out of thouble once when we looked to be in deep s**t.

hth

Proost.

Have one on me.

jpe

Re: BACKUP/IMAGE

Thomas Ritter — Wed, 24 May 2006 18:49:55 GMT

Ronald, we have all of our system disks on local SCSI buses. At any time we have spare system disks ready to go. Our system disks, but for some log files are ready only. The sysuaf et all are off system disks. We keep copies by using volume shadowing. Normally we have two members, then we add a third and then dismount it. Everytime we install patches we perform this routine. This enables us to recover by simply rebooting and selecting another system disk. The spare system disks are then backed up to tape. There are no open files. Out approach is also very handy when performing system upgrades. You do not want to find yourself in the position were you have to restore from tape. This can take some time. And if penalty conditions are in your contract, time will cost money.

Summary: Have spare system disks, use volume shadowing to make copies, backup copies to tape.

My aus 2 cents.

Re: BACKUP/IMAGE

John Gillings — Wed, 24 May 2006 20:43:34 GMT

Ronald,

Please don't do this! You won't get a reliable backup (I don't care how many people say they've gotten away with it, that's is no guarantee that you will!)

So we do a BACKUP/IMAGE/IGNORE=INTERLOCK on a booted system disk.

The files we're guaranteed to get are the ones that aren't open (most of which are available off the distribution media anyway) You really don't NEED multiple backup copies of HELPLIB! The ones we really NEED are mostly open (SYSUAF, RIGHTSLIST etc...), so we don't get reliable copies. What is wrong with this picture?

A typical system disk has maybe 10MB of data that really needs backing up, but it's mostly open all the time. Use CONVERT/SHARE to make copies of those files to another disk, then back them up while they're closed. Fast, reliable and you have online backup copies available for immediate use.

Take an offline, standalone IMAGE backup of your system immediately after upgrading or installing major patches. Even better take a backup to a disk. If you need to restore, lay down the image backup, or replace the drive, then restore the 10MB or so of always open files.

Even better, get all those open files OFF the system disk. Same strategy for backing up.

Re: BACKUP/IMAGE

Thomas Ritter — Wed, 24 May 2006 21:04:45 GMT

John, are you saying that the shadow another disk and dismount approach is flawed ? If so, how ?

Re: BACKUP/IMAGE

Allan Bowman — Wed, 24 May 2006 23:18:20 GMT

Ron,

Getting back to your original question, the responses from Steven and Karl seem to answer your question - the additional discussions about whether or not you end up with a valid backup have previously been beaten to death in other threads (I personally have never had an issue with an on-line image backup in over 15 years of doing them). One suggestion I would make is to not put the saveset in your [backup] directory - I always put it in [000000]. With older versions of Standalone backup, you could only reliably restore from the top level directory - I'm not sure of the status of the current version. Yes, you are creating the backup on-line and can put it anywhere (I have even done it across the network), but if you ever need to restore, you will probably be using Standalone.

Allan in Atlanta

Re: BACKUP/IMAGE

Steven Schweda — Wed, 24 May 2006 23:50:16 GMT

> [...] you could only reliably restore
> from the top level directory [...]

Really? You could (and can) only _install_
VMS (VAX) from save sets in the [000000]
directory, but I don't recall any problems
with any BACKUP operations from anywhere
else. (That's not a non-existence proof,
of course, and most of my restoration
experience involved tapes, which are pretty
much directory-free.)

Re: BACKUP/IMAGE

Wim Van den Wyngaert — Thu, 25 May 2006 03:11:42 GMT

In my opinion, a restore of a backup/ign=int results in about the same situation as when you have a crash (except that the risk for inconsistency between 2 files is greater due to the time of the backup). Even if you use convert as John said, you may find differences if you have bad luck.

And I never had any problems after a crash (but had statistically speaking not enough crashes).

So, not 100% save but save enough.

Wim

Re: BACKUP/IMAGE

IFX_1 — Thu, 25 May 2006 04:09:48 GMT

Thanks.
I'll consider what is appropriate and best enough to do recovery.