OS X | Raam Dev

Posts Tagged: OS X

Creating a Bootable OS X Backup on Linux: Impossible?

I’ve had plans for a while now to set up a backup system using a Debian Linux server and rsync to back up my MacBook Pro laptop. At first glance, it seemed like it would be pretty straight forward. I’ve been able to make a bootable copy of my entire MBP using nothing but rsync (thanks to some very helpful directions by Mike Bombich, the creator of the popular, and free, Carbon Copy Cloner software). And by bootable copy I mean I could literally plug in the USB drive and boot my MBP from the drive (hold down the Alt/Option key while booting). Restoring a backup is as simple as running the rsync command again, but in the reverse direction. I know this solution works because I used it when I upgraded to a 320GB hard drive.

To start, I needed to create a big enough partition on the external USB drive using Disk Utility (formatted with Mac OS Extended (Journaled)). I then made a bootable copy of my MBP with one rsync command:

sudo rsync -aNHAXx --protect-args --fileflags --force-change \ --rsync-path="/usr/local/bin/rsync" / /Volumes/OSXBackup

But my dream backup system was more unattended. I wanted something that would periodically (a couple times a day) run that rsync command over SSH (in the background) and magically keep an up-to-date bootable copy of my MBP on a remote server.

I love Linux and I jump at any opportunity to use it for something new, especially in a heterogeneous network environment. So when I decided to set up a backup server, I naturally wanted to make use my existing Debian Linux machine (which just so happens to be running on an older G4 Mac Mini).

So, after making a bootable copy of my MBP using the local method mentioned above, I plugged the drive into my Linux machine, created a mount point (/osx-backup), and added an entry to /etc/fstab to make sure it was mounted on boot (note the filesystem type is hfsplus):

/dev/sda /osx-backup hfsplus rw,user,auto 0 0

All that’s left to do now is to run the same rsync command as earlier but this time specifying the remote path in the destination (root@myserver.example.com:/osx-backup/). This causes rsync to tunnel through SSH and run the sync. Unfortunately, this is where things started to fall apart.

OS X uses certain file metadata which must be copied for the backup to be complete (again, we’re talking about a true bootable copy that looks no different than the original). Several of the flags used in the rsync command above are required to maintain this metadata and unfortunately Linux doesn’t support all the necessary system calls to set this data. In particular, here are the necessary flags that don’t work when rsyncing an OS X partition to Linux:

-X (rsync: rsync_xal_set: lsetxattr() failed: Operation not supported (95))
-A (recv_acl_access: value out of range: 8000)
–fileflags (on remote machine: –fileflags: unknown option)
–force-change (on remote machine: –force-change: unknown option)
-N (on remote machine: -svlHogDtNpXrxe.iL: unknown option)

According to the man page for rsync on my MBP, the -N flag is used to preserve create times (crtimes) and the --fileflags option requires chflags system call. When I compiled the newer rsync 3.0.3 on my MBP, I had to apply two patches to the source that were relevant to preserving Mac OS X metadata:

patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff

I thought that maybe if I downloaded the source to my Linux server, applied those same patches, and then recompiled rsync, that it would be able to use those options. Unfortunately, those patches require system-level function calls (such as chflags) that simply don’t exist in Linux (the patched source wouldn’t even compile).

So I tried removing all unsupported flags even though I knew lots of OS X metadata would be lost. After the sync finished, I tried booting from the backup drive to see if everything worked. It booted into OS X, but when I logged into my account lots of configuration was gone and several things didn’t work. My Dock and Desktop were both reset and accessing my Documents directory gave me a “permission denied” error. Obviously that metadata is necessary for a viable bootable backup.

So, where to from here? Well, I obviously cannot use Linux to create a bootable backup of my OS X machine using rsync. I read of other possibilities (like mounting my Linux drive as an NFS share on the Mac and then using rsync on the Mac to sync to the NFS share) but they seemed like a lot more work than I was looking for. I liked the rsync solution because it could easily be tunneled over SSH (secure) and it was simple (one command). I can still use the rsync solution, but the backup server will need to be OS X. I’ll be setting that up soon, so look for another post with those details.

HOWTO: Install md5sum & sha1sum on Mac OS X

I was a bit surprised to learn that my Mac didn’t have the md5sum and sha1sum tools installed by default. A quick search and I found a site that provides the source. The sources compiled successfully on my Mac (OS X 10.5.5, xCode tools installed).

The only quirk appears in the last step:

$ ./configure $ make $ sudo make install cp md5sum sha1sum ripemd160sum /usr/local/bin chown bin:bin /usr/local/bin/md5sum /usr/local/bin/sha1sum \ /usr/local/bin/ripemd160sum chown: bin: Invalid argument make: *** [install] Error 1

The make install command tries to change the ownership of the files to the bin user. Since that user doesn’t exist on my system, the command fails. This isn’t a problem though, as both binaries work perfectly. By default, they are installed to /usr/local/bin/.

Update
As a commenter pointed out, the /sbin/md5 utility provided by OS X contains a hidden -r switch that causes it to output in a format identical to that of md5sum, making it compatible with scripts that require md5sum’s format. If you want to use the md5 utility provided by OS X, you can add the following to your ~/.profile or ~/.bashrc:

alias md5='md5 -r'
alias md5sum='md5 -r'

Accessing the VMWare Fusion BIOS

As noted in the Known Issues section of the VMWare Fusion Release Notes, the VMWare Fusion BIOS goes by way too fast to give you a chance to access it. The only way you can access it is by modifying the .vmx configuration file for the VM:

The VMware Fusion BIOS posts too quickly to access.

Most users will not need to access the BIOS, but advanced users might want to do so, to change the boot order, set a boot password, or enable a second floppy drive. To work around this problem, use a text editor to add the following line to the configuration (.vmx) file of the virtual machine:

bios.forceSetupOnce = "TRUE"

The next time you boot up the virtual machine, it will automatically boot into the BIOS. This configuration option then reverts to FALSE. You must set the option to TRUE each time you want to boot the virtual machine into the BIOS.

Having trouble finding the .vmx file?

You cannot edit the .vmx file by opening it with Finder. You need to use the Terminal to edit the file. Here’s how you do that:

Launch Terminal (Applications -> Utilities -> Terminal.app) and navigate to the folder (or directory) where your Virtual Machines are stored. To do this, you use the “cd” command. For example, my Virtual Machines are stored in Documents -> Virtual Machines, so I type the following to change into that directory: cd Documents/Virtual\ Machines/ and then press Enter.

Now you need to change into the directory that matches the name of your Virtual Machine. For example, let’s say it’s called “Windows XP” — you would type cd Windows\ XP/. (Note that you have to “escape” spaces in the folder name by preceding them with a backslash.)

Once you’re there, you can use the “ls” command (that’s a lowercase L) to list the contents of that folder. You should see the .vmx file you’re looking for. Now to edit that file in TextEdit, simply run the following command: open -e *.vmx.

That’s it! Now you can edit the file as described above to enable the BIOS.

Backup-Bouncer

I haven’t tried it yet, but Backup-Bouncer looks like a very useful tool for verifying backup methods (it doesn’t actually verify backups, but rather the accuracy of a backup method’s ability to copy OS X metadata). The latest version of rsync (v3.0.3) passes Backup-Bouncer with flying colors when tested with this command: sudo rsync -aNHAXx –protect-args –fileflags –force-change /Volumes/Src/* /Volumes/Dst/test

Upgraded rsync from v2.6.9 to v3.0.3

I just upgraded rsync on my Mac from v2.6.9 to v3.0.3 by following these directions. The ./configure command failed until I downloaded and installed the latest Xcode Developer Tools from Apple. The latest version of rsync is supposed to be faster for large transfers (such as backing up my entire 320gb MBP hard drive!).