Re: Incrementally Updated Backups (RMAN)
- From: Harmandeep Singh <singh.bedi@xxxxxxxxx>
- To: ksmadduri@xxxxxxxxx
- Date: Tue, 21 Jan 2014 19:19:15 +0530
Backups in RMAN are of two types (1) Full & (2) Incremental
*Full backups *are like cold backups and they take more time. To restore in
this case, we restore from the old backup sets and then RMAN applies the
archived redo logs on top of that. But it takes times as applying redo
changes takes more time
*Incremental backups * are taken with first backup as level 0 backup. It
is, as you mentioned is equal to Full backup(mentioned above)
Further incremental backups(level 1) after 0 level can be taken in 2 modes
(1) Differential <default> (2) Cumulative
Differential backups just take the differential change between last level 0
or 1 and so takes less time and space while backing up but takes more time
to recover
Cumulative backups take the full cumulative change between last level 0 ,
so take more time and space while backup but less time to recover
In your case, with just 500 GB redo generation in 10 days, incremental
with differential seems best, as it saves both time and space at backup
creation level.
For further information, please refer to below
https://youroracledba.wordpress.com/tag/rman-incremental-backups/
Also check the Retention policy before finalizing the backup strategy else,
you might end up with obsolete backup sets and not able to recover
Thanks,
Harmandeep Singh
oraclebits.wordpress.com
On Tue, Jan 21, 2014 at 4:08 PM, Kumar Madduri <ksmadduri@xxxxxxxxx> wrote:
> Hello:
> My understanding is that this seems to be the best combination in the
> sense that it gives me a full backup (at a point in time) plus have the
> advantages of incremental backup.
> In case of incremental backups (differential or cumulative), restore may
> be tricky or not possible depending on non-availability of a backup pieces
> (Of course, catalog db/control file keeps track of backup sets that are
> needed for recovery etc but if the unix sysadmins fail to backup the
> directories holding a particular backupset or dba accidentally deletes a
> backupset then it can be tricky).
> In case of normal compressed backups (full), it gives me warm feeling that
> a backup exists and I can apply archive logs to any point in time to do the
> restore/recovery. But it takes up more time and storage space.
> I find incrementally updated backups to be the combination that gives me
> the best of both worlds (and also would save me time and storage place in
> case of my database that has LOB data in it. The db is 1. 2 TB but only 500
> GB redo is generated at most in 10 days ) with the only following drawback
> - I would have only one good backup (with the default config ML note
> 745798.1) and so if I take backups on Monday 2:00 AM and Tuesday 2:00 AM, I
> would not be able to roll forward fro Monday 2:00 AM to Monday 2 PM (for
> example) on Wednesday. I could only do point in time recovery from time of
> my latest incremental backup. I can do a level 0 backup a different time or
> a full backup but that kind of defeats the purpose of having to save the
> storage space.
> - The other thing is if I use "Recover copy of database until time clause
> sysdate -n" then I would have differential incremental backups till n days
> before recover is applied and I would have the same challenge of trying to
> maintain all the backup pieces till n days (i.e. t he same disadvantage or
> inconvinience of having a incremental backup strategy)
> These are probably actually not disadvantages but the way the program
> works but I call them drawbacks for lack of another word
>
> Are there any other pitfalls that I should be aware of if I want to
> implement this as the only backup strategy i.e no more full backups or
> incremental backups ?
> Is this being implemented in this format else where?
>
> Thank you and apologies for the long winded mail.
>
> - Kumar
>
Other related posts:
