“Apple® today announced that its groundbreaking iWork® productivity apps, Keynote®, Pages® and Numbers®, are now available for iPhone® and iPod touch®, as well as iPad®. Created for the Mac® and then completely redesigned for iOS and Apple’s revolutionary Multi-Touch™ interface, Keynote, Pages and Numbers allow you to create and share stunning presentations, beautifully formatted documents and powerful spreadsheets on the go. iWork apps are available on the App Store™ for $9.99 each to new users and as a free update for existing iWork for iPad customers.” — via Apple – Press Info – Apple iWork Now Available For iPhone & iPod touch Users.

I’ve been using ChronoSync for years. At one time it was all I used for backups. It was somewhat flexible, somewhat easy to use, always reliable… Then Time Machine came along*.

Since then I’ve beefed up my data retention and redundancy policies to include several buckup routines with multiple applications across multiple media. My current backup regime consists of:

* several daily automated ChronoSync backups of critical directories to various portable USB drives and LAN storage units,
* Time Machine of the user directory to an internal drive,
* DropBox storage of critical directories,
* MobileMe for preferences and settings,
* several manual backup operations to my Linux server

Seems pretty comprehensive, somewhat painless and hands-off, but where the real bottle-neck occurs is when ChronoSync and Time Machine start backing up at the same time. ChronoSync is a pig and tends to just buckle as soon as Time Machine winds up. The two apps seem to compete for the same cycles and neither one will free up any resources until I’m forced to stop both processes. Growing very tired of this battle of the two backup schemes I decided to write my own backup script.

## Goals ##

I’ve come to like Time Machine’s snapshot-like, incremental backups, and I’ve become weary of just backing up segments of what I value. So first and foremost I wanted my script to backup everything.

Second, it has to be fast and efficient. The lighter it is the more often I can run it. The more often I run it the the better my chances are of having the latest greatest backups.

Third, it needs to backup to a server. Time Machine does a great job of backing up to local hardware so there is no need to replicate that.

Lastly, it needs to run automatically.

## Technology ##

To achieve these goals I decided early on what technologies I was going to use (it was a no-brainer actually).

* When you think of any communication between a computer and a remote server, shell scripting is the obvious choice. Since most \*nix systems come loaded with Bash then…
* rsync, an awesomely powerful command line program that excels at remote synchronizations with minimal data transfer will do the bulk of the work.
* SSH is going to be the pipe that gets me from here to there.
* cron is going to allow me to schedule my backups .

## The Script — CRIBBS ##

I spent a few days perusing the web for solutions that could give me a start. I ended up drawing off a number of key sources** but in the end had put together the best script for me. It’s not terribly original but it did take me a solid day to get things just right. There is more I’d like to do to it yet but this will do for now.

No point including it here since it’s likely to change and improve over time. But you can see it in all it’s glory over on Code Collector… ladies and gentlemen, I give you [CRIBBS -- Cron Rsync Incremental Backup Bash Script][a_110527145011]!

### Notes ###

* I’ll admit I was pretty harsh on Time Machine in the beginning. Google “[time machine sucks][a_110527114401]” and my [epic rant][a_110527114451] against it ranks number 1.

** Here are some of the main sites I used for inspiration:

* [Easy Automated Snapshot-Style Backups with Linux and Rsync](http://www.mikerubel.org/computers/rsync_snapshots/)
* [How to Backup Your Mac Using Rsync](http://www.macinstruct.com/node/85)
* [Using Rsync and SSH](http://troy.jdmz.net/rsync/index.html)
* [Time Machine for every Unix out there](http://blog.interlinked.org/tutorials/rsync_time_machine.html)

[a_110527114401]: http://www.google.ca/search?client=safari&rls=en&q=time+machine+sucks&ie=UTF-8&oe=UTF-8&redir_esc=&ei=dcbfTducNcrh0QGgwInECg

[a_110527114451]: http://adam.merrifield.ca/2007/11/30/time-machine-a-giant-leap-backward/

[a_110527145011]: http://www.codecollector.net/view/13622/CRIBBS__Cron_Rsync_Incremental_Backup_Bash_Script

“When using CSS, we can just include both declarations, one using rgba, and one without it, as mentioned in my post on cross-browser RGBA backgrounds. When writing JavaScript however, it’s a waste of resources to do that (and requires more verbose code), since we can easily check whether the browser is RGBA-capable, almost as easily as we can check whether it suppports a given property. We can even follow the same technique to detect the support of other CSS3 values (for instance, multiple backgrounds support, HSLA support, etc).”

via Check whether the browser supports RGBA (and other CSS3 values) | Lea Verou.

“So. A lot of old TM users have been looking for the Editor That Will Be TextMate 2.0 By Default. This has in turn given rise to new editors all aiming for that ETWBTM2BD spot. I’ve been following a few of them sporadically. Sublime Text is coming to the Mac! It supports some TextMate bundle operations to make it easier to move over to it! And so does Kod, and even though it doesn’t actually do anything yet it’s open source! Let’s not forget Panic’s Coda and MacRabbit’s Espresso, which are both marketed as quasi-IDEs aimed specifically at web developers and—again—sport limited compatibility with bits and dribbles of TextMate’s bundles.”

via Coyote Tracks – Text Editor Intervention.

Funny how if I search long enough for the geeky answers I end up clicking links back to my own site. That was the case today in search of answers for [controlling my CPU's][a_110502102511].

It used to be in the days of OS X 10.4 you could control the number of CPU’s and turn them on or off from the menu bar–you simply installed `/Developer/Extras/PreferencePanes/Processor.prefPane` and then enabled the “Show control in menu bar” from the Processor preference in **System Preferences.app**. This was more like a 3 tiered operation because the preference pane enabled the CHUD tools that appeared in the menu bar which also gave you access to the **CPUPalette.app**

However this little menu extra was a 32-bit application that never got converted to 64-bit when the rest of the OS’s core services did, namely the **SystemUIServer** (menu bar), so this no longer works in 10.6. We still have access to the 32-bit preference pane and we still have access to the **CPUPalette.app** but we don’t have the bridge between the two, the menu bar extra.

In my previous post I noted that you can use the **CPUPalette.app** on it’s own (found in `/Library/Application Support/HWPrefs/`), but you have to dig for it. Or you can install the 32-bit `/Developer/Extras/PreferencePanes/Processor.prefPane`, but using it in a 64-bit **System Preference** panel is a pain in the butt (and the “Show control in menu bar” still doesn’t work).

So here are a few work arounds, though less then ideal, for controlling your CPU’s in a less then **frustrating** manner. Until these CHUD tools get a 64-bit refresh (or I figure out how to run SystemUIServer in 32-bit mode) there are little other options…

### Make CPUPalette Easier to Access ###

This is likely the least invasive method…

* first, find the **Processor.prefPane** in `/Developer/Extras/PreferencePanes/` (because it has a cool processor icon) and get info on the preference, click the icon (top left), then type ⌘-C.
* then find the **CPUPalette.app** in `/Library/Application Support/HWPrefs/`, get info, click the icon (top left), then type ⌘-V. The **CPUPalette.app** now has the same processor icon.
* now drag the app to your dock. Clicking the icon in the dock will now launch **CPUPalette** for quick access.

### Make Processor.prefPane Easier to Use ###

Well not easier to use I suppose… just make it one less step. You can install **Processor.prefPane** but when you go to use it you’re prompted with the message **”To use the “Processor” preferences pane, System Preferences must quit and reopen.”**

The workaround for this is simply to use **System Preferences** in 32-bit mode. To do this, get info on `/Applications/System Prefences.app` and choose **”Open in 32-bit mode”** under the **”General”** section.

In my limited testing this had no ill effect on any other preference but I think I’d rather stick with the **CPUPalette** method instead.

[a_110502102511]: http://adam.merrifield.ca/2009/03/07/control-your-processors-in-mac-os-x-105/