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:[EMAIL PROTECTED] On Behalf Of Richard Rhodes Sent: Thursday, June 19, 2008 11:53 AM To: ADSM-L@VM.MARIST.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.
