Time Machine disappointments

I’ve learned a little about Apple’s Time Machine today and as a result I am much less impressed than I was.  In fact, I’m wondering if I should use it at all.

I’ll start with saying it’s still way better than anything I’ve seen out of Windows, although I haven’t seen what backup functionality they copied from Mac OS into Windows 7. (Wait, did I say that?  I meant, thought of all on their own with input apparently from random customers who then go on TV.)

Time Machine is a supported way within the OS to back up and recover the system drive.  If your root drive dies, you can just boot of the OS CD and tell it to restore from your Time Machine backup.  It also provides a nice interface for easy single-file recovery when you do something stupid and screw up a file and just want yesterday’s version.    That all sounds nice, but…

Time machine wants to back up to a “real” hard drive.  That is, it wants a locally-attached drive, such as a SATA, USB, FW, or eSATA drive.  If you have more than one Mac (like me) you have to either have a USB drive per computer, or you have to walk around with your USB/FW drive, plug it in, then wait for the backup to complete before moving on.

I can hear the Maccies yelling already.  “You need a time capsule!”  First, I’m not buying ANOTHER extra-expensive Apple box just to be a centralized NAS for backup, especially when I’ve got NAS-accessible disk so readily accesible.  So I learned how to configure a “regular” NAS system so that my Mac thinks it’s a time capsule. You actually create a disk image on your filesystem (think .ISO image, but for an HFS+ file system).  It’s called (for some reason, a “sparsebundle.”)  You can read all about how to do that here.

I immediately thought of that as stupid, but I figured it was just a way of tricking my Mac into thinking it was backing up to another Mac.  So I thought, “Hey!  I’ve got another Mac and it has a Drobo on it.  If I share that Drobo via AFP to the other iMac, will Time Machine be OK with that?”  Yes and no.  Time machine does see the AFP-shared volume on the other Mac; however, guess what it does?  It creates a .sparsebundle file over there.

This is different than what it does for locally-attached disks.  If it’s a locally attached disk, it just creates a directory called “Backups.backupdb,” creates a subdirectory in there by the name of the Mac you’re backing up, and then puts its backups in there.  No special file, just a directory.   Having said that, this is a “special” directory.  You can’t modify anything in that directory because it knows it’s backups.  If you try to copy anything into that directory, it will actually say “You can’t modify backups” and exit.

So whether I buy a Time Capsule, use a Linux box, or use another iMac, I’m creating a “sparsebundle” image file.  OK, so let’s say I get over that.  What about the fact that this sparsebundle file apparently gets corrupted a lot?  (What really started this whole post was a comment Joel Ramirez made on my “Dark side” post from a few months ago about how this is a pretty common problem.  I started googling and I found lots of references to just that.  Here’s apparently a really good post on how to fix the problem most of the time.  Then there’s a $100 third-party tool called DiskWarrior that’ll fix it most fo the time the free version doesn’t fix it.  if you read that the way I read it, there are still times it will be corrupted.)  Apparently one of the ways to corrupt it is to tell your Macbook to go to sleep in the middle of a backup.  I know, “Doctor, it hurts when I do this.”  “So don’t do that.”

I thought, well, I’ll just trick it.  Since it can back up to a slice on the same disk (which is a pretty dumb thing to do for recovery, of course), I sliced up my root disk with disk utility, then made the second slice the Backup slice and pointed time machine at it. I performed a Time Machine backup to it and my plan was to then rsync those backups to the Backups.backupdb directory on the other server, creating artifically what happens if you walk around with a USB drive to several Macs.  You end up with several directories underneath Backups.backupdb, each with the name of the Mac it backed up.

Guess what?  If you try to create any directories or files in the Backups.backupdb as any user (including root) you get “permission denied.” Mac OS is protecting that folder from me so I don’t do anything stupid like delete it. On one hand, that’s pretty impressive and stupid user proof.  (Although you can delete the files in the folder, so I’m not sure how safe it is.)  But I can’t rsync to a directory I can’t write to, so that plan is out. (I suppose I could rsync all of them to a different directory that’s not protected, but this is starting to fall into the ridiculous category.)

So I’m stuck with either carting around a USB drive or living with the issues of the sparsebundle file.  It looks like I can automate checking it every night, but I’m not sure how long it will take.  And what do I do if I can’t fix a given copy of it?  Should I use it like a BCV and create a copy after I’ve verified it, and then don’t copy it if the verify fails?  That’s a big waste of disk space.  It would be something like this:

cd /Volumes/Drobo
for i in *.sparsebundle
hdiutil attach -nomount -readwrite -noautofsck -noverify $i
device=`df -k |grep 'Apple_HFSX'|awk '{print $1}'`
fsck_hfs -rf $device
if [ $? -eq 0 ] ; then
    rm -f $i.backup
    cp $i $i.backup
   echo "Sparsebundle integrity check failed on $device ($i). Restoring $i from $i.backup"
   rm -f $i
   cp $i.backup $i

Why don’t they just do with remote macs the same thing they do with local macs?  This makes no sense to me. I’m goint to end up wasting a couple of hundreds of GBs of space because of this.

The long and short of it is that I am much less impressed with Time Machine than I used to be. But it’s still better than NTBackup. 😉

Update: I made some changes to the rsync paragraph based on a comment that made me stand corrected.  The end result is the same, though.

9 thoughts on “Time Machine disappointments

  1. millerdev says:

    "Guess what? If you cd into Backups.backupdb as any user (including root) and do an ‘ls’ you see nothing."

    I’m not sure what you’re talking about here. The terminal is not stupid user proof. Oh, and here’s is a quick (scrubbed) copy/paste from my terminal:

    $ cd /Volumes/TM/<br />$ ls<br />Backups.backupdb	Desktop DF	Desktop DB<br />$ cd Backups.backupdb/<br />$ ls<br />macpro-name-scrubbed

    I did this with as a normal, non-admin user. This is on a OS X 10.6 machine.

    ~ Daniel

  2. cpjlboss says:

    I don’t know what happened or why I saw what I saw. Perhaps I was in the wrong directory. I updated the blog post, but I still have a problem.

  3. millerdev says:

    What I meant by saying “the terminal is not stupid user proof” was that Apple doesn’t do too much to protect users that venture into the terminal. It’s easy to do a lot of damage there (rm -rf … anyone?).

    You said “this is starting to fall into the ridiculous category.” Unfortunately, that’s often the case once you get beyond the simple use cases supported by Apple. As an IT person for a primarily-Mac shop I have had to stray into the realm of the ridiculous (or just undocumented) more than once. But I’d take the low level unix tools in OS X any day over what’s available in that other popular OS that many people are stuck with.

    I’d rather do a few ridiculous hacks once or twice than deal with corrupt backups or a manual process. So if I were you I’d keep trying to find a way to make it work. Don’t throw your hands in the air (or runn around the house with a USB drive).

    I can also say that TM has prevented headaches more than once for this user. Now if Apple would only implement dedupe in TM, that would be AWESOME.

  4. mjaggers says:

    Did you do any tests with iSCSI and Time Machine? Might be able to keep you from carting around disks or having the sparse bundle issue.

    I’ve already done a complete system restore using the Time Machine backups, but I’ve also used Apple products enough to know that there always seem to be a few gotchas lying around.

  5. cpjlboss says:

    I know what you meant and I’m not that easily offended. 😉

    My current plan is this:

    1. Create slice of OS disk call it backup
    2. Backup TM to that (it lets you)
    3. Rsync that to a USB hard drive on another computer with the –delete option so the two directories stay in sync
    4. Make a “real” TM backup to another portable hard drive (backout in case 1-3 & 5 don’t work)
    4. Then try and restore from the portable hard drive made in steps 1-3.

    Wish me luck. I’m currently on step 2.

  6. cpjlboss says:

    Not sure if I could share an iSCSI drive or if I’d have to split it up into multiple LUNs. Then the question would be how to boot off that backup. I do have an iSCSI-capable Drobo, so that might be worth a try. It’s a post for another day. Right now I’m going to try what I mentioned above for now — then enhance later.

  7. Guest says:

    Apple Time Machine is STUPID
    I am really disappointed that a backup software would start when the machine was really busy and would continue when the machine got busy.

  8. cpjlboss says:

    I wouldn’t say it’s stupid. I really like how the backups are structured. I don’t like how it handles remote backups and I agree with you about how it does scheduling of backups. And you can’t dictate the schedule without scripting, either.

Leave a Reply

Your email address will not be published. Required fields are marked *