Introduction
Many organizations believe: “Our data is in the cloud, so it is safe — we don’t need backups.” This is one of the most dangerous mistakes you can make.
The cloud protects you from hardware failure — a broken disk, fire in a data center, or power outage. But it does not protect you from:
- Accidental deletion by your own staff
- Ransomware that encrypts or erases your files
- Misconfiguration that wipes entire databases
- Malicious insiders or stolen credentials
- Regional service outages that last for hours or days
According to Gartner 2026:
- 45% of cloud businesses have lost critical data in the last two years
- 70% of small companies that suffer a major data loss close within 12 months
- Ransomware attacks now specifically target backup systems first to remove your last option to recover
- Under UU PDP Article 16, you are required to have procedures to restore data after an incident — backups are the only way to meet this rule
Backup is making extra copies of your data so you don’t lose it. Disaster Recovery (DR) is your full plan for how to get your whole business running again when the worst happens. This guide explains exactly what rules to follow, how to test your plans, and how to avoid losing everything even if your main systems are completely destroyed.
The Golden Rule: The 3-2-1-1-0 Backup Strategy
This is the global standard used by governments and banks — never deviate from this:
- 3 copies of your data total
- 2 different types of storage or media
- 1 copy kept offsite (in a different region or separate account)
- 1 copy immutable (cannot be changed or deleted by anyone, including you)
- 0 errors — verified by regular test restores
If you follow only this rule, you will survive almost any disaster.
Key Metrics You Must Define Before Building
You cannot design a recovery plan without knowing these two numbers:
- RPO – Recovery Point Objective: How much data can you afford to lose?
- Example: 15 minutes = backups run every 15 minutes — you lose at most 15 minutes of work
- RTO – Recovery Time Objective: How long can your business stop working?
- Example: 4 hours = systems must be fully operational within 4 hours of failure
Common settings by business type:
- Critical services (payments, health): RPO 5–15 mins / RTO 1–4 hours
- Standard operations: RPO 1–24 hours / RTO 8–24 hours
- Archives: RPO 1–7 days / RTO up to 1 week
The 4 Levels of Disaster Recovery
Choose the level that matches your risk — higher levels cost more but give faster protection:
Table
| DR Level | Description | Cost | Typical Downtime | Best For |
|---|---|---|---|---|
| Level 1: Backup & Restore | Save copies; rebuild from scratch if needed | Lowest | 1–3 days | Small teams, non-critical data |
| Level 2: Pilot Light | Keep minimal core systems running; scale up during crisis | Medium | 4–24 hours | Standard business operations |
| Level 3: Warm Standby | Full duplicate environment running at low capacity | High | 1–4 hours | Customer-facing services |
| Level 4: Multi-Site / Active-Active | Two identical live systems in separate regions | Highest | Seconds to minutes | Financial, emergency, 24/7 services |
Core Backup & Recovery Controls
This is the single main table in this guide — it covers every critical requirement:
Table
| Control | Mandatory Standard | Why It Is Critical | Common Failure Point |
|---|---|---|---|
| Separate Account/Region | Backups never live in the same account or region as live data | Survives total account compromise or regional outage | Attacks delete backups alongside live data |
| Immutability | Lock backups for minimum 30–90 days; no one can delete/modify | Ransomware cannot erase your last resort | Standard storage gets encrypted or wiped |
| Encryption | Separate keys for backups; not shared with production | Breach in main system does not expose backup keys | Keys stored together unlock everything |
| Regular Testing | Restore test files monthly; full DR simulation quarterly | Plans that are never tested often fail when needed | Backups exist but are corrupted or unusable |
| Versioning | Keep deleted or changed files for minimum 90 days | Recover from accidental overwrites or mistakes | Old versions get removed automatically |
| Access Rights | Only emergency recovery team can access backups; no daily access | Attackers cannot reach backup storage even if they steal admin rights | Same broad permissions used for everything |
| Retention Policy | Match compliance needs; keep legal records long-term | Meet audit requirements; recover older data if needed | Deleting too early causes compliance failure |
Step-by-Step Implementation Plan
Build your protection in this exact order:
Phase 1: Assess & Classify (Weeks 1–2)
- Map All Data: List databases, files, configurations, and user uploads — do not miss anything
- Classify Criticality: Decide RPO and RTO for each system
- Remove Unnecessary Data: Delete what you don’t need — less data means faster, cheaper recovery
Phase 2: Build Backup Protection (Weeks 3–5)
- Enable Native Backups: Use built-in tools like AWS Backup, Azure Recovery Services, Google Cloud Backup — they integrate securely
- Enforce Immutability: Turn on object lock or write-only permissions — this is your strongest defense against ransomware
- Cross-Region Replication: Automatically copy backups to a completely different geographic area
- Lock Down Access: Create a dedicated recovery group — remove all backup rights from daily admins
Phase 3: Design Your Disaster Plan (Months 2–3)
- Write Clear Procedures: Step-by-step guides for “What if the main region fails?” / “What if we get hit by ransomware?”
- Define Roles: Who declares a disaster? Who restores data? Who communicates with staff and customers?
- Prepare Templates: Pre-configure network settings, permissions, and installation scripts so you don’t have to guess during a crisis
- Document Everything: Store copies of the plan offline and outside your cloud environment
Phase 4: Test & Improve (Ongoing)
This is the step 90% of organizations skip:
- Monthly Test: Restore a random file or database table — confirm it works
- Quarterly Simulation: Pretend your main system is dead — run through your recovery process completely
- Update After Changes: Every time you add new software or change workflows, update your backup plan
- Learn From Tests: If something takes longer than your RTO, fix it before a real emergency happens
Common Mistakes That Destroy Recovery
1. Backups in the Same Place
If your backups live in the same account or region as your live data, an attacker or outage can destroy everything at once.
2. No Immutability
Ransomware groups now search for and delete backups before encrypting your systems. If you can delete your backups — so can they.
3. “We’ll Figure It Out When It Happens”
During a disaster, stress is high and time is short. You will forget passwords, miss settings, and make mistakes — write it down now.
4. Testing Only Restoring Files
Restoring a database is not the same as restoring an entire business. Test network connections, permissions, integrations, and payment flows too.
5. Forgetting Configuration
Backing up files is useless if you don’t have the firewall rules, encryption keys, and server settings to run them again.
Real-World Example
A Jakarta retail platform used daily backups stored in the same region. When an attacker stole an admin account, they deleted all backups then encrypted the live database. The business was down for 11 days while they rebuilt from scratch and lost millions in sales.
After recovery:
- Moved backups to a separate account in a different country
- Enabled 90-day immutable locking
- Wrote a full DR plan and ran quarterly tests
- Restored access rights so only two people could touch backups
Result: Six months later, a misconfiguration deleted their main database. They restored fully in 3 hours with zero permanent data loss.
Conclusion
Backups are not an “extra” — they are your insurance policy for the cloud. All the encryption, firewalls, and IAM rules mean nothing if you have no way to recover after something goes wrong.
Start today by checking where your backups are stored, enabling immutability, and running your first test restore. These small steps will give you the confidence that no matter what happens, your business can keep going.