ADSM-L

Re: Tivoli storage manager migration/backup

2006-10-19 12:29:32
Subject: Re: Tivoli storage manager migration/backup
From: "Bos, Karel" <Karel.Bos AT ATOSORIGIN DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Oct 2006 18:27:36 +0200
Hi,

Define a script:
Backup stg diskpoolX copypoolX wait=yes
Backup stg tapepoolX copypoolX wait=yes
Migrate stg diskpoolX

Define an admin schedule to run the script.

If your diskpool is large enough to hold at least one day of backup
data, you can turn on caching and always have the latest backup data on
disk. Caching data on diskpool has some performance issues hitting
backup's and migration (fragmentation!) performance. But, I can live
with that.


Regards,
Karel


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Skylar Thompson
Sent: donderdag 19 oktober 2006 17:54
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: 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

Attachment: disclaimer.txt
Description: Text document