I have never worked with backup tools like HP Omniback or Veritas Netbackup, we have always used the basic hotbackup scripts. I am currently in a project where I have to backup about 100GB daily to DLT tapes. Are these DLT tapes fast?
I have been discussing with UNIX Admin about perfoming HOT BACKUP with Omniback and he told me the best way for Omniback work efficiently is backing up a filesystem each time, what he means that we should backup a whole filesystem then end backup process then start another filesystem etc The problem is we have several tablespaces in each filesystem and I dont really want to put all of them in backup mode at the same go thus generating more redos than usual (and if system crashes we are forced to recover all tablespaces in that filesystem) Has anyone worked with Omniback and knows a better way?
We dont have Oracle Agent for Omniback II and not using RMAN
I really can't reply to the use of Omniback, I was at a shop for a short time where they used it to backup their server. But it was a small shop and they could be assured of very low usage at night, so they would set the entire database into backup mode and backup it entirely at one time. It was also a rather small database so it wasn't a real problem.
In my shop I have set up my production servers using RAID 1 + 0 and created a third mirror for my backup. At night I resilver the third mirror, set all tablespaces into backup mode and break the mirror, then take all tablespaces out of backup mode. This process to break the mirror and take all tablespaces out of backup mode for eight databases takes less then one minute, so I don't have to worry about redo logs. Then I can backup the mirror to tape at my leasure. I do this because DLT tapes are not fast. There are some newer ones coming out later this year that have a faster speed, but DLT technology is not new and it is not very fast.
Sorry I couldn't answer you question directly, but hope this helps some.
I haven't used omniback, but have used many Unix based products with Oracle databases (Legato Storage Manager, Veritas Netbackup, CA Alexandria, etc.)
These products in their base forms backup regular Unix files well. However, when it comes to backing up Oracle Databases, you must purchase an "extension" or "agent" type program. This agent program will allow you to either interface with RMAN or backup your files individually while the agent takes your tablespaces in and out of backup mode.
Without these "agents" (well worth the price IMHO), you have alot of scripting ahead of you. The options I can think of is:
1. Figure how to backup one file from the command line and incorporate into your hotbackup script. This is very difficult as most of these packages run off "backup jobs" (preconfigured jobs that backup filesystems).
2. Use RMAN or your hotbackup scripts to backup to disk and then kickoff a filesystem backup for the target filesystem.
3. Use a third mirror as justadba suggested.
I like the DLT 7 or 8 series drives. I think they are plenty fast enough for most database backups.
As you pointed out, you don't want to put a lot of tablespaces in backup mode if you don't have to.
Also, there would be timing issues between when the tablespace was scheduled to go into backup mode and when the backup job kicked in. And what if the tape was't done when you took your tablespaces out of backup mode?
yea marist I have considered all three options, as you and the unix admin I talked to you all pointed out that these backup tools backups up filesystems (seems that you can backup files but since there quite a few files for simplicity the UNIX guy doesnt want to schedule one job per file)
Then I thouhgt of backing up the files to another disks and during the day *pass* those files to the DLT tapes but the database is expected to grow to > 500gb and backing up such database we require extra 500GB disk! This applies to the third mirror (we have RAID 0+1 as well)
That's why I thought of RMAN incremental backup feature but since I am not pretty familiar with RMAN I asked in another thread if anyone knew if this feature works OK
justdba can you elaborate a bit more about your process? When you say you resilver the third mirror do you mean you break the mirror? How about the archived logs?
Then another option would backing up just data tablespaces everyday and index tablespaces twice a week or so
You could have your sysadmin configure a job that backs up /u01/oraback. Then, figure out how to kick off this backup from the command line. If you get this figured out, the rest is cake.
In your hotbackup script:
1. copy the datafiles that belong to tablespace XYZ to /u01/oraback
2. put your TBS back online
3. kickoff your preconfigured backup job
4. when your backup job is finished, wipe out /u01/oraback
5. repeat for next tbs
My experience with RMAN's incremental backups is limited but not very positive. I found that little time was saved with using the incremental backup feature. Then again, I may have had it configured wrong...
I have a nightly cron script to backup the server. The script builds the mirror nightly and after it is "broken" I mount the mirror as a snapshot volumn. It is these volums I backup to tape. The process is:
1. unmount the "snapshot" volumns.
2. destroy the snapshot (this is necessary to create a new mirror).
3. begin the resilver process to create the 3rd mirror.
4. when the resilver process is complete, put the databases into backup mode.
5. break the mirror.
6. take the databases (tablespaces) out of backup mode.
7. Perform an fsck on the mirrors to clean them up.
8. Mount the snapshot volumns.
9. tar the volumns to tape along with the archived log files.
This provides us the a hot backup that is fully recoverable (I know as I've had to use it) on a daily basis. The entire process is controlled from a cron script that calls the other scripts to perform the work. The scripts are dynamic so when additional tablespaces are added to databases, all tablespaces are accounted for in the backup. Between the various databases, developer dumps and the executables, we backup approximately 350 Gbytes of disk nightly via this routine. And it's a simple matter to add additional databases and volumns to the process.
If I understand the vernacular correctly, silvering is creating a mirror of a volumn, and resilvering is recreating the mirror of the volumn. I think the two are interchangable here. If you are running a server with RAID 1+0, you have striped mirrors for data redundency. To resilver a mirror means to rebuild the mirror for the stripe. Hope this makes sense.