The computer systems we rely on so much for everything from email to processing our photos are inherently fragile. We store large amounts of precious data on them, and having backups is important so we don’t lose things when (not if) the storage devices fail.
This article talks about how I use OS X’s Time Machine function as part of our backup strategy. If you’ve got a single OS X machine or a group, hopefully this information will be useful!
Time Machine does automatic hourly backups (you can disable this and just trigger backups manually, but this has its own set of risks). All our OS X machines on our network here are set up so that they’re protected by Time Machine for hourly backups. Not only that, but every month a set of hard drives is swapped with others stored in an off-site location, so we have protection against some level of natural disaster as well as device failure and file deletions.
Note that we do not currently use Time Machine for backups of large datasets such as audio/video/photo media, Lightroom catalogs, or VMware/VirtualBox/Parallels machines. These are backed up at least daily through other software which is outside the scope of this article.
One of the many reasons for this is that Time Machine will only back up files stored on “internal” (e.g. SATA) disks. It also copies whole files, meaning a small change to a 30 GB VM image will result in an extra 30 GB of backup space being used.
Time Machine is backing up the operating system, Applications, and home directories (including iTunes/etc). It gives us the ability to go back in time and restore individual files/folders, as well as restore whole machines. And yes I’ve successfully used this to recover laptops after their internal drives committed harikiri. Some of our machines are also protected by having their boot volumes regularly cloned to another drive using Super Duper! (Carbon Copy Cloner does this too) as that can speed up restoration after a catastrophic crash. But on most machines there are many continually-updated files so the background hourly backups of Time Machine are great!
Note that a partition/volume used for Time Machine (TM) backups should in general not be used for other things at the time time. TM will gradually try to use up all the available space on the volume, which can cause problems for other software assuming there will be some free space. A good first step is to set the name of the volume to something that tells you it’s dedicated to Time Machine!
New Time Machine feature in Mountain Lion
Prior to OS X 10.8, if your machine was set up to store Time Machine on a disk, you had the option to change it to backup to a different disk. Some people have used this to occasionally switch to a different backup drive, and switch back again later. Note that when it runs out of space TM will delete old snapshots to make space. As long as your drive is big enough to hold your data plus some older versions (it only needs extra space for the changed files) the system is supposed to keep running. In 10.8 (Mountain Lion) you have the option to add the second Time Machine disk as an extra, and then add still more. With more than one TM volume, the machine will take turns backing up to each hourly. If a drive is offline, it will switch to the next drive in the cycle automatically.
Different machine TM configurations
I’ve got two types of machine to describe, so I’ll start with the simple one:
Standalone photo workstation
My photo workstation (a big machine fixed in place in my office) is set up with internal storage as well as external SATA docks.
For the Time Machine backups a drive is put into a NewerTech Voyager dock. A partition ( call it TM_wkstn_01) has been set up on this drive to be large enough for the machine’s TM backups. Once the initial TM backup was completed, that drive was ejected, and another inserted with the same partitioning. This drive’s partition is TM_wkstn_02, and was added as a second TM volume. The next TM backup did a full backup to this.
If both drives were online at the same time, each hour the machine would backup to an alternate drive. But because only one is installed at a time (and swapped at the start of the next month) it will keep backing up to that one, and next month when the other drive is available it will automatically switch over to using that. The next backup to that drive will take a little longer as it will include all new data since the drive was last online, but it’s usually not noticeable.
However, after 10 days a warning will be issued via a pop-up on the screen:
This warning is misleading as the system has in fact been backed up, just not to that drive. Hopefully this will be cleaned up in future OS X updates.
For a single workstation this is a fairly robust Time Machine installation. But of course our setup is a bit more complex, so I’ll proceed with outlining another type of machine in our setup.
Our laptops are also set up with multiple TM volumes, but there’s a difference.
The first volume is an ordinary partition on a local (external) hard drive. On my own MacBook Pro this TM volume is a partition on a rugged 1 TB drive which also holds backups of my photos and Lightroom catalogs, and travels with me on photo expeditions (along with another drive, but that’s a different story). Then there are two more TM volumes, but each one is on a networked TM destination on an OS X Server on our office network. When the laptop is on the road and connected to its local drive it backs up to it, but when on the “home” network (whether by 1000 Mb/s LAN, or 300 Mb/s or 130 Mb/s 802.11n WiFi: dependent only on the physical location of the machine in the building) it will back up to the server (and alternately to the local drive if it’s also connected). Over the network the Time Machine backups are relatively slow (especially for the initial full backup) but in normal operation this isn’t an issue as it happens in the background.
These network backups could be done to dedicated Apple Time Capsules or to any of various third-party NAS boxes advertising TM serving, but we’re using the Time Machine server component of OS X Server. OS X Server (an AU$21 purchase from the App Store) has been installed on the photo workstation in my office. Note that Server 2.2 (introduced in early December 2012) added some useful features for managing TM backups, including having multiple TM repositories/shares on the same server.
Two TM repositories are set up on the server. Recall that the workstation described earlier (which is being the server) has its own TM volume as TM_wkstn_01, and this is a partition on an external drive. The remainder of this drive is one large partition which contains one of those TM repositories. The same is done on the other backup drive. So only one of the networked TM shares is actually available at any one time (the other drive is off-site) and the other OS X machines around the office back up to it during the month. At the start of the month when the drive on the workstation/server is swapped, the other networked TM share becomes available (this automatically happens without user intervention once the drive is online) and backups continue to it.
It’s easier (and cheaper) to do things this way than to take a whole Time Capsule or NAS server offsite each month. Of course, the client OS X machines also generate their own warnings after 10 days about not backing up to a TM volume, but that’s a small price to pay for the convenience.
Not only are our laptops set up this way: it’s also used on a desk-bound Mac mini.
Every month a drive from the server is taken off-site, and it contains the Time Machine backups of every machine (one partition with the server’s own TM backup, and another with the networked backups from all the others). Another drive on-site contains the current TM backups, plus history from a month ago when the drive was previously onsite.
A glance at the Server app reports on when the last backup from each of the client machines was, which helps ensure no “silent failures” have been going on in the background.
If (when) the back-up drive fails, we can simply replace it with a new drive and all we’ll lose is some of our backup snapshot history (from every second month). To get more robust than that we would need to store the TM data on RAID storage (swapping out multiple disks each month) but for us the TM history is not of great value. What IS important is being able to restore files to recent state (or if that drive failes then the off-site drive will be at most a month old). There’s a trade-off of convenience vs. absolute protection.
Time Machine is not a robust archive of your history
Keep in mind that Time Machine will delete old history to make space as required, and that it’s still possible for Time Machine volumes to become corrupted, and sometimes it’s easiest to simply wipe the volume and start again. I’ve never treated Time Machine as a long-term archive for files.
Note that all our drives which are going to be stored offsite are encrypted at the filesystem level with OS X’s FileVault2. Of course it is important to not forget/lose the encryption keys, but as long as you have a system for this then it’s great peace of mind against the risk of having the offsite drives lost or stolen. Time Machine also has the option to encrypt its backups, for another level of security.
|Everything deserves a backup copy!|
If you’re an OS X user depending on Time Machine (or thinking of using it) hopefully this article will have given you a few ideas for what’s possible!