ADSM-L

Re: Tivoli storage manager migration/backup

2006-10-19 12:08:49
Subject: Re: Tivoli storage manager migration/backup
From: Kelly Lipp <lipp AT STORSERVER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Oct 2006 10:05:53 -0600
Skylar,

In our systems, we backup stg first and then migrate so we know we have
one done before the other.  In your case, you synchronize theses
processes (our STORServer Manager product does this for you) by creating
scripts.

I guess I don't really worry too much about a tape failure before the
backup stg/migration processing completes.  Worst case, you might have a
problem and lose client data.  That's only a problem if you need the
data on the client at the same time that happens.  Unlikely.  In the
case where you lose client data on the TSM server (a very rare event),
the client will send it again (to the extent possible) the next time a
backup runs.  So in most cases the problem is self healing.

Now, if I were using poor tape technology I would be really worried.
But if I'm using something modern, like LTO3, then I worry less.

Thanks,

Kelly (thought I'd try to answer as many questions at Richard today)
Lipp 


Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Skylar Thompson
Sent: Thursday, October 19, 2006 9:54 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Tivoli storage manager migration/backup

Kelly Lipp wrote:
> Yes there is a way to do write to two tapes simultaneously: one 
> primary and one copy.  Use the copystg parameter on the primary pool 
> to set this.  This action behaves with respect to the collocation 
> parameter on each pool.  So if the primary pool is collocated and the 
> copy is not, the correct thing will happen.
>
> Also, remember we don't mirror tapes anyway and that term is not 
> appropriate.  What we do is make sure that there are two copies of the
> data: one copy in the primary pool and one in the copy pool.  These 
> copies are created either by writing to the to pools at the time of 
> the client backup (which is not always practical) or by using the 
> backup stgpool command.
>

OK. I looked at simultaneous write, but we have so many clients that
have been known to have over a terabyte of data to back up spread out
over tens of millions of files that going to tape before going to disk
seems like a bad idea.

> In general, plan on writing to two tapes at the same time if the data 
> from the client is large.  If it is not, consider sending data to a 
> disk based pool first, backing that up to the copy pool and then 
> migrating to the tape pool.
>
>

Is there a way to guarantee that data is backed up to a copy tape pool
before being migrated to the primary tape pool? We want to avoid any
tape-to-tape transfers before we have two known-good copies that we can
recover from.

And I guess this is as good a place as any to ask: How are other people
mitigating the primary tape pool as a single-point of failure? What do
people consider the likelihood of tape failure between the time the disk
cache is migrated to primary tape, and the primary tape is backed up to
copy tape (probably ~24 hours)? For the record, we're using Ultrium3
tapes w/ hardware compression.

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- K324, (206)-685-7354
-- University of Washington Medical Center