ADSM-L

Re: [ADSM-L] TSM DB backup - dr, issues and concerns

2008-06-19 13:26:07
Subject: Re: [ADSM-L] TSM DB backup - dr, issues and concerns
From: Wanda Prather <wprather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Jun 2008 13:19:25 -0400
4) is a no.

1) is good, but if you're on vacation when it happens, does everybody else
know how to play that tune?

2) would give you the best coverage - no DB data loss past the last sync
point
However, if you try to use the replicated DB post-disaster, where are your
tapes?
If you are creating copypool tapes and sending them to a vault, suppose you
do your backup stgpool and disaster strikes BEFORE the eject runs or the
courier comes.  That set of copy pool tapes burns up with the building,
and your replicated DB will reflect tapes that you weren't able to save.  So
you will need procedures tested to sync the replicated DB with what media
you actually have available for recovery.

 3.5) A very easy and clean alternative is 3.5:

Do your DB backup to tape in the remote library as now
Since you already have SRDF in place,
Do a DBsnapshot to a disk file device class and let SRDF replicate it.
That way you've not only got 2 DB backups available, they are on different
media.
One is bound to be readable!
W

On 6/19/08, Richard Rhodes <rrhodes AT firstenergycorp DOT com> wrote:
>
> We have been having some discussions about our TSM db backups,
> and, db backups for DR.
>
> Environment:
> - dual datacenters
> - connected by high speed DWDM network
> - tape drive san connected between datacenters
> - libraries and TSM servers at both sites
> - TSM db backups go directly to tape in the offsite library
> - we ONLY use full backups (no incremental or roll-forward mode)
>
> Paranoid QUESTION came up:  In a DR (or any TSM db restore,
> for that matter) what do we do IF we have a problem reading
> the db backup tape . . .
> Answer:  use the previous backup.  (resulting in bigger data loss window)
>
> I was asked to brain-storm if/how this can be mitigated.  I've come
> up with the following list of thoughts . .
>
> 0)  Don't worry about it . . . It's too paranoid.
>
> 1)  perform db backup to offsite Virtual Volumes, which can have a
> copy pool for protection.  We used to do this, but dropped it when
> we got direct san connections between datacenters.
>
> 2)  remotely mirror the db/log (sync SRDF - we're an EMC shop)
>
> 3)  perform db backup to local disk (file device), and push a backup of the
> files to a remote TSM server with primary and copypool copies.
>
> 4) implement incremental backup????????
>   ( can you apply incremental across a lost db backup?
>     ie - given:   full-1, inc-1a, inc-1b, full-2, inc-2a, inc-2b
>     If full-2 is bad, can you restore full-1 and post all inc's in order
>     to get to the most current db state?)
>
> 5)  If (4) doesn't work (and I don't think it does), does anyone know
> if v6.x with DB2 will support log backups to allow this kind of
> restore?  (what we do for Oracle all the time)
>
> 6)  Other???  What do YOU do, or is this something you just don't worry
> about?
>
>
> Thanks!
>
> Rick
>
>
>
> -----------------------------------------
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
> the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you
> are hereby notified that you have received this document in error
> and that any review, dissemination, distribution, or copying of
> this message is strictly prohibited. If you have received this
> communication in error, please notify us immediately, and delete
> the original message.
>