Two macs, one person. Yes, a first world problem — but how hard could it be?

Very.

Having recently switched to a dual-computer workflow (one desktop, for performance; one laptop, for portability), I was not so much eager to find out how to make them work well together as I was sure I was facing a potentially frustrating adventure. I was not wrong.

What I want is — seemingly — simple:

• I want all my data to permanently live on the desktop computer (where the large hard drive will be).
• I want a subset of that data to be readily available on the portable computer, and I want to be able to choose what’s in that subset
• I want my app preferences to be synced between the two computers
• I want to be able to leave home in a hurry, and sync my two computers while I am away from home (but not away from Internet access)
• I want all my data to be backed up using Time Machine
• I want an off-site backup

In short, I want my computers to be convenient and my data to be safe.

I did some research and learned that my options were basically thus:

1. Use a cloud-based file sharing service, such as DropBox. Pros: Easy to set up; network sync when away from home. Cons: Doesn’t sync my app preferences; requires substantial monthly fee for the amounts of data that I have.
2. Use a personal cloud device, such as Transporter. Pros: Easy to set up; network sync when away from home. Cons: Doesn’t sync my app preferences.
3. Use a Mac-to-Mac sync utility, such as ChronoSync or Synk. Pros: Easy to set up; can sync app preferences; one-time purchase. Cons: Syncing when away from home requires extra work.
4. Use OS X Server and Portable Home Directories (PHD). Pros: One-time purchase; can sync app preferences. Cons: complex to set up, syncing away from home requires extra work.

I ruled out cloud file sharing right away; the amount of data I have would put me in the $100-$200 per year Dropbox pricing tier. At that price, I can buy a Transporter and it will pay for itself in 3 years.

I spent some time researching the OS X Server option, and learned that it’s completely useless. Portable Home Directories operate in one of two modes: slow sync (default), which works by having one computer scan the other for changes over AFP, and is (at my volume of data) unacceptably slow; and fast sync (can be turned on from Terminal), which works by having one computer track changes locally so the other computer doesn’t have to actively scan for changes. Fast sync sounds like it would solve my problem — but it has a bug such that it fails any time it encounters a zero-byte file, of which I have many (and so do you — for example, SQLite database stores, such as the Messages database, frequently include a zero-byte file).

That left me with either a personal cloud device or a Mac-to-Mac sync app. When it comes to Mac-to-Mac syncing (assuming that we are talking about syncing over WiFi — there is also syncing in target disk mode, but that requires restarting on the of the computers, so it’s not my first choice), my biggest concern was what happens if I leave home in a hurry. Can I use Mac-to-Mac syncing between two computers separated by the Internet?

In short, maybe. It can be done using Back to My Mac — set up file sharing between the two Macs, sign both of them up for Back to My Mac, and instruct the sync app to do its thing from there. However, this is not what I settled on.

In part, I wanted to experiment with a Transporter, because the idea of a Dropbox-like service in which I control the storage appeals to me beyond the quandary of syncing two Macs. In part, Mac-to-Mac syncing doesn’t solve my off-site backup problems, whereas a Transporter might, so I decided to check out whether Transporter works for Mac-to-Mac syncing.

It sort of does.

First of all, it suffers from all the problems of low-fidelity file replication — it does not fully preserve HFS+ extended attributes and ACLs, so various files get variously mangled on the way in and out of Transporter. If all I wanted to sync were run-of-the-mill platform-agnostic files (PDFs, JPGs, etc), Transporter would work fine.

However, my software development folder is basically the nightmare of every file sync app — there are symlinks (for example, in framework bundles), extended attributes (for example, Mavericks file tags), and ACLs. If you look hard enough, you will even find resource forks. I don’t want to think about which files are going to get mangled between my computers, so I want all that stuff to Just Work™. With Transporter, it doesn’t.

Symlinks turn into copies of their targets; extended attributes and POSIX permissions selectively vanish; and I didn’t even check what happens with resource forks because once I lost symlinks and EAs, using Transporter by itself was not going to be viable.

Whenever a problem like this crops up, I turn to disk images, because they are intended to be a file format that provides support for all the Mac bits and pieces, while existing in storage that has no idea how a Mac works. So, instead of using Transporter the way I am supposed to, I created myself a (sparse bundle) disk image on my Transporter and copied some files to it.

In some ways, this worked better: my Transporter was happy to store the disk image; the nature of sparse bundle disk images is such that updating it involves relatively small reads and writes, rather than the entire disk image being constantly rewritten; and I could mount my disk image and see that the Macness of my files was intact.

The problems with this approach came from a different direction. Transporter makes no guarantees about the order in which local changes are propagated to the remote end. This isn’t a problem until you mount the same disk image on two computers, and they both decide to modify it. Whatever locking mechanisms are used by the sparse disk image implementation require some modicum of ordering of changes, so I corrupted my disk image within minutes of mounting it on both computers.

Compounding this is the fact that Time Machine does not back up contents of disk images. (Not even if they are permanently mounted by root.) So, not only was I putting my data on a disk image (which in itself increases the probability of losing a whole lot of files if only a small amount of data is damaged), but I was exempting my data from a backup, and that was just not going to fly.

The upshot of all this is that Transporter (or Dropbox, or any other remote file storage, really) is fundamentally flaky. Some are better, some are worse, but at the end of the day, I do not want to be committing the main copy of any of my data to a flaky storage medium, especially not if in doing that I lose one layer of backups (Time Machine).

On the other hand, a good sync app will — by definition — offer a high degree of reliability. And so I turned to the last stone left unturned: how could I combine the ubiquity of a Transporter with the reliability of a file sync app? While preserving Mac metadata, and Time Machine backups, and a pony?

I assumed that anything I put in a Transporter might disappear — which makes it a good ephemeral medium, and a reasonable backup medium, but not at all a storage medium. Therefore, all my data had to have a definitive place of residence on one (or both) of my computers, and be backed up by Time Machine.

I created a (sparse bundle) disk image on my Transporter. This disk image will be used for getting data between the computers, but will not be the definitive place of storage of any of that data. (This disk image lives in my Transporter Library, which means that writes to it are actually serialized, and therefore the probability of disk image corruption is diminished.)

I tried out a few file sync apps and settled on ChronoSync on account of its ability to bit-for-bit verify the results of a sync, and its ability to preserve Mac metadata, as well as its excellent error reporting.

Finally, I set up a ChronoSync document which syncs data on my computers with the sparse disk image mounted from my Transporter. Now my data is in a trusted place (my disk), getting backed up (by Time Machine), redundantly synced to a separate device (Transporter), and with Mac metadata preserved (by ChronoSync).

I am still debating my options for an off-site backup; the easiest solution is to move my Transporter to a friend’s home, but there are some tradeoffs involved in that that I am still pondering.