La bebida de soya como sustrato para el crecimiento de bacterias lácticas

As mentioned previously in this book, disks will fail. Occasionally, even the disk that contains the operating system will fail. How do you protect against such a disaster? Depending on your budget and the level of availability that you need, you may explore one or more of the following options if you're running Solaris: Solstice Disk Suite mirrored root disk

If you are running Solaris, you can use Solstice Disk Suite (SDS) to mirror your root disk. (Other platforms have similar products.) A mirrored disk would

automatically take over if the other disk fails. SDS is bundled free with Solaris, and mirroring the root drive is relatively easy.* It's also easy to undo in case things get a little mixed up. You simply boot off a CD-ROM, mount the root filesystem from the good drive, and change the /etc/vfstab to use the actual disk slice names instead of the SDS metadevice names. There are two downsides to this method. The first is that many people are using Veritas Volume Manager to manage the rest of their disks, and using SDS for the root disk may be confusing. The second downside is that it does not protect against root filesystem corruption. If someone accidentally overwrites /etc, the mirroring software will only make that mistake more efficient.

Although this chapter talks mainly about SunOS/Solaris, the principles covered here are used in the other bare-metal recovery chapters.

Page 250 Veritas Volume Manager encapsulated root disk

If you have purchased the Veritas Volume Manager for Solaris, you also have the option of mirroring your root drive with it. (Putting the root drive under Veritas control is called encapsulation.) I'm not sure what to say about this other than to say that I've heard more than one Veritas consultant or instructor tell me not to encapsulate the root disk. It creates too many potential catch-22 situations. Of course, this method also does not protect against the corruption of the root filesystem. Standby root disk

A standby root disk is created by copying the currently running root disk to the alternate boot disk. If the system crashes, you can simply tell it to boot off the other disk. Some people even automate this to the point that the system always boots off the other disk when it is rebooted, unless it is told not to do so. (There is a tool on http://www.backupcentral.com that does just that.)

The advantage to the two previous methods is that if one of the mirrored root disks fails, the operating system will continue to function until it is rebooted. The disadvantage is that they do not protect you against a bad patch or administrator error. Anything that causes "logical" problems with the operating system will simply be duplicated on the other disk. A standby root disk is just the opposite. You will be completely protected against administrator and other errors, but it will require a reboot to boot off the new disk.

Mirrored/HA system

A high-availability (HA) system, as discussed in Chapter 6, High Availability, is the most expensive of these four options, but it offers the greatest level of protection against such a failure. Instead of having a mirrored or standby root disk, you have an entire system standing by ready to take over in case of failure.

What About Fire?

All of the preceding methods will allow you to recover from an operating system disk failure. None of them, however, will protect you when that server burns to the ground. Fire (and other disasters) tend to take out both sides of a mirrored disk pair or HA system. If that happens or if you didn't use any of the preceding methods prior to an operating system disk failure, you will need to recover the root disk from some type of backup.

Recovering the root disk is called a bare-metal recovery, and there are many platform-specific, bare-metal recovery utilities. The earliest example of such a utility on a Unix platform is AIX's mksysb command. mksysb is still in use today and makes a special backup tape that stores all of the root volume-group information. The administrator can replace the root disk, boot off the latest mksysb, and the

Page 251 utility automatically restores the operating system to that disk. Today, there is AIX's mksysb, Compaq's btcreate, HP's make_recovery, and SGI's Backup. Each of these utilities is covered in its own later chapter.

Without a planned bootstrap recovery system, the usual solution to the bare-metal recovery problem is as follows: 1. Replace the defective disk.

2. Reinstall the OS and its patches. 3. Reinstall the backup software.

4. Recover the current, backed-up OS on top of the old OS.

This solution is insufficient, misleading, and not very efficient. The first problem is that you actually end up laying the OS down twice. The second problem is that it doesn't work very well. Try overwriting some of the system files when a system is running from the disk to which you are trying to restore.

Homegrown Bare-Metal Recovery

There is a better way to restore the current OS configuration to a new disk, without laying down the information twice. This method is simple; here are its steps: 1. Back up all appropriate metadata (disk layout, /etc/vfstab, etc.).

2. Take a good backup of the OS via dump or a similar utility.

3. Boot the system to be recovered into single-user mode using a CD-ROM. 4. Set up the recovery disk to look the same as the old root disk, and mount it. 5. Recover the OS to the mounted disk.

6. Place the boot block on the mounted disk. 7. Reboot.

What Is the Boot Block?

The key to the homegrown bare-metal recovery procedure is the recreation of the boot block. Without it, this procedure doesn't work. The boot block is the first few blocks of data on the root sector of the disk. ("Boot block" is actually a Sun term, but other platforms have a similar block of boot information.) Each hardware platform knows enough to look here to find the basic "boot" information. The main part of this block is the location on the disk where the kernel is stored. This block of boot information, or boot block, is stored outside, or "in front of," the root filesystem-on the raw disk itself. Without the boot block, the system will not boot off that disk.

Page 252 On What Platforms Will This Procedure Work?

I originally developed this procedure for SunOS and Solaris, since Sun did not have a utility like IBM's mksysb; however, it is adaptable to many Unix systems. For example, all of the bare-metal recovery chapters to follow (except the AIX chapter) contain examples of how to adapt this procedure for that platform. When I describe the procedure, I use a Solaris system for the examples. A detailed Solaris bare-metal recovery example then follows the general procedure description. Before Disaster Strikes

As is the case with most bare-metal recovery procedures, you need to do a few things up front in order to protect yourself in the event of such a disaster. The first three steps talk about backing up data that is not usually included in a filesystem-level backup. One way to back up all this information is to run SysAudit* (or a program like it) from cron, and save this information in a file every day.

1. If you are going to replace the root disk with another one without reinstalling the OS, you have to partition the new disk the same way the old one was partitioned. The only way you are going to know how the old disk was partitioned is to save this partitioning information.

2. Save the fstab file. This file contains a list of all local filesystems and can be very useful when you're trying to rebuild a system from scratch. The names and locations of the fstab for various flavors of Unix are shown in Table 7-1.

Table 7-1. Locations and Names of /etc/fstab

Unix Flavor Location of fstab File

AIX /etc/filesystems

BSDI, DG-UX, FreeBSD, Next, Digital Unix, Irix, Ultrix, SunOS, Convex, Linux, HP-UX 10+

/etc/fstab

HP-UX 8.x, 9.x /etc/checklist

SCO Openserver /etc/default/filesys

Solaris, SVr4 /etc/vfstab

3. Send this information to a centralized system or more than one centralized system so you can access if it any server becomes unavailable. One of the best ways to do this is via email.

4. When you rebuild a system using a new root disk, you also need to recreate or restore the boot block. SunOS, Solaris, Compaq Unix, IRIX, and HP-UX all have a way to recreate the boot block for you (e.g., Sun's installboot command). If your version of Unix has no similar command, then you also will

* SysAudit is on the CD-ROM and is available at http://www.backupcentral.com.

Page 253 need to back up the boot block. One way to do this is to use dd to back up the first few blocks of data on the root slice. To use dd, issue a command like:

# dd if=/dev/dsk/device bs=10k count=10 \ of=/nfsdrive/root.systemname

For example:

# dd if=/dev/dsk/c0t0d0s0 bs=10k count=10 \ of=/elvis/bootbackups/root.apollo

This gives you a file called /nfsdrive/root.systemname, which is the backup of the boot block on systemname.

As mentioned previously, this step is not needed in most Unix versions; it is needed only if the Unix version does not have a command to recreate the boot block. For example, Solaris uses the installboot command to recreate the boot block, so you do not need to perform this step on a Solaris system.

5. Back up the operating system. One way to accomplish this is to use the program hostdump.sh.* For example, suppose that the operating system is contained in the following filesystems: /, /usr, and /var. To back this up with hostdump.sh, enter the following command:

# hostdump.sh 0 device logfile hostname:/ hostname:/usr hostname:/var

6. This creates a single tape that contains a full backup of /, /usr, and /var from hostname. Send this backup off-site for safekeeping, but keep an on-site copy for quick restores.

The preceding example uses /, /usr, and /var. Your system also may have /opt, usr/openwin, or other filesystems that contain the operating system. Make sure you include all the appropriate filesSystems.

After a Disaster

If you follow the previous preparatory steps you should be able to easily recover from the loss of an operating system drive using the following steps:

1. Replace the root drive with a drive that is as big as, or bigger than, the original root drive. (Past experience has shown that the closer you stay to the same drive architecture, the better chance of success you will have.)

Page 254 2. Boot the system to single-user mode or ''miniroot" using the operating system CD-ROM, or a similar method. The command to do this is very platform dependent, even among the various Sun platforms.

Table 7-2 contains a list of the appropriate commands to boot the various Sun platforms into single-user mode from a CD-ROM. Table 7-2. Various Commands to Boot a Sun from the CD-ROM

Platform Boot Command

4/110, 4/2xx, 4/3xx, 4/4xx b sd(0,3,1) -s

Sparc 1, Sparc 1+, Sparc SLC, Sparc IPC boot sd(0,6,2) -s

SPARC 1E boot sd(0,6,5) -s

SPARC ELC, IPX, LX, classic 2, 10, LX, 6xxMP, 1000, 2000, 4x00, 6x00, 10000 (and probably any newer architectures)

boot cdrom -s

3. Partition the new drive to look like the old drive. To do this on Solaris, we use the format command: SunOS# format sd0

a. Choose p for "partition." b. Choose p for "print." c. Choose s for "select number." d. Resize as appropriate. Solaris# format c0t0d0

e. Choose p for "partition." f. Choose p for "print." g. Choose s for "select number." h. Resize as appropriate.

4. Optionally, install and configure a volume manager.

On Solaris, it is not necessary to mirror the root disk via SDS or Volume Manager, even if you were using mirroring before. You can mirror it or encapsulate it later when you have time.

5. Create new filesystems on the new disk: Solaris# newfs /dev/dsk/c0t0d0s0

Solaris# fsck /dev/rdsk/c0t0d0s0 # repeat for other slices 6. Restore the OS backup to /mnt. If you are using something other

than hostdump.sh, follow its procedure. If using

hostdump.sh, follow this procedure. First, you need to get the electronic label from the tape.

Page 255

The rest of this procedure assumes that you used hostdump.sh to back up your operating system drive. If you used another method, you will need to follow the restore procedure for that method to restore the operating system.

7. Rewind the tape. To do this, we will use the mt command. (See Chapter 5, Commercial Backup Utilities, for more information about mt.) # mt -t /dev/rmt/0 rewind

8. The hostdump.sh program creates a text file called /tmp/BACKUP.LABEL that contains a list of all filesystems that will be backed up to a particular volume. It then uses tar to place that text file as the first file on the backup volume. Use tar to extract this label from the tape:

# tar xvf /dev/rmt/0 #

9. Read /tmp/BACKUP.LABEL to find out which file(s) on the volume contain(s) the filesystem(s) you need to restore.

10. Fast-forward to the first tape file that contains the first filesystem that you want to restore. For this example, the first dump file is the one we want, so it's the second file on the tape; note the use of the n flag to specify that the tape should not rewind when this command is complete.

# mt -t /dev/rmt/0n fsf 1

a.Mount one of the slices of the restore disk. The first one should be mounted as /mnt. (That will become the root filesystem.) The second disk slice (e.g., the future /var) should be mounted as /mnt/var:

Solaris# mount /dev/dsk/c0t0d0s0 /mnt

After you finish steps b and c, you will be repeating this step to mount the next operating system partition. If /var was originally mounted on slice 1, the command to do that would be:

Solaris# mount /dev/dsk/c0t0d0s1 /mnt/var

Steps a-c should be done one filesystem at a time. For example, mount /mnt, then restore / into /mnt/usr, and restore /usr into /mnt/usr. Do not mount all of the directories at once. Restoring / overwrites the /mnt/usr mount point and tends to confuse things. So, mount and restore the filesystems one at a time.

Page 256 b. cd to the filesystem you want to restore:

# cd /mnt

c. Use the appropriate command to restore that filesystem: Solaris# ufsrestore rbfy 64 device_name

d. Repeat steps a through c until you have restored all OS filesystems.

12. Recreate the boot block image onto the root disk (e.g., installboot, mkboot, disklabel):

Solaris# installboot /usr/platform/`uname -i` /lib/fs/ufs/bootblk /dev/ rdsk/c0t0d0s0 13. Reboot using the new disk:

Solaris# reboot

You should now have a fully functional system. If the only disk that was damaged was the root disk, you do not even need to reinstall any applications or data. Am I Crazy?

That looks like a lot of work, doesn't it? It is. However, you can do much of it ahead of time. You can even have a disk ready to go. This method also renders a truer copy of the original operating system much faster than any other. It's often much quicker than the method described at the beginning of this chapter that requires that you reload the operating system, since it doesn't require that you load any patches.

You also could use this procedure to standardize all your operating system disks, which would give you a chance to practice it as well. First you would need to define a partitioning standard for all your OS disks that was large enough to hold the biggest partition that you had (e.g., the biggest /usr would have to fit this scheme). You can then partition a disk that way, restore one client's OS to it, and see if you then can install the OS on the client. If you can, you then can take that client's old OS disk and use it to make the new system's disk. By the time you're done, you could have all your OS disks set up the same way. Now there's a project plan... Recovering a SunOS/Solaris System

Neither SunOS nor Solaris has a bare-metal recovery utility like the other operating systems covered in this book. However, the existence of dump, restore, and installboot make doing a bare-metal recovery relatively simple. The individual steps and the logic behind them were covered earlier. Following is an example of how such a recovery would look on a Solaris system. This example covers a Sparc 20. Its operating system is Solaris 2.6, and it has two filesystems, /and/var.

Page 257 Preparing for Disaster

First, we will back up the system using hostdump.sh. This utility is covered in Chapter 3, Native Backup & Recovery Utilities, and will use ufsdump to back up the / and/var filesystems.

On the system that I used for this example, the / and /var filesystems contained the entire operating system. Your system may be different, so you may need to back up other filesystems such a /usr, /opt, /usr/openwin, etc.

The command to do this and its results are displayed in Example 7-1. Example 7-1. The hostdump.sh Output

# /usr/local/bin/hostdump.sh 0 /dev/rmt/0n /tmp/backup.log curtis:/ curtis:/var ==========================================================

Beginning level 0 backup of the following clients: curtis:/ curtis:/var

This backup is going to curtis:/dev/rmt/0n and is being logged to curtis:/tmp/backup.log

========================================================== Querying clients to determine which filesystems to back up... Including "curtis:/:ufs:sparc-sun-solaris2.6" in backup include list.

Including "curtis:/var:ufs:sparc-sun-solaris2.6" in backup include