Synthetic Full Backups Redux

A couple of weeks ago I was speaking with a potential customer who mentioned an article I wrote back in February called “Synthetic Full Backups – So What?” He said I had the concept all wrong, and that others had different definitions of synthetic backups. He suggested that I correct my blog. So, here’s my correction.

In my previous article I said, “Synthetic Backups are (usually) full backups that are built out of pieces of previous incremental and full backups already on the server without the need to re-send data to the Server. It saves a lot of time on restore and saves space on the Server.”

My potential customer (let’s call him Osgood) argued that I didn’t go far enough with my definition, considering how my software works. He argues that synthetic backups, by definition, require the storage server to apply sub-file “patches” generated by the client or agent software. He says it really works like this:

The client software extracts changes from files and groups of files and sends them to the Server. The Server then applies those changes to a master copy of the backup, maintaining what amounts to a synthesized full backup.

But there are several problems with Osgood’s definition of the technology, which may explain why nobody relevant is doing it, and only one misguided competitor is even contemplating it, but I’ll get to those in a minute.

RBackup actually synthesizes restore sets from all available backups (full, incremental, or otherwise) on demand, at restore time. My method requires more storage space at the Server, allowing the much higher level of redundancy and safety required by most businesses.

Here’s why I can’t do synthetic full backups using Osgood’s method.

Applying patches at the Server requires decrypting the data, which itself requires transmitting the customer’s encryption key across the Internet to the Server.

So, right away this method busts virtually all data privacy and security regulations in the USA, the EU, the UK, and everywhere else on the planet that cares about such things. 

To be absolutely certain there wouldn’t be a problem with his method Osgood telephoned a government bureaucrat who told him, “As long as you have the best of intentions, I see no problem, regardless what happens!”

So, damn the laws – just tell the judge you had the best of intentions?!

Osgood’s method would save space on the storage server by maintaining only one copy of customers’ backup files. But what if a customer wants to recover last week’s copy? With only one copy of the data, you would lose the ability to do a point in time restore, or to restore a previous (virus-free) copy of a newly infected file.

Osgood’s method would require the storage server to do far more work than my method, cutting its efficiency significantly or requiring much more expensive hardware. Where a single Server using my method can handle thousands of user accounts, a single Server using Osgood’s method could handle only a couple of hundred users.

He then explained that my software’s lack of “proper” synthetic backups wasn’t the only thing wrong with it. He had a laundry list of changes he wanted me to make – My prices are too high, I don’t support backups to tape, CD and DVD. Then he dropped this bomb: He needs to sell his service for $30 per year per terabyte because his “customers are poor.” I swear I didn’t make that up!

Osgood needs a different set of customers. Nobody offers a terabyte of high-quality online backup for $30 a year. The costs of doing business are higher than that. I emailed him a quote, but I’m pretty sure there’s no chance of him buying anything from me, especially after this article.

Rob Cosgrove is the President of Remote Backup Systems, founder of the Online Backup Industry, and a vocal advocate for maintaining the highest standards in Online Backup software. His latest book, the Online Backup Guide for Service Providers: How to Start and Operate an Online Backup Service, is available online now, on Amazon.com, and at bookstores.