Re: What is the best backup method, using RMAN, for backing up the physical and standby database?

From: DG problem <skatefree_at_gmail.com>
Date: Mon, 4 Feb 2008 17:44:56 -0800 (PST)
Message-ID: <93d5b4e4-76cd-479d-b252-390043fa0951@s19g2000prg.googlegroups.com>


On Jan 31, 9:59 pm, Steve Howard <stevedhow..._at_gmail.com> wrote:
> On Jan 30, 9:24 pm, DG problem <skatef..._at_gmail.com> wrote:
>
> > 9.2.0.8 on HP-UX.
>
> > Primary DB on HOST1 (150Gb in size) and physical standby DB on HOST2.
> > Both hosts have their own tape library backup unit.
>
> > A low bandwidth link connects both hosts. Both hosts are in different
> > states.
>
> > It is important to keep backups of both databases on their respective
> > tape library.
>
> > Backups should go to disk first and then be backed up to tape.
>
> > What would be the best backup method?
>
> Hi,
>
> Out of curiosity, why would you back it up in both places?  We have
> several physical standby databases and backup just the standby, as it
> is a block for block copy of the primary.

Having backups on both the primary and standby give us more flexibility with no real disadvantages (out of hours backups don't effect our performance). For example, I could duplicate the production database on the database server if I needed to for whatever reason, however, I never have yet. It also adds an extra level of redundancy in case something bad happens. For example, if we lost the standby datacenter (maybe fire or natural disaster) we could keep working on the primary with full backups which we could then take off site. It also means that we have symmetric datacenters so if we switched over to the standby, everything would continue to work the same way, just with role reversal. Since for symmetry reasons we need to have a tape library on production, for the above reasons, we may as well use it. I guess you can never have too many backups :)

>
> Our storage is robust (EMC DMX), so we made the decision to just
> failover to the primary if we have a media failure (which are *very*
> rare for us, given redundant storage, controllers, switches, etc.),
> and rebuild the primary once the media failure has been repaired.
> That eliminated the need for duplicate backup media, and offloaded the
> RMAN backup CPU cycles to the standby node.
>
> I'm assuming the low bandwidth connection makes direct transfer a pain
> in the rear?  How did you build the standby originally (timing,
> logistic issues, etc.)?  If that was acceptable, rebuilding the
> primary from a backup of the new primary after failover should be
> feasible, and then switch back over to it at an agreed upon time.

The standby was built when the database was only a few gigabytes in size so a weak link was not a problem for transferring files. If we had to do it again, we would just send the backup by car, which is a couple of hours drive.

>
> If you ever have complete catastrophe, the backups of the standby can
> be used to rebuild it in either physical location (block for block
> copy of either database).
>
> Regards,
>
> Steve
Received on Mon Feb 04 2008 - 19:44:56 CST

Original text of this message