2009-02-11
True point in time restores may be hard
One of the things that people ask for from their backup system, often for sensible reasons, is the ability to recreate the system exactly how it was at some past time; these are usually called 'point in time' restores. Point in time restores for the recent past are usually reasonably easy, but doing it for significant times ago can be very difficult.
The problem is the dependencies involved start to grow and grow. For example, if you want to be able to restore your accounting system to the exact state it was in four years ago, you don't just need a full set of the data from four years ago; you're also probably going to need the exact version of software that you were using four years ago, the same operating system version you were running back then, and then old hardware to run it on (because the four year old OS probably doesn't run on modern hardware because it doesn't have the necessary drivers for things like, say, SATA disks).
Once you have all of that, you may still need new license keys, or at least license keys that haven't expired. In a world that increasingly uses digital signatures, you may also need new un-expired SSL keys, newly signed code for applets, and so on. (You can try turning back the clock to four years ago, but then your old system may not interact very well with the rest of your network.)
Now, this is an extreme and possibly artificial example. But it illustrates the important issue: data has dependencies. If you need to be able to deal with that data the same way you did in the past, you need the data's dependencies or something that is a good enough substitute for them. And those dependencies have other dependencies, and so on.
(This is one of the problems with reliable archives.)
Fortunately, this isn't always the sysadmin's problem. Reasonably often we're just tasked with being able to restore the raw data exactly as it was at some point in time, and interpreting it correctly is (in theory) someone else's concern.