Backup Isn’t Disaster Recovery: The Gap Malaysian Firms Miss

Backup vs disaster recovery is not a wording argument. Backup protects data, disaster recovery restores a working service, and organisations that have funded the first while assuming they bought the second only find out during an incident.

This guide sets out what each one actually delivers, the gaps that turn a healthy backup regime into a multi-day outage, what Bank Negara Malaysia requires of regulated institutions on recovery testing, and a seven-step check you can run against your own environment this week.

What Backup Does, and What It Does Not

Backup is the practice of keeping additional copies of data so that a copy survives when the original is lost, corrupted or encrypted. A backup regime is measured on whether the copy exists, whether it is readable, and how far back it reaches.

What it does not do is put a service back in front of users. A backup does not include the servers to restore onto, the network path to reach them, the operating systems and licences they need, the configuration that makes the application work, or the sequence in which everything has to come up. Those are separate purchases, separate decisions, and separate documents.

The practical consequence: an organisation with clean, verified backups and nowhere to restore them is looking at days, not hours. The restore itself is often the shortest part of the job.

Backup vs Disaster Recovery: The Difference in Practice

Backup is a component of disaster recovery. It is the input. The rest of disaster recovery is everything that turns that input back into a service.

6 Gaps That Turn a Backup Into an Outage

1. There is a backup window but no recovery time objective. The organisation knows backups run nightly. Nobody has agreed how long the business can be down, so no one has ever tested whether the current arrangement can meet it. The backup schedule answers a question about data loss, not about downtime.

2. There is nowhere to restore onto. No standby servers, no reserved cloud capacity, no network connectivity to the recovery location, and no spare licences. Hardware procurement in the middle of an incident is measured in weeks.

3. Restores are tested at file level and assumed at system level. Retrieving a spreadsheet proves the media is readable. It proves nothing about restoring a database cluster with its dependencies, in order, at production volume, under time pressure, using staff who have not done it before.

4. The backups sit where the production systems can reach them. Ransomware encrypts what it can reach, including network shares and connected backup targets. A copy that is offline, immutable, or held at a separate facility is the copy that survives. A second copy in the same building also shares that building’s fire, flood and power risk.

5. The dependencies were never documented. Directory services, DNS, certificates, integration keys, third-party connections, batch schedules and the person who knows the start-up order. Applications do not restore in isolation, and the missing item is rarely the data.

6. Retention is shorter than the problem. Ransomware and logical corruption are frequently present long before anyone notices, so a fourteen-day retention window can mean every surviving copy already contains the damage. Retention has to be set against how long a problem can go undetected, not against how much storage was budgeted.

An organisation that closes these gaps has moved from a backup regime to a recovery capability. That work sits inside a wider business continuity plan, which also covers the people and premises the systems serve.

What Bank Negara Malaysia Requires on Recovery Testing

For regulated institutions the distinction is settled in policy, and the requirements are specific enough that a backup regime cannot satisfy them.

Bank Negara Malaysia’s policy document on Business Continuity Management, issued on 19 December 2022, requires a disaster recovery plan alongside the business continuity plan and the crisis management plan. Each is tested at least annually, and the disaster recovery plan is tested for all critical application systems.

The testing requirements in paragraph 9.48, which took effect on 19 December 2025, set the bar that separates a real recovery capability from a documented intention:

• A live run conducted on a business day at recent peak load and volume, not a quiet Sunday with a sample dataset.
• A scenario of at least three consecutive business days operating from the recovery site, which tests capacity and staffing rather than the moment of failover.
• Any failed live run re-tested within a year of the failure.

The same policy requires the recovery site to be far enough from the primary site to avoid the same disruption, and to draw on a separate telecommunications network and power grid. It also requires contracts with key service providers to carry recovery objectives aligned to the institution’s own, with participation in integrated testing.

Two obligations apply outside the financial sector as well. Personal data in a backup copy remains subject to PDPA obligations wherever that copy is held, including at a third-party facility. And organisations whose customers are regulated will be assessed against these expectations during third-party reviews, whichever industry they are in.

Where the 3-2-1 Rule Stops

The familiar guidance is three copies of the data, on two different media, with one copy held off-site. Newer versions add an offline or immutable copy and a requirement that restores be verified with zero errors.

It is sound advice, and it addresses exactly one risk: losing every copy of the data. It says nothing about how long the business is down while those copies are turned back into a service, which is the question the board will ask. Treat 3-2-1 as the floor for data survival, then set a recovery time objective separately and build to it.

How to Test Whether You Have Disaster Recovery or Just Backup

Seven checks. Each one has a documented answer or it does not, and the ones without answers are the gaps.

1. Name the recovery time objective for your three most critical systems. If the answer is a backup frequency, the objective has not been set.

2. Point to the infrastructure those systems would recover onto. A contract, a reserved capacity agreement, or a rack in a second facility. An intention to procure is not an answer.

3. Produce the date of the last full system restore, not a file restore. Include what was recovered, how long it took, and who ran it.

4. Compare that duration against the recovery time objective from check 1. A gap here is the finding that matters most, and it is usually the one nobody has written down.

5. Show where the off-site copy is held and how it is transported or transmitted. Confirm it cannot be reached and encrypted from the production network.

6. Open the runbook and follow the first ten steps on paper. Check that the names, addresses, credentials process and contact numbers are current, and that the start-up order is recorded rather than remembered.

7. Identify who declares a disaster, and how they are contacted at 3am on a public holiday. Recovery time starts when the decision is made, not when the incident begins.

An organisation that can answer all seven has disaster recovery. An organisation that answers the first, fifth and sixth has a good backup regime and an untested assumption.

Where Strateq Fits

Strateq began providing commercial disaster recovery services in Malaysia in 1989, and has run its own data centres here since.

The recovery layer that backup does not cover is the part it operates: warm-site facilities housing a range of platforms and systems, each equipped with the peripherals a full recovery needs, so a declared disaster has somewhere to land. Its system engineers work around the clock through testing, simulation and live recovery operations, which is when the runbook gaps in check 6 tend to surface.

For the copies themselves, Strateq provides off-site storage for client media and documents in lockable metal boxes within a secured, air-conditioned facility under 24-hour surveillance, along with media transportation between customer sites and the facility. Work-area recovery for business continuity sits alongside it, so the staff who operate the recovered systems have equipped space to work from.

Run the seven checks against your own environment, and bring the ones you cannot answer to Strateq’s disaster recovery team.