Veritas-bu

[Veritas-bu] VTL questions

2005-11-21 06:21:32
Subject: [Veritas-bu] VTL questions
From: william.d.brown AT gsk DOT com (william.d.brown AT gsk DOT com)
Date: Mon, 21 Nov 2005 11:21:32 +0000
Not all VTLs work the same way, which is why you may get different answers 
to the questions.  That said, I would expect different OEMs of FalconStor 
to be the same!

First up, I don't have a VTL, but I have been doing some digging as I 
think they may be useful to us, not least as one person said, the disk 
pool is shared between media servers.

The two main kinds of VTL reflect different histories.

Those that come from mainframe background (e.g. CentricStore) are trying 
to minimise media usage, especially for incrementals.  They work by 
backing up to disk (as a VTL), and when they have enough data to fill a 
tape, they start to write a tape.   On that tape will be backups from all 
sorts of different systems, but tape usage is excellent - you use all 
tapes to maximum capacity.  The VTL does not mind if it spans tapes 
destaging data to tape.  The tape barcodes are managed by the VTL, not by 
NetBackup.

So on the plus side media costs are as low as they can be, and also your 
bill with Iron Mountain.  On the minus side if the data you want to 
restore is no longer on the disk in the VTL, you must restore it from tape 
to the VTL, before the virtual tape is available to NetBackup.   For DR 
this may be an issue, as your DR provider will need to have your brand of 
VTL - but be aware many do, though no doubt they will charge you and 
everyone as if they bought it just for you...  Alternatively, if you have 
your own DR site, or a dual-site recovery plan, you just buy one for each 
site.  They usually have optionally asynchronous or synchronous 
replication to another similar system.

These are big expensive things but you might just have one for a whole 
data centre.

-o-

The other kind come from the small site - there are many such devices in 
the market.   These do tend to match physical barcodes 1:1 with virtual 
tapes.  Some can asynchronously replicate to a matched system on another 
site - so you can have the physical tapes offsite at all times.  DR is 
'normal' in that you can just take physical tapes to any server that can 
read them.   A number of users however don't use the export function but 
use Vault to duplicate from the VTL to physical tape; I think there are 2 
reasons - (1) I doubt if the VTL will share tape drives with normal 
NetBackup use (2) Vault is good at providing the picking lists for DR. 
Vault can be expensive.  I would guess that that type of user will have 
moved to DSSUs when they went to NBU 5.

The ability of VTLs to use real tape efficiently varies.  Some take a 
worst case assumption and assume zero compression when writing to tape, so 
will report a virtual tape full at the uncompressed capacity.  Really old 
VTLs did not even compress the on-disk data, so did not use the disk 
effectively either.   I gather most VTLs now do compress the data going to 
disk, and just take a pessimistic view of how that will compress to tape. 
They cannot exactly emulate the efficiency of a real tape drive, as it 
varies between drive types and vendors.  So the real usage is likely to be 
worse than writing directly to tape, but better than the 'uncompressed' 
figure.

-o-

A lot will depend on how you actually do the backups.   If you multiplex 
to virtual tapes, you will get multiplexed physical tapes.   If you don't, 
you will need to take care to fill virtual tapes before exporting them, or 
you will have poor media usage.  Again these are thing that you can avoid 
with DSSUs.  What you definitely gain with both DSSUs and VTLs is that you 
eliminate the mount delays, which can be very significant if you have a 
lot of small backup jobs.  Both DSSUs and VTLs have concurrency limits - 
I've seen people in this list saying that SATA arrays are not good for 
many concurrent writing processes.   VTLs usually require you to define 
some finite quantity of drives; at NBU 5 you buy a licence per drive 
(virtual and physical) - at NBU 6 it changes to a TB-based licence for 
VTLs.  A given VTL (or server for FalconStor) has finite CPU power and FC 
bandwidth, so cannot power an infinite number of virtual drives.

-o-

Lastly I am reminded that you can use in-line tape copy to write to the 
VTL and real tape in parallel.   This does mean the backup runs as slow as 
the real tape, but it has the advantage that the physical tape is ready to 
take offsite as soon as the backup completes.  The primary save set on 
disk is available for restores, and you can come up with a policy to 
expire it and promote the physical tape to primary.  The drawback with 
DSSUs and the VTL export is that if the VTL is onsite, and you are not 
replicating the data offsite, moving to a VTL can mean the tapes don't go 
offsite as soon as they do "now" i.e. when you are writing to real tape. 
We've looked at this and worked out that, as our tapes are collected to go 
offsite in the morning, the exported tapes would still be beaing written - 
we would miss the van.  Same with DSSUs and really any 2-stage process to 
put the data to tape.  That means last night's backups don't go offsite 
the morning after they are written - they go 24 hours later.  That may 
well be unacceptable risk.  Some VTLs will start tape exports while the 
data is still coming in for a particular volume, to try and overlap the 2 
stages; sounds a bit uncertain to me.

William D L Brown



<Prev in Thread] Current Thread [Next in Thread>