VAX/VMS image backup of system disk

[Nahmad_1]

Hi There

I have a VAX 6610 VMS 5.5 image backup of system disk took ONLINE using the command /backup/image/log/verify dua0: mug0:dua0.sav/save

Would I be able to run the system ? if yes what could be missing etc ? How could it be fixed ?

Thanks in advance

Nahmad

[Volker Halle]

Nahmad,

yes, you can boot the system from this online image-backup. Whether everything will work depends on what you need to run your system.

You won't really miss - if you don't require those files - open .LOG files. Same for ERRLOG.SYS, ACCOUNTNG.DAT. Queue_Manager files may be a different story.

If you would have used /IGNORE=INTERLOCK, even more files would have been copied - although in a 'possible inconsistent state'.

Volker.

[Robert Gezelter · Accepted solution]

Nahmad,

As Volker has noted, an BACKUP/IMAGE produces a complete copy of the system disk with all the files on that disk (Thus, all files for a running system, to the extent that all the files are on that disk).

If files were modified while the BACKUP operation was in progress, these changes may or may not be included in the BACKUP. Most often, this effects log files (which are not generally a problem) and files such as the authorization file.

However, while the contents are a complete copy of the disk, the resulting tape is not itself bootable. The Standalone BACKUP utility must be used to restore the tape saveset to a disk before the disk can be bootstrapped.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

Except for file that open from time to time you can have application or db related stuff that is permanently locked. E.g. DSM files.
So, add/ign=int.

Wim

[Andy Bustamante]

Add the /ignore=interlock switch. Be aware this doesn't provide a static snapshot, it allows backup to make a "best shot" at a moving target. It's generally close enough to restore a system to operation, assuming you're willing to accept a bit clean up.

>>>Would I be able to run the system ?

Almost certainly probably yes.

>>>if yes what could be missing etc ?

As stated above, any files being modified. UAF, Rightslist, Queue manager files (be prepared to recreate queues and resubmit all jobs), Anything else being updated at the time of backup. See the log for an idea of what files might be at risk.

>>>How could it be fixed ?
Recreate the orginal files, use an older backup that may have worked, use convert/share to create a static file before the backup (that stricly speaking isn't a fix, it's a step to prevent the corruption you allow with /ignore=interlock).

With a VAX, you can create a bootable standalone backup kit with stabakit.com on an alternate disk. Boot from this limited kit or CD if available to create a clean system disk backup.

Andy Bustamante

[Hoff]

Is this an extension of this question:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1298864

Do you need to restore the disk image reliably?

If you do, then use standalone BACKUP.

BACKUP with /IGNORE=INTERLOCK is not a reliable online BACKUP, and I and others do end up patching those back together for folks that used that without knowing the implication, and that didn't have a good backup.

In particular, the qualifier can lead to silent data corruptions in the output saveset. (If HP believed this was reliable, then it would be a documented on-line archival solution, and could well be the default here, and we'd not be having this discussion.)

If you're experienced, go for it. But if you're here asking these questions, then you're probably not sufficiently experienced to recover from an arbitrary corruption. (In my experience, the queue database can be stomped, and I've seen other stuff stomped, too.)

As for what can go wrong, that's an open-ended question. You might be lucky, or you might well need a call to HP or to a third-party to patch your disk back together.

[Robert Walker_8]

Gday,

The answer is Yes you will be able to run however files open are going to more than likely come up as "no such file" (as they wont be backed up unless /ignore=interlock - however could still be corrupt). I have done this a number of times to build systems quickly.

This will more importantly include the audit log and queue database file. Others such as accounting and operator log arent that important unless you need them for historical purposes. SYSUAF and RIGHTSLIST will normally be ok. All exes are generally open - those installed but again they arent written to (or shouldnt be) - I suppose shared memory segments backed to file ($cremap or whatever the service name is these days may also be an issue).

I always do
1. show dev/file /out=a.a
2. search a.a exe /match=nor

You can ignore msg, logs (unless needed for historical).

I would also shutdown software which isnt needed to be running at the time (eg pathworks, etc), you could even do queues and auditserver if able.

How to fix - well if you didnt shutdown audit and queues then these need to be shutdown on the other system and copied over manually. Boot existing system using MIN startup is probably the best way - also probably best way to get your online disk image if you can afford the downtime.

If you were just replicating the server then you could recreate queue ($ init/queue/mana or something) and same with audit server.

You will also probably have to upon restoration of your online image start it up in min (possibly boot with bypassing sys$system:startup.com - this is done by booting server into sysgen and setting startup=opa0 - however warning first thing to do at that point is to set no on otherwise any mistake and youll have to reboot - also when finished set startup=sys$system:startup.com again - best to do show startup first to get details prior to changing it)

Regards,

Robert.