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.
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.
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.
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.
The impact of snapshot and cloning technology on SAP systems.
A step-by-step guide to Solution Monitoring.