Some chapters from Unix Backup & Recovery did not make it into Backup and Recovery. We have added these original chapters to the Wiki in hopes that some of you will help us maintain it.
Compaq Tru64 Unix
This chapter explains the procedure that you would use to recover your Compaq Tru64 Unix operating system disk in case of a complete system failure—when you are left with nothing but bare metal. For suggestions on how to avoid this situation, please read the first section of Chapter 7, SunOS/Solaris.
Compaq Tru64 Unix, also known as Digital Unix, is a Unix-compatible operating system based on the Mach kernel and is the main survivor of the Open Software Foundation. It is different in a number of ways from Solaris, AIX, and HP-UX. During OS installs or during backup and restores, one difference shows up quickly: there are two different filesystems supported by Compaq Unix. First, there is UFS (Unix File System), which is commonly found on many other Unix flavors. Second, there is Digital’s proprietary filesystem known as the AdvFS (Advanced File System). AdvFS provides a journaled filesystem, cloning, volume management, and other advanced features.
I would advise against using AdvFS on the operating system partitions. There are a number of reasons, but the first is the most compelling: during a bare-metal recovery, simplicity is a virtue. Unless you’re very comfortable with AdvFS, it isn’t simple. The primary advantage of AdvFS is that you are dealing with large data volumes rather than the relatively small and static OS partitions. Also, until very recently AdvF still had a number of bugs that could jeopardize the stability of a system.
Another difference is that Digital has software upgradable firmware, similar to Sun’s OpenBoot PROM, which supports, depending on the hardware, booting NT, Compaq Unix, or OpenVMS. During any operating system upgrade, make sure to upgrade the firmware also. This firmware, also known as the “console,” is like a minioperating system; it provides for configuration, diagnostics, and booting. During a bare-metal recovery, you need to be familiar with the firmware console.
This chapter was written by Matthew Huff, director of operations at OTA Limited Partnership. Matthew has worked as a computer professional since 1987 and specializes in complex cross-platform system architecture.
Compaq’s btcreate Utility
Digital provides a system, similar to IBM’s mksysb, which creates a bootable tape designed to shorten the time it takes to completely restore a system. The tape consists of a tape boot block, a specialized kernel, a stripped-down operating system, and a backup of your system partitions. Once it is created, complete restores are as simple as booting the prepared tape from the console:
>>> init
>>> show dev
>>> boot -fl "nc" MKA400
You should create such a tape after a new system has been completely configured and after any major is made. Because the facility utilizes dump or vdump, the normal caveats apply. Ideally, you should create the tape while the system is in single-user mode. This, however, restricts the ability to automate the process.
The btcreate Command
The command to create the bootable tape is /usr/sys/bin/btcreate. If you run the command without any parameters, it prompts you for the missing information. First, it asks you for a kernel configuration file to use; make sure the kernel it creates will have the correct configuration for the devices that you need during a restore. Next, it asks whether to use a memory filesystem (ramdisk) to load the operating system during the restore. If you don’t use the memory filesystem, you need to specify a partition to use (typically, the swap partition). Also, the command asks the device address of the tape drive you wish to use. Finally, it asks which partitions to dump and append to the bootable tape. Since once you have the OS completely restored, you can easily use your standard recovery tools, so it is best to specify only the OS partitions for the bootable tape.
If you don’t want to use the interactive prompt, you need to specify at least the -f, -k, -m, -t, and -s flags:
- The -f flag forces btcreate to overwrite an existing filesystem.
- The -k flag specifies the name of the kernel configuration file in /usr/sys/conf.
- The -m flag allows you to specify a memory filesystem or a partition to use during the restore.
- The -t flag specifies the device to back up to.
- The -s flag allows you to specify a file that contains a list of filesystems to back up.
Each line of the file must specify the device name, mount point, and type (UFS or AdvFS):
# /usr/sys/bin/btcreate -f -k ALAMO -m mfs -t nrmt1h -s /nfsdrive/btcreate. alamo
Using the Bootable Tape
Once you boot from the tape, it loads the kernel and the miniversion of Compaq Unix. It then starts /sbin/btextract to begin the restore. It prompts whether to perform a default or advanced restore. Be careful: with a default restore you cannot choose which partitions to restore it restores every one that was specified in the file used for btcreate. The advanced restore prompts you for parameters including which partitions to restore.
Homegrown Bare-Metal Recovery
If you are in a heterogeneous environment with other, different Unix systems such as Sun, HP, or IBM, you might want to use a consistent method for bare-metal recovery among all your machines. This section shows how the homegrown recovery procedure described in the previous chapter can be applied, providing a complete custom bare-metal recovery plan for Compaq Unix. In addition, Digital provides a very powerful proprietary system for bare-metal recovery that has many advantages and is covered in the next section.
Before Disaster Strikes
Like most bare-metal recovery procedures, you are required to do a few things up front in order to protect yourself from such a disaster:
- If you are going to replace the root disk with another one without reinstalling the OS, you will have to partition the new disk the same way the old one was partitioned. The only way you are going to know that is to save this partitioning information. (It also would help if all your OS disks were partitioned in the same way.) You can use disklabel to print the current partition information:
# disklabel -r raw-disk-device
- Save the /etc/'fstab file. (This file is very useful when trying to rebuild a system from scratch.)
- If you are using AdvFS, save the /etc/fdmns directory structure:
# tar cf /nfsdrive/fdmns.systemname.tar /etc/fdmns
- Send this information to a centralized system, or more than one centralized system, so you can access it if any server becomes unavailable. One of the best ways to do this is via email.
- Back up the OS. An easy way to accomplish this would be to use the program hostdump. sh. For example, suppose that the operating system is contained in the filesystems /, / usr, and /var. To back up these filesystems with hostdump.sh, enter the following command:
# hostdump.sh 0 device logfile hostname:/ hostname:/usr hostname:/var
If you are backing up an AdvFS filesystem, be aware that vdump uses a small percentage of the partition to store information. If that filesystem is very near 100%, vdump might not be able to dump that partition, especially if you are using the -x option. (The -x option provides tape checksums, which, while slowing normal backups somewhat, are a very good feature and should be used.)
Step 5 creates a single tape that contains a full backup of /, /usr, and /var from hostname. Send this backup offsite for safekeeping, keeping an onsite copy for quick restores.
After Disaster
If you followed the preceding steps, you should be able to easily recover from the loss of an operating system drive:
- 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.)
- If your original disk was close to 100 percent utilized, you will need a larger partition than the original.
- Determine the name of the console device.
In order to boot an alphastation or alphaserver from CD-ROM, you will need the name of the console device. The console of Digital’s alphastations and alphaservers has a different naming scheme than Compaq Unix. The main reasons for this is because you can run NT, Compaq Unix, or OpenVMS on the same hardware. Each operating system has, of course, its own dissimilar device names and structures.
Here is sample output from an alphastation:
>>>show device
BOOTDEV ADDR DEVTYPE NUMBYTES RM/FX WP DEVNAME REV
------- ---- ------- -------- ----- -- ------- ---
ESA0 08-00-2B-39-78-99 , TENBT
DKA300 A/3/0 DISK 1.05GB FX RZ26L 440C
MKA400 A/4/0 TAPE RM TZ87 971B
DKA600 A/6/0 RODISK 655.97MB RM WP RRD43 0064
...HostID A/7 INITR
The device name, listed in the BOOTDEV column, is the label you use for booting, diagnostics, etc.; it is created from a combination of the device type and address. The first two characters are based on the device type (DEVTYPE column):
DK
Individual SCSI disks, IDE devices masquerading as SCSI devices, or external RAID controllers
DR
Internal RAID controllers
MK
Individual SCSI tapes
JK
Jukebox SCSI media changers
DV
Floppies
ES, EW
Ethernet
PK
SCSI controllers
The third character is based on the controller, i.e., A for the first controller, B for the second, and so on. The remaining digits indicate a sequence number. For SCSI, they are based on the SCSI ID and SCSI LUN. LUNs are used mainly for large drive arrays or media changers. Normal SCSI devices also have a LUN of 00. For example, DKA300 would be a SCSI disk on controller A with a SCSI ID of 3 and a LUN of 00.
Other console variables can be listed by the show command at the console or by using consvar -l under Compaq Unix.
- Boot the system to the “Install Unix Shell” using the operating System install CD-ROM.
>>> init
>>> show dev
>>> boot DKA600
- Select “Unix Shell” from either the text or graphical interface.
- If the drive was partitioned with the default layout for that particular Digital drive type, use the -rw option of disklabel to partition the drive. The disklabel utility requires that you specify what type of filesystem the root partition is so that it can write the correct boot block on the disk:
# for UFS root partitions
# disklabel -rw -t ufs device digital_drive_type
# for AdvFS root partitions
# disklabel -rw -t advfs device digital_drive_type
If you had a custom partition table, you will have to use vi to edit the partition table:
# for UFS root partitions
# disklabel -rz -t ufs device digital_drive_type
# for AdvFS root partitions
# disklabel -rz -t advfs device digital_drive_type
# disklabel -re device
- If you have a third-party drive, there is an undocumented trick to setting up the partition table. disklabel can be made to use the SCSI geometry command to scan the disk and set a default partition. Instead of specifying the Digital drive type, you use the device twice. This forces disklabel to read the SCSI geometry:
# for UFS root partitions
# disklabel -rz -t ufs device device
# for AdvFS root partition
# disklabel -rz -t advfs device device
# disklabel -re device
- Create a new root filesystem on the disk:
# for UFS partition
# newfs /dev/raw_device digital_drive_type
# for UFS partition
# fsck /dev/raw_device
# for AdvFS partition
# mkfdmn -t digital_drive_type /dev/raw_device root_domain
# for AdvFS partition
# mkfset root_domain root
# mkdir /var/mnt
- Restore the root OS backup to /var/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.
Rewind the tape:
# mt -t /dev/rmt0h rewind
Use tar to extract the label from the tape:
# tar xvf /dev/nrmt0h #Remember to use the no-rewind device.
Read /tmp/BACKUP.LABEL to find out which file(s) on the volume contain(s) the filesystem(s) you need to restore.
Fast-forward to the first tape file that contains the root 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.
#Remember to use the no-rewind device.
# mt -t /dev/nrmt0h fsf 1
Restore the root partition.
- Mount the root partition:
# for UFS partition
# mount /dev/device /var/mnt
# for AdvFS partition
# mount root_domain#root /var/mnt
- cd to the filesystem you want to restore:
#cd /var/mnt
- Use the appropriate command to restore that filesystem:
# for backups that used dump
# restore -Yrf /dev/rmt0h
# for backups that used vdump
# vrestore -vxf /dev/rmt0h
- Unmount restore root filesystem:
# unmount /var/mnt
# sync; halt
- Boot to single-user mode:
>>> init
>>> show dev
>>> boot -fl "s" DKA300
Restore remaining filesystems. Since the definitions of the AdvFS domains and filesets are stored on the root partitions in /etc/fdmns, no more AdvFS configuration is necessary.
- Prepare the /usr partition:
# for UFS partition
# newfs /dev/raw_device digital_drive_type
# for UFS partition
# fsck /dev/raw_device
# mt -t /dev/rmt0h rewind
- Use tar to extract the label from the tape:
#Remember to use the no-rewind device.
# tar xvf /dev/nrmt0h
- Read /tmp/BACKUP.LABEL to find out which file(s) on the volume contain(s) the filesystem(s) you need to restore.
- Fast-forward to the first tape file that contains the filesystem that you want to restore:
#Remember to use the no-rewind device.
# mt -t /dev/nrmt0h fsf 2
- Restore the /usr partition.
- Mount the partition:
# for UFS partition
# mount /usr
# for UFS partition
# mount domain#fileset /usr
- cd to the filesystem you want to restore:
#cd /usr
- Use the appropriate command to restore that filesystem:
# restore -Yrf /dev/rmt0h # for backups that used dump
# vrestore -vxf /dev/rmt0h # for backups that used vdump
- Repeat steps 17–22 for /var if it is defined on another partition, rather than within /usr.
- Reboot:
# shutdown --r now