Different VTL Options
Posted in General, Storage Applications, Storage Management, Advisor - Joe Disher by Joe DisherNot that I like to disturb the piece amongst my brethren…. but…. In an effort to insight a riot with one of my fellow Storage Advisors I want to talk about “Virtual” Tape Library (VTL) options. (Hey at least I’m being specific as to what type of virtualization I’m talking about!)
For those that have not seen the flurry of advertisements and information spewing out lately in the backup community about VTL’s, I offer this definition; VTL’s offer a way to either replace or augment a tape backup strategy by creating a “virtual” tape device running on inexpensive disk drives. The disks are likely to be SATA (Serial ATA) and the host interconnect could be any of the popular interconnects such as Fibre Channel, SCSI or even iSCSI. The host just sees the VTL as a library that it can write to. Now, a VTL can maintain several backups on disk or simply be a temporary holding place prior to getting migrated off to “real” tape for offsite protection.
One of the subtle differences being focused on recently with different VTL deployments deals with the notion of standalone or integrated VTL’s. A nice article describing both is here: Users flag flaw in integrated VTLs
Standalone VTL’s present themselves as a viable tape library to the backup host and backup software. Integrated VTL’s take that notion one step further by controlling the movement of the backups to an integrated “real” tape library connected to the back of the VTL without any backup software intervention.
In many cases “integrated” means “better”. In this case I think it’s actually not better at all. In fact, I think it detracts from the manageability that already inherently exists within backup applications. If using an integrated VTL, the movement of the second backup to “real” tape is controlled by the integrated VTL itself. The backup software has no visibility to the fact that the data has been moved to tape. This means that recovery will always be a 2 step process since the backup software’s database has no clue that a “real” tape library exists, let alone that it’s actually backing up to a “virtual” tape library to begin with.
For my money, I’d rather use a standalone VTL solution to augment my backup environment. It makes more sense to me if the backup software can see both the VTL and any “real” tape library I may have connected – and can therefore control the migration of data to “real” tape. Most importantly, this results in the ability to restore easily from either the VTL or the real tape library without any extra steps.
All that said nothing is stopping the integrated VTL vendors from coming up with solutions that can communicate more effectively with the backup applications to allow for more flexible control – but for now I think less integrated is certainly better.
I’d love to hear what you think about VTL and its options.
Joe
October 20th, 2005 at 8:48 pm
Joe, I’ll reserve a special pro bono slap just for you.
See you next week, buddy.
November 1st, 2005 at 12:38 pm
Hey Joe. Nice to see you last week at SNW.
Regarding your VTL comment - check out the upcoming announcements by Neartek (on 11/15/05). They will solve this VTL tape dilemma….
November 7th, 2005 at 9:12 pm
I saw a similar article about this at B&S with some users making comments around Tape mgmt with integrated VTLs. My comment is that Not all intregrated VTL’s suffer from this limitation.
Alacritus (now part of Netapp) does not have this issue and Tape mgmt can be performed either by the VTL or the backup application. Furthermore, data can be restored from tape by the application even if the VTL is lost. Among the several other differentiators of the Alacritus VTL solution thing is that it does Tape optimization.
Since all data compresses differently, the actual amount of data that fits on a given tape will change from backup to backup. Since a VTL must be able to copy a virtual tape to a physical tape at a later time, it is important that the virtual tape be the correct capacity to fit on the physical tape. If it is too large, it will not fit and cannot be copied. Most VTL vendors solve this by making the virtual tape size equal to the native capacity of the physical tape. However, this makes for very inefficient media utilization – at 2:1 compression, half of each physical tape is wasted.
Alacritus has a unique and patented feature that monitors the compressibility of each data stream, and dynamically adjusts the size of the virtual tape to closely match the compressed capacity of the physical tape. Since compression estimation does not actually compress all of the data (it only needs to partially compress a statistically significant sample), there is no noticeable performance impact. The compression estimation function has also been tuned to take into account the different compression capabilities of different tape drives. The result of using compression estimation is significantly better utilization of physical media
So “For your money” Joe you should be using an integrated VTL that gives you *options* , *flexibility* and *significantly* better utilization and cost savings of physical media.
Cheers
November 8th, 2005 at 8:16 am
NickT,
Sounds like the Alacritus solution meets the goal that I described in my last paragraph of being an integrated VTL solution that “can communicate more effectively with the backup applications to allow for more flexible control”. I had not pointed out the values of controlling compression more accurately for better utilization. I have not had the opportunity to play with an Alacritus solution, but it sounds like it meets the objectives of delivering a thorough and, most importantly, flexible VTL solution.
Thanks for the comments NickT - keep ‘em coming!
Blog ya later!
Joe
July 14th, 2006 at 11:28 pm
sir
in Tape backup there will be a hardware compression.
if i use VTL backup my data will be compressed?
July 25th, 2006 at 7:57 am
Great question - the compression component of the backup job is separate from the VTL piece. You will indeed still compress the data (as much as it can be depending on the type of data) prior to getting comitted to the VTL.
Blog ya later!
Joe
June 1st, 2007 at 5:09 am
This is a late comment, but there are solutions available.
For example some implementations send back updates back to the backup application when an export is performed. This way i believe that the backup application is aware of the export operation that way. I think the approach is to make the backup application more VTL aware. I’m sorry i dont have any weblinks for this.
But you can take a look at scache.com to see our integrated VTL approach.
Dual copy by the backup application in the case of a standalone VTL means additional burden on the backup server and also on the primary backup network..