How well segregated is your data?  I'd advise having the SAP data and logs
in their own pools.  Since this type of data tends to expire in groups, do
you need to reclaim the tapes in these pools at all?

The hardest part, with a system like this, is getting the tapes idle to be
able to run "backup stg" against.  You may want to look at having the data
written to both the primary and copypools at the same time, or doing
something to idle the tapes you need to copy (mark them ReadOnly to force
new tapes to be used, something like that).  How busy your system is makes
this harder.

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 01/05/2006 12:04 PM
-----

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/05/2006
11:31:11 AM:

> We'll be adding 6 more drives in a few weeks -- to a total of 16. I have
> 6 off-site copy pools, one of which never goes through reclaim as it's a
> 21-day archive pool. I'm most concerned about the process for wrapping
> up an in-process reclaim and getting the tape out of the drive by the
> time the afternoon database backup finishes (I do full backups to LTO --
> currently runs about 20 minutes).
>
> I figure I'll need to open a reclaim window in the 2 AM to 6 AM time
> frame in order to get everything done.
>
> And I'd REALLY like to spend the money and put in the telecom circuit
> instead.
>
> Tom
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> John Monahan
> Sent: Thursday, January 05, 2006 11:10 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Running tapes off-site multiple times in a day?
>
> I'm thinking you're going to need to add tape drives before thinking of
> doing something like this.  You are going to shorten your current daily
> maintenance window because you have to squeeze in a portion of it to do
> a
> second run.  Could be done if you can shorten your current window
> enough,
> but I would think that would mean adding tape drives.  Getting your
> reclaims done is going to be a problem as well with only single threaded
> reclamation processes - if you currently run until 8pm sometimes and you
> are going to need to shorten that - will be tough unless you break your
> data up into more pools.
>
> Sounds awfully ugly to me.  I think the correct answer is yes it is
> technically possible, but do we REALLY need to do it this way.
>
>
> ______________________________
> John Monahan
> Senior Consultant Enterprise Solutions
> Computech Resources, Inc.
> Office: 952-833-0930 ext 109
> Cell: 952-221-6938
> http://www.computechresources.com
>
>
>
>
>              "Kauffman, Tom"
>              <KauffmanT@NIBCO.
>              COM>
> To
>              Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
>              Dist Stor
> cc
>              Manager"
>              <[email protected]
> Subject
>              .EDU>                     Running tapes off-site multiple
>                                        times in a day?
>
>              01/05/2006 08:54
>              AM
>
>
>              Please respond to
>              "ADSM: Dist Stor
>                  Manager"
>              <[email protected]
>                    .EDU>
>
>
>
>
>
>
> Like I said -- the questions are crawling out of the wood-work.
>
> Our management wants to reduce the possible data loss in the event of a
> disaster by taking copies off-site both in the early morning and again
> at the end of first shift.
>
> Is anyone else doing this? Will this be as painfull as I expect it to
> be?
>
> I know I'll have issues with reclaims -- I currently run expire
> inventory at noon, with reclaims kicking in shortly thereafter and
> sometimes running to 8:00 PM, so I'll have to implement a reclaim
> window.
>
> Electronic off-siting isn't an option -- I've seen us cut 400 MB Oracle
> redo logs for our SAP/R3 database at the rate of one every 2.5 minutes
> for extended time periods (and this is explicitly the data that has to
> go off-site). I'd need multiple T1 lines to cover the traffic, and the
> cost of a single T1 is considered to be "too high".
>
> I'm currently running TSM 5.1.6.3, planning on upgrading to 5.3.current
> in the next two weeks.
>
> TIA
>
> Tom Kauffman
> NIBCO Inc