One of the more interesting replies to my recent discussion of NetApp's dangerous VTL--which NetApp apparently feels is likely to cause significant loss of backup data--concerned the concept of "tape smart sizing". To quote NetApp's CTO: "I can also confirm that Tape Smart Sizing works exactly as advertised."
Since I dismissed it as little more than a David Blaine type trick, it might be useful to ask: what exactly is advertised? Again, just quoting NetApp:
"[tape smart sizing] sample[s] the data for compressibility as it’s being written to the VTL and then dynamically adjust the size of that virtual tape to match the estimated compressed capacity of the physical tape it will be written to. The LTO-3 virtual tape is now automatically adjusted depending on what type of data is being written to it and how it will compress in the Real-Tape World. Welcome to not wasting money or space on extra physical tapes when using a VTL."
Incidentally, NetApp also claims that:
Every other VTL out there requires you to to set a fixed size on the virtual tape when configuring the virtual library.
The consequence of this is, according to NetApp, that if you write 200 GB data that is 2:1 compressible to any other VTL, you will use 200 GB of disk space; write it to tape, and you use 100 GB of tape (because tape is compressed). So, it seems that you would require 2 virtual LTO-1 cartridges. Take those 2 virtual cartridges, and they will each half fill a physical cartridge. Thus, wasted tape.
So we have two different bloggers claiming that tape smart sizing is useful, and unique in terms of its ability to save space of physical media. Basically, that "every other VTL" will require that you waste physical tape space as described above.
Let me state this unequivocally, and for the record: this is not true. EMC's virtual tape products have no such issue.
Why not? Well there is some interesting stuff here...
First, you might be asking: why not compress the data on disk too? Compress it there, and then when you move it to tape, you move your (compressed) 100 GB virtual cartidge to a (compressed) 100 GB physical cartridge. Life is good.
And this is absolutely correct. So why don't NetApp talk about that? Because when the Near Store VTL was introduced, they didn't have disk compression. Not in software. And not in hardware. So they were forced to use 200 GB of disk space for 200 GB of data, even if it was compressible at 2:1. Not good.
Well that was a while back, about 3 years ago now. Things change. These days, they offer hardware compression, as do most VTL vendors. As does EMC with every EDL we sell. With hardware compression, that 200 GB of data will compress onto a single 100 GB virtual cartridge. Problem solved.
So when I described smart sizing as "unnecessary and useless" this is why. If your VTL does compression, it is rendered irrelevant. (Which makes me wonder why NetApp even talks about this "feature" given that they do employ compression?)
The second reason that this is typically not an issue is that the problem only emerges when you use your VTL to create a physical tape (and you don't have compression). Both must be true before the issue emerges.
However, if you use your external backup application, or an embedded Media Server (NetBackup) or Storage Node (Networker) on an EMC EDL, then the issue doesn't emerge at all. If you use your backup application you are not copying media, strictly speaking, you are copying backup objects. And in that case, I am moving and/or copying an object from virtual media to physical media, and it does not matter what the sizes are of the two types of media are. I can vault or bpduplicate or nsrclone or whateverhaveyou (pick your favorite command from your favorite backup application) and I can go from LTO1 virtual to LTO4 physical or from 3590B virtual to SDLT physical (shudder). Or any other combination. With no implication or consequences for media utilization. All media will always be fully utilized, assuming there is sufficient actual data to fill them!
The kicker is that most people choose this approach because it means that their backup application can track the location of both physical and virtual media, both on and offsite.
By way of conclusion then: tape smart sizing is in fact, irrelevant. Not only is it irrelevant, but the claim that it offers unique functionality that no other VTL vendor can provide is both misleading and inaccurate.
Now what is the real take away from all this? The real take away in my mind is that the benefits of virtual tape need to be understood as more than just a laundry list of features. Most importantly: what is the impact of that feature in my environment? Backup and recovery is not just a platform, it is a process, a set of operational procedures. Virtual tape and deduplication therefore become more than just a platform. They have real, meaningful, and very positive impacts on my backup and recovery process and procedures.
The same technology platform can be implemented in multiple ways. The same objective can be reached by multiple paths. This may make it harder to understand what technology is "best". Mostly, I often don't believe there is a single "best". There is what is best for you, with your environment, your process, your budget (or budget constraints). What meets your business requirements, lets you meet your SLAs for RPO and RTO? What involves the least administrative impact? And so on.
But to discuss a feature without fully understanding the consequences it will have (or won't, in this particular case) in an actual environment is surely not the right first step for any project that is about to re-evaluate backup and recovery processes and platforms.