It seems the underlying premise is that if you’re gonna take systems & processes designed for the distributed computing era [read: 'traditional'], and *wedge* them into the cloud computing era, you’ll get results that Steve sums up so eloquently with “…Thus, server recovery needs to include Fed-Ex. If it needs to include Fed-Ex, why bother?”

Tantamount to riding your horse to get to work on the highway. As the man said: “[w]hy bother?” Dude…welcome to the cloud computing era…get a car. Better yet, take public transit.

“Cloud” + [backup software designed for cloud computing] = go

“Cloud” + [traditional backup software] = “[w]hy bother?”

—–The man gets it!! That is exactly the point I was making – software or hardware or process – trying to fit historically inadequate elements into a post modern world will FAIL. The world needs things built for the job at hand – in its current manifestation – not to keep on trying to shove arcane broken stuff down the throats of the modern reality. – Steve

First the overuse of the word “cloud”. Case in point “private cloud”.

I am not sure about the “private” cloud argument as part of the debate. That scenario to me says a client has his own centralized storage to which everything goes to. Some marketing bozo called it “private” cloud because its trendy. I could argue that any traditional backup vendor that backed up data to a centralized storage pool with built in redundancy has got “private” cloud; and they can do the FedEx recovery trick. I don’t think this example is useful in relation to what Steve was referring to.

So lets keep “cloud” simple.

I would agree that Disaster Recover from the cloud is not practical. I would however also argue that backup isn’t just DR.

A lot of the information that is critical to a business could be backed to the cloud. Take a law firm or an accountancy firm. The documents they produce could very comfortably be pushed to cloud storage for backup. They no longer have the headache of managing their offsite tapes etc.

I would also back Curtis comment on keeping local copies. There are lots of reasons for keeping a hybrid cloud / local backup solution.

The benefit of the cloud for backup is that it provides an automated off site copy of your critical data and removes the need for manual intervention. Think of backup to cloud in the context of replacement to offsite tape vaulting.

So if your question Steve, “Can cloud be a complete replacement to backup storage?” then I would agree with you it isn’t suitable.

“Can cloud augment your backup strategy?” – yes it can.

What I hear you saying is that if recovery speed matters, your only copy of data shouldn’t be offsite. And on that point we universally agree.

What I was arguing with is that your post said “Backup doesn’t make sense for the cloud,” which I wholeheartedly disagree with. It makes sense for small companies, small offices of larger companies, and home users where the RTO is “as long as i get my data back eventually I’m happy.” And remember, 90+% of businesses in the US are small companies. So I would say cloud backup is right for 90+% of businesses — as long as they realize what their RTO is and they’re OK with that.

Does it make sense for protecting large mission critical apps? No! The software can’t even handle the load, let alone have the recovery work in time. Source dedupe/cloud backup is for smaller sites; bigger sites need local copies on VTLs/IDTs for faster recovery.

1. If it’s all about the recovery, then it’s all about what’s an acceptable RTO for the app being backed up. I saw JPMC give a talk were they had gone to a private cloud (i.e. Puredisk backing up to their own servers) to back up 250+ remote sites. They use the “Fedex recovery” model for those remote sites because a 48-hr RTO is more than acceptable for those remote sites. They recover the server locally and fedex the recovered server to the site. It totaly meets their requirements. If another company has a 48 hr RTO, then I would suggest that a pure cloud backup would work just fine for them.

2. You’re leaving out that any good cloud backup provider also offers a local copy of the data as an option. IOW, you back up to the local server and its syncs to the remote server. You use the local copy for operational recovery and the cloud copy as DR. This model scales very high and allows aggresive RTOs as well.

3. If by outsourcing your backup you take it out of the hands of people who hate backups and put it the hands of people that love backup, you’ve done more for your backups than you could ever do internally. If Microsoft had outsourced the backup of Sidekick, for example, this story would have never happened.

I personally think that backup is the perfect app to outsource/put in the cloud, as long as you address the issues that you brought up.

—-”as long as you address the issues that you brought up”….For a guy who agrees with me you sure argue a lot!!! The whole point in my argument is just that – bi-directional functionality. Sure, if you have an RTO of 2 days, no problem at all with the pony express. Having said that, how many “corporate” app’s really can wait 2 days just to start to recover? I’m fine with those app’s, or individual’s where it isn’t critical, but the cloud simply can’t be used if recovery matters – without, as you correctly point out, a local version of the data. In that case, however, you aren’t using the cloud for recovery, you are using it for DR – which I’m fine with. —Steve