"Standalone" backup of system with Rdb

[Jeremy Begg]

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

[Robert Gezelter · Accepted solution]

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]

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]

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.

[Jeremy Begg]

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]

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]

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]

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

[Hoff]

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]

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

[GuentherF]

The RMU/ALTER command allows you to show the current disk devices used for the DB files. It also allows you after the image restore of the disk to change the disk device names.

As mentioned before, if the disk device name is a logical/concealed device name you just need to change the definition of the logical name. You could make that change BEFORE the image backup and test the DB with the logials in place - that's I would do it.

/Guenther

[John Gillings]

Jeremy,

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

That's kind of yes and no. Yes, the backup contains device names (usually logical names), but you can override them on restore.

We routinely restore Rdb data bases to different systems with different disk configurations and names. In some cases radically different, like from a large production system with data bases spread over many disks to a much more limited test system. That involves changing data base layouts as well as disk names. See:

$ RMU/BACKUP/RESTORE_OPTIONS=file

and the mirror image:

$ RMU/RESTORE/OPTIONS=file

You can edit the (text) options from the backup side to change the data base configuration on restore. Usual VMS paradigm, you only need to specify the attributes you wish to override. Everything else will be inherited from the saveset.

If you didn't save the options file on RMU/BACKUP, you can generate one from a saveset with:

$ RMU/DUMP/BACKUP/RESTORE_OPTIONS

or from a live database with:

$ RMU/DUMP/RESTORE_OPTIONS

For simple data bases

$ RMU/RESTORE/DIRECTORY=target

may be sufficient.

The only caveat I'd add is for some versions of Rdb there are some degenerate cases where the options file may contain syntactic errors. Easy to spot, and when they occur, the options file is usually superfluous (just a pain to deal with when automating generic data base restore).

[Jon Pinkley]

Jeremy,

Before you do your backups, verify that the mount count and transaction count on the disk to be backed up are 1. A show device/files should show only
Process name PID File name
00000000 [000000]INDEXF.SYS;1

If you have the time, I would also specify /verify on the backup command. Since the disk should be static during the backup, there should be no verification errors. I also agree with the recommendation to use /ignore=(nobackup), especially if you have not used DFU to search for files that have the /nobackup flag set. When we used Rdb at my previous job (more than 15 years ago), we set the database files to /nobackup because we used RMU for our "online" backups.

I would still use RMU/BACKUP to make a backup file, but probably would not use that backup to restore from unless there was a problem with the database backups made with the VMS image backup.

The other thing I have not seen mentioned in the thread, is dealing with the queue database. When you backup a system disk when booted off an alternate system disk, the entire queue database will be backed up and all entries will remain. You may want to set all batch entries to /hold (and keep track of what you did) so they will not immediately start when you reboot on the new system. Also, I would recommend making a "backup" of the batch queues with a tool like Jess Goodman's command procedures, which can be found at

http://dcl.openvms.org/search.php?query=goodman&what=stories&limit=100

You may want to read this thread, which covers a bit more about the queue database.

http://h30499.www3.hp.com/t5/System-Management/Backup-of-system-disk-through-Command-View-EVA-snapclone/m-p/4338198#M23056

If you are extra paranoid, you may want to do a backup/physical/verify in addition to the other backups. This will preserve any placed files, and can always restore to an identical disk, but not very useful for anything but a complete restore. If you do this, I would use a different set of tapes and would keep these in a different location than the /image backups.

I also second Bob's recommendation to keep the backup tapes separate from the system during the move.

Jon

[Chris Barratt]

Hi Jeremy,

I have this vague recollection of a statement that using RMU/BACKUP and RESTORE was the only supported way of taking and restoring backups of Rdb databases.

I'm sure the image backups, carefully done, would probably work. Personally, though, I would only ever use RMU for the moving of databases - and usually take the oppportunity to tweak some database parameter (there's always something) during the restore.

Cheers,
Chris

[Andy Bustamante]

As John points out you can restore an RMU backup to different devices names.

One of the Mylex options allows you to save the controller configuration to a FAT32 floppy. These can be very nice to have around in case the controller needs to be changed out.

I probably don't need say this, but while the system is in transit, don't leave the latest backup in the tape unit.

[Jeremy Begg]

Thanks for the extra information about RMU commands which might prove useful. I'll certainly have a play with them in the near future.

Regards,
Jeremy Begg

[Hein van den Heuvel]

How much data is there? No more than 100Gb right? Easy fit for any PC drive.

How about practicing with a Virtual Alpha, like FreeAXP or PersonalAlpha?

You may want to check that this is still ok under the usage terms.

It would be just to make sure the backups are useable, not to run production.

fwiw,
Hein