Re: diff between incremental and archive backups

  • From: Mladen Gogala <gogala.mladen@xxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Sat, 14 Nov 2015 23:29:23 -0500

On 11/14/2015 07:55 PM, Tim Gorman wrote:

Mladen,

On 11/14/15 16:15, Mladen Gogala wrote:
What is the point in taking incremental backups from the standby database? To mitigate the impact on the production users?
The purpose of physical standbys should be obvious, right? I should also mention that if RTO requirements are strict enough, that not only one standby is recommended? One standby should be kept at the current point-in-time for immediate switchover, while another should be kept with a 24-48 hour lag, for faster point-in-time recoveries? I mean, if RTO is very strict regardless of failure scenario, then what solutions other than replicated standbys exist? So, hopefully we're not getting into a discussion about standbys and so we will just talk about backups?

Agreed. This thread is not about the standbys.


So then I'll turn your question back to you: if you have a physical standby, what is the point in taking backups (incremental or otherwise) from the primary?

There is no point in doing that, none whatsoever. However, this wasn't my question. I suggested doing full backups only, from the standby. The only issue I have is with incremental backups, performing of which I consider a superstitious rite, probably intended for bringing rain. It didn't work in California.


If that was not your point, and instead you're asking why take incrementals (as opposed to fulls) from the standby, again I'll turn the question back to you: what is the point of wasting resources performing full backups when one can perform a far more efficient incremental backup?
The problem with incremental backups is that they increase the time to restore. If you need to do backup, and that is not always the case, then you always need to restore a full backup. So full backup cannot be avoided. Restoring incremental backups can be avoided. And if the backups are proxy backups, taken from some kind of a clone (storage snapshot or replica, standby database), resources are not wasted. Resources are dedicated for taking backups.


Cumulative incremental backups meet halfway on the tradeoff between backups and restores that you've mentioned, and might well satisfy RTO requirements while minimizing resources consumed. Maybe so? Maybe not?

Why take incremental backups at all? You do need to restore them in addition to the full backup. The only reason why taking all full backups was so prohibitively expensive was storage consumption. That is resolved by deduplication.


My position is a bit specific, because I am a high level consultant working for a backup vendor. I usually participate in the creation of the backup strategy.
I'm just a grunt DBA, always have been, always will be.

Tim, you're a consultant, and a darned good one at that. DBA usually has a database to take care of. I don't. Nobody will call me tonight and say that the archive destination is full and that the database is hanging. I will sleep like a baby until 8:30 AM EST tomorrow morning. Nobody will call me tonight and complain that transactions are deadlocked or that there is a performance problem with an application. People were calling me with those or similar complaints for about a quarter of a century, when I was a DBA, responsible for a database. There is no longer a database that I am in charge of. Therefore, I don't consider myself a DBA any more.


I've never felt that it makes sense to start off by discussing "how" (i.e. backups) before you've decided on "what" (i.e. how to recover in event of failure), no matter one's job description.

So, I prefer the term "recovery strategy", because backups are only one mechanism used in recovery.

So do I. The term recovery strategy is something I frequently use. I agree with you completely.


Also, what kind of recovery time do you expect from restoring incremental backups of a multi-TB database?
If failover to a standby doesn't resolve the problem, then the next probable solution is a partial recovery of the affected datafiles or tablespaces. If a partial restore/recovery isn't possible, then there is nothing left but a full restore/recovery. Having blown past two good recovery mechanisms already, I'd be just as concerned with "will it work?" rather than "how long will it take?"
Unfortunately, my clients don't always share your philosophy. I frequently have to prove that I will be able to restore database in the time allotted by the SLA.


And, even with no incrementals, restore of a multi-TB database is not a happy occasion, ever. That is why it is the last resort.
Tim, backups are also used for copying databases to development and test databases. And yes, backups are the solution of the last resort, I definitely agree with you.

--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com

--
//www.freelists.org/webpage/oracle-l


Other related posts: