--zx4FCpZtqtKETZ7O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Lee, Kenneth (SBS US) <kenneth.lee AT siemens DOT com> [2005-11-19 11:16]:
> That is not what I have been told by the vendors.  On some VTL, the
> appliance is connected to the physical tape library and controls the
> tape library.  When you create the virtual tape, the appliance will
> inventory the physical tape first before creating the virtual tape (same
> bar code).  NetBackup uses the virtual tape but the appliance will write
> to a physical tape when you eject the tape from NetBackup.  Therefore,
> NetBackup will see only one tape, which is now on the physical tape with
> the same bar code.  The virtual tape is deleted.  This also removes the
> duplication process overhead of running from the media server.  My

Yes, that what it does with the setup you are describing. In the
VTL->Library link, the VTL gets its barcodes from the physical tapes in
the library. The problem is that the "eject" takes a lot longer, which
shouldn't be an issues if you are planning for it.

> problem with this is how the tapes will be restored.  Do I have to move
> it back to a VTL tape before restoring, or can I just use the physical
> tape as NetBackup is only aware of one tape.  The vendors also said this
> is being done in a real environment.  Is anyone really doing this?

Actually, this is just a tape inventory issue. Once the "real" tape
exists, you just need to make sure the original media server can get to
it regardless of what library it lives in. Depending on the vendor, I
believe there is a passthrough from the real tape through the VTL in the
case of a restore, but this is not always the case. If you have another
robot that is not attached to the VTL, you could just put the tape in
that and inventory.

You also have some minor management issues to deal with if something
happens to the physical tape, but that shouldn't be a show-stopper.

--=20
David Rock
david AT graniteweb DOT com

--zx4FCpZtqtKETZ7O
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDgMZsMrO4/Yb/xwYRAhtwAJ9NwgTbMba59/PXT13BomgCwn0RDACguKzn
pgqpsv6g37T0JuwrdNetbDg=
=oSYk
-----END PGP SIGNATURE-----

--zx4FCpZtqtKETZ7O--