All the Perl that's Practical to Extract and Report

Backing up the iBook

ziggy on 2002-10-31T21:37:04

I've been playing with my FireWire drive today. First, a few things are known not to work:

  • A drag-copy won't copy files that I can't read, and it will reset file ownership and permissions.
  • tar, pax, rsync and cpio might be able to retain file attributes, but cannot backup the HFS+ resource fork.
  • sudo tar or the moral equivalent will handle copying files I can't read, and preserve permissions as well
I've heard about psync that comes with the Mac::File distribution, but decided against it. I started out with hfstar, but it was acting funny. I had an old version and upgraded it, and it still was acting a little funny (although it was preserving the resource fork when I used hfstar to do the extraction).

Poking around, I found rsync_hfs, available from the CVS repository at opendarwin.org. I started using that, since it would be much easier to do an incremental backup just before I send the iBook back for repairs.

Here's what I learned:

  • rsync to takes about 1 hour/GB to copy a data to a blank destination directory. I'm guesstimating that this is due to computational overhead, since FireWire can do much better than that. (hfstar seemed to be performing comparably)
  • Drag-copy performed about 50x better, pretty much at raw FireWire speed. (An 8GB mix of small and large files took about 15 minutes, while a 400MB rsync took about 20 minutes). However, the drag-copy technique won't get the file metadata right, nor will it copy files I can't read.
  • A final fixup through sudo rsync_hfs will cleanup any remaining issues that the came from the drag-copy
This worked so well, I'm considering reformatting the hard drive after the hardware is fixed to make this a dual-boot machine. :-)

psync?

pjm on 2002-11-01T12:48:30

Which leads to the obvious question: why not psync? Reports I read tell of speeds way in excess of what you're seeing, and it seems to be reliable. I think someone (Randal?) might have been having trouble making a bootable backup via psync, but that seemed to be a drive-specific issue (ie an early firewire drive).

Just interested in why you looked elsewhere (as I've pointed a lot of people toward psync as a way to incrementally backup on Mac OS X).

Re:psync?

merlyn on 2002-11-01T14:04:37

I'm told my problem with making a bootable drive was merely that I hadn't installed a base system onto the drive. When I jumped from my 667 to my 800, I did it by installing a small release on the 800, psync'ing the entire release over the top (gotta love that target disk mode), and the 800 was bootable as if it was the 667. Works fine.

I'm using psync daily to a backup firewire drive. However, since I can't "boot" off of that, I'll probably just install and drag-copy stuff back if I ever need to use it.

Re:psync?

ziggy on 2002-11-01T14:24:49

I believe that the speeds are directly related to the number and size of the files being copied. That is, copying 1 1GB file is significantly faster than copying 1024 1MB files or 256K of 4K files. I've seen the variation in speed even with a drag copy. And most of the files I'm backing up are small files...

rsync does impose some overhead on top of that. After some more experimenting, it seems like rsync[_hfs] actually re-copies a file if the permissions are wrong, and my 8GB transfer was of my home directory (with a lot of MP3s), so the rsync fixup of /Users didn't have much to modify.

I've had to reformat the drive a few times now. I wanted to use it on Mac OS X, FreeBSD and Win*. However, the drive came as a dedicated HFS+ partition. Drive Utility won't create an MS-DOS partition (only a dedicated MS-DOS drive). While Drive Utility can create a UFS partition, I didn't get to test it out because (1) my FreeBSD kernel didn't have the umass driver compiled in, and (2) I'm skeptical that FreeBSD can read Apple's drive map.

It's not that I have something against psync per se. Just that I wanted to try rsync[_hfs] first. I'll probably test psync shortly.

No Mac::File

pudge on 2002-11-07T14:02:04

I believe you mean MacOSX::File. There is no Mac::File. There is a Mac::Files, part of MacPerl/Mac::Carbon, soon to be released!