Virtual tape does just what you’d think: a backup thinks it’s writing to tape, but in reality the data is going elsewhere. It may still end up on tape eventually, but in the meantime it’s heading for disk, local or otherwise. This stuff isn’t cheap, but then neither are the systems where people would be interested in it.
It does raise some interesting questions, though. In the Unix and Linux world, we don’t usually have to resort to anything like this: tar, cpio or whatever can already happily write to anything, so we don’t need virtual tape. Most Unix utilities don’t assume a lot about their output. Microsoft backup programs are, of course, much different, and will usually be hardwired to expect certain hardware.
As we move up from tar and cpio, things change. Higher level backup programs are more apt to be concerned with hardware details, and will want to both query and control a tape at a very low level. These programs aren’t going to send a backup to anything that doesn’t look like a tape drive, and more specifically a type of tape drive that the software comprehends. Virtual tape would be the only way to cajole these critters to write to some other storage.
But isn’t there still something wrong here? Why would the backup app folks let IBM or whoever come in and sell thousands of dollars worth of software when it would seem that they could rather easily tweak their programs to write to anything? You would think that their design is a generic writer that calls stubs for various hardware specific features, and that it would be somewhat trivial to write stubs for disk backup or whatever.
Apparently not. I can only guess, but if they can’t do that, their software must be horribly complicated and extremely difficult to modify.
*Originaly published at APLawrence.com
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com