Backup and disaster recovery is the least glamorous part of infrastructure, right up until the morning it is the only thing that matters. Ransomware, a failed migration, a deleted database, a data-centre outage — the difference between an incident and a catastrophe is almost always decided long beforehand, by two numbers and whether anyone ever tested them.
This article sits under the cloud computing pillar and follows on from object, block and file storage — where your backups physically land is part of the design.
RPO and RTO: the two numbers that decide everything
Two objectives, pointing in different directions:
- RPO — recovery point objective: the maximum data loss you can tolerate, expressed as time. An RPO of one hour means that after a failure you can accept losing up to an hour of data. RPO drives how often you back up or replicate.
- RTO — recovery time objective: the maximum downtime you can tolerate. An RTO of four hours means the system must be back within four hours of the disruption. RTO drives how you recover, and how much standby capacity you pay for.
The trap is treating them as an IT preference. They are business decisions: what does an hour of lost orders cost, and what does a day offline cost in revenue, penalties and reputation? Tighter numbers are always achievable — and always more expensive. An RPO near zero means continuous replication; an RTO near zero means running a second environment ready to take over. Most organisations should set different targets for different systems rather than gold-plating everything.
Backup is not disaster recovery
Backup answers "can we get the data back?" Disaster recovery answers "can we keep operating?" — and business continuity, wider still, covers the people and processes around both. You need all three, and they are not substitutes for one another.
Backup done well: 3-2-1 and immutability
The durable rule of thumb is 3-2-1: keep three copies of your data, on two different types of media, with one copy off-site. It long predates the cloud and still holds — the cloud simply makes the off-site copy easy.
Ransomware changed what "a copy" has to mean. Modern attacks deliberately hunt for and encrypt or delete backups first, precisely because the backup is what would otherwise defeat the extortion. The defence is immutability: write-once copies that cannot be altered or deleted for a defined retention period, even by an administrator account. Object storage with object-lock, and air-gapped or logically isolated copies, are how this is done. Encryption of backups, and tightly controlled access to the backup system itself, complete the picture.
DR strategies, from cheap to instant
Recovery approaches form a ladder — the further up you go, the shorter the RTO and the higher the standing cost:
| Strategy | How it works | Typical RTO | Cost |
|---|---|---|---|
| Backup and restore | Restore data onto infrastructure provisioned after the event | Hours to days | Lowest |
| Pilot light | Core services (e.g. databases) kept running small; the rest started on demand | Tens of minutes to hours | Low |
| Warm standby | A scaled-down but functioning copy of the environment, scaled up on failover | Minutes to tens of minutes | Moderate |
| Hot standby / active-active | A full second environment running live, traffic switched or already shared | Seconds to minutes | Highest |
Match the rung to the system, not to the whole estate: a customer-facing transaction system may justify active-active, while an internal reporting tool is perfectly well served by backup and restore. Paying hot-standby prices for everything is how DR budgets get cut entirely at the next review.
An untested backup is not a backup
The single most common failure in this field is discovering — during a real incident — that the backups were incomplete, corrupt, unrestorable, or that nobody knew the procedure. A backup you have never restored is a hypothesis, not a safeguard. Test restores on a schedule, run failover exercises against the actual RTO, document the runbook so it does not live in one person's head, and monitor backup jobs so silent failures surface immediately rather than six months later.
Backup and DR in Singapore
For Singapore's financial institutions, recovery targets are not a matter of preference — they are set by the regulator. The MAS Notice on Technology Risk Management requires a relevant entity to establish a recovery time objective of not more than 4 hours for each critical system, and to ensure that unscheduled downtime for a critical system does not exceed a total of 4 hours in any 12-month period.[1] It also requires the entity to identify its critical systems in the first place, and to validate and document its recovery testing — including how the RTO is validated — at least once every 12 months.
The accompanying Technology Risk Management Guidelines set the wider expectations for resilience, recovery and the oversight of outsourced and third-party providers.[2] If a cloud provider or managed service sits in the recovery path of a critical system, the institution remains accountable for the outcome — which makes the provider's own recovery commitments a due-diligence item, not a footnote.
Beyond finance, two things apply to everyone. Backups containing personal data are still personal data: the PDPA's protection obligation covers them, and its transfer limitation applies to where recovery copies physically land — an off-site copy in another country is a data transfer.[3] And Singapore's dense, well-connected data-centre market makes a genuinely separate second site unusually practical here, whether that is another availability zone, a colocation facility or a regional region-pair.
How to set your targets
A practical sequence that avoids both under-protection and gold-plating:
- Identify your critical systems. Which failures actually stop the business or harm customers? Everything else gets a cheaper tier.
- Set RPO and RTO per system, with the business. Put a cost on an hour of lost data and a day of downtime; the numbers follow from that, not from the tooling.
- Design backups to 3-2-1, with at least one immutable copy that ransomware cannot reach — and encrypt them.
- Pick the DR rung that meets each RTO — restore, pilot light, warm or hot standby — and be honest about what you are paying for.
- Check where copies live. Off-site is required; off-shore is a PDPA transfer question. Decide the region deliberately.
- Test, and test the failover, on a schedule. Document the runbook, monitor backup jobs, and validate the RTO at least annually — as MAS requires of regulated firms and every organisation should expect of itself.
Building backup and DR you can rely on?
Recovery design is where resilience is won or lost. Compare Singapore cloud, data-centre and managed-service partners who design, run and test backup and disaster recovery.
Browse Cloud & Systems Integrators in Singapore
Frequently asked questions
What's the difference between RPO and RTO?
RPO — recovery point objective — is how much data you can afford to lose, measured in time; it drives how often you back up or replicate. RTO — recovery time objective — is how long you can afford to be down; it drives how you recover and how much standby capacity you pay for. Both are business decisions about tolerable loss and downtime, not technical settings, and tighter numbers always cost more.
Isn't a backup the same as disaster recovery?
No, and conflating them is a costly mistake. A backup is a copy of your data you can restore from. Disaster recovery is the ability to keep operating somewhere else after a major failure — systems, networking, configuration and people, not just files. Restoring terabytes onto hardware you have not provisioned will not meet a short RTO, no matter how good the backups are.
What is the 3-2-1 backup rule?
Keep three copies of your data, on two different types of media, with one copy off-site. It predates the cloud and still holds — cloud storage simply makes the off-site copy straightforward. Modern practice adds one more requirement: at least one copy should be immutable, so ransomware cannot encrypt or delete it.
How do we protect backups from ransomware?
Assume the attacker will target the backups first, because modern ransomware does. Use immutable, write-once copies that cannot be altered or deleted for a set retention period even by an administrator — object storage with object-lock, or air-gapped/logically isolated copies. Encrypt backups, tightly control access to the backup system itself, and test restores so you know the clean copy actually works.
What RTO does MAS require in Singapore?
The MAS Notice on Technology Risk Management requires a recovery time objective of not more than 4 hours for each critical system, and that unscheduled downtime for a critical system does not exceed 4 hours in total within any 12-month period. Regulated entities must also identify their critical systems and validate and document recovery testing, including RTO validation, at least once every 12 months.
Do PDPA rules apply to our backups?
Yes. Backups holding personal data are still personal data, so the PDPA's protection obligation applies to how they are secured. The transfer limitation obligation also applies to where copies physically land — sending an off-site backup overseas is a transfer of personal data, and requires the recipient to be bound to comparable protection. Choose backup and DR regions deliberately.
Sources
- Notice on Technology Risk Management (MAS Notice PSN05) — Monetary Authority of Singapore — official checked 2026-09-01
- Technology Risk Management Guidelines — Monetary Authority of Singapore — official checked 2026-09-01
- Overview of the PDPA — Personal Data Protection Commission (PDPC) — official checked 2026-09-01
Related resources
Go deeper on this topic
Knowledge base
Vendor directories
Research cluster
Related analysis
Recent TechDirectory Insights coverage from the same research cluster.