While Mac OS X is similar to other flavors of Unix in many ways, the topic of backups is one where the differences stand out. Some of the available tools are the same, but familiar tools may not be the best choices. Also, as with other operating systems described in this part of the book, the methods used to record critical metadata and to boot from the recovered disk differ. Following the format of prior chapters, this chapter will show you how to make a simple and inexpensive backup of a Mac OS X system for use in bare-metal recovery.
This chapter was contributed by Leon Towns-von Stauber. Leon has been using and administering a variety of Unix systems since 1990 and has followed Mac OS X since purchasing a NeXT workstation in 1991.
The following sections outline a procedure you can use to anticipate and conduct a full recovery of a Mac OS X system, without needing to install the OS first. The sequence is generally the same as on other platforms.
A great time to test this procedure is right when you receive your new Mac, and you haven’t yet put any data on it.
You first prepare for the recovery:
Attach backup media to the system.
Back up the important metadata.
Back up the operating system with a native utility.
Then, when bad things happen, you perform the recovery:
Boot from alternate media.
Partition, and format the new root disk.
Restore the operating system information.
Set the system to boot from the new root disk.
We’ll start with a general overview and then move on to a concrete example of the procedure. As with any backup method, your safety net is only as good as your last backup, so scheduling backups and testing your recovery procedures are important.
This procedure can use any external hard disk drive as a backup medium. Examples include a FireWire or USB storage device of sufficient capacity to hold a full backup. Depending on your storage requirements, even an iPod makes an excellent alternative. Another option is to use a Mac laptop in FireWire Target Disk Mode, assuming it has a FireWire port. Finally, you can also use an NFS share from any Unix-type server. While the USB and FireWire drives may be excellent options for an individual user, the NFS option is usually the best for a data center. Unfortunately, an SMB share will not work, because SMB drivers aren’t available from the install CD console that we will be using during the recovery, but more on that later.
To enter Target Disk Mode, click on Apple Menu→System Preferences→Startup Disk→Target Disk Mode.... Alternatively, hold down the T key while booting the Mac laptop. Hook up a FireWire cable between the laptop and the system you’re backing up. The laptop then acts as an external FireWire drive.
After you’ve attached the external backup disk, you need to collect the information
necessary to format the replacement disk before you restore data to it. Save the output
of diskutil
list
, pdisk
device
–dump
(on PowerPC units), and mount
–t
hfs
to files on your backup disk that you can
reference during recovery.
As of the time of this writing, Apple has recently released the first Macs built
around Intel x86 CPUs instead of PowerPC CPUs. If you happen to be running an
Intel-based Mac, you will not be able to use pdisk
,
and fdisk
will not supply information on the disk
you’re running it from, but more on that later.
It’s also a good idea to save Open Firmware variable settings to a file with
nvram
–p
, just in case your NVRAM gets zapped along with
your root disk. And for good measure, keeping a copy of the output from System Profiler
handy means you have fairly complete documentation of your system’s hardware and
software setup available. (Launch the System Profiler application by going to the Apple
Menu and selecting About This Mac→More Info..., then use File→Save to create a profile
of your configuration.)
Now it’s time to back up the data you’ll use to recover the operating system. There
are several native backup utilities from which to choose, but for this procedure, we use
one specific to Mac OS X named ditto
. With Mac OS X
10.4 and later, you could conceivably choose tar
instead of ditto
. However, we’re going to use an
install disc as the boot device during recovery, and the compression tools employed by
tar
(gzip
or
compress
) aren’t available there, whereas ditto
features have built-in PKZIP compression. In order to
save space on the backup medium and for compatibility with older versions of the OS, the
example procedure detailed later in this chapter uses ditto
for backup and recovery. For more on backup utilities native to Mac
OS X, see Chapter 3.
When the day comes to use your backup for a system recovery, either as practice or because something terrible has happened, your first task after replacing any failed components is to boot up the system. The easiest choice for this is to use the same optical media you would use to install a fresh copy of Mac OS X, and that’s the approach we take in our example.
Once the machine has booted up, it’s time to partition and format the new disk using
the diskutil
and pdisk
output you saved during backup. For this you can use the diskutil partitionDisk
command.
Restoring the data is pretty much the opposite of backing it up: use ditto
to decompress and unpack the archive files. If you
need to restore your Open Firmware setup, use nvram
–f
filename
. Finally, once all the data has been restored, use
the bless
command to configure the system to boot
from the new disk.
This example uses diskutil
, pdisk
, mount
, nvram
, ditto
, and bless
to back up and recover a complete Mac OS X system on an
Apple iBook, using an iPod as the backup medium. Some alternate examples will also be
provided throughout the sample procedure. All volumes are formatted as HFS+.
First, attach the backup disk to the system. The disk volume is automatically
mounted by diskarbitrationd
; for this example, we
assume it’s mounted under /Volumes/iPod.
The target disk could also be a share mounted from an NFS server. To do that, you need to mount it. For example, if there is an NFS share called /backups on the NFS server 192.168.0.1, you can mount it to the directory /backups by running the following commands:
#mkdir /backups
#mount -t nfs 192.168.0.1:/backups /backups
Now save the important metadata. Use diskutil
to
get partition names and sizes, as well as the root disk device name (usually /dev/disk0). With this in hand, run pdisk
to get exact partition sizes in blocks, and mount
to take note of the root partition and any special
partitioning options (such as journaling or case-sensitivity), as shown in the following
example:
%mkdir /Volumes/iPod/Backup
%diskutil list | tee /Volumes/iPod/Backup/diskutil.txt
/dev/disk0 #: type name size identifier 0: Apple_partition_scheme *18.6 GB disk0 1: Apple_partition_map 31.5 KB disk0s1 2: Apple_HFS Mac OS X 7.9 GB disk0s3 3: Apple_HFS Mac OS X Alt 7.9 GB disk0s5 4: Apple_HFS Local 2.5 GB disk0s7 /dev/disk1 #: type name size identifier 0: Apple_partition_scheme *18.6 GB disk1 1: Apple_partition_map 31.0 KB disk1s1 2: Apple_MDFW 32.0 MB disk1s2 3: Apple_HFS iPod 18.6 GB disk1s3 %sudo pdisk /dev/disk0 -dump | tee /Volumes/iPod/Backup/pdisk.txt
Partition map (with 512 byte blocks) on '/dev/disk0' #: type name length base ( size ) 1: Apple_partition_map Apple 63 @ 1 2: Apple_Free 262144 @ 64 (128.0M) 3: Apple_HFS Apple_HFS_Untitled_1 16515072 @ 262208 ( 7.9G) 4: Apple_Free 262144 @ 16777280 (128.0M) 5: Apple_HFS Apple_HFS_Untitled_2 16515072 @ 17039424 ( 7.9G) 6: Apple_Free 262144 @ 33554496 (128.0M) 7: Apple_HFS Apple_HFS_Untitled_3 5253424 @ 33816640 ( 2.5G) 8: Apple_Free 16 @ 39070064 Device block size=512, Number of Blocks=39070080 (18.6G) DeviceType=0x0, DeviceId=0x0 %mount –t hfs | tee /Volumes/iPod/Backup/mount.txt
/dev/disk0s3 on / (local, journaled) /dev/disk0s5 on /Volumes/Mac OS X Alt (local, journaled) /dev/disk0s7 on /Volumes/Local (local, journaled) /dev/disk1s3 on /Volumes/iPod (local, nodev, nosuid)
Again, if you’re on an Intel Mac, pdisk
isn’t
available, and fdisk
will not report on the disk
it’s running from, so you need to do something else. One choice is to use the diskutil
output, although it won’t be as exact. Another
choice is to boot from the install media and launch a Terminal, then run fdisk
from there, storing the results in a file on your
backup drive.
Now save your Open Firmware variables with the nvram
command:
% sudo nvram –p > /Volumes/iPod/Backup/nvram.txt
As mentioned earlier, at this point you can also save information from System Profiler.
Now it’s time to back up the data. With the system in a quiescent state to avoid filesystem inconsistency, back up each partition on the root disk:
%cd "/Volumes/Mac OS X"
%sudo ditto –c –k –rsrc –X . "/Volumes/iPod/Backup/Mac OS X.zip"
%cd "/Volumes/Mac OS X Alt"
%sudo ditto –c –k –rsrc –X . "/Volumes/iPod/Backup/Mac OS X Alt.zip"
%cd /Volumes/Local
%sudo ditto –c –k –rsrc –X . /Volumes/iPod/Backup/Local.zip
These commands create a ZIP archive for each partition you’re backing up. All resource forks and file metadata are retained in the archive files.
If you really prefer to use tar
with Mac OS X
10.4 or later, replace the ditto
commands with
something like this:
%sudo tar clpzf /Volumes/iPod/Backup/
partition
.tgz .
Also, make a copy of /usr/bin/gzip to the
backup drive. During recovery, add the directory containing the copy of gzip
to your command path:
# export PATH=${PATH}:/Volumes/iPod/Backup
Now, restore the data like this:
#cd /Volumes/
#
partition
tar xpzf /Volumes/iPod/Backup/
partition
.tgz
Detach the backup disk and keep it somewhere safe. (If you’re using NFS, you only need to unmount it.)
You have a Mac OS X system with a nonfunctional root disk. If you followed the procedure covered earlier, the recovery should be straightforward.
First, turn on power to the system. While the system is starting up, hold down the
Option
key until the machine presents a graphical
list of devices from which to boot. Insert a Mac OS X installation CD or DVD (disc 1 if
it’s a multidisc set), and click on the reload
button
to make it show up in the list of boot devices. Select the installation disc, and
proceed with the boot. After booting up and selecting the language to use, you reach a
welcome message, and the menu bar shows up at the top of the screen. From the Utilities
menu, launch Terminal
to get a command line.
Now attach the backup disk. As with the backup procedure, diskarbitrationd
handles the mounting. When this is done, you have the
following storage devices attached: an optical drive with a Mac OS X install disc
mounted on /, an external backup disk mounted on
/Volumes/iPod, and a new internal hard disk with
nothing mounted. (If for some reason there are partitions mounted from the internal
disk, unmount them at this point with diskutil unmountDisk
disk0
.)
An alternative to using a USB or FireWire drive, such as an iPod, is to use an NFS mount. Besides an NFS server, you will need an IP address. If you have a DHCP server available, you are given an IP address automatically. If you don’t have a DHCP server, you have to manually set the IP address using the following command:
#ifconfig en0
ipaddress
netmask
netmask
broadcast
broadcast-address
You then need to mount the NFS share. Assuming an NFS server with an IP address of 192.168.0.1, and a share called /backups, the command to mount it is:
#mkdir /var/tmp/backups
#mount -t nfs 192.168.0.1:/backups /var/tmp/backups
You then will be able to access the backups on the /backups file share. Remember to unmount the share after you’ve restored data from it.
Refer to /Volumes/iPod/Backup/diskutil.txt and
/Volumes/iPod/Backup/pdisk.txt so that you can
partition the new disk. The diskutil
output provides
the partition names. To determine the size of each partition, use the pdisk
output to add up the partition’s block size with that
of the free area listed before it, then divide by two to convert 512-byte blocks to
kilobytes. For example, the sizes of the first two partitions in this example are
(16,515,072 + 262,144) / 2 = 8,388,608, and the size of the last partition is (5,253,424
+ 262,144) / 2 = 2,757,784.
We go through this calculation because specifying the sizes in gigabytes as shown
in the diskutil
output usually results in
partitions sized slightly larger or smaller than you’d expect. If you’re recovering an
Intel Mac, though, the diskutil
output may be the
only information you have.
Use diskutil
to partition the disk:
#diskutil partitionDisk disk0 3 JournaledHFS+ "Mac OS X" 8388608K
JournaledHFS+ "Mac OS X Alt" 8388608K JournaledHFS+ Local 2757784K
Started partitioning on disk disk0 Creating Partition Map 5% .. Formatting Disk 32% .. Formatting Disk 54% .. Formatting Disk 100% .. Finished partitioning on disk disk0 /dev/disk0 #: type name size identifier 0: Apple_partition_scheme *18.6 GB disk0 1: Apple_partition_map 31.5 KB disk0s1 2: Apple_HFS Mac OS X 7.9 GB disk0s3 3: Apple_HFS Mac OS X Alt 7.9 GB disk0s5 4: Apple_HFS Local 2.5 GB disk0s7
See the diskutil
manpage for more details on the
command syntax and options. One thing to note is that if you’ll be running Classic for
Mac OS 9 support on this system, you should add the OS9Drivers
parameter after the argument specifying the number of
partitions. You can tell if your old disk had OS 9 drivers installed by the presence of
several additional Apple_Driver
partitions in
diskutil.txt.
After you partition the disk, the new partitions are mounted automatically. Now you’re ready to restore the filesystem data. If need be, you can also reset the Open Firmware variables:
#ditto –x –k –rsrc "/Volumes/iPod/Backup/Mac OS X.zip" "/Volumes/Mac OS X"
#ditto –x –k –rsrc "/Volumes/iPod/Backup/Mac OS X Alt.zip" "/Volumes/Mac OS X Alt"
#ditto –x –k –rsrc /Volumes/iPod/Backup/Local.zip /Volumes/Local
#nvram –f /Volumes/iPod/Backup/nvram.txt
The last step of recovery is to prepare the new disk for booting. The following
bless
command enters the designated folder’s
directory ID (an HFS+ identifier analogous to a UFS inode number) into the disk’s Master
Directory Block, and sets the boot-device
Open
Firmware variable so that the system boots from the new disk the next time it comes
up:
# bless -folder "/Volumes/Mac OS X/System/Library/CoreServices" -setBoot
Upon booting, the system will look in the blessed folder for a file of type tbxi
and find BootX, which contains
bootstrapping code to begin the kernel initialization process. You can use the
following to see this file’s type on your system if you have the Developer Tools
installed:
% /Developer/Tools/GetFileInfo /System/Library/CoreServices/BootX
Again, if you need Mac OS 9 support on this system, you need to add something to the command line, like this:
#bless -folder "/Volumes/Mac OS X/System/Library/CoreServices" -setBoot
-folder9 "/Volumes/Mac OS 9/System Folder"
-bootBlockFile /usr/share/misc/bootblockdata
See the bless
manpage for more
information.
Finally, reboot the system and get back to work (or play, as the case may be).
BackupCentral.com has a wiki page for every chapter in this book. Read or contribute updated information about this chapter at http://www.backupcentral.com.