Overview

The data on a Reality database can be saved in two ways: a logical save that extracts the files and accounts to be saved from the database, and a physical save that saves the data exactly as it is on the disk. In both cases, there are several TCL and host commands available, providing a range of save and restore options.

Logical Saves

Logical saves have the following advantages:

• A logical save is machine architecture independent and can be restored on a host with different byte ordering.
• The logical save utilities generate file statistics and perform a consistency check.
• Logical saves may be used as part of a procedure to optimise file layout in the database. See Improving Database Efficiency.
• Utilities are available to selectively restore accounts, files and items.

However, because a logical save has to extract the files and accounts to be saved from the database, it can take a long time, particularly for a large database.

Physical Saves

Physical saves are very much faster than logical saves - especially when performed to multiple tape decks simultaneously. However, they do have the following restrictions:

• Physical saves cannot be used on filestore databases (UNIX).
• 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.
• If the free-space table is being used for checkpointing and you run out of space, database updates will freeze until space becomes available (as each item of checkpoint data is saved, the associated checkpoint space is released). You can avoid this problem by using a host file or disk partition to hold the checkpoint data.
• Reality files on foreign databases cannot be saved.
• The physical save utilities do not generate file statistics nor perform a consistency check. If required, this can be done using the ALL-FILE-STATS command.
• The physical save utilities cannot be used to optimise file layout.

When performing a physical save to tape image it is strongly recommended that you compress the image. For physical saves, compression level 2 gives the best compromise between performance and file size.

Checkpointing

Physical saves use checkpointing so that Reality users can continue to work while the backup is carried out. When the backup starts, the database is momentarily frozen to ensure it is consistent and to allow a "snapshot" to be taken of the state of the database. Then, as the save proceeds, each time a block in the database is changed, the original data is copied to the checkpointing area. The data that is backed up is a mixture of unchanged data from the database and checkpoint data. The backup therefore accurately reflects the state of the database at the time the backup started.

By default, the checkpoint data is saved in the database's free space table. This requires no additional hardware, but has the disadvantage that if the database runs out of free space, user updates will be suspended until the checkpoint data has been saved . As each item of checkpoint data is saved, the free space is released.

As an alternative to using the free space table, you can specify a host file or disk partition in which to save the checkpoint data. This can be done by setting the FSCheckpointPath database configuration option, or by specifying a command option. This ensures that there is always space available for checkpointing the database and that normal database operation will not be affected while its is being backed up.

The checkpoint location you should use depends on how busy the database is likely to be during the save. If it is likely to be quiet or idle, you can use the free space table. If it is likely to be busy, you should checkpoint to a host file or disk partition; a disk can be dedicated to this purpose if necessary.

tlmenu

This menu-driven utility is primarily intended for administration of Reality's Resilience features. It includes commands to save and restore a database using FILE-SAVE/ACCOUNT-RESTORE, dbsave or SAVE-IMAGE/LOAD-IMAGE. Refer to The tlmenu Utility for details.