ADSM-L

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

2008-06-19 15:28:10
Subject: Re: [ADSM-L] TSM DB backup - dr, issues and concerns
From: Remco Post <remco AT PIPSWORLD DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Jun 2008 21:26:02 +0200
What I'd reccomend:

1- db backups to remote datacentre, incrementals after major things
2- db snapshots to local datacentre, just to be sure, db snapshots
don't interfere with your db incrementals
3- async mirroring of the db and log storage, for fast recovery and
minimal performance impact (sync mirroring has too big an impact)
4- TSM mirroring of the db and log volumes so you can potentially
repair your db if just one volume is corrupt
5- logmode roll-forward

normally I'd say:

a- clients backup
b- local db snapshot
c- backup stg
d- remote db backup (full)
 - run prepare
e- reclamation
f- remote db incr
g- migration
h- remote db incr
i- expire volhist
j- go 2 a

in this way, your remote full db backup will cover the most recent
tate of your remote volumes. Basically, It will cover everything that
is there. Now, If you relly want you could:
 - also do a remote dbsnapshot at d
 - have something 'smart' duplicate your db backup volumes, this
could even be dd, you just have to manually manage this, but it is not
really hard to implement, just hard on the bookkeeping.

Op 19 jun 2008, om 20:45 heeft Andy Huebner het volgende geschreven:

0) "Too Paranoid" is not good English

2) We use TSM to mirror the DB and Logs to another array in a
different
building.

3) We have thought about this, but not done it...

6) 2 DB backups per day to tape.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of
Richard Rhodes
Sent: Thursday, June 19, 2008 11:53 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM DB backup - dr, issues and concerns

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.


This e-mail (including any attachments) is confidential and may be
legally privileged. If you are not an intended recipient or an
authorized representative of an intended recipient, you are
prohibited from using, copying or distributing the information in
this e-mail or its attachments. If you have received this e-mail in
error, please notify the sender immediately by return e-mail and
delete all copies of this message and any attachments.
Thank you.

<Prev in Thread] Current Thread [Next in Thread>