>What I would really like to see is an improvement to the VTL software.
I
>don't see why they have to read all the data on a virtual tape to
>migrate one multiplexed saveset. After all, it is really just data on
>disk. With some clever programming, I believe the VTL software could
>eliminate the throughput problem with reading a multiplexed saveset.

Ah, but that defeats the whole POINT of VTLs.  They're SUPPOSED to
behave like tape drives in every way (except for the unreliable part).
In addition, what you're proposing is a lot harder than you think it is.
No offense, but if I were a VTL company, I wouldn't put any development
into solving your problem.  I would tell you to stop multiplexing. ;)

I would put my development money into other cooler features, like
de-dupe, replication, and date re-presentation.  (The latter is way
cool, where they pull the backup image apart and present your backed up
files to you in their original format via a browser of NFS/CIFS mount.)

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER