Monthly Backups

[B14speedfreak]

Hi all,

Thanks in advance for any posts and for reading.

We are currently running Veritas Netbackup 5.1 with the Oracle Plugin on Solaris Boxes (v8), most systems are at least 9.something version of Oracle. Essentially we use an RMAN backup script which runs the full backups and archive log backups, we also run file system backups as well. All of these go straight to tape via a single channel. One of the systems is about 1/2 terbyte in size, which takes a bit of time to go to tape.

We have been asked to look into doing monthly backups, where by we can have a full monthly backup of all the changes made on our systems. The really important thing is that we must be able to restore from tape to any time in that month.

Basically my question is, is anyone currently doing monthly backups for Oracle Databases and how are you going about them? Also are there any pitfalls or suggestions anyone can make? Is is possible to validate that these backups could restore the database back to any point in time in the month?

Thanks again in advance for reading and any posts,

B14... aka.. marky mark...

 

[LKBrwnDBA]

1) Try adding two more channels
2) Do Weekly FULL backups +
3) Daily Cummulative Incremental backups + Archive Log backups.



----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[KenCunningham]

I would say that a monthly backup is too infrequent, but if you are forced to go that route, probably your best option is to carry out the backup, then make sure that all of the archive logs created during the month are available to you so that you can, if necessary, do a point in time restore from your original backup plus the necessary archive logs.

 

[B14speedfreak]

Hi all,

Thanks for the replays.

The main problem with the first response is that surely we would not be able to go back to any point in the month, if we do a full backup every week? Also since the backup goes straight to tape, allocating another channel isn't going to make difference to speed is it?

The second response sounds reasonable, however I see your point about it not being ideal, since any restores would take ages to do (since you would have to make sure the correct archive logs are applied).

Having talked to my boss a bit, I think the idea is to have a single tape to produce a monthly backup. But then to do weekly backups as well (for improved restores). I think the idea is that if we needed to go back to a certain month or day we could do. I am guessing that its for auditing purposes.

Have any of you guys got experence of a UFS dump? Apparently we used to do them for full backups.

Thanks again,

B14... aka... marky mark...

 

[LKBrwnDBA]

With RMAN backups using catalog you can restore to any point in time as long as you have the backup files available: Full+Cummulative+Archive.

Unless you backing-up to ONE tape unit, you can have several channels (one for each tape channel).



----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[B14speedfreak]

Thanks for the replay,

Yeah I mean you see, on most of the servers we only have one tape drive (IE only tape at a time can be loaded (currently)).

But your saying that even though we currently do full weekly backups, provided that we still have the tapes (IE they are not over written) we should be able to restore back to any point in time?

Thanks for the replay...

B14... aka... Marky Mark...

 

[KenCunningham]

...as long as you have the archive logs from the time of the last backup, yes. By 'UFS dump', I assume you mean ufsdump itself? I have found this method very reliable on Solaris, though we have used it only for cold backups. Not sure if it can be used for the hot variety.

 

[LKBrwnDBA]

Yes, with RMAN you can restore at any point in time as long as you have the backup files, and using an RMAN catalog will greatly simplify the task.

If you have enough disk space, keep the last weekly + last cummulative + last archive logs on disk.

For example; backup to disk using 3 or 4 channels, then copy backup files to tape;

Another option is to backup by tablespace, for example:

Monday -> System, Sysaux, Other small ones...
Tuesday -> Data_01
Wednesday -> Index_01, Index_02
Thursday -> Data_02
Etc...
Daily -> Archive logs.





----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[B14speedfreak]

Hi all,

Thanks for the replays they are all very useful, and your all definately giving me some ideas.

Yeah we use a catalog at the momement, we have a seperate database for this.

We used to do UFSDUMP but as you say it was cold, the system was down when we did it. Theres a bit of debate about weather we could put the instances into hotbackup mode.

Don't think we could go down the route of backing up individual table spaces one day at a time, simply because, as per every Oracle database these days, we are after high availablity (we are planning to move to RAC on most (if not all) of our systems), this applies to the restores and backups as well though. As per usual, they want everything, quick backup times, quick restore times. So whilst the idea of backuping individual tablespace to disk then tape first reduces the loads on the systems, the restore times will be a lot slower, which is something that we are not really willing to live with.

I think that essentially it boils down to the fact that we are going to need to use a lot more tapes. I guess to try and reduce the impact on the databases we could go to disk first then to tape, however this will mean a lot more network activity, and disk io activity.

I think I am going to require a bit more clarification from my Boss first before I propose anything.

Thanks again for all the replay they are very useful...

B14... aka... marky mark...

 

[LKBrwnDBA]

Just a remider: RMAN backups do not need either a database shutdown or any type of 'downtime'.

Cheers,


----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[B14speedfreak]

Yeah thats true...

I mean to be honest I don't think we would go down the route of shutting down the databases, simply because they are too import for the business operationally and the data is very important thats contained within them... hence why I am asking you guys!

Thanks again for all the replays they are very very useful,

B14... aka... marky mark...