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 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Skylar Thompson Sent: Thursday, October 19, 2006 9:54 AM To: ADSM-L@VM.MARIST.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 ([EMAIL PROTECTED]) -- Genome Sciences Department, System Administrator -- K324, (206)-685-7354 -- University of Washington Medical Center
