30 September 2013

I upgraded my Mac recently, and moved from a laptop with two internal drives – an SSD and an HDD – to a single, large SSD. I wanted to note down the aspects of this transition I’d have like to have known beforehand, and also want to know for

My old computer placed various core user folders – Documents, Music, etc – onto the HDD, whilst storing the System and Applications on the SSD. I symlinked the User folders into my home directory, and OSX was none the wiser.

As far as backing up goes, I used to use the excellent SuperDuper. When I moved to my symlinked setup, I went to Time Machine, which can back up multiple drives to a single Time Machine volume. I told it to back up both the SSD and HDD; it backed up the symlinks themselves from the SSD, and the directories they referred to from the HDD.

When I transfer data to a new Mac with Migration Assistant, I do so from a backup or bootable clone of the original computer – never from the computer itself. I chose to restore from Time Machine. This will only restore from a bootable drive – so I was only given the option to restore from my SSD, which contained Applications and my Desktop, but not my Documents. This unnerved me a bit at the time.

However, this is because the Migration Assistant only offers to restore from bootable (system) drives. Once I’d restored, I booted up the new system, mounted my Time Machine drive, and dragged everything over from the “Latest” directory symlink inside the HDD’s backup folder; I soon had my documents and other files back in the original locations they should have been.

So that’s the main note I wanted to make: restoring from that kind of setup works entirely fine, but you musn’t panic when your HDD isn’t offered as a volume to restore from.

I use Caps Lock as my Control key, and vice versa. (Blame Vim). I had to re-specify this preference, and frequently, it would get overwritten on wake-from-sleep. A reboot (which presumably repaired permissions fixed this).

For a while, I noticed git wasn’t working. This was because it was not installed through homebrew, but directly into /usr/local/bin – and that was no longer in my PATH. Adding it back to my PATH re-enabled it. (All my homebrew binaries were working fine).

My /etc/hosts had been overwritten back to default; I need to copy that across manually. As had all my Apache config (/etc/apache2/httpd.conf), my vhosts config file (/etc/apache2/extra/httpd-vhost.conf), and /etc/php.ini . Nothing we can’t recover quickly, but it did mean the usual dance of setting up vhosts for sites that already existed, and pointing php.ini at the correct MySQL socket file (/tmp/mysql.sock on OSX).

I think that’s it – everything else transferred entirely seamlessly, and there was nothing to fear about my unusual setup – you just have to make sure you’ve been backing up correctly, and everything will work.