1828036 Members
2053 Online
109973 Solutions
New Discussion

BACKUP/IMAGE

 
SOLVED
Go to solution
IFX_1
Frequent Advisor

BACKUP/IMAGE

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?

14 REPLIES 14
Steven Schweda
Honored Contributor
Solution

Re: BACKUP/IMAGE

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
Karl Rohwedder
Honored Contributor

Re: BACKUP/IMAGE

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
Vladimir Fabecic
Honored Contributor

Re: BACKUP/IMAGE

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
In vino veritas, in VMS cluster
Martin Vorlaender
Honored Contributor

Re: BACKUP/IMAGE

>>>
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
John Donovan_4
Frequent Advisor

Re: BACKUP/IMAGE

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.
"Difficult to see, always in motion is the future..."
comarow
Trusted Contributor

Re: BACKUP/IMAGE

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.
Jan van den Ende
Honored Contributor

Re: BACKUP/IMAGE

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
Don't rust yours pelled jacker to fine doll missed aches.
Thomas Ritter
Respected Contributor

Re: BACKUP/IMAGE

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.
John Gillings
Honored Contributor

Re: BACKUP/IMAGE

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.
A crucible of informative mistakes
Thomas Ritter
Respected Contributor

Re: BACKUP/IMAGE

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

Re: BACKUP/IMAGE

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
Steven Schweda
Honored Contributor

Re: BACKUP/IMAGE

> [...] 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.)
Wim Van den Wyngaert
Honored Contributor

Re: BACKUP/IMAGE

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
Wim
IFX_1
Frequent Advisor

Re: BACKUP/IMAGE

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