Redundant DB vs Exports as Backup Strategy

[khammer99]

Hello,

At the risk of starting a flame war...
We're trying to establish a backup/recover strategy and are trying to decide between using a redundant/hot backup db, doing exports, regular tape or a combination of all ot them.
Please feel free to post opinions, but I was hoping to be directed to some
sources that could help our team weigh the pros and cons of each and then finalize a strategy.

Some backgroud:
Oracle: 8.1.4
OS: Solaris 2.6 and 2.8 (we have a couple of database machines)
DB Availability: Technicaly 24x7, however we can schedule regular maintenance windows (early Sunday mornings, :( ) as needed.

I'm sure more information is required. Again, I was hoping to find some on-line resources to investigate, before I ask for more definitive opinions.

Thank you to all who respond

[svk]

What is most important in deciding the backup strategy is what application and environment you and the databases are supporting.

Every method that you have mentioned have very clear limitations and scope and I'm sure you know @ them.

So, start with your restore/recovery requirements and that decision tree should automatically lead you to the solution @ backup strategy.

[VVVVVVVV]

Hi ,

We have a situation where we have a DB that doen online TX processing. It is
a 24X7 environment but the cost of Oracle EE did not justify running a true
Oracle standby DB. We came up with the following.

1) Machine A is the live machine.
Machine B is the standby.

2) The database was installed and built on A and a cold backup taken to B.

3) We wrote shell scripts to do the following on A
- Every hour a logswitch is forced.
- The generated archived redo logs are FTP'd to B.
- The Archived redo logs on A are then moved to tape storage and deleted off the machine to make sure the arch destination never fills up.

4) Once a day we do the following on B.
- Start-up the server in mount mode.
- Recover the db using the archived logs that where FTP'd from A.
- Shut the DB down
- Start it up again do an incomplete recovery and open it read-only to test it. Shut it down again.

This way the DB on machine B will never be more than an hour out of sync with A.

This waas all done with standard unix utilities and oracle standard edition.

We supplement this with a daily backup of the database on B - i.e a cold backup and daily exports from the database on A.

Hope this gives you a more practical answer or just some ideas.

[Glenstr]

IMHO an export is a good thing to do, but terrible as a "backup strategy" if you will, at least I would not run it as my only backup method, you cannot do a point-in-time recovery with it, and if you lose one tablespace or datafile you can't do an incomplete recovery.

All of my 24-7 dbs I have online backups running daily, and on most I also run an export at a quiet time of day with consistent=y set. I dont have any redundant db's, but Dobermans solution to the standby database is a good one.

I do have some test db's running that I often update with a script that simply truncates or drops all the tables then imports using the latest export taken, this works good and can be out in a cron job or task scheduler.

hth

[rookie8551]

I think it all depends on how "exact" you want your recovery to be.
If you have a fast OLTP type system, where updates and inserts happen all the time and one or just a few at a time you need to be able to recover up to the minute the instance failed.
But if your system is a DSS type system where updates and inserts are few and in large groups, like the DB I`m working on right now, you can export at set intervals (I use NT`s soon tool to create a cycle, each run sets up the next run) and then keep the exports on some "backup machine" and on sunday backup the EXP files along with a "cold" backup of all datafiles, control file and so on.
Hope this helps, have fun.

[TimHall]

Start using RMAN. It gives you a finer granularity of recovery (down to block level in 9i) and you don't need to switch the tablespaces to backup mode when doing a hot backup.

Depending on the size of your DB, scheduling exports is a usefull addition for minor reconstructions that don't require large-scale recovery.

Combinations of RAC, replication and standby server provide even greater levels of redundancy with additional costs and maintenance requirements.

Cheers

[khammer99]

Hello Again,

First of all, I would like to thank the people who responded to my question. I apologize for not responding sooner, but a recent major bought with a cold/sickness whatever, left me an invalid for about a week.
We are leaning heavily to using a redundant backup database as our backup strategy. We ran some test earlier in the year and found this to be a pretty straight forward scheme.
Can anbody point out any pitfalls of using this as a sole backup strategy?

[YellowLark]

Sure, the backup DB is a good plan. Just make sure you have cold backups and/or export files as well.

A redundant DB as your SOLE backup won't help you if a DBA or user accidently deletes needed data and you need to restore it.

[marist89]

Originally posted by khammer99

Can anbody point out any pitfalls of using this as a sole backup strategy?

What happens if your DB fails DURING the backup/refresh process?

[Shestakov]

backup/recovery plan (or startegy) this is like insurance.
When u come in insurance company u have to deside to youself:
-- i must have insurance against ... and i ready to pay for it ...
then
-- i have to have insurance against ... and i ready to pay for it ...
may be I want to have .... but i have to estimate price of this point of insurence plan.

The method for create a backup/recovery plan the same.
U have to esmate in what situations u can lost what component of database or datas in database.
Than - How match time u may spend for recovery situation, for resolve a problem?
list of these situtions and conditions is basis for create B/R plan.
Backup method this is a payment for recovery the database with needed transactions and
within needed time.