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
|