Examples of ON-Bar Restore Commands

The following sections contain examples of ON–Bar syntax for restoring data.

For an example of renaming chunks during a cold restore, see Renaming Chunks During a Restore (IDS).

Performing a Restore

To perform a complete cold or warm restore, use the onbar -r command. ON–Bar restores the storage spaces in parallel. To speed up restores, you can add additional CPU virtual processors. To perform a restore, use the following command:

onbar -r

In a warm restore, the -r option restores all down storage spaces and logical logs, and skips online storage spaces. A down storage space means it is offline or a chunk in it is inconsistent.

You cannot perform more than one warm restore simultaneously. If you need to restore multiple storage spaces, specify the set of storage spaces to restore to ON-Bar (see Restoring Specific Storage Spaces) or allow ON-Bar to restore all down storage spaces by not explicitly specifying any spaces.

In a cold restore, the -r option automatically salvages the logical logs, and restores all storage spaces and appropriate logical logs.

Restoring Specific Storage Spaces

To restore particular storage spaces (for example, a dbspaces named fin_dbspace1 and fin_dbspace2), use the -r option, as the following example shows:

onbar -r fin_dbspace1 fin_dbspace2

You can also specify the storage spaces to restore by listing them in a text file and passing the pathname of the file to ON-Bar with the -f option.

If any of the dbspaces that you request to restore are online, they are skipped in the restore. ON–Bar writes a message to the activity log about the skipped dbspaces.

Performing a Logical Restore

To perform a logical restore, use the following command:

onbar -r -l

The minimum amount of temporary space that the database server needs is equal to:

• The total logical-log space for the database server instance, or the number of log files to be replayed, whichever is smaller.
  Tip:
  To improve performance, replay logical-log transactions in parallel during a warm restore. Use the ON_RECVRY_THREADS configuration parameter to set the number of parallel threads. To replay logical-log transactions in parallel during a cold restore, use the OFF_RECVRY_THREADS configuration parameter. For more information, see your IBM Informix: Performance Guide.
• The total logical-log space for the coservers on which storage spaces are being restored, or the number of log files to be replayed, whichever is smaller. Each coserver must have enough temporary space for all its temporary log files.

Skipping Logical Replay (XPS)

The database server automatically skips logical replay when it is not necessary during a warm restore. For example, if you lose a dbspace that contains a large table that has not changed since its last backup, you can quickly restore it without replaying the logical logs. If all dbspaces being restored on a coserver meet the following criteria, logical replay is skipped for the warm restore:

• A backup or set of incremental backups exists for the dbspaces.
• No logging activity has occurred for the dbspaces since the last backup. Read-only (static) dbspaces will always satisfy this condition, unless they were changed to read-only after the last backup was taken.

If dbspaces are being restored on multiple coservers, logical replay is skipped on those coservers where no dbspaces need it and performed on those coservers where at least one dbspace needs it.

In the following onstat -d example, the S flag shows that dbspace dbnoreplay is a candidate for skipping logical replay. This S flag disappears the first time that a logging operation occurs in that dbspace.

Dbspaces
address number flags fchunk nchunks flags owner    name
a66c140 1      1     1      1       N     informix rootdbs
a68bea8 2      20001 2      1       N  S  informix dbnoreplay

The database server always replays the logical logs during a cold restore.

Restoring Data on Extended Parallel Server

To restore all dbspaces in a dbslice named fin_slice, use the following command:

onbar -r fin_slice

If you have a mixture of dbspaces to restore, some that require logical replay and some that do not, follow these steps:

1. Restore the dbspaces that do not require logical replay first.
2. Restore the dbspaces that require logical replay.

You can use the dbspaces restored in the first pass sooner but the total restore time might be longer. This method enables you to quickly restore tables in a data warehouse. For more information, see Skipping Logical Replay (XPS).

Performing a Physical Restore Followed By a Logical Restore

In certain situations, you might want to perform a restore in stages. If multiple devices are available for the restore, you can restore multiple storage spaces separately or concurrently, and then perform a single logical restore.

For information on what actions to take when an error occurs during a physical or logical restore, see Resolving a Failed Restore.

Salvaging Logical Logs

Decide whether you want to salvage the logical logs before you perform a cold restore. If not, the data in the logical logs that has not been backed up is lost. If a disk is damaged, salvage the logs if they are still accessible before you replace the disk. For more information, see Performing a Cold Restore.

The onbar -r command automatically salvages the logical logs. Use the onbar -r -p and onbar -r -l commands if you want to skip log salvage.

Avoid salvaging the logical logs in the following situations:

• When you perform an imported restore

  Salvage the logical logs on the source database server but not on the target database server. For more information, see Transferring Data with the Imported Restore.

• If you reinitialize the database server (oninit -i) before you perform a cold restore

  Reinitialization creates new logical logs that do not contain the data that you want to restore.

• If you install a new disk for the dbspace that contains the logical logs

  Salvage the logs from the old disk, but not from the new disk.

Performing a Cold Restore

If a critical storage space is damaged because of a disk failure or corrupted data, you must perform a cold restore. If a disk fails, you need to replace it before you can perform a cold restore to recover data.

Performing a Whole-System Restore (IDS)

A whole-system restore must be a cold restore and it must restore all storage spaces. A whole-system restore does not require you to restore the logical logs.

A whole-system restore requires a whole-system backup. However, you can perform a plain restore of a whole-system backup. If you use onbar -b -w to back up the whole system, you can restore with any of the following commands:

onbar -r -w         # whole-system restore (salvages logs automatically)
onbar -r -p -w      # physical-only whole-system restore (no log salvage)
onbar -r            # parallel restore of the whole-system backup
onbar -r dbspaces   # restore dbspaces from a whole-system backup
onbar -r -t time    # point-in-time restore
onbar -r -t time -w # whole-system point-in-time restore

If you use onbar -r -p -w, the database server is in fast recovery mode when the restore completes. Perform either a logical restore (onbar -r -l) or use onmode -m to bring the database server online. For more information, see Performing a Whole-System Backup (IDS).

Considerations When LTAPEDEV is Set to Null

A whole-system backup with LTAPEDEV set to /dev/null on UNIX or to \dev\nul on Windows does not back up the logical logs.

Using the -O Option in a Whole-System Restore

Use the -O option with a whole-system restore only to re-create missing chunk files. You cannot use the onbar -r -w -O command when the database server is online because the root dbspace cannot be taken offline during the whole-system restore.

Restoring Data Using a Mixed Restore

You can use mixed restore to reduce the time until urgent data becomes online and available when you need to restore the server. Urgent data is data that you deem as critical to your business operation, and should not be confused with critical dbspaces in the Informix server (the root dbspace and any dbspaces containing the physical or logical logs).

In a mixed restore you perform a cold restore on only the critical dbspaces and dbspaces containing your urgent data first. Because you do not restore all dbspaces in the system and you save the time necessary to restore those dbspaces, you can bring the server online faster. You then restore the remaining dbspaces in one or more warm restores.

For example, consider a database server with four dbspaces in addition to the root dbspace: logdbs, dbs_1, dbs_2, and dbs_3. Suppose the logical logs are stored in logdbs and the physical log is in the root dbspace. The critical dbspaces that must be restored during the initial cold restore are rootdbs and logdbs:

onbar -r rootdbs logdbs dbs_1

When the cold restore completes, you can bring the server online and any data stored in rootdbs, logdbs, and dbs_1 becomes accessible.

Next, run the onsmsync utility without arguments:

onsmsync

You can then perform a warm restore of dbs_2:

onbar -r dbs_2

Finally, you can perform a warm restore of all remaining dbspaces (for this example, only dbs_3):

onbar -r

Instead of performing two warm restores, you could have issued the onbar -r command, without specifying a list of dbspaces, immediately after the initial cold restore. This command would have restored all dbspaces remaining to be restored: dbs_2 and dbs_3. Conversely, in a larger system with dozens of dbspaces, you could divide the warm restore portion of the mixed restore into several warm restores, each restoring only a small subset of the dbspaces remaining to be restored in the system.

Strategies for Using Mixed Restore

To successfully implement a mixed-restore strategy, you should carefully select the set of dbspaces in which you place your databases and database objects at the time you create them. ON-Bar backs up and restores physical, not logical, entities. Thus, ON-Bar cannot restore a particular database or a particular set of tables. Instead, ON-Bar restores a particular set of storage spaces. It is up to you to track what is stored in those storage spaces.

For example, consider a database with the catalogs in the dbspace cat_dbs:

create database mydb in cat_dbs with log;

A table in this database is fragmented among the dbspaces tab_dbs_1 and tab_dbs_2:

create table mytab (i integer, c char(20)) 
fragment by round robin in tab_dbs_1, tab_dbs_2;

An index for the table is stored in the dbspace idx_dbs:

create index myidx on mytab(i) in idx_dbs;

If you need to restore the server, you cannot access all of the data in the example database until you have restored the dbspaces containing the database catalogs, table data, and index: in this case, the dbspaces cat_dbsp, tab_dbs_1, tab_dbs_2, and idx_dbsp.

To simplify the management and tracking of your data, it is recommended that you divide your set of dbspaces into subsets in which you store data of a particular urgency. When you create your database objects, place them in dbspaces appropriate to their urgency. For example, if you have data with three levels of urgency, you might want to place all the objects (database catalogs, tables, and indexes) associated with your most urgent data in a particular set of dbspaces or dbslices: for example, urgent_dbs_1, urgent_dbs_2, ....urgent_dbs_n. You would place all the objects associated with less urgent data in a different set of dbspaces (or dbslices): for example, less_urgent_dbs_1, less_urgent_dbs_2, ...., less_urgent_dbs_k. Lastly, you would place your remaining data in a different set of dbspaces (or dbslices): for example, non_urgent_dbs_1, non_urgent_dbs_2, .... non_urgent_dbs_r.

If you need to restore the server, you would first perform a cold restore of all critical dbspaces and dbspaces containing urgent data, urgent_dbs_1 through urgent_dbs_n. For example, assume logical logs are distributed among two dbspaces, logdbsp_1 and logdbsp_2, and the physical log is in rootdbs. The critical dbspaces are therefore rootdbs, logdbsp_1, and logdbsp_2.

You would perform the initial cold restore by issuing the following ON-Bar command:

onbar -r rootdbs logdbsp_1 logdbsp_2 urgent_dbs_1 ...  urgent_dbs_2

At this point you can bring the server online and all business-urgent data is available.

Next, perform a warm restore for the less-urgent data:

onsmsync
onbar -r less_urgent_dbs_1 less_urgent_dbs_2 .....  less_urgent_dbs_k

Finally, you can perform a warm restore for the rest of the server by issuing the following command:

onbar -r non_urgent_dbs_1 non_urgent_dbs_2 ... non_urgent_dbs_r

Alternatively, you can use the following command to restore all storage spaces:

onbar -r

Restoring Data to a Point in Time

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 typically used to recover from a mistake. For example, if you accidentally dropped a database, you can restore the server to a point in time just before you dropped the database.

A point-in-time restore is specified by including the -t option in the ON-Bar command; for example, onbar -r -t time. If you use the onbar -r -t time command, you must restore all storage spaces to the same point in time.

Performing a Cold Point-in-Time Restore

To restore database server data to its state at a specific date and time, enter a command using the date and time format for your GLS locale, as this example shows:

onbar -r -t "2004-05-10 11:35:57"

In this example, the restore replays transactions that committed on or before the specified time, including any transactions with a commit time of 11:35:57. Transactions in progress but not committed by 11:35:57 are rolled back.

Quotation marks are recommended around the date and time. The format for the English locale is yyyy-mm-dd hh:mm:ss. If the GL_DATETIME environment variable is set, you must specify the date and time according to that variable. For an example of using a point-in-time restore in a non-English locale, see Point-in-Time Restore Example.

Performing a Point-in-Time Cold Restore in Stages

You can perform a point-in-time cold restore in stages, similar to an ordinary restore in stages as described in the section Performing a Physical Restore Followed By a Logical Restore. Use the -t time option for both the physical and logical restore steps:

onbar -r -p -t "2004-05-10 11:35:57"
onbar -r -l -t "2004-05-10 11:35:57"

Performing a Point-in-Time Mixed Restore

You can perform a point-in-time mixed restore. Supply a point-in-time value to the initial cold restore by using the -t time option, then restore the remaining storage spaces in one or more warm restores. Do not include the -t time option in the warm restores.

The following example performs a cold restore for a subset of the storage spaces (including all critical dbspaces) in the initial cold restore, and then performs a warm restore for dbspace_2 and dbspace_3, followed by a warm restore of dbspace_4 and dbspace_5, and finally performs a warm restore of all remaining storage spaces:

onbar -r -t "2004-05-10 11:35:57" rootdbs logspace_1 dbspace_1 
onsmsync
onbar -r dbspace_2 dbspace_3
onbar -r dbspace_4 dbspace_5
onbar -r

onbar -r -p -t "2004-05-10 11:35:57" rootdbs_1 dbslice_1
onbar -r -l "2004-05-10 11:35:57"

Performing a Point-In-Time Restore with Multiple Timelines

When you perform more than one point-in-time restore, you create multiple timelines. You can specify any time in any timeline with the onbar -r -t time command.

Performing a Point-in-Time Warm Restore

You cannot perform a point-in-time warm restore. A warm restore of a dbspace will always roll-forward the dbspace to the latest time available in the logical logs.

Restoring from an Older Backup

By default, ON–Bar restores the latest backup. If you do not want to restore this backup (for example, when backup verification failed or the backup media was lost), you can restore from an older backup.

Performing a Point-in-Log Restore (IDS)

A point-in-log restore is similar to a point-in-time restore. The point-in-log restore stops at the time of the last committed transaction listed in the logical log. You must use point-in-log restore in a cold restore only and you must restore all storage spaces. To perform a point-in-log restore, use the following command:

onbar -r -n log_id

You can specify any log ID from any timeline to restore to a specific logical log. If the specific logical log applies to more than one timeline, then ON-Bar uses the latest one.

Restoring Online Storage Spaces

Use the following command to force a restore of online storage spaces (except critical dbspaces) in a warm restore:

onbar -r -O dbsp1 dbsp2

The database server automatically shuts down each storage space before it starts to restore it. Taking the storage space offline ensures that users do not try to update its tables during the restore process.

Re-Creating Chunk Files During a Restore

If the disk or file system fails, one or more chunk files could be missing from the dbspace. If you use the -O option in a warm or cold restore, ON–Bar re-creates the missing chunk files, including any necessary directories, before restoring the dbspace as long as enough space exists on the file system. The newly created chunk files are cooked files and are owned by group informix on UNIX or group Informix-Admin on Windows.

Restoring a Dropped Storage Space

If you accidentally drop a storage space, you can use a point-in-time restore or a point-in-log restore to recover it.

Deferring Index Rebuild After Logical Restore (XPS)

When logical log replay encounters a CREATE INDEX log record, by default ON-Bar schedules each such index for rebuild at the end of logical roll-forward. Since rebuilding an index can require a significant amount of time and requires share locks to be held on all table fragments on which the index is defined, you might want to turn off the automatic rebuilding of indexes.

To prevent ON-Bar from rebuilding indexes at the end of logical roll-forward, use the -I option in the restore command.

For example, the following command restores the entire system, without rebuilding indexes:

onbar -r -I

When you use the -I option with ON-Bar, any indexes that did not already exist at the time the backup was performed will be unavailable or might be unusable after the restore.

You can re-create the down indexes in one of the following ways:

• Drop and re-define them manually using the DROP INDEX and CREATE INDEX SQL commands.
• Use the onbar -r -i command. The onbar -r -i command only triggers index rebuild among storage spaces that are already online; it does not restore any storage spaces.

The -I and -i options are particularly useful if you have created many indexes since your last backup and have performed a mixed restore on the system. In this case, you might want to use the -I option in each phase of the mixed restore. Then, after you have restored the entire system, run the onbar -r -i command to re-create the down indexes.

Restoring Data when Reinitializing the Database Server

Any backups that you performed before reinitializing the database server are unusable. During initialization, ON–Bar saves the emergency boot file elsewhere and starts a new, empty emergency boot file. Do not use the copy of the emergency boot file unless you want to restore the previous database server instance.