Sidebar: Restoring the Operating System from Dump Tape

Note: The following instructions are specific to Sun systems.

Preparing for Restoration

If the disk has already crashed, get out your plans on disaster recovery for the system. If you don't have plans, you will need to restore every incremental dump of the / and /usr partition since the most recent level 0 dump. Now get the tapes that you will need, starting with a level 0.

If the disk is having problems but is still readable, do a level 0 dump of every disk partition, and use that dump for restoration.

Connect a local CD-ROM unit and tape drive if the system does not normally have one. You cannot restore the OS from a remote tape device. Boot the system with the miniroot. This process copies a "mini-unix" operating system to the b partition (swap) of the system disk. Once the system is up, make sure you don't have a corrupted / or /usr partition by running newfs and fsck. The examples below use /dev/sd0a for the / partition, and /dev/sd0g for the /usr partition:

# newfs /dev/rsd0a
# fsck /dev/rsd0a
# newfs /dev/rsd0g
# fsck /dev/rsd0g

Avoiding Pitfalls

Do not use verbose mode with the restore command when restoring / or /usr, but do use interactive mode. If restore complains that some directories do not contain . or .., or that it expected one file and found another, there is not enough room in /tmp for the scratch files restore needs.

Although restore will continue under these circumstances, the resulting restored file system may have directories with incorrect file permissions, ownerships, and so on. Entire directories may also be missing. This situation is most likely to happen on systems with relatively large /usr partitions. Since the miniroot is contained in the b partition, which is normally used for swap, there is little room to spare unless the system was configured with a larger than usual swap partition.

The best thing to do is to move /tmp to an unused disk partition, perhaps one normally used for additional swap. If you do not have an unused partition, an alternative is to restore /usr first, using the former / partition for /tmp, then go back to using the default /tmp when restoring the / partition.

Moving /tmp

First, make a mount point for the new /tmp partition. The example below calls it /new_tmp. Next, mount the disk partition you want to use on /new_tmp (the example uses disk sd1, partition d), and change the ownership and permissions:

# mkdir /new_tmp
# mount /dev/sd1d /new_tmp
# chown bin.staff /new_tmp
# chmod 1777 /new_tmp
# chmod g+s /new_tmp

The permissions should now be: drwxrwsrwt. Next, rename the /tmp directory and replace it with the /new_tmp partition:

# mv /tmp /old_tmp; mv /new_tmp /tmp

Restoring the / Partition

Mount /dev/sd0a to /a, and cd to /a. Position the backup tape to the dump of / and restore the / partition. When the restore completes, make sure you don't have a corrupted boot file by copying the one from the miniroot:

# cp /boot.<arch> /a/boot

where <arch> is the architecture of the system as obtained by the arch command:

# arch -k

For example, if arch -k returns sun4c use:

# cp /boot.sun4c /a/boot

Running installboot

You need to run the installboot utility whenever / is restored or moved. This is because installboot puts a list of block locations into the boot track, and this information changes when a restore of / occurs. The syntax to use for the installboot command is:

installboot -vl <bf> <dev> <dskpar>

where <bf> is the boot file, <dev> is either bootsd, bootxy, bootxd, or bootid, according to what type of disk is being used, and <dskpar> is the raw disk partition that contains the root file system. To run installboot for our example:

# cd /usr/kvm/mdec
# installboot -vl /a/boot bootsd /dev/rsd0a

Remove the scratch files created by restore in /tmp (/tmp/rstdir and /tmp/rstmode), then umount /a and fsck /dev/rsd0a again.

Restoring the /usr Partition

Mount /dev/sd0g to /a, cd to /a, reposition the tape to the dump of /usr, and restore the /usr partition. Once the /usr restoration is complete, umount /a, and fsck /dev/rsd0g again.

Now reboot the system. If you were not able to do a level 0 dump at the beginning of these procedures, you need to recover files from incremental tapes that have changed since the level 0 dump used for restoration. If you have disaster recovery plans, restore only the most recent copy of each file on your list.

Doing a Baseline

It is very important that a level 0 dump be run as soon as possible after restoring. Doing so will ensure that your dump schedule gets back on track. Otherwise, incrementals may not be done correctly.