As Tom mentioned, the key here is the reusedelay parameter on the copy storage pool. You don't bring a tape back from off-site until you are sure that its replacement is off-site as well. If you assume it takes two days for a newly created copy storage pool tape to arrive safely offsite, then set reusedelay to three or more and don't bring it back until then. The key to all of this is the fact that copy storage pool volumes are reclaimed by using data in the on-site pools. That is, the off-site copy storage pool tapes are not brought back for the reclamation process. This is a very clever design offered only by TSM (in fact the entire notion of reclamation is unique to this product).
Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs, CO 80949 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Kauffman, Tom Sent: Thursday, January 24, 2002 7:32 AM To: [EMAIL PROTECTED] Subject: Re: Mitigating Risk with TSM's incremental backups I'd suggest using TSM to back the data up to LTO, then back up the LTO storage pool to a copy pool and send the copies off-site. Run reclaims and only bring back empty or pending empty off-site tapes. My worst case sends off a tape that is 5% full daily. The reclaim actually kicks in just after the tapes are checked out. The downside to this is the number of $110 LTO tapes you need, and that's a function of how often you move tapes off-site and how often you bring back the empties. You don't need DRM for this, although it may help (never tried it, so I can't help there). I've got a few conventions I use and a few scripts that simplify life, and we ship off-site daily, with the empties coming back on Friday. The naming convention I use is <poolname> as diskpool, <poolname>-LT as tape pool, and <poolname>-LT-COPY as copy pool: INDEF (disk pool for our commonstore), INDEF-LT, and INDEF-LT-COPY. One of the daily scripts does the backup storage pool. Another does a "q vol stg=*copy acce=reado,readw st=fil,ful", captures the volsers and does the "checkout libvol <library> <volser> remove=bulk checklabel=no". A typical day sees 8 tapes going off-site, including the TSM database backup; a normal Friday has 40 tapes coming back, including 5 week-old TSM database backups. Hope this helps - Tom Kauffman NIBCO, Inc > -----Original Message----- > From: Justin Derrick [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 24, 2002 8:06 AM > To: [EMAIL PROTECTED] > Subject: Mitigating Risk with TSM's incremental backups > > > I've been using TSM for quite a few years on AIX, and > surprisingly, this > issue hasn't come up before. > > My customer is using TSM in conjunction with Content Manager > OnDemand. The > config looks like this: > > AIX 4.3.3 on H70 > OnDemand, DB2, TSM > Data is cached on disk (by OnDemand, not TSM), and also > copied to Optical > (a la 3995), then backed up to LTO. > They are currently a very low-volume shop, adding under 1GB a > day to the > TSM system. > > The question raised to which I didn't have a good answer was: > > If we take a non-full LTO offsite for disaster recovery purposes, then > bring it back onsite as part of regular rotation, a vulnerability is > created. If the tape is on site when a disaster occurs > (which would always > be the case since their courier only delivers once a day), > not only is that > day's information lost, but all the previous days of incrementals > previously written to the tape are destroyed as well. > > I know we could keep multiple copypools in the chain, but it > seems like an > expensive solution to a simple problem. > > The immediate solution would be to create new 'full' backups of the > contents of the optical jukebox every day, and take them > offsite. While > this would actually be feasible in the short term (given > their low growth) > it would quickly become unmanagible in the future. > > Is the solution to simply buy enough tapes so that you simply > send one tape > a day offsite for as long as possible, then perform large > reclaimation once > every 'long as possible'? This sounds like it's within the > realm of the > DRM, which I'm woefully inexperienced with. Any advice, > direction, etc. > would be greatly appreciated. > > -JD. >
