Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Showing results for 
Search instead for 
Did you mean: 

Recommedation for backup / restore!

Rob van Buiten
Regular Advisor

Recommedation for backup / restore!

Hi All,

[hp-ux11.11, oracle 9i2.0.7, dp5.5, advanced backup to disk)

We use the oracle integration for dataprotector and want to speed up backup/restore.

We also use advanced "backup to disk" which make a single backupfile in a backup directory!

Can I do something with channels, load balancing, concurrency??


Steven E. Protter
Exalted Contributor

Re: Recommedation for backup / restore!


There is no perfect way to do backups.

I will list my preferences with oracle from best to least favorite.

1) Cold backup. Shut the database down and get an OS copy of the database. Use Online JFS snapshots if you can't tolerate the downtime. These allow you do down the db, set a snapsot and bring it back up, saving the writes to a special logical volume. This is the most reliable way of doing backup.
2) Occaisional cold backups with hot backups to disk. This will along with archive logs keep you close to current and is reasonably reliable.
3) rman. I don't like it, but Oracle stands behind it. You'd have to do performance analysis on the box to figure out what the problem is and if rman is able to correct it.

Steven E Protter
Owner of ISN Corporation
Rob van Buiten
Regular Advisor

Re: Recommedation for backup / restore!


forgot to say that the database cannot be closed. (we have a 7x24 hour production environment)
So it must be online!
Rita C Workman
Honored Contributor

Re: Recommedation for backup / restore!

The new Ultrium LTO tape units go really fast...I've got a couple libraries using them. But overall, if you have a lot of becomes a crunch to get it all off to tape. And nobody wants to keep their DB in hotbackup mode any longer than they have to.

Here's a couple things dependant on the storage you have.
For larger arrays you may be able to use BCV or CDL technology.
BCV's create a seperate disk that I can then backup from to tape, and use for quick disk restore if needed.
CDL technology is creating your backup to disk-it follows the tape library scenario, except it's not a's all disk.
I like BCV's.....
So, if you got the funds, then take a look at syncing to another mirror and splitting it off and mounting it elsewhere (i.e. BCV's). We're 24x7 too and by implementing this it took the stress of getting the backups done within the 24 hour timeframe.

Not sure that's what you were looking for,
Michael Steele_2
Honored Contributor

Re: Recommedation for backup / restore!

We use data protector and oracle and backup using BCV's. Backups go over the SAN instead of the network and its quite fast.

a) How many terrabytes are you moving?
b) Are you backing up over the network or the SAN?
c) How many backup drives are available?

Data Protector provides multiplexing ( or plexing ) of backups. Plexing backups to one drive that is attached to up to 50 ( advertised higher ) but 5 or less then 5 concurrent backups is probably the industry standard.

The only problem with multiplexing is the restoring of the data, it will take longer.
Support Fatherhood - Stop Family Law
Volker Borowski
Honored Contributor

Re: Recommedation for backup / restore!


yes rman supports the use of multiple channels and to optimize read performance, you can even multiplex more files into a channel.

The system I was supporting for the last 3 years is now backed up with 8 channnels and 4 files per set over gigabit ethernet with IBMs TSM/TDPR3.

It's a meanwhile 5+TB SAP system, for which we had some trouble using RMAN for full backups (was core-dumping randomly).
This is very bad, because using the SAP tools, you can't fill up a broken full rman backup.

So we are now doing full backups without rman the classic style (backint - util_file) so if you get a bounce at 80% backup time, you can fill it up saving the remaining 20%, allthough you will not have a valid backup for a following incremental backup then.

As for speed. The TSM guys have set up some virtual tapedevices on disk (quite speedy), which are migrated to tape later. Backuptime varies quite a lot, mostly because during the night some 30 other systems start to backup. So for this system we tend to schedule backups during the day, to get the backupserver resources (esp. inbound bandwidth) with less concurrency from other systems.

Best shot for 5 TB full backup is around 12 hours now, but can tend to 22-23 hours, depending on concurrent nightly backup server load. Because we have to share backupresources this way, we switched from scheduled backup operation to a manual one, depending on the amount of redologs written. So if the system is less busy for a day, we are rescheduling the backup, because doing another incremental with "just" one TB of redologs is rather costy.

Currently we "try" to follow this pattern:
- full backup before moths end
- additional INC (or full) backups for special actions -> i.e. SW patches
- normal operation is to do an INC backup after 1,5-2TB of redologs (which is ~6 days normaly and 3 or 9 days rarely, depending on operation) on this system. This value has been chosen, because our INC backup Volume after this period is around 1TB and that was a calculated optimum for restore cenarios at reasonable cost.

And yes, I do no like this pattern. I would favor to do at least two scheduled full backups a month and to keep more backup versions, but I was overruled because of costs.

Bottom line: If you have bandwidth and fast tapes and enough CPU resources, using additional channels will speed up backup allmost in a linear way. Keep an eye esp. on CPU (the above described one has plenty :-).
We have an other system with 4 cpus, that becomes nearly unusable for dialogusers with a rman online backup with two channels because of cpu load.

Hope this helps