Mac Forum / Applications / Mac Applications / June 2008

Understood. I was pointing out that, on an individual Mac basis, the
odds of needing to restore an occasional file or two are A LOT greater
than needing to restore an entire volume. I'll tell you, there's nothing
quite like setting up a bootable clone backup system for someone only to
have them say a while later, "What do you mean I can't recover that file
I accidentally deleted last week?"

That makes no sense. Who has made these comments about he alleged
"overhead"? Basically, no, TM has no overhead in the storage system, so
that nonexistant overhead couldn't very well slow down a restore. If you
have a slow restore, then it must be for some other reason. Trying to
translate specs for disk transfer rate into observable performance in
real tasks is a non-trivial matter. There are lots of issues that can
come into play there. I don't think I'll even try to list them. But TM
overhead isn't one of them, because there isn't any. TM uses a plain old
HFS+ storage system. The only thing the least bit unusual about it is
the symlinks to directories, which doesn't constitute overhead and
wouldn't affect restores.

That should be 3 Gigabits per second for SATA-2, not 3 GigaBYTES per
second. Actual maximum speed after protocol overhead is 300 MB/sec, so
these numbers are out by a factor of ten.

The original SATA was 1.5 Gbps or 150 MB/s (which was an improvement
over ATA-133, at 133 MB/s).

That number also seems to be out by a significant factor. Real hard
drives have best transfer rates in the order of 100 MB/s. It could only
achieve 1 GB/s if reading out of a RAM cache on the drive, and no hard
drive interface is fast enough to deliver that much throughput.

I don't have any direct experience with eSATA, but it should be able to
achieve the same speeds as SATA. The drive is typically the limit, not
the interface. For a striped multi-drive RAID, the interface might be a
limit.

For a single drive, the drive is usually the limiting factor with FW800.
My Seagate Barracuda (7200 rpm 3.5") 500 GB drive achieves a best
throughput in the order of 60 MB/s on FW800. (It drops to 40 MB/s for
FW400, 30 MB/s for USB 2.0.)

Agreed. I've never seen USB 2.0 transfer data faster than 30 MB/s.
PowerPC Macs tend to be much slower than Intel ones. PowerBook G4s I've
tried never got faster than 20 MB/s on USB 2.0.

And you have to halve that speed to get a realistic maximum transfer
rate.

The above numbers don't take into account the speed of the other drive:
if restoring to a laptop (2.5") drive, don't expect transfer rates to
exceed about 30 MB/s, which is what the 160 GB drive in my MacBook Pro
can manage.

The most significant delaying factor is overhead when dealing with small
files.

If you are copying large files, the actual transfer rate can be very
close to the theoretical limit of the drive and/or bus. Most of the time
is spent actually shunting vast amounts of data from one drive to the
other.

If you are copying a lot of small files, the transfer rate drops
dramatically. For each file copied, the system has to update the
directory information (metadata). This isn't written to the disk
constantly, but it has to be updated immediately in memory, and is
flushed to disk reasonably often.

In addition, the system typically only requests a small amount of data
to be read from the source drive, and written to the destination drive,
because it copies one file at a time. This may involve seeking and
rotational latency. The source drive's cache won't help much when doing
lots of small read requests, unless the files are stored sequentially
(no fragmentation and the files are being copied in the same order they
were originally written) and the drive is smart enough to read ahead.

The protocol overhead for all these small I/O requests is also
significant. Rather than sending one request to the drive to transfer
several megabytes, the computer is sending hundreds of requests, each
asking for a few kilobytes. Each of these requests has to be generated
by the CPU, sent over the interface to the drive, and processed by the
drive controller.

I've observed this pattern with all backup methods. If I'm backing up my
computer, most of it goes quite slowly, until it hits my iTunes library:
it is then copying about 4 MB per file, and this goes substantially
faster than copying the dozens of small files that make up typical
applications or system packages. Maximum speed is achieved while backing
up my VMware Fusion disk image (several gigabytes in a single file).

I did a full system backup of my MacBook Pro with SuperDuper! just
before installing 10.5.3. It backed up about 120 GB via Firewire 800 in
somewhat more than two hours. I would expect a restore to go a little
faster, because the backup drive has all the data stored sequentially
(no fragmentation). I don't have a comparitive figure for Time Machine,
as I haven't used it to do a full backup of the computer (only my data
files).

Time Machine does have some additional overhead when doing a backup,
because it has to maintain the hard links and some additional metadata
(extended attributes) for each file. When restoring, some of this
metadata has to be removed, so I'd expect a greater degree of overhead
than when doing a restore from a SD clone.

In addition, the TM backup will be heavily fragmented due to recently
modified files being grouped together at the tail end of the backup,
with earlier unmodified files being scattered all over the place. This
means a lot more seeking is required to read all the files that make up
a single "unified" backup. I expect this would significantly slow down
restoring from TM compared to a SD backup.