Re: Why virtual volumes?
Richard Rhodes wrote: Here are just some of the problems . . . Rick, Yes, we see the exposure, but aren't the ones managing the budget. The completed DR architecture, when it's in place, will include on- site and off-site copies of both data centers. Thanks for your insights, Keith Arbogast
Re: Why virtual volumes?
Allen Rout wrote: I'm having difficulty figuring out why this still feels not-answered to you. Allen, That statement, i.e. ...my dilemma, was more an justification of my original post than a commentary on the answers I had received. The simplest version of my question would have been, What am I missing?. Answers from the list have been very helpful, on the whole. Again, Allen: As for your last concern, it's not IBM's job to show you how you might do the work better without their product. Allen, That's an odd statement. You don't need to defend TSM, but it's IBM's job to teach best uses of TSM with current technology, not that of 1997. Thank you for your other advice. It is very helpful. Keith Arbogast Indiana University
Re: Why virtual volumes?
Richard, You asked thought provoking questions, but didn't answer mine. Hi, again . . . I guess I don't quite understand the situation. You have a remote site with a server you want to backup to your TSM server. Then, you ask why you would need VV's back at the remote site. What I don't understand is why you feel you need any kind of VV/tape/whatever at the remote site? If your TSM server had DR capability (offsite copypool and offsite db backup) then I don't see what you are trying to solve with a VV back at the remote site. As to why VV? I think it depends upon what the other options are. We used to use VV for db backups and offsite copies. It works well, although we had major problems with TSM not putting expired tapes back into scratch status. I really liked VV for TSM db backups. All you needed for restore was IP connectivity. When we restored TSM servers to our test system for upgrade testing this worked real well, instead of having to play with the devconfig file RMT devices to do a restore. Basically, I see VV as being usefull when you already have TSM servers with libraries at separate sites, and you want to get offsite copies of your data, and/or if you have multiple tsm servers with libraries and you don't want to get into library sharing. Ie: It's there, use it. I see VV as a TSM method of have remote and/or shared TAPE. How to do remote tape: VV, remote SAN (FCIP/iFCP), Truck. How to do shared tape: VV, san with library sharing. The question to me is what problem are you trying to solve, then which technology. Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Why virtual volumes
Hi Keith, virtual volumes used to be a big benefit while bridging big distances for DR of backup data via fc/scsi was extremely expensive. Today, I use the feature in our multi-site infrastucture to do my additional db-snapshots to one (central) tsm-server. No tape is involved in this part of the game, just a bunch of scsi-disks in a fairly inexpensive intel-based server. This saves me a second (DR)-TSM-server at each of the remote sites plus 400 GB-tapes for 2-GB-DBbackups plus MB-incrementals. We just had to do a rebuild after a controller crash killing the Raid system on one remote server: restore works like a charm, even if not as fast as a local restore. For a HA-sites, the benefit is certainly saving a lot of tape space/slots plus doing an (automated...?) rebuild of the TSM-Server at the local DR site without involving tape handling. We no longer use vv to move around actual data as this can be done much more elegantly by features like DWDMs and tape accelleration features today. It just depends on how much you are allowed to spend... Regards, Markus -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen außer für den Fall von Vorsatz oder grober Fahrlässigkeit die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mails aus. Jede von der Bank versendete E-Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Bank ausgelegt werden. __ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail or of parts hereof is strictly forbidden. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment of this message. We accept no liability for loss or damage caused by software viruses except in case of gross negligence or willful behaviour. Any e-mail messages from the Bank are sent in good faith, but shall not be binding or construed as constituting any kind of obligation on the part of the Bank.
Re: Why virtual volumes?
I'm curious. We've never relied on storing the TSM db backup to tape. We backup to disk and rcp it to a 2nd site. That's seems the simplest method. Anyone else do the same? [EMAIL PROTECTED] 08/23/2007 9:00:35 AM Richard, You asked thought provoking questions, but didn't answer mine. Hi, again . . . I guess I don't quite understand the situation. You have a remote site with a server you want to backup to your TSM server. Then, you ask why you would need VV's back at the remote site. What I don't understand is why you feel you need any kind of VV/tape/whatever at the remote site? If your TSM server had DR capability (offsite copypool and offsite db backup) then I don't see what you are trying to solve with a VV back at the remote site. As to why VV? I think it depends upon what the other options are. We used to use VV for db backups and offsite copies. It works well, although we had major problems with TSM not putting expired tapes back into scratch status. I really liked VV for TSM db backups. All you needed for restore was IP connectivity. When we restored TSM servers to our test system for upgrade testing this worked real well, instead of having to play with the devconfig file RMT devices to do a restore. Basically, I see VV as being usefull when you already have TSM servers with libraries at separate sites, and you want to get offsite copies of your data, and/or if you have multiple tsm servers with libraries and you don't want to get into library sharing. Ie: It's there, use it. I see VV as a TSM method of have remote and/or shared TAPE. How to do remote tape: VV, remote SAN (FCIP/iFCP), Truck. How to do shared tape: VV, san with library sharing. The question to me is what problem are you trying to solve, then which technology. Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: Why virtual volumes?
Nicholas Cassimatis wrote: With all of the features in TSM, there are a number of them that don't work for specific situations. Simultaneous writes on backup/ migration, virtual volumes, NDMP backups, 3rd mirrors of DB and Log volumes, adding documentation to your Prepare file - lots of features that don't always make sense to use. But they're there, if you want/ need them. Knowing when they do and when they don't is the crux of my dilemma. The virtual volume methodology is presented in IBM designed training classes, Administrator's manuals, and in a very recent TSM Webcast as if it is the best practice for cross data center backups. There is much about how to do it, but precious little about why to do it. No mention of the problem that it is intended to solve. Or, how you might do the same thing as well or better without it. Our current goal is that each of our two data centers be the offsite backup and DR site of the other. If we lose a TSM server or a data center we would restore it at the one sixty miles away. Thanks to everyone who responded. It has been a tremendous help. Keith Arbogast
Re: Why virtual volumes?
Richard Rhodes wrote: I guess I don't quite understand the situation. Richard, I'm sorry I haven't made our situation clearer. In the current phase of the project we are building a TSM server in Bloomington to backup local clients to disk which will be migrated to virtual volumes in Indianapolis. After migrating local clients to the new server, we plan to build a TSM server in Indianapolis which will backup nodes there to disk, which will be migrated to virtual volumes in Bloomington. Each data center will be the offsite backup and DR site of the other. But, now that we have virtual volumes working, I am looking at it and thinking 'yish!'. With best wishes, Keith
Re: Why virtual volumes?
Richard, I'm sorry I haven't made our situation clearer. In the current phase of the project we are building a TSM server in Bloomington to backup local clients to disk which will be migrated to virtual volumes in Indianapolis. After migrating local clients to the new server, we plan to build a TSM server in Indianapolis which will backup nodes there to disk, which will be migrated to virtual volumes in Bloomington. Each data center will be the offsite backup and DR site of the other. But, now that we have virtual volumes working, I am looking at it and thinking 'yish!'. With best wishes, Keith Hi Keith, thanks for more details. Let me see if I fully understand . . . . Bloomington TSM-a local clients backup to disk pool disk pool migrates to TSM-b/VV at Indianapolis == primary tape pool is on TSM-b/VV at Indianapolis vv server - contains primary pool from TSM-b Indianapolis TSM-b local clients backup to disk pool disk pool migrates to TSM-a/VV at Bloomington == primary tape pool is on TSM-a/VV at Bloomington vv server - contains promary pool from TSM-a Summary: - All clients backup to local TSM server to disk pool. - Disk pool gets MIGRATED to VV primary pool at other site. - There is NO copy pool at either site. Is this correct? Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Why virtual volumes?
I said . . . Let me see if I fully understand . . . . Bloomington TSM-a local clients backup to disk pool disk pool migrates to TSM-b/VV at Indianapolis == primary tape pool is on TSM-b/VV at Indianapolis vv server - contains primary pool from TSM-b Indianapolis TSM-b local clients backup to disk pool disk pool migrates to TSM-a/VV at Bloomington == primary tape pool is on TSM-a/VV at Bloomington vv server - contains promary pool from TSM-a Summary: - All clients backup to local TSM server to disk pool. - Disk pool gets MIGRATED to VV primary pool at other site. - There is NO copy pool at either site. While I'm munching on lunch, let met say a few words about this architecture. Our setup was very similar, except instead of backup local and migrating to the other site, we just backed up all servers directly to the remote site. All backups were by definition OFFSITE. It looked like this . . . Site A TSM-A nodes for servers at SiteB disk pool primary tape pool copy pool Site B TSM-B nodes for servers at SiteA disk pool primary tape pool copy pool At the beginning, Site A was our main computer center and Site B was a old datacenter had very few servers. In other words, it was hardly used. At this point the design made sense. What happened over time is that old datacenter, SiteB, grew and grew and grew, to become a peer datacenter. The two sites also became DR sites for each other. We realized that what looked and worked well at first had MAJOR problems when they became peer sites and DR for each other. Here are just some of the problems . . . - If you loose SiteA, then you loose ALL backups for SiteB - both primary and copy pools. Site B is up and running, but it has NO BACKUPS at all. Of course, the opposite is true also. - In a DR, since you lost ALL backups for the surviving data center, you MUST run FULL backups ASAP. Big, heavy load doing initial/full backups right in the middle of the DR. This is in contention with any restores you need to do - Again, if you loose SiteA, at Site B you have to define all those nodes to the surviving SiteB TSm server, and change the dsm.sys/dsm.opt files on the client nodes. This is lots of work. Summary: What we found with this architecture is that we would spend as much time doing stuff to the surviving TSm server and client nodes as would do for the nodes that needed DR recovery. NOT a pretty picture. Now, everyone knew this. We had preached these problems for a long time, but couldn't get action to change. Finally, we called a big meeting with all the managers, and I stood up front and told them our TSM DR plan (that is, the dr plan for any servers that relies on TSM for DR recovery) DIDN'T work. Again, they already know this, but hadn't heard it like that before. They took it very well, and came up with the money we requested to correct the problem. So, we changed to the classic design - onsite backups to disk, migrated to a onsite primary tape pool, with a offsite copy pool. Since our sites are close enough, we extended our SAN between the sites via DWDM and implemented library sharing. The offsite copy pool is created straight to remote tape. In a disaster, we have to restore the lost TSM server and start restores from the copy pool. The surviving TSM server just keeps humming along performing backups for the sirviving datacenter servers. Our oracle people didn't like this change. What they liked about the old design was that Oracle archive log backups went directly offsite, quickly! They had a small RPO due to this. Now, there RPO is much longer due to the time it takes to get the data into the offsite copy pool. So, if you are considering a all offsite architecture, PLEASE think through the DR implications completely. This can be especially hard when initial assumptions change gradually over time and come back to byte. Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Why virtual volumes?
On Thu, 23 Aug 2007 09:46:17 +1000, Stuart Lamble [EMAIL PROTECTED] said: On 23/08/2007, at 7:29 AM, Nicholas Cassimatis wrote: And a TSM DB Backup takes (at least) one volume, so with physical cartridges, that's a whole tape. With VV's, you're only using the actual capacity of the backup, which is more efficient on space. At the cost of some reliability. What happens if the particular tape the virtual volumes are on goes bad, and you're in a disaster needing a DB restore? Once you've sent data to a VV, (which looks like just-a-file to the target server) you can then copy it like any other file. Choose your exposure: (tape-failure-rate) * 1/number-of-db-tapes vs. ( tape-failure-rate ) ^ 2 or, if you're neurotic (like me) you can do ( tape-failure-rate ) ^ 3 with both onsite and offsite copy pools :) By the time you take 3592 volume failure rates cubed, you're in planetcracking asteroid risk levels, A.K.A. No Longer The Risk Amelioration Target. Well, why not do what we're doing soon? We currently have some 1200 LTO2 tapes, and are in the process of migrating from LTO2 to LTO4; (some of) the LTO2 tapes will be kept in the silo for database [..] There's someone I know who's used exactly that kind of logic to keep themselves on 3590 J volumes (as in, to this very day.) To me, keeping old tech around just-because seems a poor tradeoff. You build additional complexity into your system by maintaining separate device groups, you waste silo slots on measley 200G volumes... Worst, you're using the less reliable, older devices to manage your family jewels. For me, the ability to make copies of the DB backups swamped every other reliability-related concern. - Allen S. Rout
Re: Why virtual volumes?
On Thu, 23 Aug 2007 09:40:28 -0400, Keith Arbogast [EMAIL PROTECTED] said: Knowing when they do and when they don't is the crux of my dilemma. The virtual volume methodology is presented in IBM designed training classes, Administrator's manuals, and in a very recent TSM Webcast as if it is the best practice for cross data center backups. There is much about how to do it, but precious little about why to do it. No mention of the problem that it is intended to solve. Or, how you might do the same thing as well or better without it. I'm having difficulty figuring out why this still feels not-answered to you. Perhaps the answer is best associated with a gradient of solution costs, measured over time. There are myriad different ways you might choose to transport bits from site A to site B.. some of the simplest to understand are courier, long-haul dark fiber, and IP. Courier traffic is in many ways simplest, and quite cheap in dollars, but has very poor operational characteristics: unusual traffic is difficult to accomodate, delays are common, couriers are unreliable. We never had an Iron Mountain audit of our stored volumes which passed without incident. That made me feel very scared. If you want to pay for the extra-expensive GBICs and miles of dedicated dark fiber, you can just treat the offsite devices as though they were onsite. This doesn't address many of the DR issues at all (having data in two places, what about the hardware you intend to use at disaster time, etc..) but is certainly much simpler to manage if you're flush. As expensive as this is right now, reel yourself back to 1997, and wonder to yourself what it would cost to get oh, say, 350 miles of dark fiber. IP connectivity would look pretty good then. (at least, it did to me. :) Since TSM is already focused on storing IP-communicated data (and there are IBM projects accustomed to using TSM as an abstract object store) it was obvious to use the skills and resources already familliar to the DR-desiring supplicant to help him solve his problem. Hey, presto: you want to do offsite stuff for your TSM, well all you need is -ANOTHER- TSM, which you can manage in more or less the same way. If you do this, your offsite data is available to you in real-time. You can do last-minute pushes right until the hurricane actually busts down your primary data center. So, that's the problem it's intended to solve, and that's also why you might want to use this particular tool to solve it. As for your last concern, it's not IBM's job to show you how you might do the work better without their product :) but biased as I am, I think TSM's solution is damn near optimal. Our current goal is that each of our two data centers be the offsite backup and DR site of the other. If we lose a TSM server or a data center we would restore it at the one sixty miles away. This seems perfectly reasonable. I recommend you become very familiar with deploying several TSM instances on the same piece of hardware. In that way, you can do all sorts of DR testing on hardware you already own. You can restore all of SERVER-A onto an instance hosted on SERVER-B's physical hardware, and prove to yourself that it can be done consistently and according to procedure. I'd recommend you have at least three different server instances on each end of your link (which doesn't mean more than one set of hardware)... One to serve the local clients, one to serve the offsite-copy needs of the distal clients, and one as a library manager to the other two, so when you discover the need to add yet-another instance, it's straightforward. - Allen S. Rout
Re: Why virtual volumes?
Richard Rhodes said Let me see if I understand... Rick, Yes, you understand very well. We will not have offsite copy pools until there are 3584's at both data centers. It is a huge concern for those who understand the implications. All the best, Keith
Why virtual volumes?
I am not understanding the crucial advantage(s) of using virtual volumes to backup a data center to a remote site. Why not backup nodes in a remote data center to a TSM server in a local data center? We have two data centers about 60 miles apart. If we backup nodes in one data center directly to a TSM server in the other the TSM architecture is simpler, cheaper and familiar. If we lost the remote data center, we could restore its TSM nodes to hardware in the local data center thanks to the TSM server already there since it contains all the needed metadata. No TSM server build or database restore is required. It may be worth mentioning that we are already backing up a few remote nodes to a local TSM server with communication speeds in the range of other, local backups. If we build the virtual volume architecture on the other hand, we must purchase, build, and maintain at a distance a second server in each data center to connect the tape library there to the TSM server in the other data center. If we lose a data center under the virtual volume plan, its TSM server and primary disk pool will be lost along with everything else. All our eggs will be in one basket. We would need to restore the lost TSM server in the other data center before we could restore anything else. What unique advantage do virtual volumes provide that will repay the extra expense, work, and vulnerability? Finally, why must backup objects be archive objects for the virtual volume architecture to work. What forces that, and what else does it imply? With many thanks, Keith Arbogast Indiana University
Re: Why virtual volumes?
I am not understanding the crucial advantage(s) of using virtual volumes to backup a data center to a remote site. Why not backup nodes in a remote data center to a TSM server in a local data center? Sure, do it, we backup many remote sites to our central datacenter. The question is, what is your DR strategy for the central datacenter where the TSM server is located? If that datacenter is destroyed, where is your backup copy of your data (copy pool) and the backup of the TSM DB? The remote nodes are save/secure, but they are the least of your worry. Your TSm server needs offsite db backups AND a offsite copy of your backups (copy pool). To do electronic offsite copies and db backups, you can use VV, or implement direct SAN attached tape drives between our data centers. VV would use your IP network. Accessing remote tape drive directly could be either by extending a SAN directly or bridging the SAN across the IP network. Of couse, you don't need to do this with either VV or extended SAN. You can also ship copy pool tapes and DB backps offsite to another facility for safe keeping. We have two data centers about 60 miles apart. If we backup nodes in one data center directly to a TSM server in the other the TSM architecture is simpler, cheaper and familiar. If we lost the remote data center, we could restore its TSM nodes to hardware in the local data center thanks to the TSM server already there since it contains all the needed metadata. No TSM server build or database restore is required. It may be worth mentioning that we are already backing up a few remote nodes to a local TSM server with communication speeds in the range of other, local backups. Again, the question is - what happens if you loose that TSM server? If we build the virtual volume architecture on the other hand, we must purchase, build, and maintain at a distance a second server in each data center to connect the tape library there to the TSM server in the other data center. If we lose a data center under the virtual volume plan, its TSM server and primary disk pool will be lost along with everything else. All our eggs will be in one basket. We would need to restore the lost TSM server in the other data center before we could restore anything else. True, but how are you going to rebuild the centralized TSM server if that datacenter is lost? In a DR you have to rebuild something! - If you loose the remote node, then you have to rebuild and restore the node. - If you loose the central TSM server, you need to rebuild and restore the TSm server to access your backups. If this is a big disaster where you lost the TSm server, library, and all onsite tapes, then somewhere you need a copy of the backups (copy pool) and backup of the db, and a location/library/server to restore to. Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Why virtual volumes?
Richard, You asked thought provoking questions, but didn't answer mine. What is the compelling reason to use virtual volumes? Offsite copypools and certain restorability of the TSM database are essential. Thank you for spotlighting those points. However, I can do those without virtual volumes. Right? What circumstances make virtual volumes helpful, preferable or necessary? TSM development designed and built them for a reason. What is the reason? This is not a rhetorical question. I am hoping someone will turn this light bulb on for me. With best wishes, Keith Arbogast
Re: Why virtual volumes?
Well I would say, then, the reason for VV is to eliminate the need for real volumes: using virtual volumes on a remote TSM server eliminates the need to move real tape volumes to the remote server in the event of a disaster. Are they useful: that's a matter or opinion. Somebody made the very real point that you must have at least two copies of your data: one in the primary pool and one in a copy storage pool someplace else. Whether that's real or virtual is up to you. Kelly J. Lipp VP Manufacturing CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Keith Arbogast Sent: Wednesday, August 22, 2007 2:35 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Why virtual volumes? Richard, You asked thought provoking questions, but didn't answer mine. What is the compelling reason to use virtual volumes? Offsite copypools and certain restorability of the TSM database are essential. Thank you for spotlighting those points. However, I can do those without virtual volumes. Right? What circumstances make virtual volumes helpful, preferable or necessary? TSM development designed and built them for a reason. What is the reason? This is not a rhetorical question. I am hoping someone will turn this light bulb on for me. With best wishes, Keith Arbogast
Re: Why virtual volumes?
I think orinally, it was because intersite SCSI/FC was impossible or too expensive, while IP was cheap. (Or maybe one TSM server had scsi tape drives and a second did not.) Virtual volumes are basically treating one TSM server as a client and archiving to the other TSM server over IP. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Keith Arbogast Sent: Wednesday, August 22, 2007 4:35 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Why virtual volumes? Richard, You asked thought provoking questions, but didn't answer mine. What is the compelling reason to use virtual volumes? Offsite copypools and certain restorability of the TSM database are essential. Thank you for spotlighting those points. However, I can do those without virtual volumes. Right? What circumstances make virtual volumes helpful, preferable or necessary? TSM development designed and built them for a reason. What is the reason? This is not a rhetorical question. I am hoping someone will turn this light bulb on for me. With best wishes, Keith Arbogast
Fw: Why virtual volumes?
One area I've used VV's is for remote vaulting. Yes, you can write directly to a tape drive at the remote site, but over a slower connection, trying to send data to a tape will cause LOTS of backhitching on the drive, reducing tape performance (which probably isn't a problem), and reducing the useful life of the tape cartridge (bad). VV's allow you to land the data on disk, the allow the local TSM Server to migrate it to tape. You also aren't occupying a tape drive at the remote site for the (extended) duration of the job. And a TSM DB Backup takes (at least) one volume, so with physical cartridges, that's a whole tape. With VV's, you're only using the actual capacity of the backup, which is more efficient on space. If you're doing multiple backups per day, or lots of incrementals (for example, having logmode set to rollforward on a busy server), being able to stack multiple VV's on a physical tape will greatly reduce the tape cartridge resources you need (I'm seeing installations getting over 2TB on the new 3592/TS1120 drives - for a 60GB TSM DB Backup, that's VERY wasteful). With all of the features in TSM, there are a number of them that don't work for specific situations. Simultaneous writes on backup/migration, virtual volumes, NDMP backups, 3rd mirrors of DB and Log volumes, adding documentation to your Prepare file - lots of features that don't always make sense to use. But they're there, if you want/need them. Nick Cassimatis
Re: Why virtual volumes?
On 23/08/2007, at 7:29 AM, Nicholas Cassimatis wrote: And a TSM DB Backup takes (at least) one volume, so with physical cartridges, that's a whole tape. With VV's, you're only using the actual capacity of the backup, which is more efficient on space. At the cost of some reliability. What happens if the particular tape the virtual volumes are on goes bad, and you're in a disaster needing a DB restore? I'd rather spend the extra money on tapes and know that if something goes bad, we'll at least be able to recover some of the data ... (I'm seeing installations getting over 2TB on the new 3592/TS1120 drives - for a 60GB TSM DB Backup, that's VERY wasteful). Well, why not do what we're doing soon? We currently have some 1200 LTO2 tapes, and are in the process of migrating from LTO2 to LTO4; (some of) the LTO2 tapes will be kept in the silo for database backups (along with a single LTO2 drive for writing to those tapes.) There's another silo with LTO3 volumes; some of the LTO2 tapes will be put into that silo for exactly the same reason (LTO3 drives will write LTO2 tapes, so there's no issue with needing an LTO2 drive in that silo, at least for the time being). Call me a conservative fuddy duddy if you want, but I prefer to keep the TSM database backups as simple as possible.
