Re: Incrementally Updated Backups (RMAN)

From: Kumar Madduri <ksmadduri_at_gmail.com>
Date: Tue, 21 Jan 2014 06:12:27 -0800
Message-ID: <CAHDOOG7FMoSi7yNrWfXQLPMNgDS71w3L3Q4gHjGJL1_PGuiPcg_at_mail.gmail.com>



Harmandeep;
I understand all of that. I was looking for more real world experiences if any related to incremental updated backups (where I would have in reality only one full backup at the end of the backup cycle as opposed to multiple copies if I go with full backup)
  • Kumar

On Tue, Jan 21, 2014 at 5:49 AM, Harmandeep Singh <singh.bedi_at_gmail.com>wrote:

> 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_at_gmail.com>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
>>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 21 2014 - 15:12:27 CET

Original text of this message