Commit dee2e0b7 authored by O'Reilly Media, Inc.'s avatar O'Reilly Media, Inc.

Initial commit

\ No newline at end of file
## Example files for the title:
# Unix Backup and Recovery, by W. Preston
[![Unix Backup and Recovery, by W. Preston](](
The following applies to example files from material published by O’Reilly Media, Inc. Content from other publishers may include different rules of usage. Please refer to any additional usage rights explained in the actual example files or refer to the publisher’s website.
O'Reilly books are here to help you get your job done. In general, you may use the code in O'Reilly books in your programs and documentation. You do not need to contact us for permission unless you're reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from our books does not require permission. Answering a question by citing our books and quoting example code does not require permission. On the other hand, selling or distributing a CD-ROM of examples from O'Reilly books does require permission. Incorporating a significant amount of example code from our books into your product's documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN.
If you think your use of code examples falls outside fair use or the permission given here, feel free to contact us at <>.
Please note that the examples are not production code and have not been carefully testing. They are provided "as-is" and come with no warranty of any kind.
File added
File added
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.61 [en] (Win95; I) [Netscape]">
<title>Unix Backup &amp; Recovery Tools CD</title>
<table BORDER WIDTH="522" >
<td VALIGN=TOP WIDTH="29%" HEIGHT="562"><b><font size=+1>Unix Backup &amp;
Recovery Tools &amp; Procedures CD</font></b>
<p><b><i>This CD Contains:</i></b>
<p><b>Database Recovery Procedures for:</b>
<p>&nbsp; <a href="informix.html">Informix</a>
<p>&nbsp; <a href="oracle.html">Oracle</a>
<p>&nbsp; <a href="sybase.html">Sybase</a>
<p><b>An <a href="rfitable.html">RFI</a> for choosing backup software</b><b></b>
<p><b>Free Backup Utilities:</b>
<p>A one-step filesystem backup script: <a href="hostdump.tar"></a>
<p>A hot backup script for Oracle: <a href="oraback.tar"></a>
<p>A hot backup script for Informix: <a href="infback.tar"></a>
<p>A hot backup script for Sybase: <a href="syback.tar">syback.tar</a>
<p>A fast implementation of tar: <a href="star-1.2.tar">star</a>
<p>A tool to read bar tar images: <a href="badtar.tar">badtar</a>
<p>A tool to read pesky tapes: <a href=""></a>
<br><a href="code.html"></a>&nbsp;</td>
<td VALIGN=TOP WIDTH="71%" HEIGHT="562"><a href=""><img SRC="unixbr.gif" height=475 width=361></a>
<p>It is always a good idea to check <a href=""></a>
for updated versions of the free software contained on this CD, as well
as other resources.</center>
File added
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<center><font face="TIMES"><font size=+3>Recovering Informix</font></font></center>
<br><font face="TIMES"></font>&nbsp;<font face="TIMES"><font size=-1>Recovering
Informix is much easier than recovering other databases. One reason is
that the commands to actually perform the recovery are simple---there is
only one argument for <i>ontape</i> and only two arguments for <i>onbar</i>.
This section covers just about any recovery scenario that you might find
yourself in, yet it's only 20 main steps.</font></font>
<p><font face="TIMES"><font size=-1>Another reason that Informix recoveries
are simple is that the sysmaster database, physical log, and logical log
are considered critical. In order to recover one of them, you have to recover
all of them. In Oracle, for instance, there are four or five different
recovery tactics that you can take, depending on which one of these objects
is damaged. With Informix, there is only one recovery tactic.</font></font>
<p><font face="TIMES"><font size=-1>The Informix recovery procedure does
not assume that you know why your database went down. It does assume that
you have been making backups via <i>ontape</i> or <i>onbar</i>. It also
assumes that if you are using <i>ontape</i>, you know which tapes or files
contain the latest level 0 and/or level 1 backups, as well as the location
of all logical log backups since your last physical backup. If you are
using <i>onbar</i>, this procedure assumes you know how to use your storage
manager well enough that you know how to respond to its prompts for any
media that may not be in an autochanger. In short, all media management
is up to you.</font></font>
<p><font size=-1><font face="TIMES">The examples below use <i>ontape</i>.
The example hostname is <i>curtis</i>, and the instance name is </font><font face="Courier">crash</font><font face="TIMES">.
The archives are being sent to disk files named <i>/informix/logical/crash/crash.level.level.Z</i>,
and continuous backups are being sent to a disk file named <i>/informix/logical/crash.log</i>.</font></font><font face="TIMES"><font size=-1></font></font>
<p><font face="TIMES"><font size=-1>You should start with Step 1, "Does
oninit work?"</font></font>
<p><map NAME="flowchrt"><area HREF="#Step19" SHAPE="RECT" COORDS="383,803,505,889"><area HREF="#Step17" SHAPE="RECT" COORDS="21,950,158,1070"><area HREF="#Step16" SHAPE="POLY" COORDS="26,844,93,902,156,844,90,793,89,793,26,844"><area HREF="#Step15" SHAPE="RECT" COORDS="538,660,669,748"><area HREF="#Step18" SHAPE="POLY" COORDS="382,704,446,652,507,706,445,755,382,704"><area HREF="#Step7" SHAPE="POLY" COORDS="26,575,26,574,93,523,155,576,91,626,26,575"><area HREF="#Step8" SHAPE="POLY" COORDS="204,574,208,574,270,521,330,577,267,628,204,574"><area HREF="#Step10" SHAPE="RECT" COORDS="383,533,505,618"><area HREF="#Step12" SHAPE="RECT" COORDS="537,532,666,620"><area HREF="#Step13" SHAPE="POLY" COORDS="648,431,710,379,773,430,711,485,648,431"><area HREF="#Step11" SHAPE="POLY" COORDS="483,430,483,431,549,377,607,432,546,482,483,430"><area HREF="#Step9" SHAPE="POLY" COORDS="323,429,389,377,389,377,450,432,388,481,388,480,323,429"><area HREF="#Step5" SHAPE="RECT" COORDS="145,360,274,447"><area HREF="#Step14" SHAPE="RECT" COORDS="659,208,757,295"><area HREF="#Step6" SHAPE="RECT" COORDS="506,208,624,292"><area HREF="#Step4" SHAPE="POLY" COORDS="321,250,386,197,447,252,385,302,385,302,321,250"><area HREF="#Step5" SHAPE="RECT" COORDS="106,232,234,320"><area HREF="#Step3" SHAPE="RECT" COORDS="420,67,537,158"><area HREF="#Step2" SHAPE="POLY" COORDS="284,62,223,115,284,165,348,113,284,62"><area HREF="#Step1" SHAPE="POLY" COORDS="29,112,92,60,153,116,93,166,29,112"></map><img SRC="informix.gif" NAME="flowchrt" USEMAP="#flowchrt" height=1106 width=797></center>
<b><font face="TIMES"><font size=+1></font></font></b>
<p><a NAME="Step1"></a><b><font face="TIMES"><font size=+1>Step 1: Does
oninit Work?</font></font></b>
<p><font face="TIMES"><font size=-1>The obvious first step in determining
if an instance is in need of recovery is to try and start the instance.
Do this by issuing the <i>oninit</i> command with no options. If it works,
it just returns the prompt to you. You could also see one of two errors.</font></font>
<dir><font face="Courier"><font size=-2>curtis $ oninit</font></font>
<p><font face="Courier"><font size=-2>WARNING: Cannot access configuration
file $INFORMIXDIR/etc/$<i>ONCONFIG</i>.</font></font></dir>
<font face="TIMES"><font size=-1>This error is pretty obvious. If you see
it, you are missing your configuration file.</font></font>
<dir><font face="TIMES"><font size=-1>If you see the error above, proceed
to Step 2.</font></font></dir>
<font face="Courier"><font size=-2>oninit: Cannot open chunk '/informix/rootdbs.dbf'.
errno = 2</font></font>
<p><font face="Courier"><font size=-2>oninit: Cannot open chunk '/informix/rootdbs_mirror.dbf'.
errno = 2</font></font>
<p><font face="Courier"><font size=-2>oninit: Fatal error in shared memory
<font face="TIMES"><font size=-1>If any of your critical dbspaces has damaged
or missing chunks, you may see an error like the one above. If all critical
dbspaces are mirrored, and only one-half of the mirror is damaged, you
do not see this error. It also does not appear if a non-critical dbspace
is damaged. This error appears only if <i>all</i> chunks in a <i>critical</i>
dbspace are damaged.</font></font>
<dir><font face="TIMES"><font size=-1>If you see an error like the one
above, proceed to Step 4. If you don't see either error, proceed to Step
<a NAME="Step2"></a><b><font face="TIMES"><font size=+1>Step 2: Is the
onconfig File Missing?</font></font></b>
<p><font face="TIMES"><font size=-1>The <i>oninit</i> utility uses the
file to determine the basic information needed to start the instance. This
includes, but is not limited to, the following instance-specific information:</font></font>
<font face="TIMES"><font size=-1>The location of the root dbspace</font></font></li>
<font face="TIMES"><font size=-1>The location of the physical log</font></font></li>
<font face="TIMES"><font size=-1>The SERVERNUM value</font></font></li>
<font face="TIMES"><font size=-1>The base address of shared memory</font></font></li>
<font face="TIMES"><font size=-1>Sqlhosts information</font></font></li>
<dir><font face="TIMES"><font size=-1>If the <i>onconfig</i> file is missing
or corrupted, proceed to Step 3. If this is not the reason the instance
would not start, proceed to Step 4.</font></font></dir>
<a NAME="Step3"></a><b><font face="TIMES"><font size=+1>Step 3: Restore
or Recreate the onconfig File</font></font></b>
<p><font face="TIMES"><font size=-1>If you are running <i>onbar</i>, it
can automatically recreate the <i>onconfig</i> file. However, if this file
is the only one damaged, there's no need to do a full restore just to restore
this file. Restoring or recreating it is easy enough.</font></font>
<p><font face="TIMES"><font size=-1>If you are running <i></i>,
it makes a backup copy of the <i>onconfig</i> file before it changes it.
DBAs and other scripts often do the same. Look first to see if you have
such a backup copy. If not, try to restore the file from the nightly filesystem
backups. If you cannot find a backup copy, and cannot restore one from
backup, you will need to recreate it. If any of the following objects is
available, it will be easy:</font></font>
<font face="TIMES"><font size=-1>The chunk (or its mirror) that contains
the root dbspace</font></font></li>
<font face="TIMES"><font size=-1>A level 0 or 1 archive created by <i>ontape</i>
on disk</font></font></li>
<font face="TIMES"><font size=-1>A level 0 or 1 archive created by <i>ontape</i>
on tape</font></font></li>
<font face="TIMES"><font size=-1>To recreate the <i>onconfig</i> file from
the root dbspace chunk or an <i>ontape</i> archive on disk, run the following
command, where filename is the name of the chunk or archive on disk:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>strings <i>filename</i>|grep
'^[A-Z][A-Z_]*'</b> \</font></font>
<p><b><font face="Courier"><font size=-2>><i>$INFORMIX</i>/etc/<i>$</i>ONCONFIG</font></font></b></dir>
<font face="TIMES"><font size=-1>If you have only an archive available
on tape, the command is similar:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>dd if=<i>$TAPEDEV</i> bs=<i>$TAPEBLK</i>
<p><b><font face="Courier"><font size=-2>| strings |grep '^[A-Z][A-Z_]*'
<dir><b><font face="Courier"><font size=-2><i>> $INFORMIX</i>/etc/<i>$</i>ONCONFIG</font></font></b></dir>
<font face="TIMES"><font size=-1>This creates an editable text file that
contains all the parameters and their current values. The <i>grep</i> command
does not completely remove extraneous lines, so you should edit it and
remove any lines that do not look like the following:</font></font>
<dir><font face="Courier"><font size=-2>PARAMETER value</font></font></dir>
<font size=-1><font face="TIMES">If you do not have one of these objects
available, you need to manually recreate the file. Copy the <i>onconfig.std</i>
file in <i>$INFORMIXDIR/etc</i> to the name of the <i>onconfig</i> file.
The values that you must change are </font><font face="Courier">ROOTNAME</font><font face="TIMES">,
</font><font face="Courier">ROOTPATH</font><font face="TIMES">,
</font><font face="Courier">DBSERVERNAME</font><font face="TIMES">,
</font><font face="Courier">SERVERNUM</font><font face="TIMES">,
and </font><font face="Courier">SHMBASE</font><font face="TIMES">. These
values will allow you to restore the instance.</font></font>
<p><a NAME="Step4"></a><b><font face="TIMES"><font size=+1>Step 4: Is there
an Inaccessible or a Critical Chunk?</font></font></b>
<p><font face="TIMES"><font size=-1>If an Informix instance will not start,
the most common cause is a missing or corrupt critical chunk. (If a non-critical
chunk is damaged the instance starts and records the problem to the online
log file.) The error that you receive may look something like the following:</font></font>
<dir><font face="Courier"><font size=-2>oninit: Cannot open chunk '/informix/rootdbs.dbf'.
errno = 2</font></font></dir>
<font face="TIMES"><font size=-1>According to <i>errno.h</i>, an "Error
2" means "No such file or directory." This means that the chunk, or the
symbolic link that Informix uses to refer to that chunk, is missing. Another
common error is 13, which means "Permission denied." This means that someone
other than Informix owns the device. Any error other than those usually
means that the physical file is all right, but the data within it is corrupted.</font></font>
<dir><font face="TIMES"><font size=-1>If the file is missing or its permissions
are wrong, proceed to Step 5. If not, proceed to Step 6.</font></font></dir>
<a NAME="Step5"></a><b><font face="TIMES"><font size=+1>Step 5: Repair
or Replace the Missing Chunk</font></font></b>
<p><font face="TIMES"><font size=-1>This step is necessary only if the
physical file is somehow damaged. If it was a filesystem file, it might
be deleted or its permissions changed. If it was a raw device, the disk
drive could be damaged or missing, or its permissions could be wrong. Another
problem could be that you are using a symbolic link to the real chunk,
and the symbolic link was accidentally deleted.</font></font>
<p><font face="TIMES"><font size=-1>If the missing file is a symbolic link,
you simply need to restore or recreate the file in its original location.
The only difficulty part is that Informix doesn't tell you which file it
was symbolically linked to. Restoring the symbolic link from your regular
filesystem backups is probably the easiest answer. Another method would
be to consult any documentation that you may have about how you put the
instance together. (Restoring from backup is obviously much easier.)</font></font>
<p><font size=-1><font face="TIMES">If it is not a symbolic link, the damaged
file may be a filesystem file or raw device. If it is a filesystem file
and the filesystem itself is intact, simply recreate a new file with the
touch command. After doing so, make sure that the file is read/write for
the </font><font face="Courier">informix</font><font face="TIMES"> user
and </font><font face="Courier">informix</font><font face="TIMES"> group.
If the filesystem is not intact, you need to relocate the file. Hopefully,
you followed the common practice of using symbolic links to point to the
actual chunks. If you did, you can recreate the chunk file anywhere on
the system and just change the symbolic link to point to the new location.
If you did not, you need to make a symbolic link in the original location
to point to the new file.</font></font>
<p><font face="TIMES"><font size=-1>For example, assume that the filesystem
is destroyed, and it contained chunk <i>/data1/rootdbs.dbf</i>. However,
you set up the Informix instance to point directly to <i>/data1/rootdbs.dbf</i>,
instead of to a symbolic link to that chunk. You create a new file called
in <i>/data2</i>, but you have to tell <i>oninit</i> to use the new file.
You need to <i>unmount</i> <i>/data1</i> (although it probably is already)
and create a symbolic link in the old location with the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>ln -s /data2/rootdbs.dbf /data1/rootdbs.dbf</b></font></font></dir>
<font face="TIMES"><font size=-1>This is, of course, a very bad solution
since repairing and remounting /data1 will overwrite the symbolic link.
If you have to do this, consult your IDS Adminstration Manual about permanently
relocating the file. (Use a symbolic link this time.)</font></font>
<p><font face="TIMES"><font size=-1>Before continuing, you may wish to
verify that all chunks are all right. If you don't have a complete list
of filenames, you can obtain them by running the <i>strings</i> command
on a root dbspace chunk or a <i>ontape</i> archive:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>zcat /informix/logical/crash/crash.level.1.Z
<p><b><font face="Courier"><font size=-2>| strings | grep '^/'</font></font></b></dir>
<font face="TIMES"><font size=-1>Make sure that you have checked both of
the following conditions:</font></font>
<p><font face="TIMES"><font size=-1>Permissions</font></font>
<dir><font face="TIMES"><font size=-1>Ensure that someone didn't accidentally
change the ownership or permissions of any chunks. If you are using symbolic
links to point to the actual chunks, the only permissions that matter are
those for the final file to which the symbolic link is pointing. For example,
suppose that you have a symbolic link called <i>/informix/chunk1</i> that
points to <i>/dev/dsk/c0t0d0s5</i>. If you are running Solaris, and if
you run an <i>ls -l</i> on <i>/dev/dsk/c0t0d0s5</i>, you will find this:</font></font>
<dir><font face="Courier"><font size=-2>lrwxrwxrwx 1 root other 84 Nov
5 02:29 /dev/dsk/c0t0d0s5 -> ../..</font></font>
<p><font face="Courier"><font size=-2>/devices/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000</font></font>
<p><font face="Courier"><font size=-2>/esp@f,800000/sd@0,0:f</font></font></dir>
<font face="TIMES"><font size=-1>It is the permissions of <i><a href="mailto:sd@0,0:f">sd@0,0:f</a></i>
that matter, not the symbolic link /dev/dsk/c0t0d0s5. To verify its permissions,
run the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>Ls -lL /dev/dsk/c0t0d0s5</b></font></font></dir>
<font size=-1><font face="TIMES">Adding the <i>-L</i> option causes it
to display the ownership and permissions of the source file, not of the
link. Make sure that both the owner and group are </font><font face="Courier">informix</font><font face="TIMES">,
and that the file is read/write for both the owner and the group.</font></font></dir>
<font face="TIMES"><font size=-1>Symbolic link</font></font>
<dir><font face="TIMES"><font size=-1>This problem usually happens when
the DBA is trying to "clean house." If you're using symbolic links to point
to the actual chunks, and someone deletes the symbolic link, you obviously
have a problem. If you are using symbolic links, make sure that you remake
the symbolic link instead of creating a chunk in its place.</font></font>
<dir><font face="TIMES"><font size=-1>If the instance is currently down
because a critical dbspace could not be opened, return to Step 1 and run
again. If the instance is already up and you were sent here by Step 8,
proceed to Step 9. If you have repaired or replaced any missing chunks,
and the instance still won't start, proceed to Step 6.</font></font></dir>
<a NAME="Step6"></a><b><font face="TIMES"><font size=+1>Step 6: Performing
a Cold Restore</font></font></b>
<dir><font face="TIMES"><font size=-1>You should be performing this step
only if directed to do so by Step 5.</font></font></dir>
<b><font face="TIMES"><font size=-1>Make sure you need this step</font></font></b>
<dir><font face="TIMES"><font size=-1>This is not a step to be taken lightly.
Depending on the size of your instance, a cold restore may take a considerable
amount of time. Please take a moment to verify that you really do need
to perform a restore; if you do, follow the appropriate section below.</font></font>
<dir><font face="TIMES"><font size=-1>Can't I just restore the critical
<p><font face="TIMES"><font size=-1>Both <i>ontape</i> and <i>onbar</i>
allow you to specify a list of dbspaces to restore. This even works with
critical dbspaces. However, if you restore just the critical dbspaces,
the restore leaves all other chunks in an "inconsistent" state, as specified
by the "I" flag that they display after the restore is done. Informix support
does have a tool that will change this flag to consistent, but your mileage
will vary on this one. If you are restoring a critical dbspace, you should
really restore the whole thing.</font></font></dir>
<b><font face="TIMES"><font size=-1>Restoring with ontape</font></font></b>
<dir><font face="TIMES"><font size=-1>Make sure to remove the current logical
log "tape" prior to beginning a physical restore. If you're backing up
to disk, this means moving the file to a different location. If you're
backing up to tape, this means physically removing the current logical
log tape. When performing a physical restore with <i>ontape</i>, it asks
you if you want to back up the current log, and you should <i>always say
yes.</i> However, this performs an <i>ontape -a</i> backup, not an <i>ontape
-c</i> backup. Remember that the primary difference between these two options
is that <i>ontape -a</i> <i>overwrites</i> the "tape" currently in the
drive. <i>If it contains any logs other than the current log, they will
disappear forever.</i></font></font></dir>
<font face="TIMES"><font size=-1>After removing the current logical log
tape or file from its current location, place the latest level 0 archive
in the device specified by <i>$TAPEDEV</i>. If you are backing up to disk,
this may require uncompressing and moving a file to the appropriate location.
If your backing up to tape, it involves placing the latest level 0 archive
in the tape drive. After doing so, execute the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>ontape -r</b></font></font></dir>
<i><font face="TIMES"><font size=-1>Ontape</font></font> prompts you for
everything that it needs. You need to know if you have a level 1 or 2 backup,
since it will ask you that. You'll also need to know the location of all
logical log backups since the latest archive was taken.</i>
<dir><i>Informix asks you if you want to back up the logs. Always say yes,
but make sure that you are giving it a fresh tape or file to back up to,
since it will overwrite it -- not append to it.</i></dir>
<i>The following example was done with an instance that is archiving to
disk using now uses named pipes, so the value for
$TAPEDEV will be a named pipe (e.g., /informix/logical/crash.level.1.fifo)
that reflects the last level that was performed. Since will
recreate the named pipe when it needs to, we will overwrite it with symbolic
links. The example instance also used to continuously back up
the logical logs to disk. The value for $LTAPEDEV is /informix/logical/crash.log,
and when it switches logs, it copies them to /informix/logical/$</i>
<p><i>An ontape restore with archives on disk always requires more than
one window, and this section needs to show both windows below to fully
demonstrate the example. To reduce confusion, it uses a regular paragraph
like this one when switching windows. Since it still needs to explain the
reasoning behind certain commands or answers within a window, it uses this
font to do that. There is also a heading on each body of computer output
specifying either Restore Window or Alternate Window. The restore window
is the window where the ontape -r command is being run, and the alternate
window will be the window where we perform other commands. We will start
with Figure 13-20, the restore window.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i><font face="Courier"><font size=-2>#The first thing that we need
to do is</font></font></i>
<p><i><font face="Courier"><font size=-2>#uncompress the archive files</font></font></i>
<p><i>curtis$ <b>uncompress /informix/logical/crash/crash.level.*.Z</b></i>
<p><i>curtis$ <b>ls /informix/logical/crash</b></i>
<p><i>crash.level.0 crash.level.1</i>
<p><i>#Now we need to remove the named pipe and replace it with a</i>
<p><i>#symbolic link</i>
<p><i>#to the actual backup file</i>
<p><i>curtis$ <b>rm /informix/crash.level.0.fifo</b></i>
<p><i>curtis$ <b>ln -s /informix/logical/crash/crash.level.0 /informix/crash.level.0.fifo</b></i>
<p><i>#Now we can begin the restore</i>
<p><i>curtis$ <b>ontape -r</b></i>
<p><i>Please mount tape 1 on /informix/logical/crash/crash.level.0 and
press Return to continue ...</i>
<p><i>Archive Tape Information</i>
<p><i>Tape type: Archive Backup Tape</i>
<p><i>Online version: INFORMIX-OnLine Version 7.23.UC4</i>
<p><i>Archive date: Thu Jan 21 00:57:14 1999</i>
<p><i>User id: informix</i>
<p><i>Terminal id: ?</i>
<p><i>Archive level: 0</i>
<p><i>Tape device: /informix/crash.level.0.fifo</i>
<p><i>Tape blocksize (in k): 16</i>
<p><i>Tape size (in k): 1024000</i>
<p><i>Tape number in series: 1</i>
<p><i>Spaces to restore:</i>
<p><i>1 [rootdbs ]</i>
<p><i>2 [plogdbs ]</i>
<p><i>3 [llogdbs ]</i>
<p><i>4 [testdbs ]</i>
<p><i>Archive Information</i>
<p><i>INFORMIX-OnLine Copyright(C) 1986-1995 Informix Software, Inc.</i>
<p><i>Initialization Time 03/04/98 20:08:25</i>
<p><i>System Page Size 2048</i>
<p><i>Version 4</i>
<p><i>Archive CheckPoint Time 01/21/99 00:57:17</i>
<p><i>number flags fchunk nchunks flags owner name</i>
<p><i>1 2 1 1 M informix rootdbs</i>
<p><i>2 2 2 1 M informix plogdbs</i>
<p><i>3 2 3 1 M informix llogdbs</i>
<p><i>4 1 4 1 N informix testdbs</i>
<p><i>chk/dbs offset size free bpages flags pathname</i>
<p><i>1 1 0 10000 9051 PO- /informix/rootdbs.dbf</i>
<p><i>1 1 0 10000 0 MO- /informix/rootdbs_mirror.dbf</i>
<p><i>2 2 0 5000 2447 PO- /informix/physlog.dbf</i>
<p><i>2 2 0 5000 0 MO- /informix/physlog_mirror.dbf</i>
<p><i>3 3 0 5000 3447 PO- /informix/logiclog.dbf</i>
<p><i>3 3 0 5000 0 MO- /informix/logiclog_mirror.dbf</i>
<p><i>4 4 0 500 191 PO- /informix/testdbs.dbf</i>
<p><i>#Ontape displays all this information to you so that you know</i>
<p><i>#that this is the right tape to restore the right instance.</i>
<p><i>#It doesn't actually do</i>
<p><i>#anything until you respond "y" to the next question.</i>
<p><i>Continue restore? (y/n)<b>y</b></i>
<p><i>#Always say "YES" to this next question.</i>
<p><i>Do you want to back up the logs? (y/n)<b>y</b></i>
<p><i>Please mount tape 1 on /informix/logical/crash.log and press Return
to continue ...</i>
<p><i>Would you like to back up any of logs 65 - 67? (y/n) <b>y</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-20: Starting an ontape
<i>This next section is from another window. We need to move the old logical
log "tape" out of the way so that the salvaging of the current log does
not overwrite it. In the example in Figure 13-21, we will use the same
naming convention as the other files.</i>
<dir><i><font face="Courier"><font size=-2>[Alternate Window]</font></font></i>
<p><i>curtis$ <b>cp crash.log crash.log.1999.</b></i>
<p><i>curtis$ <b>compress crash.log.1999.</b></i>
<p><i>curtis$ <b>ls -l crash.log.1999.01.21*</b></i>
<p><i>total 2424</i>
<p><i>-rw-rw---- 1 informix informix 73961 Jan 21 01:12 crash.log.1999.</i>
<p><i>-rw-rw---- 1 informix informix 1949 Jan 21 01:13 crash.log.1999.</i>
<p><i>-rw-rw---- 1 informix informix 557056 Jan 22 17:04 crash.log.1999.01.22.17:04:00.Z</i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-21: Preparing disk-based
logical log backups</font></font></i></dir>
<i>Once we've copied the "tape" to another location, it is safe to tell
Informix to salvage the current logical log. Note in Figure 13-22 that
when it asks for the oldest log that we would like to back up, we answer
with the oldest number available. (It never hurts to have too many logical
log backups. If we were to answer "66," what would happen if the restore
needed log 65 and it had not been backed up, or its backup had been damaged?
We would be out of luck, that’s what.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i>Logical logs 65 - 67 may be backed up.</i>
<p><i>Enter the id of the oldest log that you would like to backup? <b>65</b></i>
<p><i>Please label this tape as number 1 in the log tape sequence.</i>
<p><i>This tape contains the following logical logs:</i>
<p><i>1 - 67</i>
<p><i>Log salvage is complete, continuing restore of archive.</i>
<p><i>#we do have a level one archive, so when it asks if we have one,</i>
<p><i>#we will answer "yes."</i>
<p><i>Restore a level 1 archive (y/n) <b>y</b></i>
<p><i>Ready for level 1 tape</i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-22: Backing up the current
logical logs</font></font></i></dir>
<i>You may recall that prior to beginning the restore, we created a symbolic
link from the level 0 archive on disk to the location that Informix expects
the archive to be. Now that we are "swapping tapes," we need to remove
that link and create another one that points to the level 1 backup. (The
commands in Figure 13-23 are obviously being done in another window.)</i>
<dir><i><font face="Courier"><font size=-2>[Alternate Window]</font></font></i>
<p><i>curtis$ <b>rm /informix/crash.level.0.fifo</b></i>
<p><i>curtis$ <b>ln -s /informix/logical/crash/crash.level.1 /informix/crash.level.0.fifo</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-23: Simulating a tape
<i>Now that we have swapped tapes, we can respond to the prompt shown in
Figure 13-24.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i>Please mount tape 1 on /informix/logical/crash/crash.level.0 and
press Return to continue ...</i>
<p><i>Archive Tape Information</i>
<p><i>Tape type: Archive Backup Tape</i>
<p><i>Online version: INFORMIX-OnLine Version 7.23.UC4</i>
<p><i>Archive date: Thu Jan 21 01:10:13 1999</i>
<p><i>User id: informix</i>
<p><i>Terminal id: ?</i>
<p><i>Archive level: 1</i>
<p><i>Tape device: /informix/crash.level.1.fifo</i>
<p><i>Tape blocksize (in k): 16</i>
<p><i>Tape size (in k): 1024000</i>
<p><i>Tape number in series: 1</i>
<p><i>#We do not have a level to archive, so we will answer no to</i>
<p><i>#following prompt.</i>
<p><i>Restore a level 2 archive (y/n) <b>n</b></i>
<p><i>#We do want to restore log tapes, though...</i>
<p><i>Do you want to restore log tapes? (y/n)<b>y</b></i>
<p><i>Roll forward should start with log number 65</i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-24: Responding to ontape’s
<i>Again, we must move over to the other window and prepare the logical
log "tape." First, we move the salvage logs to an appropriately named file
and compress it. Then we use the log concatenation method discussed in
the previous sidebar. Since the logs are compressed, in Figure 13-25 we
create a single concatenated log using zcat.</i>
<dir><i><font face="Courier"><font size=-2>[Alternate Window]</font></font></i>
<p><i>curtis$ <b>mv crash.log crash.log.1999.</b></i>
<p><i>curtis$ <b>compress crash.log.1999.</b></i>
<p><i>curtis$ <b>ls -l crash.log.1999.01.2*</b></i>
<p><i>total 2424</i>
<p><i>-rw-rw---- 1 informix informix 73961 Jan 21 01:12 crash.log.1999.</i>
<p><i>-rw-rw---- 1 informix informix 1949 Jan 21 01:13 crash.log.1999.</i>
<p><i>-rw-rw---- 1 informix informix 557056 Jan 22 17:04 crash.log.1999.01.22.17:04:00.Z</i>
<p><i>-rw-rw---- 1 informix informix 557056 Jan 22 18:00 crash.log.1999.</i>
<p><i>curtis$ <b>zcat *1999* >crash.log</b></i>
<p><i>curtis$ <b>chmod 664 * crash.log</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-25: Creating one large
logical log backup</font></font></i></dir>
<i>Now that we have created the single log, we can respond to the following
prompt in Figure 13-26.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i>Please mount tape 1 on /informix/logical/crash.log and press Return
to continue ...</i>
<p><i>#Since we put all logs into this single log, there are no</i>
<p><i>#more logs to restore.</i>
<p><i>Do you want to restore another log tape? (y/n)<b>n</b></i>
<p><i>Program over.</i>
<p><i>#The next step is very important. You must bring the</i>
<p><i>#instance online when you are done, or you will</i>
<p><i>#need to do the restore all over again.</i>
<p><i>curtis$ <b>onmode -m</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-26: Completing the restore
and starting the instance</font></font></i>
<p><i>Make sure that you use onmode -m to bring the instance online after
doing a cold restore. If you do not, you will need to completely redo the
restore if you stop and start the instance before doing so.</i></dir>
<b><i>Restoring with onbar</i></b>
<p><i>The first and simplest recovery with onbar is to enter onbar -r.
This specifies to do a complete restore of any offline dbspaces. It automatically
performs the following three steps for you:</i>
<i>onbar -l -s (salvage the logical log).</i></li>
<i>onbar -r -p [-w] (complete physical restore, which reads the archive
<i>onbar -r -l (complete logical restore, which reads all available logical
<i>You may also add an optional -w flag (onbar -r -w) that specifies using
the latest whole backup when performing the restore. If you have not been
performing -w backups, then you cannot use -w on the restore. If you have
been using -w on your backups, then you can use the same option on the
restore. You also have the option of not using the -w option on the restore,
even if you did use it to back up.</i>
<p><i>Unlike ontape, you do not even need to move files around or swap
tapes if you have an autochanger. It automatically retrieves the appropriate
volumes that it needs to write to or read from. Even if you do not have
an autochanger, it prompts you for the appropriate tapes by name.</i>
<p><i>You also have the option of performing the three steps by yourself.
This allows you to use a number of flags to do different kinds of restores
based on your needs of the moment. The first thing you need to do, though,
is issue the onbar -l -s command to salvage any logical logs that have
not been backed up.</i>
<p><i>After doing that, you have a number of options when performing the
physical and logical restores. (As started earlier, a physical restore
is one that just reads the archive tape. It does not apply any logical
logs. Applying the logical logs is called the logical restore. The following
onbar command represents your options when beginning the physical restore.
Please note the grouping of the options. The -p, -n and -t options are
mutually exclusive, and so are the -w, dbspace_list and noflags options.</i>
<dir><font face="Courier"><font size=-2>$ <b>onbar -r \</b></font></font>
<p><font face="Courier"><font size=-2>[ <b>-p</b> | <b>-n <i>xxx</i></b>
| <b>-t <i>time</i> </b>] [ <b>-w</b> | <b><i>dbspace_list</i></b> | <b><i>noflags</i></b>
<font face="TIMES"><font size=-1>Here is a listing of the various options
and how they affect the restore:</font></font>
<p><i><font face="TIMES"><font size=-1>-p</font></font></i>
<dir><font face="TIMES"><font size=-1>Adding the <i>-p</i> option to the
-r</i> command tells it to perform <i>only the physical restore</i>. If
you use this option, you need to run the <i>onbar -r -l</i> command to
perform the logical restore. If you do not specify this option, <i>onbar</i>
performs both a physical and a logical restore.</font></font></dir>
<font face="TIMES"><font size=-1><i>-n xxx </i>or <i>-t time</i></font></font>
<dir><font face="TIMES"><font size=-1>If you do not specify <i>-p</i>,
you can also use these flags to decide how the logical restore is performed.
For details on these flags, see the following logical restore section.</font></font></dir>
<i><font face="TIMES"><font size=-1>-w</font></font></i>
<dir><font face="TIMES"><font size=-1>This specifies to <i>use the latest
whole backup</i> when restoring the database. Although using this flag
will perform a restore of the whole database, this flag is actually telling
backup to use</i>, not what kind of restore to do. The reason this flag
is here is that if you do restore from a whole backup, you have the option
of <i>not</i> doing a logical restore, since you have restored the database
to a consistent point in time. (This option is not available to you if
you have not been making backups with the <i>-w</i> option.)</font></font></dir>
<i><font face="TIMES"><font size=-1>dbspace_list</font></font></i>
<dir><font face="TIMES"><font size=-1>If you do not use the <i>-w</i> option,
you can optionally list the dbspaces that <i>onbar</i> should recover,
separated by white space.</font></font></dir>
<i><font face="TIMES"><font size=-1>noflags</font></font></i>
<dir><font face="TIMES"><font size=-1>This is actually just a placeholder
to demonstrate what would happen if you used no other flags at all. If
you enter <i>onbar -r</i> or <i>onbar -p</i> <i>without </i>specifying
or a list of dbspaces to recover, it automatically detects and recovers
any dbspaces that are offline. The noflags option, as described here, is
meant to reiterate the fact that you do not have to specify the
flag to get a complete restore. The -w flag specifies the restore's
not its <i>destination</i>.</font></font></dir>
<font face="TIMES"><font size=-1>If you specified just a physical restore,
you may now perform the logical restore. When doing so, you have three
<p><i><font face="TIMES"><font size=-1>onbar -r -l</font></font></i>
<dir><font face="TIMES"><font size=-1>This is the default method, and performs
a logical restore using all logical logs that were created since the latest
<i><font face="TIMES"><font size=-1>onbar -r -l -n lognumber</font></font></i>
<dir><font face="TIMES"><font size=-1>If you know the last log that you
wish to use, you may use this option. You may specify the last log that
should read using <i>-n lognumber</i>.</font></font></dir>
<i><font face="TIMES"><font size=-1>onbar -r -l -t time</font></font></i>
<dir><font face="TIMES"><font size=-1>You've been waiting for this one.
You know that you accidentally deleted a major table at 14:02. You would
like to replay all transactions <i>except that one.</i> You may tell <i>onbar</i>
to do this using the new <i>-t</i> <i>time</i> option. (In the previous
deleted table example, you would probably enter <i>onbar -r -l 14:00</i>.)</font></font>
<dir><font face="TIMES"><font size=-1>Make sure that you use <i>onmode
-m</i> to bring the instance online after doing a cold restore. If you
do not bring the instance online with onmode –m before the next time you
stop and start the instance, you will need to completely redo the restore</font></font></dir>
<font face="TIMES"><font size=-1>In summary, an <i>onbar</i> restore offers
you the same simplicity as an <i>ontape</i> restore, since both have the
all-encompassing <i>-r</i> option that means to do a complete physical
and logical restore. However, if you need extra options like point-in-time
or point-in-log restores, they are available. It also has the added benefit
of working with your storage manager so that you no longer have to worry
about what tape has what backup. If you have not begun to look at <i>onbar</i>,
perhaps now is the time to start.</font></font>
<dir><font face="TIMES"><font size=-1>Nine out of every 10 restores will
end right here. To make sure that everything is okay, return to step 1
and restart the instance <i>after first bringing it online with onmode
<a NAME="Step7"></a><b><font face="TIMES"><font size=+1>Step 7: Are there
Errors in the Online Log?</font></font></b>
<p><font face="TIMES"><font size=-1>Perhaps the instance started on your
first try. Perhaps you needed to do a cold restore in order to get it started.
The next thing to do would be to check the online log for any errors. Examples
of the types of errors you may see are shown in Figure 13-27:</font></font>
<dir><font face="Courier"><font size=-2>23:27:34 Assert Failed: WARNING!
pthdrpage:ptalloc:bad bfget</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Who: Session(7, informix@curtis,
0, 169149316)</font></font>
<p><font face="Courier"><font size=-2>Thread(13, fast_rec, a12ccd8, 1)</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Results: Cannot use TBLSpace
page for TBLSpace 4194305</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Action: Run 'oncheck -pt
<p><font face="Courier"><font size=-2>23:27:34 See Also: /tmp/af.d79e5</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Cannot Open DBspace 4.</font></font>
<dir><i><font face="TIMES"><font size=-1>Figure 13-27: Example errors in
the online log</font></font></i></dir>
<i>If you see any errors like this, you should run an onstat -d to see
which chunk is having a problem:</i>
<dir><font face="Courier"><font size=-2>Chunks</font></font>
<p><font face="Courier"><font size=-2>address chk/dbs offset size free
bpages flags pathname</font></font>
<p><i><font face="Courier"><font size=-2># Output abbreviated...</font></font></i>
<p><font face="Courier"><font size=-2>a12a508 4 4 0 500 191 PD- /informix/testdbs.dbf</font></font></dir>
<font face="TIMES"><font size=-1>The flags above show you that the <i>/informix/testdbs.dbf
is down. What you need to find out now is why it is down.</font></font>
<dir><font face="TIMES"><font size=-1>If you start the instance and there
are no errors in the online log, then proceed to Step 16. If there are
errors in the log, proceed to Step 8.</font></font></dir>
<a NAME="Step8"></a><b><font face="TIMES"><font size=+1>Step 8: Is There
an Inaccessible Non-Critical Chunk?</font></font></b>
<p><font face="TIMES"><font size=-1>If <i>oninit</i> is able to access
all critical chunks, it brings the instance online. If any non-critical
chunks are inaccessible, it just logs the problem in the online log. If,
after checking the online log and running an