When people develop software, there are three things that aren't thought about until the final stages of development.

  1. Security
  2. Backup
  3. Performance

As a corollary, some might add Manageability.

Now all of these topics will probably have some token representation in any project's design specification, but few really think about them until the end, and sometimes not even then. Often a program won't be really performant and secure until at least the second version, and some projects go for years without reasonable backup solutions.

Why does this happen? Well as far as Security and Backup are concerned, people like to think of their software working, not about how their software might fail. It's uncomfortable to think about your data corrupted because of a crash or a virus, so you push those things off till the end. There's also a lot of naivety. How hard can backup be? Before we ship, I'll throw together a command-line utility that dumps all my data to a file. The customer can just reimport this file. It'll probably never even be needed, since my data store is rock solid.

I work at Microsoft on the Volume Shadow Copy Service, a service for creating point-in-time images of a volume. As such, I work very closely with many backup vendors (who are the main consumers of Volume Shadow Copies) and I'm very sensitive to people who don't design for backup. Windows contains a very general infrastructure that allows all data stores to publish the location of their data, how to backup the data, and provides hooks so the store can get the data into a consistent state before backup and after restore. Yet people persist in creating dozens of proprietary backup APIs and, even worse, command-line tools for backup. This creates a nightmare for admistrators: my backup application backs up some of his data, but he then needs scripts that automate all of the other command lines. It creates an even bigger nightmare for backup vendors: they have to track down all of these strange backup APIs with all their strange and varied semantics, and make it all consistent somehow. After Windows 2000 shipped, it was close to a year before any backup vendor shipped a solution. This was a huge deployment blocker, and cost Microsof t a lot of money.

Hooking the infrastructure to provide a consistent API is a start, but it's not enough. Your data store needs to have been designed with backup in mind. Case in point: I recently dealt with a distributed application, when talking about backup/restore they realized that they couldn't safely restore any one of their databases. All of their databases had references to each other, so restoring one meant restoring all of them. This application can be deployed across a server farm of dozens of machines. Their story to administrators was that if one machine failed, you have to do a full restore on every machine in your farm! If I was an administrator, I'd refuse to deploy this product! Once again, backup/restore was an afterthought.