damians personal blog

The symptoms:
An external firewire harddrive behaves normal right after startup. But after a short time, any attempt to access the drive will result in the "rotating wheel of death" - be it the finder, diskutility or the terminal. If I wait patiently for about 20 minutes, the functionality comes back to normal, until I want to access the damaged harddrive.

Failed remedy:
DiskWarrior, which is usually quite successfull, found the disk to be "too severely damaged for repair." What now? Give up all the data on the drive? Not before having tried all available means! (And, basically, the data is still there and accessible, at least for a moment after startup).

The home-grown remedy:

• Boot the computer into single user mode (press CMD-S at startup)
• Start the operating system but stay in single user mode: % sh /etc/rc
• Connect the firewire drive and check which device number it has got:
  % ls dev (the device will have a name like disk1, the partition on it will be numbered subsequently disk1s1 and so on; usually, the partition You want is disk1s3)
• Mount the partition sudo diskutil mount disk1s3 (although You are logged in as root You still have to use sudo to make it work)
• Optionally check if the partition has mounted without troubles: % df
• Access the data You want using % cp or % rsync (I suggest % sudo rsync -avPE [SRC] [DEST] since it continues the data transfer where it has left it)
• Unmount the partition with % sudo diskutil unmount force disk1s3 if it is not responding (this may take quite a while, so you better be patient)

For me, this worked. I cannot yet tell whether it is a hardware or a software problem, but at least I got my data back.

        20.Aug.2006, 10:27 :: mac os x :: Permalink :: Comments (0)

Wenn das keine grosszügige Aktion ist, dann weiss ich also auch nicht:

Ça c'est ce que j'entend par un rabais généreux:

        19.Aug.2006, 14:25 :: life outside computers :: Permalink :: Comments (0)

Short description of how I backup today. Far less elegant than the coming TimeMachine feature of Leopard, not as complete, and not automated. But I hope until the release of the beast it will do.

As every average geek I have an other machine than my main computer around which is up about 24/7. This computer, in my case a Mac mini, disposes of much more HD space than my laptop (via external FireWire Rack).

The basic syntax of the command I use: rsync [OPTION] SRC [USER@]HOST:DEST
How the command for my purpose looks: sudo rsync -avzPE --stats --timeout=600 --exclude-from=.excludefilelist / damian@dbirdz.dyndns.org:/Volumes/300barracuda/MacBirdPro

What the different parts mean:

• sudo : makes certain system files accessible and is necessary to preserve file owner
• -a : archive mode (recursive; preserve symlinks, permissions, times, group, owner, devices)
• -v : verbose, so You see what's going on
• -z : compress file data, greater CPU load but less network traffic, thus mostly faster (not recommended if backup destination is on the same machine)
• -P : keep partially transferred files (very important, avoids redundant data transfer) and show progress during transfer
• -E : copy extended attributes (i.e. Mac specific resource fork)
• --stats : give some file transfer stats after having finished
• --timeout=600 : if a transfer fails, retry while 10min to finish job before giving up
• --exclude-from=excludefilelist : it may be clever to exclude some file from the backup. my file looks about as follows (entries preceeded by a # are ignored):

#/Volumes  
.vol  
/dev  
/Network  
#/private/var/vm  
/private/var/vm/sleepimage  
#/Developer

• / : indicates which is the source directory, thus the whole root partition
• damian : the username on the remote machine
• dbirdz.dyndns.org : DNS name or IP of the remote machine
• /Volumes/300barracuda/MacBirdPro : path to the remote directory where the backup will be written

If rsync is not yet installed on Your machine, You can get it via fink or from the rsync homepage directly.

        18.Aug.2006, 23:54 :: mac os x :: Permalink :: Comments (0)