SaaS: Outsourcing Your Backup, or Not?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Progress towards finishing my Rational Conference piece has been minimal this morning, due in part to some necessary travel arrangements but mostly to a morning of back to back to back to back conference calls. I’ll try and nail it down this evening, if I get a chance, but in the meantime I have a quick question for you: do you back up the data housed in your SaaS applications?

If you’re anything like me, the answer is probably no. When I corrupted the hard drive on my Thinkpad X40, in fact, one of the comforting factors was that the important pictures I’d taken (read: important to me) were all up in Flickr. Hence, the backup was their problem, not mine. But is that really true?

Despite being a paid – “Pro”, in their terms – user of the Flickr service, I don’t see anything in their terms of service that implies that they can be held responsible should they accidentally delete some or all of my uploaded pictures. To be fair to Flickr, though, I also don’t see anything saying that they are “not” responsible. Legally, I suspect that this means that if I wake up tomorrow with no pictures left in my account, my potential recourse is writing an angry blog on the subject.

And that was the paid version – what of the users of the free service? According to Jeremy Zawodny, users of the free service that rely on things like Gmail for crucial data are “dipshits“. But as Ian indirectly observes, that means most of us are dipshits, because most of us – I’d argue – are only too happy to outsource the task of backup to online providers.

More often than not, this is a sound strategy. Except for the few occasions when I forget to log in to my Hotmail account – kept around for junk mail purposes – for 30 days and it deletes my account and everything in it, I don’t have any SaaS data loss horror stories to tell. del.icio.us, Flickr, Gmail, and co have all kept up their end of the bargain that I – unlike Jeremy – believe is implied if not promised when I sign up for an account.

But as backup zealots might argue, all of that just means I’m due. That was, in fact, precisely what was on my mind the other day when reports started trickling through Twitter that Google Reader has lost entire subscriptions. While the accounts were ultimately restored, and Google was enthused that they could “identify, diagnose, and fix today’s outage within an hour”, it was something of a wake up call for yours truly.

Most of my data is fairly well backed up. Pictures and other desktop content are up in Strongspace – or at least, most of it. Music is mirrored up to S3 on a weekly schedule. But my subscriptions? I suppose I had an OPML export, somewhere, that was several months old. Probably, anyway.

Obviously I exported a copy as soon as I got the chance, and will keep it around against the possibility that Reader really does lose my information. But that’s not a backup procedure – that’s a manual hack. And it’s just one application out of the half dozen or more that I use. For some applications, webmail for instance, backup is fairly trivial. For others, however, such as Reader, it’s non-standard.

What about you guys? Do you back up data from the SaaS applications you use? If so, how?


  1. Redundancy is the mother of all backups. I use flickr & twango to backup my photos regularly, and sometimes I transfer them to zoomr.

    My del.icio.us links are emailed to gmail (via rrs2email) automatically, and sometimes I sync them with magnolia, or make an offline backup…

    Whatever the TOS are, they can never guaranty that there will be no data loss (maybe they can guaranty financial compensation for it, but it will not bring your data back)…

  2. I back up most of it because I keep local copies. I don’t back up my email, and … now I’m suddenly quite paranoid about that. Thanks, Steve!

  3. […] reading: Tecosystems: Outsourcing your backup, or not? Ian Murdock: Dipsh*ts Like Me Gmail Horror […]

Leave a Reply

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