Unless you have a very small system, the VSSI product probably will not be a good choice for your backups. For example, our dasd farm, excluding the 2000+ disks that house the TPF test system base disks, is 576 disks strong. A full backup of the non-TPF disks is in the neighborhood of 200-300 GB. On our old, hand-me-down tapes (Timberlines) it takes over 120 full cartridges. That volume, which does not include the backup of the VTAPE library, would make backing up to VTAPE impractical.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Shiminsky, Gary > Sent: Wednesday, September 03, 2008 11:36 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VTAPE from Virtual Software Systems > > We would be using the VTAPE product as part of the solution. > Most of the backups would be going to the VTAPE library and > then the VTAPE library would be backed up to newer, higher > capacity tape drives/cartridges. > > Gary > > Gary L. Shiminsky > > VM/VSE Senior Systems Programmer > Office of Information Technology > State of New Hampshire > 27 Hazen Drive > Concord, NH 03301 > 603-271-1509 Fax 603-271-1516 > > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter > Sent: Wednesday, September 03, 2008 1:55 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VTAPE from Virtual Software Systems > > Without having ever run VTAPE here... perhaps you could > better define your requirements? > > Are you saying that you want to eliminate all tape drives? > If so, how will you back up your DASD (upon which I believe > that VTAPE writes its virtual tapes)? Unless you have > mirrored DASD, with the mirror far enough away to constitute > a D.R. site, you still need tape backup for D.R. > > Even with mirrored D.R. DASD, if there is ever DASD > corruption, the mirroring code could just mirror the > corruption to the remote site. > Indeed, the DASD vendor's microcode could even be the cause > of the corruption. Without tape backup, you may not be able > to restore. > > Another alternative is virtual tape libraries (IBM, SUN/STK, > and more), which write tape data for virtual tapes on DASD > cache for fast I/O, then > > migrate that cache to very high capacity tapes behind the > scenes. But even that isn't perfect for D.R. if at least one > copy of the tapes are not stored at the D.R. site. > > Surely there are other variations on this theme to be > considered. But in most cases, you probably want to consider > some external tapes for true > D.R. Always plan for the worst, or that's what will require > a resume > update. > > Mike Walter > Hewitt Associates > Any opinions expressed herein are mine alone and do not > necessarily represent the opinions or policies of Hewitt Associates. > > > > > "Shiminsky, Gary" <[EMAIL PROTECTED]> > > Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > 09/03/2008 11:52 AM > Please respond to > "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > > > To > IBMVM@LISTSERV.UARK.EDU > cc > > Subject > VTAPE from Virtual Software Systems > > > > > > > Hi, > > We are looking for a virtual tape system as part of a project > to replace our ageing tape drives. > > Does anybody have any experience with VTAPE from Virtual > Software Systems that they would like to share? > > Gary > > Gary L. Shiminsky > > VM/VSE Senior Systems Programmer > Office of Information Technology > State of New Hampshire > 27 Hazen Drive > Concord, NH 03301 > 603-271-1509 Fax 603-271-1516 > > > > > > > > The information contained in this e-mail and any accompanying > documents may contain information that is confidential or > otherwise protected from disclosure. If you are not the > intended recipient of this message, or if this message has > been addressed to you in error, please immediately alert the > sender by reply e-mail and then delete this message, > including any attachments. Any dissemination, distribution or > other use of the contents of this message by anyone other > than the intended recipient is strictly prohibited. All > messages sent to and from this e-mail address may be > monitored as permitted by applicable law and regulations to > ensure compliance with our internal policies and to protect > our business. E-mails are not secure and cannot be guaranteed > to be error free as they can be intercepted, amended, lost or > destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by e-mail. >
