realload
Restores a backup created with realdump or SAVE-IMAGE.
Caution
realload completely overwrites the contents of the specified database.
Syntax
realload
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
-h Display tape header. Do not restore backup.
-i Create image database. This will overwrite a database, deleting all its contents and replacing it with links to the specified tape image files. Example of usage:
realload -t<tape path list> -i -d<Dbase path>
-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 tapeParamsA 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 tapeDeviceListA 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 andACCOUNT-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).