> > > There are now VTLs that compress the data going to disk;
> > > they always have
> > > a bit of a gamble as to how well they can mimic the way
> > > the real tape
> > > compresses data; I'm told they just use very conservative
> > > estimates, to make sure the disk image will fit on the tape.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > This makes no sense to me. No tape software ever, AFAIK, guarantees
> > that a medium is a certain length or holds a certain amount of data.
> > That's just not the way tape has ever worked.
>
> The idea is if you are using your VTL to produce not just random
> storage, but map directly onto physical tape. If your local
> compression
> is greater than the drive's, then when you go to realize the virtual
> tape onto physical storage, Nebackup may be tracking a single tape
> (TAP001), but that data will not fit onto a physical device. Very
> annoying. You now have to either get the application involved and
> duplicate the data, or you have to track two pieces of
> physical media as
> a single unit and try to keep the application from knowing that....
> Good luck with restores that don't involve the VTL.
"[M]ap directly onto physical tape?" With my usual subtlety and
understatement, let me say that this is absolutely insane. <insert
smiley> A TAPE IS NOT A FIXED NUMBER OF BYTES/BLOCKS/SECTORS LONG.
This has nothing to do with compression; it has everything to do with
the nature of the medium. Gaps vary, speed can vary, BOT/EOT (archaic)
positions vary, tape backs up and erases a couple of inches of tape
after r-a-w errors, ... Not only do different tapes hold different
amounts of identical data, but the same tape will likely hold a
different amount of data if you write the same data to it twice.
Disk, with a known, guaranteed, fixed number of addressable sectors is
not like that, and tape is nothing like disk.
There is no way to guarantee that the contents of tape A fit onto tape
B. Because of that, as I said earlier, no tape software ever made,
AFAIK, makes such an assumption. If your method of using a VTL does
make that assumption, that's between you and the VTL vendor--but I doubt
you'll find support in NetBackup for that.
> is greater than the drive's, then when you go to realize the virtual
> tape onto physical storage,
The way to realize virtual tape onto real (or virtual) tape is to do it
the way all tape-to-tape is done: by software that understands tape.
bpduplicate, for instance. It's trivial to dup a 1TB SDLT600 tape onto
[a ton of] DAT4 cartridges.
> tape onto physical storage, Nebackup may be tracking a single tape
> (TAP001), but that data will not fit onto a physical device. Very
Perhaps I misunderstand what you're doing, but if you're using some VTL
utility to do duplication, I don't believe you'll be happy. NetBackup
won't know a darned thing about it, giving you a management problem for
tracking, re-creating and restoring and raising TCO.
If you use a VTL the way all I've seen are promoted--and the way it is
tested before being supported by NetBackup, it is indistinguishable from
a real library and drives and tapes; you should not have to change your
operation at all.
> (TAP001), but that data will not fit onto a physical device. Very
> annoying. You now have to either get the application involved and
> duplicate the data, or you have to track two pieces of
> physical media as
> a single unit and try to keep the application from knowing that....
> Good luck with restores that don't involve the VTL.
But it doesn't sound like it [using the VTL exactly as a tape library].
Sounds like you're running a complex operation out of sight of
NetBackup, which puts the burden on you to put things back together.
Nothing wrong with that if you're up to it. Good luck.
> would fit otherwise. I think now they do a better job of
> emulating the
> compression used by the drive and lopping off a bit so that you're
> reasonably certain of the data fitting onto good media even with local
> compression.
>From your writing, you seem to be a person with experience. Isn't
"kinda-sorta emulating some drive firmware, then fudging a bit, and
hoping to be reasonably certain" an alternative spelling of "kludge?"
|
