"Standalone" backup of system with Rdb

[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