As you may have noticed, I have a great deal of disrespect for “tape is dead” stories. To be blunt, I think they’re about as plausible as theories that the moon landing was faked.
So I thought I might list the criteria I think will have to happen in order for tape to die:
- SSD will need to offer the same capacity, shelf-life and price as equivalent storage tape.
There’s been a lot of talk lately of MAIDs – Massive Arrays of Idle Disks – being the successor/killer to tape, on the premise that such arrays would allow large amounts of either snapshotted or deduplicated data to be kept online, replicated into multiple locations, and otherwise in a night-perfect nearline state.
This isn’t the way of the future. Like VTL, MAIDs are a stop-gap measure that will fulfill specific issues to do with tape, but not replace tape. Like VTLs, if the building is burning down you can’t rush into the computer room, grab the MAID and run out like you can with a handful of tapes. Equally similarly to VTLs and disk backup units, it’s entirely conceivable of a targetted virus/trojan (or even a mistake) wiping out the content of a MAID.
No, we won’t get to the point where tape can “die” until such time as there is a high speed, safe, and comparatively cheap removable format/media that offers the same level of true offline protection.
The trouble with this is simple – it’s a constantly moving goalpost. Restricting ourselves to just LTO for the purposes of this discussion, it’s conceivable that SSDs might, in a few years, catch up with LTO-4; however, with LTO-5 due out “soon”, and LTO-6 on the roadmap, SSDs don’t need to catch up with a static format, they need to catch up with a format that is continuing to improve and expand, both in speed and capacity.
So perhaps, instead of being so narrow as to suggest that tape might die when SSDs catch up, it might be more accurate to suggest that tape may have a chance of being replaced when some new technology evolves with sufficient density, price-point, performance and portability that it makes like-for-like replacement possible.
There are “old timers” in the computer industry who can tell me stories of punch card systems and valve computers. I’m a “medium timer” so to speak in that I can tell stories to more youthful people in computing about working with printer-terminals, programming in RPG and reel-to-reel tape. So, do I envisage in 10-20 years time trying to explain what “tape” was to people just starting in the industry?
No.
Over a five year period, the TCO of keeping around 1 TB of data can be up to 23x more expensive on SATA than on LTO-4 according to one study:
http://www.clipper.com/research/TCG2008009.pdf
As Curtis Preston mentioned in LISA ’06:
http://www.usenix.org/event/lisa06/tech/#friday
Tape-only backup (D2T) is dead, but tape itself (in D2D2T) is very handy if you have to keep around data for a while (90+ days in the above study). It’s a matter of access time and frequency: if you want speed, then tape restores may take a while, but if you can wait a while it’s hard to beat.
At LISA ’07 Andrew Hume talks (00:18:00) about tape, amongst other things:
http://www.usenix.org/event/lisa07/tech/tech.html#hume
Indeed, one problem that tape is creating for itself is that as its speed continues to increase, the writing of backups direct to tape, or tape only, becomes more and more challenging/less practical.
IMHO, the mistake made by a lot of vendors in particular, is assuming that for backup to evolve tape has to die. This isn’t the case, and if anything just smacks of the tail trying to wag the dog. Backup is in actual fact continuously evolving, exemplified in this case by altering where tape is used in the process.
Backup to disk (regardless of virtual tape or, using NetWorker terminology, advanced file type devices), has now effectively become an entrenched and accepted strategy for appropriate backup infrastructure design. As much as it’s there to allow rapid recovery of recent backups, one of the other purposes of backup to disk is to enable the better use of high speed tape. This is achieved by reducing the number of paths or points in the environment that need to be optimised to allow streaming transfer of data to tape. Instead of the entire datazone/infrastructure having to be tuned to the hilt so that any one backup can keep high speed tape streaming, the infrastructure can instead be tuned so as required to allow the meeting of backup/recovery windows, with just the backup servers/storage nodes that need to write to tape configured for maximum tape transfer speeds.
There’s no compelling reason for getting rid of tape except speed. Speed would be a primary issue if tape were used for anything except long-term archival storage.
As it is, tape is cheap, has high density and is very reliable. Speed isn’t (usually) an issue when pulling data off of old media. We’re willing to trade the ability to make a lot of tapes that will last a very long time for the same price of media with an indeterminate lifespan that is very fast.
When it’s crunch time, you go with reliability every time.
Speaking of which, a story in “The Reg” on LTO-5:
http://www.theregister.co.uk/2009/08/13/imation_lto5_media/
I saw that last night and wondered about linking it into the article … It’s good to see LTO-5 implementation plans starting to appear, but I think The Register is jumping the gun somewhat in suggesting that just because Imation is the only one to have signed on so far the format/consortium must be in trouble. Let’s face it – someone has to be the first company to do so, and of course the first company to do so is going to make a fuss about that very fact.
There had been whispers a couple of years ago that HP and Certance had gone into an agreement to partner on LTO-5 drive/tape development, and I certainly can’t see IBM missing the boat on this one given the investment they’ve made in LTO-5. I suspect we’ll just see other vendors take their time – after all, LTO-4 is still in the happy/high part of its release and product cycle at the moment.
Well, it’s worth thinking ahead in the case of HP and Certance, as LTO currently only goes up to Gen 6 in the current official roadmap. It would be prudent to see if the same technologies can go to -7 and -8 (in a backward compatible way), or something new will have to developed.
If not, then it’s better to know sooner rather than later.
It’s not like long-term backup and archiving will suddenly go away. Who knows, perhaps we’ll have SSD cartridges instead of tape cartridges, or perhaps holographic storage will stop being “10 years away” at some point. We also have the memristor now, and that can hold data even when the power is off as well.
I’d also suggest that an issue well and truly already present with LTO-4, and one that will continue for the foreseeable future is that tape is getting too fast. I know that’s an odd thing to say, and I don’t mean that “all tape should be slow”; however, there needs I think to be some research done into developing high capacity tape formats that work well at much lower streaming speeds – probably topping out at 100MB/s.
Many companies aren’t large enough to actually warrant sufficiently complex architectures that combine VTL+PTL or DiskBackup+PTL – they want the simplicity of plain old tape, but they’re forced down the more complex path due to the inability to work reliably with tape at lower speeds. I.e., there’s room in backup for multiple speeds of tape – the ultra high speed for those organisations needing to push through hundreds of terabytes of data, etc., but also the high capacity/lower speed systems. I.e., enterprise tape development has been focused at growing at the top-end of the environment, forgetting that the bottom-end of enterprise data storage is growing as the amount of data kept by even small-medium businesses continues to creep.
(Oh, and final thing – I wouldn’t necessarily consider that the LTO format is going to finish at 6 – after all, when I first started working with LTO, they had only published forward-looking plans for G1/G2/G3; not long after they published plans for Ultrium 4, and now we have LTO-5 approaching with v6 defined – i.e., if it can be added to, it will be added to.)