Backup Central

Hi Guys,

Anyone currently deploy any form of backup using the mirror copy from the SAN and mounted to an alternate host or media server to backup the flat DB files?

IMO, such setup should remain as fast backup and recovery for adhoc, emergency purposes and not use for daily backup.

The advantages i heard had for such backup is to free up the server IO during the backup but not all server IO wait causing by backup stream for RMAN which can be controlled should not be a problem. If the DB size is a concern, introducing regular incremental rman dump to disk or tape should be sufficient and perform a full rman dump maybe once a week?

I see many disadvantages of using storage level mirroring for backup for the following reason

1. If you have 10 DB servers using one SAN client or media server to perform its backup, this create a single point of failure for all server using it to backup.

2. If the source LUN having some fsck issue, it will affect the backup as well as it will always prompt to perform a fsck on the mirror LUN each time they perform a sync and break. If because of one redo log LUN having issue and causing the rest of LUNs not able to backup as usually this type of backup are pre scripted and if you perform checks, the netbackup will failed with status 73.

3. Create operation issue during restoration for big backup environment. DBA or system admin who wants to restore will usually provide the DB hostname as the source in their restore request form however, if the backup team or operator who performs the restore needs to know this source hostname DB backup was perform by another server and need to select the correct hostname in the restore GUI, if the actual hostname was place, the catelog may only have the OS backup images found.

4. Create many steps for admin when adding of new LUN or increase or existing LUN on the current DB LUN that is on backup.
Steps such as creating new LUN, creating mirror LUN, ensure the media server is able to perform some device scan to see the new luns, editing script to perform sync on the LUNs, etc. If any of these wont done in one go, the backup will be affected due to production storage requirement which should not be dependant at all IMO.

5. No granulate restore as they are flat files level backup as compare to RMAN.

6. Require additional space on the server for the DB files to be restored.

7. Involved more resource to come up with the script. (Storage admin for breaking/resync mirror LUN, DBA for begin and end backup mode, system admin to come up with sudo script.)

8. Complicated when it comes to troubleshooting as explain in item 6. Any of the script change can cause backup failure or invalid backup.

9. Create different proxy or san media server due to different filesystem? If the DB is using ASM or VXFS, the server mounting the volume need to have the exact same filesystem hence create inflexiblity.

I hope to hear any of you whom had similar setup in your enviornment and what are your feeling towards such backup method?

We've been doing mirror copy and mount to alternate media server for backup of flat files for years and don't have the problems you describe. We did it previously using EMC's BCV and for the past couple of years using Hitachi's Shadow Image.

The main reason we do it is to minimize downtime on the Production database. By doing the mirroring we can start the synchronization of the mirrors long before the actual split of the mirrors without impacting Production. Once we are ready to split the mirrors we can put the database into hot backup mode (6 nights a week) for a short period of time, split the mirrors and take it out of hot backup mode. 1 night a week we actually stop the DB to do a "cold" backup and do the split. The split operation takes a very short period of time as compared to how long we would have to have a database in hot backup mode or down to do a full backup directly from the live Production server.

We do NOT have the single point of failure you describe because we do have the Production server and our Dev/Test servers as media servers as well. When refreshing Dev/Test databases we simply change the FORCE_RESTORE_MEDIA_SERVER in bp.conf to make it restore files backed up from our backup media server to the target Dev/Test server. We would do similar to restore the Production server should the need arise. You really don't want to have to restore your huge database across LAN from a backup media server to your production server.

Also just because you are doing mirroring and alternate server backup doesn't mean ALL of your Production DBs have to go to a single alternate server. In our environment we have several major database we consider Production and most of those have associated Dev/Test servers so we could use the latter for the backups if necessary.

Additionally you can (and should) run multiple streams for your backups to shorten your backup (and therefore restore) times.






-----Original Message-----
From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of dy018
Sent: Monday, June 18, 2012 10:43 PM
To: VERITAS-BU < at > MAILMAN.ENG.AUBURN.EDU
Subject: [Veritas-bu] Backup using Storage Level Flash for DB (FC,BC,SI)

Hi Guys,

Anyone currently deploy any form of backup using the mirror copy from the SAN and mounted to an alternate host or media server to backup the flat DB files?

IMO, such setup should remain as fast backup and recovery for adhoc, emergency purposes and not use for daily backup.

The advantages i heard had for such backup is to free up the server IO during the backup but not all server IO wait causing by backup stream for RMAN which can be controlled should not be a problem. If the DB size is a concern, introducing regular incremental rman dump to disk or tape should be sufficient and perform a full rman dump maybe once a week?

I see many disadvantages of using storage level mirroring for backup for the following reason

1. If you have 10 DB servers using one SAN client or media server to perform its backup, this create a single point of failure for all server using it to backup.

2. If the source LUN having some fsck issue, it will affect the backup as well as it will always prompt to perform a fsck on the mirror LUN each time they perform a sync and break. If because of one redo log LUN having issue and causing the rest of LUNs not able to backup as usually this type of backup are pre scripted and if you perform checks, the netbackup will failed with status 73.

3. Create operation issue during restoration for big backup environment. DBA or system admin who wants to restore will usually provide the DB hostname as the source in their restore request form however, if the backup team or operator who performs the restore needs to know this source hostname DB backup was perform by another server and need to select the correct hostname in the restore GUI, if the actual hostname was place, the catelog may only have the OS backup images found.

4. Create many steps for admin when adding of new LUN or increase or existing LUN on the current DB LUN that is on backup.
Steps such as creating new LUN, creating mirror LUN, ensure the media server is able to perform some device scan to see the new luns, editing script to perform sync on the LUNs, etc. If any of these wont done in one go, the backup will be affected due to production storage requirement which should not be dependant at all IMO.

5. No granulate restore as they are flat files level backup as compare to RMAN.

6. Require additional space on the server for the DB files to be restored.

7. Involved more resource to come up with the script. (Storage admin for breaking/resync mirror LUN, DBA for begin and end backup mode, system admin to come up with sudo script.)

8. Complicated when it comes to troubleshooting as explain in item 6. Any of the script change can cause backup failure or invalid backup.

9. Create different proxy or san media server due to different filesystem? If the DB is using ASM or VXFS, the server mounting the volume need to have the exact same filesystem hence create inflexiblity.

I hope to hear any of you whom had similar setup in your enviornment and what are your feeling towards such backup method?

+----------------------------------------------------------------------
|This was sent by dy_lan018 < at > yahoo.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu




Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer

---------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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.