Completing restores with Informix
During an Informix restore, the data is copied back to the storage spaces from a backup. Following are some scenarios that might require a restore:
- The entire server system is unavailable (you cannot bring the server to online mode)
- A critical storage space, such as the root dbspace or the storage space that holds the logs, is unavailable (one or more of the chunks are marked as down)
- A non-critical storage space is unavailable (one or more of the chunks and their associated mirror chunks are marked as down)
A physical restore is the process of restoring the storage spaces that backed up with level-0, level-1, and level-2 backups. The physical restore process is very efficient, because it simply copies page images from backup media and places them on disk. A physical restore needs a level-0 backup. The level-1 and level-2 backups are optional and can be applied after the level-0 backup.
Logical restore is the process of further restoring the Informix instance using transactions found on logical log backup. The logical restore occurs after the physical restore. Because the logical restore does not copy pages, but rather replays transaction records, it is slower and less efficient than the physical restore process.
A cold restore occurs when the root dbspace or a storage space that holds the physical or logical logs is inaccessible. The database server must be in offline mode while performing a cold restore. Whole system restores are always cold restores, because all the storage spaces are being restored, including the critical storage spaces.
A warm restore occurs when the root storage space and the storage spaces holding the logical and physical logs are not affected. The Informix instance must be in online, quiescent, or fast recovery mode while performing a warm restore. If you want to restore only non-critical storage space while the engine is online, you can do a warm restore. A warm restore requires the rolling forward of the logical logs (logical restore) up to the current point in time so that the storage spaces are in a consistent state with the rest of the storage spaces.
A mixed restore is a combination of a cold restore of only the critical storage spaces followed by a warm restore of the non-critical storage spaces. While a mixed restore makes the critical data available sooner, the complete restore takes longer because the logical logs are restored and replayed several times: once for the initial cold restore and once for each subsequent warm restore.
A mixed restore is desirable, for example, when a server contains a root storage space, a logical log storage space, 3 one-hundred-gigabyte storage spaces containing business critical financial data, and 50 one-hundred-gigabyte storage spaces containing history data. It might be beneficial to recover the critical storage spaces and the 3 storage spaces containing the business critical data quickly using a cold restore. Once these storage spaces are restored and the system is available to users, the less important history data can be restored using a warm restore. While the total restore time for the system will take longer because the logical logs have to be applied twice and the warm restore has to share hardware resources with active users, a mixed restore allows business to resume more quickly.
During a parallel restore, multiple processes are spawned to restore
multiple storage spaces in parallel. Parallel restores are also
referred to as storage space restores. Storage space restores can be
used to restore a single storage space, multiple storage spaces, or an
entire Informix instance. Parallel restore is only available with
ON-Bar. With ON-Bar, storage space restores are performed in
parallel (unless BAR_MAX_BACKUP is set to 1). If you perform a restore
onbar -r command, ON-Bar restores
the storage spaces in parallel and replays the logical logs once.
With ontape, all restores are serial restores, because they restore one storage space at a time.
You can rename chunks by specifying new chunk paths and offsets during a cold restore. This option is useful if you need to restore storage spaces to a different disk than the one on which the backup was made. You can rename any type of chunk, including critical chunks and mirror chunks.
This type of restore performs the following validations to rename chunks:
- It validates that the old chunk pathnames and offsets exist in the archive reserved pages.
- It validates that the new chunk pathnames and offsets do not overlap each other or existing chunks.
- If renaming the primary root or mirror root chunk, it updates the ONCONFIG file parameters ROOTPATH and ROOTOFFSET, or MIRRORPATH and MIRROROFFSET. The old version of the ONCONFIG file is saved as ONCONFIG.localtime.
- It restores the data from the old chunks to the new chunks (if the new chunks exist).
- It writes the rename information for each chunk to the online log.
If any of the validation steps fail, the renaming process stops, and ON-Bar writes an error message to the ON-Bar activity log.
It is recommended that you perform a level-0 archive after you rename chunks, otherwise you will have to restore the renamed chunk to its original pathname and then rename the chunk again.
If you add a chunk after performing a level-0 archive, that chunk cannot be renamed during a restore. Also, you cannot safely specify that chunk as a new path in the mapping list.
The process of backing up the logical log files off the
disk to storage media before doing a restore is called logical log
salvage. A restore might be needed after a system failure; however some
logical log data might not have been backed up to backup media yet. This
data must be salvaged, because it will be required to recover the
system to the point in time of the failure. A cold restore after a
system failure automatically attempts to salvage any logs, but you
also have the option of manually salvaging the logs before the
cold restore. The ON-Bar salvage log command is
onbar -l -s. The ontape salvage log command
onbar -r command automatically salvages
the logical logs. Use combination of the
onbar -r -p and
onbar -r -l commands, if you want to skip
log salvage. With ontape, you can skip log salvage during a restore by
No to the question
Do you want to backup the logs?.
A point-in-time restore is a restore that recovers the data back from level 0,1, and 2 backups and rolls forward the logical logs up to a specific point in time or up to a specific logical log. A point-in-time restore enables you to restore the database server to the state it was in at a particular point in time. A point-in-time restore is always a cold restore that you can use to undo mistakes that might otherwise not be fixable.
An example of such a mistake is accidentally dropping a table. A complete system restore will restore the table during the physical restore, but it will be dropped again during the logical restore. A point-in-time restore lets you restore the data to the moment just before the table was dropped. When you restore the database server to a specific time, any transactions that were uncommitted at the specified point in time are lost. Also, all transactions after the point-in-time restore are lost.
A table-level restore can be performed using the archecker utility. The archecker utility restores tables using a schema command file that was provided during the restore. The schema command file contains the source table to be extracted, the destination tables where the data is to be restored to, and an INSERT statement that links the two tables. Table-level restores are described in more detail under Performing table-level restores with archecker.
An external backup or restore operation is performed external to the Informix server, without using ON-Bar or ontape during the backup or restore. The data is backed up or restored using a third-party tool instead. The database needs to be blocked for an external backup to ensure that all the data is saved for the same point in time. Often the data is mirrored on the disk, and during the block the mirror is split, so that the data can be saved from one of the copies while the other continues to be in use.
Following is a summary of steps required to perform an external backup:
- Block the database server using onmode -c block.
- Back up all the storage spaces and administrative files using a third-party tool or copy command.
- Unblock the database server using onmode -c unblock.
- Back up all the logical logs, including the current log, using
ontape -a) or ON-Bar (
onbar -b -l -c).