InformIT: Mac OS X Unleashed

Table of Contents

Backups

Keeping an archive of your important applications and data is a crucial part of maintaining a Mac OS X computer, as it is with any operating system. The biggest problem with backups and Mac OS X is that there are currently no dedicated backup solutions shipping for the operating system.

The Unix users out there are probably scratching their heads out there asking, "What about tar, dump, and restore?" Although those are all perfectly good solutions for Mac OS X installations based on the UFS file system, or Unix and Cocoa apps based on HFS+, they are not suitable for Classic or Carbon applications. The dependency of these types of software on the HFS+ resource fork greatly limits what software can be used to back them up.

Traditional Unix utilities "see" the data fork only when looking at a dual-forked file. Attempting to back up a file with a resource fork will likely lead to an entirely unusable archive. This section of the chapter will look at what is currently available for backing up any Mac OS X file or application, and at the Unix tools that can be used to back up UFS and non-resource-forked files. Due to the overwhelming lack of GUI tools, the focus will be on what can be done from the Unix command line.

Mac OS X Native GUI Backup Utilities

When the table of contents for this book was in development, I had hoped that by the time this text was written, more backup tools for Mac OS X would be available. Unfortunately, the playing field is still open and waiting for a truly comprehensive native solution to be published.

The one piece of good news is that the Mac OS 8/9 tools, such as Retrospect, will continue to function and can back up a Mac OS X drive when booted into the older operating system. Another promising note is that the structure of Mac OS X makes it easy to back up individual user accounts and application preferences.

For most users, backing up the contents of their /Users/ <username> home directories will suffice for protecting personal information. This, of course, doesn't help much with applications and Unix system services that have been installed. Let's go ahead and take a look at what is available, and then at a few Unix tools that can be employed to back up critical non-Carbon/Classic applications.

Retrospect

Retrospect is, by far, the most powerful backup solution for the Mac OS and Mac OS X, featuring the ability to back up and restore to Windows and Macintosh systems, store backups on FTP servers, and more. Figure 32.6 displays Retrospect Backup 5.0 for Mac OS X.

Figure 32.6 Retrospect 5.0 is a complete back up solution for Mac OS X.

The Retrospect client application is available for Mac OS X and, despite not being true backup software, is probably the best backup solution available at this point. The Retrospect client installs on the Mac OS X computer and Retrospect backup clients can be installed on any Mac OS X computer and accessed via either Retrospect Backup 4.5 for Mac OS 8 or 9 or Retrospect 5.0.

From a master Retrospect server the system administrator can locate the Mac OS X client, select the files to back up, and store them on a variety of media including CDRW, DAT, and Internet storage sites. Backups can be scripted for automatic execution, or run at any time with the click of a mouse. Restoring files from a backup is a simple point-and-click operation that automatically copies files from the source media back to the client.

Mixed platform networks will be happy to find that Retrospect clients are available for older Mac systems as well as Windows. Although not a native solution, it is an excellent system that makes possible backing up a Mac OS X computer in a Mac-like way.

Find out more about Retrospect Backup and download the Retrospect Mac OS X client from http://www.dantz.com/.

Synk X

The Synk X shareware application provides synchronization services between folders and volumes. Written as a Carbon application, this utility can work in either synchronize or backup mode. Additionally, the software can back up to an AppleShare volume and save common settings in a double-clickable "run" document. AppleScript programmers can automate the backup process by utilizing the built-in dictionary. Figure 32.7 shows the Synk X application in use.

Figure 32.7 Synk X can synchronize or back up from a source folder to a local or remote destination.

Although Synk X does not provide support for external media, it is a quick-and-dirty backup method for those with removable disk storage devices or access to a network file server.

Download Synk X from http://mypage.uniserve.ca/~rvoth/synkx.html.

Tip

The command-line users out there might want to take a look at the utility hfspax from http://homepage.mac.com/howardoakley. This is a drop-in replacement for the pax utility that Apple uses in its own Installer application.

The hfspax software distribution works with both data and resource forks, and can be used to copy and archive any files on the computer. Unfortunately, the current distribution of hfspax does not come with the source code and is a "use at your own risk" piece of software.

Command-Line Backups

If you have created a Unix file system (UFS) partition for your OS X machine, you can use the dump utility to back up the data on that partition. The dump utility that currently comes with the OS X distribution cannot be used to back up HFS+ partitions. Because OS X does not provide an mt utility that can be used to communicate directly with a local tape drive, you might need to have access to a remote tape drive. If you do have access to a tape drive, we recommend that you store your important data on the UFS partition, because you will be able to back it up regularly.

Understanding Incremental Dumps

The version of dump that OS X provides supports incremental backups. As the phrase incremental backups might suggest, you will not back up everything on your UFS partition every time. Instead, you will decide on a backup schedule that consists of doing whatever is necessary to maintain reliability for your site. At the very least, you will run full backups every few months. At the very best, you will run full backups every few months, a monthly once a month, a weekly once a week, and a daily once a day. In practice, though, your schedule may fall somewhere in between.

The key to understanding incremental dumps is realizing that you will not be backing up everything on your UFS partitions every time you run the dump command. You will be able to issue different levels, or degrees, of the dump command. You can issue the dump command from levels 0 through 9. Except for level 0, which is the level used for a complete backup that backs up everything on the partition, you have the freedom to assign what a number means. Each dump level with a level number higher than 0 will back up only files that have changed since the most recent dump that has a lower-level number. Note that I didn't say since the most recent dump, but rather since the most recent with a lower-level number. This facility allows you to conserve tapes and save on equipment wear by doing most of your backups of only files that change, and infrequently backing up files that stay the same for long periods of time.

In the example we will look at, the level numbers I have chosen have the following meaning:

0	Full
2	Monthly
4	Weekly
6	Daily

I don't have to choose even numbers. Odd numbers are just fine, too. I've chosen to space mine out so that I can add an unexpected backup for whatever reason. It doesn't matter what arbitrary values you assign as long as the numeric values increase with the frequency of the scheduled dump, but, to make your life easier, be consistent from use to use.

It's fairly easy to be confused by the idea of incremental backups, but an example should help to clear things up.

Let's say that last month I ran a full dump (level 0) on a file system. Every day initially following the full dump, I ran dailies (level 6). A week after the full dump was made, I decided to run a weekly dump (level 4). In the days following the weekly dump, I ran dailies (level 6). The second week after the full dump, I ran another weekly (level 4). And I continued the pattern until today, a month after the full dump. Today I decide to run a monthly (level 2). Table 32.1 shows a sort of calendar of the sample backup schedule we will follow. For purposes of the example, today is the last identified day in the schedule, Monday of week 5.

Table 32.1. Sample Backup Schedule

Week	Mon	Tues	Wed	Thurs	Fri	Sat	Sun
1	0	6	6	6	6	6	6
2	4	6	6	6	6	6	6
3	4	6	6	6	6	6	6
4	4	6	6	6	6	6	6
5	2

To reiterate, remember that dumps are incremental. Keeping that in mind, what do the numbers mean in Table 32.1? Here is what lands on each of the tapes:

On Monday of week 1, a full dump, level 0, was done. Everything on the file system was backed up to the dump level 0 tape.

On Tuesday of week 1, a daily, level 6 dump was done. That is, everything that had changed since the most recent dump with a lower level was backed up. In this case, Monday's dump level 0 has a lower level, and is the most recent dump with a lower level. So, anything that changed between Monday's level 0 dump and Tuesday's level 6 was backed up to the dump level 6 tape.

What about Wednesday of the first week? Again, with the Wednesday dump, level 6, only files that have changed since the most recent dump with a lower level have been backed up. What's the most recent dump with a lower-level number? Yes, it's the level 0 dump from Monday. Again, only files that changed between Monday, level 0, and Wednesday, level 6, were backed up. Wednesday's dump is not a reflection of the changes in files between Tuesday and Wednesday because both of those dumps were level 6.

Thursday, Friday, Saturday, and Sunday's dumps for the first week mimic the behavior of Tuesday's and Wednesday's. For each of these dumps, the most recent dump with a lower number will be Monday's level 0 dump, and each of these will contain a backup of all files that changed between Monday and the day of the dump.

On Monday of the second week, a dump level 4 was done. What does this mean? Again, the files that changed between the most recent dump with a lower dump level number and the current date were backed up. Again, the dump level 0 dump from the previous Monday was the most recent dump with a lower number. The dump from Monday of the second week reflects changes that were made between the previous Monday and that Monday. The significance of using level 4 for this dump will appear with the dump for the next day.

What about Tuesday of the second week? On this Tuesday we ran a dump level 6, but this time the most recent dump with a lower dump level than 6 is not the first Monday's level 0 dump, but the second Monday's level 4 dump instead. Tuesday's dump, then, consists of the files that changed between Monday of week 2 and Tuesday of week 2.

Likewise, the dump from Wednesday of week 2 reflects the changes between Monday of week 2 and Wednesday of week 2.

What files did the dump level 2 on Monday of week 5 capture? If we look at the chart, we see that the most recent dump with a dump level lower than our dump level of 2 is the dump level 0 of Monday on week 1. So, the dump level 2 on Monday of week 5 is a dump of the files that changed between Monday of week 1 and Monday of week 5.

When you are restoring files, the same incremental approach applies. Dumps are incremental, so the restores must be incremental as well. If a user deletes a directory, to rebuild that directory to its most recent state will take one restore at each of the dump levels that you use.

For example, if I accidentally deleted a directory mid-day on Tuesday of week 5, sometime after the daily dump (level 6) was done, I would have to restore my directory from the dump level 0 of Monday of week 1, the dump level 2 of Monday of week 5, and Tuesday morning's daily dump, level 6.

Why do I have to restore my directory from multiple different archives? Because other than the level 0 dump that provides a complete snapshot of my directory, the others only provide differences over time. I need to restore the dump level 0 to get back files that have been around in my directory for ages, the dump level 2 for changes in the last week, and the dump level 6 for changes since yesterday. What comes from each tape is as follows:

The dump level 0 tape would provide the base level restore of my directory as it existed on Monday of week 1 because it's a full dump and captures everything as of when it is made.
To this, the dump level 2 tape adds any changes that occurred between the dump level 0 dump of week 1 and the date of the level 2 dump, the day before I made the mistake. Any new files that I added during that time, or older files that I changed, would be backed up on this tape, but files that I had not changed would not be included.
Tuesday's dump level 6 fills in any changes that occurred between the dump level 2 of the day before and Tuesday.

As you can see, the directory has to be restored incrementally. If Tuesday's daily dump ran at 4:00 a.m., and I made some spectacular changes at noon, just before I accidentally deleted everything after lunch, I can't get the spectacular changes back. I can only restore to the state of the directory as it was at 4:00 a.m.

Using `dump`

The dump utility has a variety of options. Options to make sure you include are the dump level, the blocking factor, any special tape size information you have to provide, and the name of the tape device. The blocking factor is information used by dump to determine how to group the data and control information on the tape. The man page mentions a maximum blocking size, which should probably be fine. The man page also mentions an option that could be used for automatic size detection. Unfortunately, this option is not currently available in the OS X distribution of dump. So, you probably will have to work out some density and feet numbers. For a remote tape device, definitely ask the system administrator of the machine with the tape drive for advice. If you are lucky, that system administrator has had to use a similar dump.

Always record on the tape packaging the date, dump level, blocking factor, and the file systems that were dumped in the order in which they were dumped. Record the blocking factor, even if you are just using the default. It might save someone else time restoring from your tape if she knows the blocking factor right away, instead of having to guess.

The clever system administrator will work out a schedule whereby tapes that are used for weekly or daily dumps will be rotated into duty as full-dump tapes and (semi-) permanently archived after some period of time. Magnetic media has a finite lifetime when running over record and playback heads, so moving a frequently used tape to a "use once and forget" status near the end (or middle, more practically) of its useful life is a way to economize on tape costs.

Here's the basic form of a dump command:

dump options <filesystem_to_dump>

Here is a sample of dump output:

root# dump 0bdsfu 64 83333 6000 rosalyn:/dev/rmt/0n /dev/rdisk2s9

       DUMP: Date of this level 0 dump: Fri Jun 29 12:31:03 2001
       DUMP: Date of last level 0 dump: the epoch
       DUMP: Dumping /dev/rdisk2s9 to /dev/rmt/0n on host rosalyn
       DUMP: mapping (Pass I) [regular files]
       DUMP: mapping (Pass II) [directories]
       DUMP: estimated 613411 tape blocks on 0.29 tape(s).
       DUMP: dumping (Pass III) [directories]
       DUMP: dumping (Pass IV) [regular files]
       DUMP: 23.54% done, finished in 0:16
       DUMP: 50.81% done, finished in 0:09
       DUMP: 75.19% done, finished in 0:04
       DUMP: 96.47% done, finished in 0:00
       DUMP: DUMP: 613410 tape blocks on 1 volumes(s)
       DUMP: level 0 dump on Fri Jun 29 12:31:03 2001
       DUMP: Closing /dev/rmt/0n
       DUMP: DUMP IS DONE

In this particular instance of dump, the level is 0. After the 0, you see the string bdsfu. This string specifies that it is followed by a collection of data values:

b is the blocking factor
d is the density in bytes per inch (bpi)
s is the size of the tape in feet
f is the tape device or file
u is an indication to update /etc/dumpdates upon successful completion of dump

Following the bdsfu string are the numeric values corresponding to each item specified, in the order specified. The file system to be dumped is specified as the last thing on the line; here it's the raw device, /dev/rdisk2s9. With some versions of dump, you can specify the mount point of the file system, but that does not work with the dump that comes with OS X. As you can see by the naming convention, rosalyn:/dev/rmt/0n, the tape drive is not local to the machine. The magical numbers used for density and size have been determined from various man pages and trial and error as something that works on a 120m DAT tape for this particular tape drive on a different operating system.

The dump output includes this line:

DUMP: estimated 613411 tape blocks on 0.29 tape(s).

Some versions of dump also include output information in total MB, KB, or bytes dumped. Although the OS X dump does not provide that precise translation, from df -k we see a convenient correlation—the tape blocks must be approximately 1KB blocks:

[localhost:~] joray% df -k /dev/disk2s9

     Filesystem   1K-blocks     Used    Avail Capacity  Mounted on
     /dev/disk2s9    692795   612336    45820    93%    /new1

Command documentation for dump is included in Table 32.2. The dump syntax used in the earlier sample follows traditional dump syntax. However, from the man page, we would expect the following statement to work also:

dump –0u –b 64 –d 83333 –s 6000 –f rosalyn:/dev/rmt/0n /dev/rdisk2s9

If we look at the resulting /etc/dumpdates file, we see

[localhost:~] joray% more /etc/dumpdates

     /dev/rdisk2s9    0 Fri Jun 29 12:31:03 2001

From the file, we see that so far there has only been one dump of /dev/rdisk2s9 and that it was a level 0. When another dump level is performed on /dev/rdisk2s9, a new line will be added with the date and time for that dump level.

Note

Most classical versions of dump have arguments more appropriate for 9-track streaming tape drives of the type you see in 1960s and 1970s sci-fi films. The parameters were not really designed to accommodate today's high-capacity cartridge drives, so you must fudge the length and density values until you achieve a working selection that makes reasonable use of the tape's capacity. Usually it is sufficient to provide size and density values that are bigger than the actual tape capacity because most modern tape drives will detect when EOM (end of media) is reached. However, if the values are significantly larger, dump's estimate of the number of tapes required will be useless, so you probably will want to attempt to make a reasonably accurate guess. Usually the man pages make helpful suggestions on making these guesses, but given the rapid advances in tape capacity in recent years, even the man pages seem to be out-of-date as far as accurate predictions go.

Table 32.2. Command Documentation Table for `dump`

`dump`	File system backup
dump [-0123456789cnua] [-B <records>] [-b <blocksize>] [-d <density>] [-f <file>] [-h <level>] [-s <feet>] [-T <date>] s dump [-W \|\| -w]
(The 4.3BSD option syntax is implemented for backward compatibility, but is not documented.)
`dump` examines files on a file system and determines which files need to be backed up. These files are copied to the given disk, tape, or other storage medium for safekeeping. A dump that is larger than the output medium is broken into multiple volumes. On most media, the size is determined by writing until an end-of-media indication is returned.
On media that cannot reliably return an end-of-media, each volume is of a fixed size. The actual size is determined by the tape size and density and/or block count options. By default, the same output filename is used for each volume after prompting the operator to change media.
`-0-9`	Dump levels. A level 0, full backup, guarantees the entire file system is copied. A level number above 0, an incremental backup, tells `dump` to copy all files new or modified since the last dump of the same or lower level. The default level is `9`.
`-c`	Changes the defaults for use with a cartridge tape drive, with a density of 8000 bpi and a length of 1700 feet.
`-n`	Notifies all operators in the group `operator` whenever `dump` requires operator attention.
`-u`	Updates the file `/etc/dumpdates` after a successful dump. The format of `/etc/dumpdates` is readable by people, consisting of one free format record per line: file system name, increment level, and `ctime (3)`. There may be only one entry per file system at each level.
`-B` `<records>`	The number of kilobytes per volume, rounded down to a multiple of the `blocksize` . This option overrides the calculation of the tape size.
`-b` `<blocksize>`	The number of kilobytes per dump record. Because the IO system slices all requests into chunks of `MAXBSIZE` (typically 64KB), it is not possible to use a larger block size without having problems later with `restore`. Therefore, `dump` constrains writes to `MAXBSIZE`.
`-d` `<density>`	Sets the tape density to `<density>` . The default is 1600 bpi.
`-f` `<file>`	Writes the backup to `<file>` . `<file>` may be a special device file, such as a tape drive or disk drive, an ordinary file, or `-` (standard output). Multiple filenames may be given as a single argument separated by commas. Each file will be used for one dump volume in the order listed. If the dump requires more volumes than the number of names listed, the last filename will be used for all remaining volumes after prompting for media changes. If the name of the file is of the form `<host>` `:` `<file>` or `<user>` `@` `<host>` `:` `file` , `dump` writes to the named file on the remote host using `rmt`.
`-h` `<level>`	Honors the user `nodump` flag only for dumps at or above the given `<level>` . The default honor level is `1`, so that incremental backups omit such files but full backups retain them.
`-s` `<feet>`	Attempts to calculate the amount of tape needed at a particular density. If this amount is exceeded, `dump` prompts for a new tape. It is recommended to be a bit conservative on this option. The default tape length is 2300 feet.
`-T` `<date>`	Uses the specified date as the starting time for the dump instead of the time determined from looking in `/etc/dumpdates`. The format of the date is the same as that of `ctime (3)`. This option is useful for automated dump scripts that want to dump over a specified period of time. The `-T` flag is mutually exclusive with the `-u` flag.
`-W`	Tells the operator what file systems need to be dumped. The information is gleaned from `/etc/dumpdates` and `/etc/fstab`. The `-W` flag causes `dump` to print out, for each file system in `/etc/dumpdates`, the most recent dump date and level and highlights of those file systems that should be dumped. If the `-W` flag is set, all other options are ignored, and `dump` exits immediately.
`-w`	Is like `W`, but prints only those file systems that need to be dumped.
`dump` requires operator intervention on these conditions: end of tape, end of dump, tape write error, tape open error, or disk read error (if there are more than a threshold of 32). In addition to alerting all operators implied by the `-n` flag, `dump` interacts with an operator on `dump`'s control terminal at times when `dump` can no longer proceed, or if something is grossly wrong. All questions `dump` poses must be answered by typing `yes` or `no`.
Because making a dump involves a lot of time and effort for full dumps, `dump` checkpoints itself at the start of each tape volume. If writing that volume fails for some reason, `dump` will, with operator permission, restart itself from the checkpoint after the old tape has been rewound and removed, and a new tape has been mounted.
`dump` tells the operator what is going on at periodic intervals, including (usually low) estimates of the number of blocks to write, the number of tapes it will take, the time to completion, and the time to the tape change.

Troubleshooting `dump`

If dump works fine on the machine with the tape drive, but not on your remote OS X client, you might need to double-check your coordination with the system administrator of the machine with the tape device.

Make sure that you are using the right device name for the remote tape drive. Ask the system administrator whether she has placed an entry for your OS X machine in root's .rhosts file. An entry in the .rhosts file has a form like this:

mother.politically.correct.com  root

Also, if the system administrator has closed services on the machine with the tape drive, ask whether rsh has been enabled and if she has placed an entry in her /etc/hosts.allow for rsh for your OS X machine. Only machines that are allowed to have access to the tape drive should be given access to the rsh service. Make sure that any other possible firewall issues have been addressed.

Restoring Your Data from Tape: Using `restore`

It's one thing to get dump to work and another to successfully restore from tape. Make sure that you test restoring data from tape before you actually have to do it. Take notes as you do it. Do your testing in noncritical locations on your system. Get an approximate idea of what you have to do. You might not end up restoring to the exact location you hope for, but you can always move the data around.

Preparing to Restore

The information that you will most likely need for restore is the blocking factor and the name of the tape drive. If you choose an interactive restore session, you don't need to worry about too many other options.

Which tapes you will need for your restore will vary with what you have to restore. If you only have to restore a file that you last updated yesterday before today's dump, today's tape is sufficient. Recall, however, that you might need to restore from the appropriate combination of the most recent full, monthly, weekly, and daily tapes.

When you restore from tape, you have to navigate the tape to the location that has the file system with the data you need to restore. This shouldn't be too problematic, assuming that you have written, somewhere on the tape package, the dump date, dump level, blocking factor, and what was dumped in the order it was dumped. If you do not write this information down, your tapes are all but useless. With sufficient experimentation, you might be able to determine the contents of a tape that you haven't recorded this information for, but realistically you should consider the contents of a tape with no written information to be lost.

Doing a Restore

What I am going to restore first is actually data that was created by another operating system's dump of a UFS file system.

The data I am most interested in is a collection of patches for SunOS 4.1.4 and scripts to install the patches. Because my UFS partition is large enough to hold all the available data, I will restore all of it, and sort through it to see what I don't really need.

To complete this task, I will need the tapes from the most recent appropriate levels. In my case, I need the most recent level 0, level 2, and level 4 tapes.

I will first restore the base contents from the level 0 tape. My label indicates that a blocking factor of 126 was used, and that the directory I'm looking for is on the seventeenth file system on the tape.

On the remote host, I have to position the tape, using the mt command. First, I rewind the tape to make sure that I am at the beginning of the tape. Then I fast-forward the tape to the end of the sixteenth file system. As you saw in the dump example, the tape device on this host machine is /dev/rmt/0n.

rosalyn osx-misc 164 > mt -f /dev/rmt/0n rewind

rosalyn osx-misc 165 > mt -f /dev/rmt/0n fsf 16

The fsf 16 instructs mt to fast-forward to the end of the sixteenth file. Some versions of restore, including the one for OS X, have a -s option that allows you to skip to the nth file on the tape. This restore option could alleviate some need for an mt utility.

With the tape properly positioned, I can now restore from it: [localhost:/new1] root# restore ibf 126 rosalyn:/dev/rmt/0n Connection to rosalyn.biosci.ohio-state.edu established. restore > ls .: ftp/ installed-950421/ stacker.mods installed/ lost+found/ The options I have indicated are i for interactive, b for blocking factor, and f for tape device. These are typical options available in traditional versions of restore. The man page with the OS X restore does not elaborate on available options. Because I have chosen an interactive restore mode, I am given a prompt from which I can run ls, which as you might expect, lists the contents of the tape. A / at the end of a name indicates that the entry is a directory. Items that you want to restore can be selected with the add command. Because I want everything on this file system, I can just enter add *. If I wanted only certain files, I could navigate and select certain files and directories with the add command. Here is my add command: restore > add * After everything has been selected, I can tell restore to extract the data with the extract command: restore > extract The restore command responds with a request for which volume to read. I've always backed up one tape at a time, so I enter 1. If you do multi-tape dumps for one file system, you will want to answer this question with the highest tape number for a given file system. The restore process will instruct you as to how to proceed from there. It's much more convenient to work with single-volume dumps and restores, however, and with today's high-capacity tape drives and a bit of planning, you should be able to avoid the necessity for multi-tape dumps entirely. You have not read any tapes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 Then I wait a while, or so it seems. Finally, restore asks whether I want to set modes: set owner/mode for '.'? [yn] y restore > quit You might want to experiment with the set owner/modes question. The results of choosing yes and no are similar, but not exactly identical. When you choose y, the hierarchy of the file system on the tape is restored to the restore directory, with permissions and ownership of the restore directory itself ('.') set to those of the file system on the tape. If root owns the file system that you're restoring from on the tape, and you used your home directory as the temporary restore location, your home directory is now owned by root. If you choose n, the permissions and ownerships of the file system on the tape are not given to the directory that you're restoring in ('.'). But the hierarchy as it appears on the tape is still restored into the restore directory with the permissions and ownerships that belong to the hierarchy. In this example, because I am restoring an entire file system, choosing yes is the best answer. Because I am now done with the level 0 tape, I can continue with the level 2 tape. To eject the level 0 tape, or start the ejection process, depending on the tape drive, I can issue this command: rosalyn osx-misc 166 > mt -f /dev/rmt/0n offline Here is how the restore goes on the level 2 tape: [localhost:/new1] root# restore ibf 126 rosalyn:/dev/rmt/0n Connection to rosalyn.biosci.ohio-state.edu established. restore > ls .: ftp/ restore > add ftp warning: ./ftp: File exists warning: ./ftp/incoming: File exists warning: ./ftp/incoming/ISSR: File exists warning: ./ftp/incoming/rtr: File exists warning: ./ftp/incoming/galloway: File exists warning: ./ftp/incoming/reeve: File exists warning: ./ftp/incoming/reeve/990726: File exists warning: ./ftp/incoming/reeve/05-1098: File exists warning: ./ftp/incoming/reeve/05-1098-2: File exists warning: ./ftp/incoming/njohnson: File exists restore > extract You have not read any tapes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 set owner/mode for '.'? [yn] y restore > quit From the warnings that restore issues, I learn that there are probably new files in directories that now already exist on my machine. Because the restore from the level 4 tape looks almost the same as the one from the level 2 tape, except for warnings about different directories, its output is not shown. Always Something There to Rewind Me If you can't seem to get off file number 1 on the tape drive, it's because you're using the rewind version of your tape device. Read the man pages on the tape host machine to find out how to use the nonrewinding interface to your tape. Currently, your tape is being helpful by automatically rewinding itself after every command. So, if you're using the rewind device and ask the drive to skip forward 16 files, it will dutifully do so. Then it will be most helpful, and automatically rewind itself again before you can issue another command. So far, we have seen that the OS X restore can restore UFS data that was dumped from another operating system. It can also restore UFS data that was dumped from the OS X dump. Here is a demonstration of restoring a file from the OS X dump that you saw earlier: [localhost:~joray/temp-restore2] root# restore ibf 64 rosalyn:/dev/rmt/0n Connection to rosalyn.biosci.ohio-state.edu established. restore > ls .: ftp/ installed-950421/ stacker.mods installed/ lost+found/ restore > cd ftp restore > ls ./ftp: / home.html BuiltByNOF.gif incoming/ Home_HProfessional_down.gif index.html Home_NProfessionalBanner.gif l3seqmotifs.pdf INSTALL-BINARY l4datsearch.pdf If-250.jpg l5apat.pdf L1a-Intro.pdf l5bprotfam.pdf L1b-Molbio.pdf public/ L2-database.pdf talks.htm L2b-genomeDBs.pdf usr/ L3a-homology.pdf whatsnew.txt L3b-globalaln.pdf ws_ftp.exe L6-phylogenetics.pdf ws_ftp.ext bin/ ws_ftp.hlp clearpixel.gif ws_ftp.ini dev/ ws_ftp.log error.wav ws_ftp.txt etc/ ws_read.me guest/ restore > cd public restore > ls ./ftp/public: .ADeskTop dilbert.tar patches-sunos-0010/ .IDeskTop grasp.tar patches-y2k/ .afpvols jk1 pfu_clean_leaders.tfa .finderinfo/ lib-libMagick.tar pfu_clean_leaders.tfa~ .resource/ mix ph_clean_leaders.tfa BACK pab_clean_leaders ph_clean_leaders.tfa~ ISSR.programs/ pab_clean_leaders.tfa sendmail.8.11.1.tar.gz Network Trash Folder/ pab_clean_leaders.tfa~ ssh-2.0.13-src.tar assets/ patches-aug98/ tbtupmc1.zip bigfile.af-mt patches-more/ yst.tar delphin.tar patches-security/ restore > cd patches-sunos-0010 restore > ls ./ftp/public/patches-sunos-0010: 100523-26/ 100626-10.tar Solaris1.1.2.PatchReport 100523-26.tar 106859-01/ install-patches-0010 100626-10/ 106859-01.tar restore > add Solaris1.1.2.PatchReport restore > extract You have not read any tapes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 set owner/mode for '.'? [yn] n restore > quit If we do a quick check for the data, we see that the temporary restore directory, ~joray/temp-restore2, has the desired file and that it was restored in the hierarchy seen while running restore. [localhost:~] joray% ls -RaF temp-restore2 ./ ../ ftp/ temp-restore2/ftp: ./ ../ public/ temp-restore2/ftp/public: ./ ../ patches-sunos-0010/ temp-restore2/ftp/public/patches-sunos-0010: ./ ../ Solaris1.1.2.PatchReport Partial command documentation for restore is shown in Table 32.3. Just as you saw with the dump syntax, the restore syntax shown earlier is the traditional restore syntax. However, from the man page, we would also expect this restore statement to work: restore –i –b 64 –f rosalyn:/dev/rmt/0n After dumping to a tape, it is a good idea to randomly check the tape to make sure that your data is readable, especially on a level 0 dump tape. It should be sufficient to use restore and run ls, rather than actually restoring something. If the tape is not readable, the tape drive will inform you right away. Sometimes there is a bad tape in the package, and you find that out only when you try to restore from it. Table 32.3. Command Documentation Table for restore restore Incremental file system restore restore -i -b <blocksize> -f <file> -s <filenumber> (The 4.3BSD option syntax is implemented for backward compatibility, but is not documented.) restore restores files from backup media created with the dump command. A full backup of a file system may be restored and subsequent incremental backups layered on top of it. Single files and directory subtrees may be restored from full or partial backups. -i Interactive. After reading in the directory information from the media, restore invokes an interactive interface that allows you to browse through the dump files directory hierarchy and select individual files to be extracted. See the listing of interactive commands later in this table. -b <blocksize> Specifies the block size, the number of kilobytes per dump record. If the option is not specified, it tries to determine the media block size dynamically. -f <file> Reads the backup from <file> . <file> may be a special device, such as a tape drive or disk drive, an ordinary file, or - (standard input). If <file> is of the form <host> : <file> or <user> @ <host> : <file> , restore reads from the named file on the remote host using rmt (8). -s <filenumber> Skips to <filenumber> when there are multiple files on the same tape. File numbering starts at 1. Interactive Commands add <file> Adds the specified file or directory to the list of files to be extracted. If the argument is a directory, it and all its descendants are added to the list. Files that are on the extraction list are prepended with a "*" when they are listed by ls. delete <file> Deletes the current file or directory and its descendants from the list of files to be extracted. extract Extracts all files on the extraction list from the dump. cd <directory> Changes to the specified directory. ls <directory> Lists the current or specified directory. pwd Prints the full pathname of the current working directory. help Lists the available commands. quit Ends the session, even if there are files listed for extraction. The utilities dump and restore are excellent examples of how the availability of Unix-based solutions often exceeds that of what is available natively on Mac OS X. Users who have abandoned non-native Classic and Carbon applications can easily use these utilities to back up their entire system. For everyone else, all we can do is wait. Diagnostics | Next Section Previous Section Share This

`restore`	Incremental file system restore
restore -i -b <blocksize> -f <file> -s <filenumber>
(The 4.3BSD option syntax is implemented for backward compatibility, but is not documented.)
`restore` restores files from backup media created with the `dump` command.
A full backup of a file system may be restored and subsequent incremental backups layered on top of it. Single files and directory subtrees may be restored from full or partial backups.
`-i`	Interactive. After reading in the directory information from the media, `restore` invokes an interactive interface that allows you to browse through the dump files directory hierarchy and select individual files to be extracted. See the listing of interactive commands later in this table.
`-b` `<blocksize>`	Specifies the block size, the number of kilobytes per dump record. If the option is not specified, it tries to determine the media block size dynamically.
`-f` `<file>`	Reads the backup from `<file>` . `<file>` may be a special device, such as a tape drive or disk drive, an ordinary file, or `-` (standard input). If `<file>` is of the form `<host>` : `<file>` or `<user>` `@` `<host>` `:` `<file>` , `restore` reads from the named file on the remote host using `rmt (8)`.
`-s` `<filenumber>`	Skips to `<filenumber>` when there are multiple files on the same tape. File numbering starts at `1`.
Interactive Commands
`add` `<file>`	Adds the specified file or directory to the list of files to be extracted. If the argument is a directory, it and all its descendants are added to the list. Files that are on the extraction list are prepended with a `"*"` when they are listed by `ls`.
`delete` `<file>`	Deletes the current file or directory and its descendants from the list of files to be extracted.
`extract`	Extracts all files on the extraction list from the dump.
`cd` `<directory>`	Changes to the specified directory.
`ls` `<directory>`	Lists the current or specified directory.
`pwd`	Prints the full pathname of the current working directory.
`help`	Lists the available commands.
`quit`	Ends the session, even if there are files listed for extraction.

Backups

Mac OS X Native GUI Backup Utilities

Retrospect

Synk X

Command-Line Backups

Understanding Incremental Dumps

Table 32.1. Sample Backup Schedule

Using dump

Table 32.2. Command Documentation Table for dump

Troubleshooting dump

Restoring Your Data from Tape: Using restore