Backup Conversions

In a recent entry, I discussed how many backup software providers are trying to integrate their core backup application with other components of the data protection and data management process to attract users to switch to their application. What is getting lost in the discussion is that while new features are nice, the biggest problem lies in converting from one backup application to another -- and it just shouldn't be so hard.

Converting from one backup application to another always makes me think of jumping out of the frying pan and into the fire. Conversion elsewhere is not so hard. For example, if you use Microsoft and for some reason decide to switch to OpenOffice, its fairly simple; OpenOffice can read and write most Microsoft office formats. As an IT example, there are tools available now that will allow you to migrate virtual machines from VMware to Hyper-V to Xen seamlessly. Why is this not the case with backup applications?

In backup software the need is probably greater than anywhere else. Not only do you have the data format to worry about (i.e. how will you read those old tapes?), you also have the conversion of all the backup jobs and policies, not to mention any special scripts that you have designed for that special application.

The typical backup software vendors response? First, keep your old application running for "a while" so you can read the old data. Second, recreate all your backup jobs and policies and, third, re-write all your scripts to work with your application. Anyone that has run a backup process will tell you that those are three big requests and moving them over can be a time consuming process.

Keeping the old application running so you can get to old backups is an ugly alternative; because of today's retention and compliance issues that could mean years if not decades of running at least one copy of the old application. That means paying software maintenance on that one instance and at least one person in the organization staying up to speed on the product.

To some extent this is further justification for disk archiving, as we describe in our article "Backup vs. Archive". A disk-based archive resolves the retention issues and keeping the old software product under maintenance. This is especially true if your archive is stored in a non-proprietary format as a disk archive should allow you to do.

Why don't backup software vendors make a conversion utility? Clearly most of the popular tape formats can be read, there are more than a few utilities that will for one purpose or another read a variety of tape vendor's tapes. The harder task is to move all those backup policies and jobs from one environment to another, but again utilities exist that read those settings as well and although I don't know anyone that converts custom scripts, it can be done.

While I'll admit that a conversion or import utility would not be a small undertaking, it would certainly eliminate the biggest obstacle most customers face in switching backup applications -- the time and effort required to do so.

Ideally when installing a new application it should offer to import all the tape, indexes, jobs and policies of the prior application, then give you the option of what to keep and what to throw out. Even further intelligence can be added to tell you what policies you don't use any more, are redundant or are in conflict with other polices. This would allow you to use your conversion time to do spring cleaning.

I agree with backup software suppliers that customers want more from their backup applications, but until switching backup applications is about as painful as switching word processors customer conversion is going to come at a slow pace.