Revising the SAP backup strategy

Some SAP customers stick to a backup strategy that was perfectly valid years ago, yet modern hardware and business demands should prompt a revision of the strategy. This article focuses on an alternate method of devising a sensible backup strategy. While this topic can stand alone, it should ideally be at least influenced by any DR strategy or HA strategy. For example, if a database is real-time replicated to another physical location, the need for frequent backups is somewhat lessened, if not eliminated entirely.

The ‘old’ strategy

SAP’s recommended standard used to be daily backups. EWAs used to red-flag for deviating from this strategy. They seem to have relaxed a little now. Some SAP customers I work with still firmly believe this is the way to go with, for example, daily online backups and a weekly offline backup. It might be the incumbent Basis admin stipulates this, or it’s from years back and “if it ain’t broke don’t fix it”. I want to argue that is an out-dated strategy, long overdue for revision.

Offline backups

The need for offline backups lies in the past; they can be abandoned in favour of full online database backups. There really is no significant advantage in doing an offline backup as long as the archive / transaction logs are well protected and preferably replicated real-time to another location. Additionally, offline backups require actual downtime, a condition that is becoming less and less tolerable for modern, integrated systems.

Less frequent online backups

In the era of horribly unreliable tape systems, frequent backups were about the real risk of not being able to recover from a backup. Now, backup frequency is more about rapid recovery times. Backup frequency should now be based on criteria such as database volatility, system role, special business needs, etc., instead of the commonly-used strategy based entirely on system role (i.e. Dev/QA/Prod).

Determining the backup strategy

Without further delay, let’s get into a model for choosing a backup strategy. A picture can be worth a thousand words; this is no exception.

Database Backups

Filesystem Backups

Is this an oversimplified approach, taking but one page to document? Probably.

The main point is not necessarily that this is the best approach; rather it’s an attempt to get people to break away from the tired old strategy based on system role. I’d be honoured if you as least think about this proposed strategy, but it is still absolutely your responsibility to ensure your strategy is effective.

I made no mention of incremental backups using RMAN or the equivalent tools of other DBMSs. I’d argue the vast majority of databases are small enough to allow full online backups within a reasonable window. I’d welcome any debate on this last point.

That could have been the end of this article, but while on the subject of backups, here are some related points.

The challenge of recover of integrated systems

Recovery to point-of-failure is absolutely crucial. While the business owners of a system might theoretically be able to tolerate some data loss by data re-entry from hard copy documents, this is a concept long out-dated by the massively complex integration between systems. Any recovery to a point-somewhat-before-failure will likely mean partner systems will be affected, sometimes severely. It’s no longer viable to restore all systems to the same point in time since partner systems have other partner systems, often external organisations. This is without doubt the biggest challenge facing integrated business processes. It emphasises the need to absolutely ensure the integrity of the logs via something like real-time replication.

Snapshot technology

Sadly, it seems most companies still don’t have snapshot-capable storage, or the license to use it. Worse, they might have it and fail to see the positive impact it can have on the SAP environment. While snapshot technology does not eliminate the need for backups, it does allow for a greatly reduced recovery time for most failures. In a subsequent article, I’ll expand on the hugely positive impact snapshot and cloning technology has in an SAP environment.

2 Comments

No question about it, the ability of storage systems to take snapshots really fast is a very nice thing that comes in handy, when doing system copies and the like.

Yet, these aren’t backup tools.A backup is meant to be a copy of your data at a _different_ and _safe_ location.This is in no way fulfilled with a storage snapshot.In fact, I’ve spent far too many weekends in SAP support trying to read out data from corrupted tables for customers that relied on the file-system-“backup”.

This leads to the other thing I miss in your blog: you focus on the technology to copy data but you don’t mention the whole rest of the backup management.What about checking the backups?In essence, a unchecked backup is the same as faulty one – think about this!

What about holding up a retention for your backups?Many customers do use backup library management systems, which I don’t see in your graphs.

Last but not least: could you update the decision graphs with some less vague labels than “special need for _rapid_ recovery” or “cost justifiable”?I guess most of your reader, including me, would be _very_ interested in learning what “rapid” means in this context and how you determine if the costs are justifiable.

I should have introduced the article a little better. The focus of the article is limited to a process to determine the frequency and types of backups. Checking the ability to recover from backups, retention periods, tiered media, etc., are all vital to a comprehensive strategy, but the variables make that discussion way too complex for a small blog. I take your point about the vague ‘rapid recovery’ and I’ll deal with this in a new comment.