realload

Restores a backup created with realdump or SAVE-IMAGE.

Syntax

realload [ –t tapeDeviceList || –n tapeUnitList ] {–T tapeParams} {[–h || –l || –v ]} {–u} {–x} {–y} {{–d} database}

Refer to Conventions for details of syntax conventions.

Syntax Elements

{–d} database Specifies the name or path of the database into which to restore the backup. If omitted, the backup will be restored into the current default database, overwriting any data that it may contain.

database must normally be the last parameter on the command line. The –d option allows you to place it anywhere on the command line.

–h Display tape header. Do not restore backup.

–l Display tape labels. Do not restore backup.

–n tapeUnitList A comma-separated list of tape unit numbers, as defined in the database config file.

–T tapeParams A string (enclosed in quotes) containing a comma-separated list of tape parameters. The list can contain the following:

type=typeNo The tape type – one of the following values:

1 = ½ inch tape (UNIX only)
2 = 8mm Exabyte tape
3 = ¼ inch (QIC) cartridge
4 = reserved
5 = DLT or 4mm (DAT) cartridge
8 = remote tape device
9 = tape image

The default is type 9.

If a list of tape units is specified (–n option), this parameter is ignored.

–t tapeDeviceList A comma-separated list of tape devices, tape image files, or remote tape definitions.

–u Sets the tape deck(s) off line on completion.

–v Verifies that all the specified tapes are readable. Does not restore the backup. Does not display the tape labels.

–x Verbose mode.

–y Answer 'yes' to all questions. Do not display the tape labels.

Restrictions

• realload may only be run by the database owner.
• Only one instance of realload may be run at a time on a database. realload cannot be run at the same time as realdump, SAVE-IMAGE or LOAD-IMAGE.
• realload can only restore a complete database. To restore individual files, restore the backup to a new database (created with mkdbase) and then use remote accounts and files to access its contents. The database may have a different configuration (in terms of number of stripes and stripe size) from the original database, but must have the same frame size and be large enough to contain the data – realload fails immediately if the skeleton database has a different frame size or is not large enough.
• If the save was performed in multi-deck parallel mode, you must use the same number of tape decks as when the backup was saved.
• A physical save cannot be restored on a host with different byte ordering; for example, a realdump save of a Windows (Intel) database can be restored on a Linux (Intel) system, but not on a Solaris (sparc) system. For long term archives it is recommended that a logical save format (using FILE-SAVE, for example) is used, because this is machine architecture independent.
• realload cannot be used to optimise file layout (unlike a logical save/restore). To do this, you must use logical save and restore commands, such as FILE-SAVE and ACCOUNT-RESTORE.
• If you are using Database Isolation, you must use realroot to select required instance of Reality before running realload.

Comments

realload locks the target database and shuts it down (logging off all users) before starting to load the data. Its previous lock state is restored when the load completes unless the load fails, in which case the database is left locked.

When complete, realload changes the restored free space table to match the database skeleton used. Loading an image into a larger database will therefore enable full use of the increased disk space.

You can also restore a physical backup from TCL by using the LOAD-IMAGE command.

The internal name of the restored database will be the same as that from which it was saved. To change the internal name to match that in the ROUTE-FILE, use the CUSTOMER.IDENT TCL command. The internal database name is used by TCL commands such as WHO.

If a CREATE-INDEX or DELETE-INDEX was in progress when the database was saved, the index concerned will be incomplete when restored and this could result in an unexpected reduction in performance. You can identify the incomplete indexes with LIST-INDEXES; the indexes concerned are marked as invalid. Incomplete indexes must be deleted and recreated if required.

If the data on the tape is encrypted, your REK file must contain the correct encryption keys to allow your users access. If transferring data from another database, you must load the keys (using the LOAD-REK command) after the restore has completed, so that the REK file is not overwritten. Refer to Copying Encrypted Data to another Host for more details.

Tape Units and Devices

If you are using tape unit numbers (–n option), these must have been set up in the database config file. When using multiple tape decks they can, if necessary, refer to different types of tape device.

If you use multiple tape devices (–t option), all the devices must be of the same tape type. If you need to use a mixture of tape types, you can use remote tape definitions that reference the local system (localhost) to hide the tape type from realload. For example, to access the tape image /users/realman/accounts.rti as a remote tape device, use:

localhost;/users/realman/accounts.rti;9

Examples

realload -n 2

Restores the default database from tape unit 2.

realload -n 2,3,4,5 -d ACCOUNTS

Restores the ACCOUNTS database from tape units 2 to 5.

realload -t localhost;/dev/rmt/1mbn;1,localhost;/users/realman/accounts.rti;9 -T "type=8" -d ACCOUNTS

Restores the ACCOUNTS database (which was saved in multi-deck parallel mode) from two local tape devices. The devices are a mixture of types (one is of type 1 – ½ inch tape, and the other type 9 – tape image), so they use remote tape definitions (type 8).