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?
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?
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.
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?
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?
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.
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.
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.
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?"
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.