Oracle-L: RE: RMAN - Disk vs Tape backups

From: Orr, Steve <sorr_at_rightnow.com>
Date: Mon, 03 Jun 2002 10:48:32 -0800
Message-ID: <F001.004728D8.20020603104832@fatcity.com>

You mentioned "disk management" issues... A problem with disk is that you are probably limited to only doing level 0 backups. If your recovery spans multiple RMAN backups then it could be a real bear trying get everything you need to recover if you're staging from disk to tape. You'd have to be very careful about keep track of your tapes.

-----Original Message-----
Sent: Monday, June 03, 2002 11:43 AM
To: Multiple recipients of list ORACLE-L

Dennis ;

You are absolutely right - the DISK option has a big down side that I did not catch :
In a disaster (computer room fire) the daily archive logs would be lost leaving you without the ability to roll forward your database - and thus the

loss of data. Therefore if you were to go with the DISK option - you would need to manually implement an remote disk or tape backup procedure for your daily archive logs (not an easy task) - that is if your clients could not live with the loss of any data.

The RMAN tape management option (as long as they are promptly stored in a fire resistant safe) definitely has its advantages.

Good point !

As a side note on disaster recovery ; We perform a 'disaster recovery' test here every 6 months.
This is a great sanity check - as it tests out our procedures and ability to

recover from a disaster.
In our last test we simulated a loss of a production server (computer room lost due to fire) - and together with the SA's we rebuilt the box from the ground up using the backups that we had in the fireproof safe. This exercise also made it very clear to our clients that given our current backup configuration - they would loose at most one days worth of transactions (the archive logs).
It also confirmed the 'assumptions' that both the DBAs and SAs were making about 'who was backing up and responsible for what'. I highly recommend going thru this procedure at least once a year.

Your comment about implemented RMAN on disk first before implementing RMAN with a MML - We took the following approach ; If you plan on routing your backups directly to tape - take one step back and begin by configuring RMAN to backup to disk first. Thus you will eliminate the (major) problems associated with configuring the tape interface. Once you have RMAN up and running on disk then implement the tape interface. ie; Don't bite off to much at a time.

Thanks and good luck in your RMAN rollout!

Patrick J. Howe
Oracle DBA
Illuminet. A Verisign Company.
4501 Intelco Loop SE
Olympia, WA 98507
Email : phowe_at_verisign.com

-----Original Message-----

Sent: Monday, June 03, 2002 8:48 AM
To: 'ORACLE-L_at_fatcity.com'
Cc: 'howe_at_Illuminet.com'

Pat

Excellent summary. I have only a few points to add. I must point out that I am an RMAN novice, just getting brief spurts of time between other people's priorities.

If you use RMAN to back up to disk, I haven't figured an advantage to backing archive logs up with RMAN. If anyone knows an advantage, I would appreciate hearing it. Obviously if you are using RMAN to write to the MML, it makes excellent sense to back up the archive logs, but writing to disk, you just create an extra copy of your archive logs on disk, which eventually gets copied to tape. RMAN will apply the archive logs, whether you've given it charge of them or not. Since you are probably doing RMAN incremental backups each day, you probably only need today's archive logs anyway.
I appreciate your points on disaster recovery. This topic rarely seems to come up with RMAN. We are into what might be termed "poor man's disaster recovery". This isn't where you have a duplicate computer room in another city (how do I apply to be the DBA at one of those facilities), but where you take backup tapes offsite and your hardware vendor promises to find you a replacement server somewhere to load your tapes into.
The disaster recovery scenario our systems manager insists on is "your server just burned to the floor, go get your backup tape from the offsite vendor and go to a another location and get your system going." The key is making sure that everything you need gets on that tape. I agree with you, that when you rely on an MML, that is one more layer of uncertainty. How can you make sure there isn't some key disk file the MML relies on, unless you test the scenario.
Someone on this list gave me the advice that it is easier to learn RMAN by backing up to disk.
A lot will depend on your site. I would expect that the larger the site, the more benefit would be derived from and MML. And the more chance to get payback from the training and learning.
More disk space - when my system administrator realized by backing up to disk he wouldn't need to learn how to interface Veritas to Oracle, he was most enthusiastic about finding more disk space.

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Friday, May 31, 2002 4:05 PM
To: Multiple recipients of list ORACLE-L

I am currently wrestling with whether to implement 'rman disk backups' or 'rman tape backups'.
I have put together the following PRO's and CON's list so that I can weigh my options.
I am putting this out to those on the list that are working with RMAN and care to add to the points i have made.
It is open for discussion - I look forward to reading your responses.

PS : Either CC me on all question responses or I will get back to you on Monday - I am currently in Oracle-L digest mode.

Thanks

TAPE
With this option rman directs the rman backup directly to tape.

PROs

Disk Maintenance issues are not applicable ; You do not have to be concerned about whether you have enough disk space for your backups. You do not have to setup, maintain and monitor daily cleanup jobs.
Rman will be able to automate the recovery process for you ; Rman knows where the backups reside (tape) and will recover them to disk - as needed by the recovery process.
Setting up a hourly remote copies of any new archive logs is easy - just setup a tape archive copy.

CONs

Recovery is slower (disk verse tape).
When duplicating your database to a different server or in a true disaster, where you have lost a server and you need to rebuild the instance on a new server - You will have the added task (and time) of installing and configuring the Media Management Layer (ie; Legato). Since your backups reside on tape, the Media Management layer on the Oracle Server needs to be installed and configured before you can talk with the backup server.
You have to concern yourself about tape resource issues ; A 'CROSSCHECK' or 'VERIFY' of your backup may keep the tape subsystem busy loading, unloading and positioning tapes. If your tape subsystem is used for other purposes other then your backup - then you could run into resourcing issues around when and if you should be running these jobs.
Also the submitting and scheduling of these tape backup jobs will probably move out of the dba's control (cron) and into the tape management scheduling group's control.
With this option you must be use rman "Backups". Rman "Image copies" can not be directed to tape.

DISK With this option rman directs the rman backup directly to disk. All of the Disk Pro's and Con's that I came up with were just the mirror image of the Tape Con's and Pro's.

The catch with this option is you probably do not have enough disk space to store all of your backups on disk, therefore you will need to put into place a procedure that backs up your rman backup files to tape and then deletes them from disk. Note that rman will still think that all of these backups still reside on disk therefore it will become the dba's job to manage the "backup-to-disk", "delete-from-disk" and the "recovery-from-tape" of these rman backup datasets.

PROs

Recovery is faster (disk verse tape) as long as the backup you want resides on disk.
When duplicating your database to a different server or in a true disaster, where you have lost a server and you need to rebuild the instance on a new server - You will not have the added task (and time) of installing and configuring the Media Management Layer (ie; Legato Client). You would use standard tape recovery procedures to recover your backups from tape - then issue the rman recovery commands.
You do not have to concern yourself about tape resource issues ; You can schedule a 'CROSSCHECK' or 'VERIFY' of your backup without worrying about impacting other outside resources.
The dba is in total control of the tape backup scheduling.
With this option you can use rman "Backups" or "Image copies".

CONs

Disk Maintenance issues are applicable ; You have to be concerned about whether you have enough disk space for your backups. You have to setup, maintain and monitor daily cleanup jobs.
If the backup you want is not on disk Rman will not be able to automate the recovery process for you ; Rman thinks that all the backups reside on disk - he does not know that you have backed them up to tape and removed them from the backup directory. Therefore it becomes the dba's job to manage theses tasks.
Setting up a manual hourly remote copy of any new archive logs is more complex. This will give the dba more tape backups that he will have to manage and keep track of.

Patrick J. Howe
Oracle DBA
Illuminet. A Verisign Company.
4501 Intelco Loop SE
Olympia, WA 98507
Email : phowe_at_verisign.com

Chat with friends online, try MSN Messenger: http://messenger.msn.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Pat & Brenda Howe
  INET: pjhowe_at_hotmail.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Orr, Steve
  INET: sorr_at_rightnow.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Received on Mon Jun 03 2002 - 13:48:32 CDT