I have architected this extensively in one vendor's environment. With a well-designed architecture, all of the issues that you mention (except not having secondary servers to mount the images on to do the backup) can be mitigated. For example. You can check the state of the tablespaces before doing the split to determine if a script already put them in hot backup mode. It mostly just take working through all the issues one by one.
Mark ---------------------------------------------------------------------- Message: 1 Date: Wed, 20 Jun 2012 18:37:29 -0700 From: dy018 <nbu-fo...@backupcentral.com> Subject: [Veritas-bu] Backup using Storage Level Flash for DB (FC,BC,SI) To: VERITAS-BU@MAILMAN.ENG.AUBURN.EDU Message-ID: <1340242649.m2f.374...@www.backupcentral.com> Hi Jeff, Thanks for sharing your experience on your enviornment. I might need to clarify further, this method of backup does work but i guess it varies from different environment setup. >From your main reason that you stated, i've no doubt about what benefit it >brings but i'm not convince this method applies to all DB backup in one >enviornment. Imagine for one enviornment do not have a share SAN infra and >each project had it dedicated SAN switch and SAN media server or SAN client to >perform the backup for the DB servers. This is reason i feel from the backup >team, the member needs to know all these different DB servers backup >(something like network NAT), what is that particular SAN media or client is >mounting the split mirror disk for its backup because the DBA will submit the >restore request of the actual DB server. The 2nd problem my enviornment face will be each project might purchase differnet type of storage, IBM, EMC, HDS and the list goes on, the splitting script which we deploy needs to be consistant, each time a new storage was introduced, new script needs to be written and tested before release to production. And to deploy such backup in my enviornment requires afew teams effort to make the backup work as explain in my first post. As for the single point of failure i describe is actually referring to backup and not restore. The point is each project might only purchase 1 dedicated SAN media or client to mount the mirror disk as they do not plan to buy redundancy for this and they also feel its a waste of the SAN switch port as well. We had a setup of 10 different DB server using 1 SAN client for it mirror LUN backup as it comes from the same project and my concern is that if that SAN client went down, all DB servers backup will be affected. Running multiple stream, we are using bpstart notify script on the SAN client to ssh into the DB server into put the DB into backup mode and split the mirror before putting the DB into end backup mode prior to mounting up for backup. We may need to use parent start notify to ensure we only run the DB script once per backup job as the bpstart notify will trigger more than once depend how many streams we set on the backup policy. +---------------------------------------------------------------------- |This was sent by dy_lan...@yahoo.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +---------------------------------------------------------------------- ------------------------------ Message: 2 Date: Thu, 21 Jun 2012 08:01:53 +0530 From: Abhishek Dhingra1 <abhishek.dhin...@in.ibm.com> Subject: [Veritas-bu] Out of office To: VERITAS-BU@mailman.eng.auburn.edu Message-ID: <ofc046a45c.c383201f-on65257a24.000de825-65257a24.000de...@in.ibm.com> Content-Type: text/plain; charset=US-ASCII I will be out of the office starting 06/21/2012 and will not return until 06/23/2012. I will be out of office starting from 06/21/2012 to 06/23/2012. I will have no access to email . For any escalation kindly contact Akhil Mehrotra (9958000151) ------------------------------ _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu End of Veritas-bu Digest, Vol 74, Issue 12 ****************************************** _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu