Operating System - OpenVMS
1748204 Members
3937 Online
108759 Solutions
New Discussion юеВ

Re: "Standalone" backup of system with Rdb

 
SOLVED
Go to solution
Jeremy Begg
Trusted Contributor

"Standalone" backup of system with Rdb

Hi,

I have been given responsibility for an AlphaServer running OpenVMS V7.2-1 with Rdb V7.0. It runs an application called DECfin.
This system is near end-of-life and no changes are planned or even anticipated, but it must be relocated to another site.

Prior to moving it I want to perform a full "standalone" backup of the machine. This will be done by booting from an alternate system disk then using BACKUP/IMAGE to copy all disks to tape. No application software will be running at this time.

There is a nightly backup procedure which uses RMU/BACKUP to copy the database files to another disk. I intend to run those commands immediately before shutting down the system and making my "standalone" backup.

If the worst happens and the backup tape has to be restored to replacement hardware, will the Rdb databases still be accessible? Or is there something else which needs to be done, e.g. RMU/RESTORE ?

Thanks,

Jeremy Begg
16 REPLIES 16
Robert Gezelter
Honored Contributor
Solution

Re: "Standalone" backup of system with Rdb

Jeremy,

To the best of my recollection, a standalone BACKUP will be complete. I would verify with the RDB manual, but the RMU operation should be only for extra insurance (a spare copy of the data).

Make sure that the /IMAGE backup also includes the /IGNORE=NOBACKUP flag. I have seen people be pole-axed when an important file has the NOBACKUP bit set because of an additional backup operation.

When moving volumes from disk-to-disk, it pays to consider the /IGNORE=NOBACKUP qualifier. Else one may be surprised.

Please check the manuals (and take a look at the files on the disk) to confirm the above.

- Bob Gezelter, http://www.rlgsc.com
Shriniketan Bhagwat
Trusted Contributor

Re: "Standalone" backup of system with Rdb

Hi,

Also use the /IGNORE=INTERLOCK switch in you BACKUP command. Below is the link for restoring the database using RMU.

http://www.pi-net.dyndns.org/docs/rdb/oraclerdb/gdmp7/gdmp_res.htm

Regards,
Ketan
John Gillings
Honored Contributor

Re: "Standalone" backup of system with Rdb

Jeremy,

> will the Rdb databases still be
> accessible?

Yes. This shouldn't be a problem. Since you can reboot a system without breaking Rdb, there's no logical difference between that and restoring a /IMAGE backup then booting, subject to Robert's caveat of making sure you specify /IGNORE=NOBACKUP.
(excellent advice, and probably in the category of "it would only occur to you after you'd been bitten by it").

Having RMU backups as well means you could restore, boot, then RMU/RESTORE as another mechanism for recovering the data bases.

There's nothing magic about Rdb files. The issue for backing up and restoring is that databases consist of multiple files (and sometimes lots of them!). A coherent backup of a data base must have consistent, synchronised copies of all files. RMU knows how to find all the files and keep them in synch. It can also do on line backups by establishing transaction "fence" for the duration of the backup.

re: Ketan

>Also use the /IGNORE=INTERLOCK switch
>in you BACKUP command

Huh? Why would you want to ignore interlocks when the objective is a restorable backup? Especially when the backup will be performed standalone?

/IGNORE=INTERLOCK does nothing more than demote an -E- severity condition to -W-. Its only really useful function is to scavenge data from a file which is locked by another user. /IGNORE=INTERLOCK should only ever be used when you really don't care about losing data from locked files. That certainly doesn't apply to Jeremy's issue.
A crucible of informative mistakes
Jeremy Begg
Trusted Contributor

Re: "Standalone" backup of system with Rdb

Thanks for those responses. It probably won't surprise you when I say I'd put /IGNORE=NOBACKUP in the category of "yes I know that!" but thanks for pointing it out :-)

I had a vague recollection that Rdb was sensitive to VMS device names: if you move a database to a different volume, the database breaks. (Even if you do the move when Rdb hasn't been started.) The reason I mention it is that this is old hardware and if disaster struck during the move, it might not be possible to get a replacement system with the exact same disk configuration (a MYLEX host-based RAID controller with 5 logical drives).

Thanks,

Jeremy Begg
Bob Blunt
Respected Contributor

Re: "Standalone" backup of system with Rdb

Ouch, a RAID config? That, in itself, shouldn't be an issue but I'd definitely check the system to make sure that you've got the software loaded for RAID monitoring and control AND that you've got a floppy with RCU available. Make sure you're well aware of the setup of the RAID and take copious notes to be sure you can reconstruct IF necessary. Consider sourcing replacement disks in advance "just in case." You didn't mention if this was a single- or three-channel Mylex or the type Alphaserver. The three-channel controllers can be setup in rather challenging ways so I'd use the functions of the RAID utilities to map the config thoroughly.

My memory also tells me that RDB *was* device sensitive. I managed development and management clusters for a big project and we gave DECplan to the managers to track milestones. During the project we moved their cluster to new hardware (and from RD54s to DSSI) and I had to move the RDB base of the DECplan database. When I got it to the new box, at around midnight of course, I realized that the tool wasn't coming up properly and had to go back to the original systems and pull the database using RMU and restore it to the new disk. I can't remember if I had to do anything else to get it running. That was in the late VMS V5 release timeframe and RDB has gone through several releases in the interim.

bob
Jeremy Begg
Trusted Contributor

Re: "Standalone" backup of system with Rdb

Thanks Bob. Apparently HP is handling the move of the system and it will be their responsibility to manage the hardware. But I'll ask them to make a note of the RAID configuration if possible.

(I'm not on the same continent as this server. I saw it once, many years ago.)

Regards,
Jeremy Begg
Jan van den Ende
Honored Contributor

Re: "Standalone" backup of system with Rdb

Jeremy,

>>>
I had a vague recollection that Rdb was sensitive to VMS device names
<<<

This is where the Concealed Device can do magic! Rdb also honors them.
As long as I can remember, I have always enforced them (by moving them around in every Development environment on an irregular, but not-infrequent basis) changing the FYSICAL device location, but maintaining Concealed Device integrity.
But, alas, when you get existing systems to manage, that can usually not be done retrospectively...

Just my EUR 0.02

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: "Standalone" backup of system with Rdb

Counting myself as more paranoid here, I'd make an RMU /BACKUP here in addition to the BACKUP /IMAGE backup of the disk(s).

An Rdb database can be spread across multiple disks, for instance, and the RMU /BACKUP finds all the pieces and stuffs it all into one easily-restorable and easily transportable and easily archivable omnibus file.
Robert Gezelter
Honored Contributor

Re: "Standalone" backup of system with Rdb

Jeremy,

I second Hoff's comment about the RMU as a "belt and suspenders" point. I would also keep the backups at the original site until after the system is up at the new site (and then keep them off-site in a vault for safety; renovations have been known to have "burn-in" issues; good to have some "fire" insurance in the form of the backups).

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