Level: Introductory Martin Fuerderer (martinfu@de.ibm.com), Software Developer, IBM
10 Mar 2005 Find out how to take advantage of the two new backup and restore features of IBM® Informix® Dynamic Server, Version 10.0. External Backup and Restore (EBR) is supported for setting up a High-availability Data Replication (HDR) server pair using either ON-Bar or ontape. Additionally, get details on how the ontape utility can now write and read data to and from standard input and output, rather than to or from a tape device or disk file.
Introduction
External Backup and Restore (EBR) is supported for setting up a High-availability Data Replication (HDR) server pair. EBR can be used for server storage spaces and is performed by operating system-provided utilities. EBR is now supported by ontape, as well as by ON-Bar.
The ontape utility can now write the backup data to standard output (stdout) rather than to a tape device or disk file. For a restore, ontape can now read data from standard input (stdin) rather than from a tape device or a disk file. This process uses pipes (an OS-provided buffer mechanism to connect separate programs to a data stream) for backups and restores.
External backup and restore for HDR setup
ON-Bar allows physical-only restore with External Backup and Restore (EBR) so that it can be used for HDR setup. In the HDR setup, the physical-only restore of the secondary server is followed by synchronization with the primary by a logical log roll-forward, where restoring logical logs from a backup medium is optional. The ontape utility also supports EBR for HDR setup.
Benefits
In a large environment, the initial setup of HDR takes a long time. This is mainly because of the necessary backup (on the primary server) and restore (on the secondary server). A complete cycle of level-0 backup and restore can take hours on very busy systems with large amounts of data. Additionally, the longer the backup and restore phase takes, the longer the synchronization time required during the logical-log replay phase.
The initial HDR setup time can be significantly reduced if EBR is used. During external backup the server needs to be blocked for a period of time, but using advanced storage techniques, this blocking time can be reduced. In addition, this feature facilitates the use of already existing external backups and thus prevents needing to take a backup specifically for setting up HDR.
EBR for HDR setup makes the procedure less disruptive for running production systems. For ontape users, ontape also supports EBR, providing a familiar interface for setting up HDR.
Description
Using the commands onmode -c block and onmode -c unblock, an external backup on the primary server is taken as described in the chapter "Performing an External Backup and Restore" of the IBM Informix Backup and Restore Guide. You choose the utility for performing the external backup or restore. The utility must be appropriate for the backup and restore of chunks used by Informix Dynamic Server and can depend on whether the chunks are on raw devices or are cooked files in the file system. A typical choice is the dd system utility provided on UNIX.
Because an external backup from a primary server is used to initialize the secondary server, the backup must be a level-0 backup. The backup must contain all chunks of all dbspaces, so that physical restore of secondary server can be completely performed with this backup. Therefore, you cannot perform the external level-0 backup of the primary server in separate steps using different pairs of onmode -c block/unblock commands. All storage spaces must be backed up within the same single pair of onmode -c block/unblock commands.
To restore the external backup on the secondary server, the storage spaces must first be physically restored using the chosen external method. To prepare the secondary server for the subsequent logical restore and recovery, use the command onbar -r -p
-e or ontape -p -e. These commands do not actually restore any data, because the data was restored by the external method. These commands start the server processes and bring the server into physically-recovered mode. At this point, the server is in exactly the same state as if it had been physically restored with a conventional method (for example, onbar -r -p or ontape -p).
In this state, the secondary server (still a standard server), can now be made into a secondary server using the onmode -d secondary ... command. After this command, the secondary server starts the logical restore and recovery in the same way as it would have if the physical restore was done with a conventional method. From this point forward there is no difference in the behavior.
Step-by-step procedure
To setup HDR using EBR:
- On the primary server, create an external backup. An external backup is always the equivalent of a level-0 backup.
- On the primary server, use the
onmode -d command to set the server type to primary and to indicate the name of the associated secondary database server.
- On the secondary server, perform a physical restore from the external backup that was created in step 1. Do not perform a logical restore.
- On the secondary server, use the
onmode -d command to set the server type to secondary and indicate the associated primary database server.
- If logical-log records that were written on the primary database server are no longer on the primary server disk, the secondary database server prompts you to recover these files from backup media. After you recover all the logical-log files on tape, the logical restore continues using the logical-log files on the primary server disk.
Figure 1. Conceptual view of HDR setup using EBR.
Figure 1 illustrates the following steps (user performed steps are marked with *):
On the primary server:
- * Execute
onmode -c block to initiate external backup.
- * Execute the external backup command.
- * Execute
onmode -c unblock to finish external backup.
- * Execute
onmode -d primary
secondary
to make the server the HDR primary.
On the secondary server:
- * Execute the external restore command.
- * Execute
onbar -r -e- p to start ON-Bar, or ontape -p -e to start ontape.
- ON-Bar (or ontape) starts the HDR secondary server process.
- The secondary server accesses and checks the disks, then reaches the log recovery phase.
- * Execute
onmode -d secondary primary
to make the server the HDR secondary server.
- The secondary server connects to the primary server.
- Ongoing log replay.
External backup and advanced storage techniques
One advanced storage technique that can be explored with the help of EBR is based on the concept that hardware or OS-level mirroring of storage disks is used to create a copy of all the database chunks used by Informix Dynamic Server. Mirroring is not only useful as a hot disk backup during normal operation, but also for an external backup. Disk mirroring can be split (at hardware or OS-level). During this split of mirroring, data needs to be consistent on the disks, which is what the command onmode -c block ensures. The splitting of disk mirroring usually takes from a couple of seconds to one or two minutes, but not longer. As soon as the split is completed, Informix Dynamic Server can continue normal operation without mirroring, after the onmode -c unblock is executed.
Therefore, from the perspective of Informix Dynamic Server and all its active users, the whole backup operation has been completed during the mirror splitting. This process works the same whether the amount of data is a few gigabytes or a terabyte. Afterward, while Informix Dynamic Server continues normal operation, the data from the mirror disks can be copied to a different location (for example, for HDR setup) or to some slower backup media like tapes. This process usually takes considerably longer, but because it does not affect the normal operation of Informix Dynamic Server, it is not a time-critical operation.
After the slower backup or copy operation is complete, the mirroring can be re-activated (at the hardware or OS level) to have the added security of continued mirroring and be prepared for the next external backup operation.
For HDR setup, the secondary server needs the restore of the external backup, but that can be achieved by copying the data from the split mirror to the secondary server disks. With the respective hardware this should also be a faster operation than a normal restore from a tape device. With this external physical restore on the secondary server complete, the secondary server then has to perform a log roll forward of the transactions that have since been done on the primary server. This catch-up is critical for the HDR server pair if they are to reach a state where the secondary server can truly be a hot stand-by for the primary server. The time needed for the whole HDR setup can be very important on a large and busy system.
Ontape backup and restore with stdio
The ontape utility can write the data to stdout (during backup) and read data from stdin (during restore). This is configurable using existing ontape parameters in the ONCONFIG file.
Benefits
You might want to further process the data that is collected during a server backup. For example, compression to save media space, cloning to duplicate the archive for safety reasons, or immediately use the data for a restore to another server instance. In all these scenarios it is not desirable to make an intermediate copy of the data on some permanent storage media (tapes or disks) only to read it immediately afterwards for further processing and thus making the intermediate copy obsolete.
Using pipes as an OS-provided memory buffer mechanism to handle the intermediate data flowing from one process to the next is a powerful facility to save both execution time and storage space. With pipes, the data is kept only in memory, neither expensive disk or tape writes and reads nor permanent storage space are required. Specifically, when an archive and restore are only performed to duplicate a complete server instance, that is, the archived data is immediately and solely used for a restore, this feature will avoid the overhead of any permanent storage altogether.
Configuration
You can configure ontape to read backup data from stdin or write backup data to stdout with the following existing configuration parameters for ontape (specified in the ONCONFIG file):
- TAPEDEV: The destination to which ontape writes storage space data during a backup and the source from which ontape reads data during storage space restore. The value used to configure stdout is
STDIO.
- TAPEBLK: The block size ontape uses to write to or read from TAPEDEV. For STDIO the block size is not used for writing to stdout or reading from stdin, since they do not have a block sizes. However, the value is still used for the transfer of data from the server to ontape (archive) or from ontape to the server (restore). Therefore a valid value is required.
- TAPESIZE: The capacity of the backup medium configured by TAPEDEV. For STDIO, the tape size is irrelevant, because there is no capacity limit for stdout or stdin. The capacity is generally considered infinite.
Backing up storage spaces
To create a backup of all (permanent) storage spaces of a server instance, use the command ontape -s [ -L level ], where level is 0, 1, or 2. With ontape it is not possible to backup specific storage spaces separately. Also, temporary storage spaces are generally not backed up.
With TAPEDEV configured to STDIO, the backup data is written directly to stdout, therefore, the data stream needs to be diverted, otherwise it is sent to the screen.
If ontape encounters an error while writing to stdout, the backup is aborted and the data that is already written cannot be used for a restore. Therefore, make sure that there is enough space for the backup data before starting ontape. For example, when ontape output is diverted to a file, then the file system must have enough space for the whole backup. As a guideline for the amount of data to be expected, use the output of the onstat -d command to display chunk sizes. From the Chunk section of the output, subtract the value of the free column from the value of the size column to obtain a good estimate of how much data a level-0 backup will produce. The sizes of a level-1 or level-2 backup are more difficult to estimate because only the necessary pages (changed since the last lower level backup) will be backed up. The maximum size of a level-1 or level-2 backup would be the same as the corresponding level-0 backup.
Examples:
The following command will create a level-0 archive of all storage spaces:
ontape -s -L 0 > /home/level_0_archive |
Stdout of the ontape command is diverted to a file named level_0_archive in directory /home. The file must either exist or the user executing the command must be able to create it. If it already exists, then the user must be allowed to write to it.
This command is effectively the same as having configured TAPEDEV to /home/level_0_archive, only in that case it would be treated as a tape device, that is, TAPEBLK and TAPESIZE would be effective when writing to the file or reading from it.
When using stdout, TAPESIZE is not effective. Therefore ontape will not ask for a new medium after it has written the amount of data specified by TAPESIZE. The OS is handling the data stream to the output file. If there is an error from the OS (for example, the file system is full), then ontape will abort when the error condition is propagated by the OS.
The following command will create a level-1 backup (assuming an appropriate level-0 backup has already been taken):
ontape -s -L 1 | compress -c > /home/compressed/level_1_archive |
Stdout of the ontape command is diverted to a pipe. The system utility compress reads from this pipe as input the data provided by the ontape command and compresses it before writing it to its own stdout. The data is diverted to file level_1_archive in directory /home/compressed. Again, the file must either exist and be write accessible for the user, or the user must have privileges to create the file.
The pipe in the command lets ontape send the data directly to the compress utility (by system memory used by the OS to implement the
pipe). No intermediate temporary file (with associated disk access) is required. Only the compressed data is finally written to the file system
(on disk).
Regarding TAPEBLK and TAPESIZE, the same considerations apply as in the previous example.
The following figure illustrates how ontape performs a backup to stdout:
Figure 2. Conceptual view of archive using STDIO.
Backup of logical log files
To backup logical log files, there are two main ontape commands: ontape -a (automatic log backup) and ontape -c (continuous log backup). The new feature does not support log backup but only the backup of storage spaces. Thus, STDIO as a value for the configuration parameter LTAPEDEV does not have a significant meaning. With LTAPEDEV configured to STDIO,
ontape expects a file named STDIO in the local working directory (from where ontape is invoked). After confirmation, ontape would write the logical log backup data to this file named STDIO.
Restore
A restore can be the restore of backed up storage spaces (physical restore), the restore of backed up logical log files (logical restore), or both. The new feature does not support logical restore.
Any restore can be restricted to restore only specific storage spaces (dbspaces). Also, chunk rename operations can be specified during a cold restore. These two options are not affected by the new feature, except that whenever the user would normally be prompted for input,
the prompting is omitted and ontape returns with an appropriate error instead.
The following figure illustrates how ontape performs a restore from stdin:
Figure 3: Conceptual view of restore using STDIO.
The normal restore (without STDIO configured) is much more user-interactive than a backup. With STDIO configured, ontape cannot be interactive in the same way because stdin is no longer connected to the user keyboard, resulting in several differences to normal operation:
- Log salvage:
A normal restore prompts the user for logical-log salvage. The user can answer yes or no. With STDIO configured, there is no such prompt and no logical log salvage is performed.
A log salvage can be performed prior to the restore with the new ontape -S option and with LTAPEDEV configured to proper files or devices. After the logs are salvaged, the restore using the new feature can be performed.
- Restore information:
During a standard restore, a great deal of information about the backup is printed to enable the user to identify whether the backup is correct. The user is then prompted to confirm the restore. This level of information and confirmation is omitted during a restore to stdin.
- Restore level-1 or -2 backup:
During a standard restore, after restoring a level-0 backup, ontape prompts the user to restore a level-1 or level-2 backup. During a restore to stdin, this prompting is omitted. Instead, the input stream is scanned for more data. If this data is found to be a level-1 backup, then it is restored. If the data is found to be inappropriate (that is, not backup data), then ontape will stop the restore and exit. If this happens, then the restore is probably not useful.
- Physical-only Restore:
The command ontape -p is used to perform a physical-only restore. With STDIO configured for TAPEDEV, ontape will read the data of storage spaces to restore from stdin and write it to the appropriate disk locations.
Examples:
cat /home/level_0_archive | ontape -p |
uncompress -c /home/compressed/level_0_archive | ontape -p |
cat /home/level_0_archive /home/level_1_archive | ontape -p |
This last command will restore a level-0 backup and subsequently a level-1 backup (assuming that it has been taken the same way as the level-0 backup).
- Combined Physical and Logical Restore:
In a standard restore, the command ontape -r is used to perform a physical and logical restore in a single execution. Because restore of logical logs is not supported by the new feature, it will be skipped during a restore to stdin. The difference to the physical restore command ontape -p is that the server will enter single-user mode. To perform both a physical and logical restore, execute two separate commands: ontape -p using STDIO followed by ontape -l using normal operation.
To perform a physical restore with STDIO configured, all the required data must be part of the input stream to ontape, and the data must be in the correct order. This means that first there must be a level-0 backup in the stream. After that a level-1 and or level-2 backup can optionally be in the stream. Logical restore is skipped and the server will enter single-user mode.
Example:
cat /home/level_0_archive [ /home/level_1_archive ] | ontape -r |
Combination of backup and restore
The greatest benefit of this feature is using it simultaneously for performing a backup and a restore: for example, to clone a server or to set up HDR. If the sole purpose of the backup is to duplicate a server, use the new -F option of ontape. The backup is then hidden from regular scheduled backup and does not affect subsequent level-1 and -2 backups. See the next section for more information.
Example:
ontape -s -L 0 -F | ( rsh secondary hostname ontape -p ) |
This command will perform a level-0 backup of the server on the local machine, pipe the input to a remote machine by the system utility rsh, and perform a physical-only restore on the remote machine, which reads the data directly from the pipe. With no disk access involved, this process be a very efficient and easy way to set up HDR.
New ontape command line parameter -F
The command line parameter -F is new with ontape and has been introduced to support the STDIO configuration. Without STDIO configured, -F is ignored.
The database server records information about backups internally, mainly on the root reserved pages (see the output of the command oncheck -pr). This information is used by the server to determine whether a particular backup request is correct (for example, can a level-1 backup be done, has the necessary level-0 backup been completed) and to determine what data needs to be archived (for example, for a level-1 backup, only data that has changed since the last level-0 backup). This information is critical to correctly backup the data, so that it can be restored again to a consistent system.
When using the STDIO configuration, however there can be situations where a backup is performed, but it is not permanent and thus not restorable. When combining a backup and restore in a single operation like in the above example, a backup is performed, but it cannot be restored at a later time because it was only used through the pipe to immediately restore to another system. Such a backup is not saved on permanent archive media like a tape. Doing such a combined backup-restore command in between the normal backup schedule (involving level-0, level-1, and perhaps level-2 backups) breaks the logic of the schedule. The next level-1 backup after the combined backup-restore command would try to use the temporary backup as the base level-0 backup instead of the last real level-0 backup. There would be a gap of missing data between the last real level-0 backup and the combined backup-restore.
To avoid this problem, use the -F option. The effect of -F together with the STDIO configuration is that the backup information will not be recorded internally in the root reserved pages. Therefore, this backup will not affect a normal backup schedule and later level-1 or level-2 backups will backup the correct data with respect to their correct, real level-0 backup.
The meaning and effect of the -F option with ontape is different from the -F option for ON-Bar. These two should not be confused.
Conclusion
At first glance, these two new backup and restore features for IBM Informix Dynamic Server, Version 10.0 seem to address little more than ease-of-use for ON-Bar and ontape. But closer examination reveals that these features offer many new, better, and faster ways of handling data for backup and restore by enlisting countless system features or utilities that are otherwise not connected or usable with Informix Dynamic Server. This gives these two features quite powerful potential, not only with this new release of Informix Dynamic Server, but for the future as well with the help of new external methods and utilities.
Resources
About the author  | | | Martin Fuerderer is a software developer who has been working on IBM Informix Database Server for several years. He has been involved at various stages in the development of the two described features. |
Rate this page
| 
