[Veritas-bu] Backup using Storage Level Flash for DB (FC,BC,SI)
2012-06-18 22:43:20
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 DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Veritas-bu] Backup using Storage Level Flash for DB (FC,BC,SI),
dy018 <=
|
Previous by Date: |
[Veritas-bu] Image cleanup jobs, Howard Graylin |
Next by Date: |
Re: [Veritas-bu] Backup using Storage Level Flash for DB (FC, BC, SI), Lightner, Jeff |
Previous by Thread: |
[Veritas-bu] Image cleanup jobs, Howard Graylin |
Next by Thread: |
Re: [Veritas-bu] Backup using Storage Level Flash for DB (FC, BC, SI), Lightner, Jeff |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|