Your backup runs like clockwork every day. Snapshots are scheduled automatically, storage capacity is never in short supply. But ask yourself this: if disaster strikes at 2 a.m., how long would it take your system to be back up and running? For most businesses running mission-critical systems on the cloud, the answer is usually... silence.

That's the gap between "having backup" and "having Disaster Recovery." Plenty of organizations invest seriously in backup, yet have never actually verified their real ability to recover.

Backup and Disaster Recovery: two different problems

Backup protects your data. Disaster Recovery (DR) protects your system's ability to keep running after an incident.

These two concepts are often lumped together, but their scope is completely different. Backup creates a copy of your data. DR ensures the entire system, including applications, servers, network configuration, and databases, recovers correctly and comes back online in the right dependency order. This confusion is common for three reasons: cloud snapshots look like a complete DR solution, providers use overlapping terminology, and few businesses actually test their recovery process before an incident happens.

The consequences only surface exactly when you need them least: you open a snapshot but don't have the IAM permissions to restore it; you finish restoring data but the app won't start because a secret key is missing; you recover into the wrong region and the system's components can't connect to each other. This isn't a theoretical risk — these are the most repeated failures in real-world incidents.

The question to ask today, not when disaster strikes: "If a major incident happened right now, how long would it take the system to come back online? And how much data can you afford to lose?"

People also read: What's the Difference between Snapshots, Backups and Replication?

RPO and RTO: putting a number on "critical"

RPO (Recovery Point Objective) is the maximum amount of data you're willing to lose. RTO (Recovery Time Objective) is the maximum time a system can stay down before recovery is complete.

These are operational metrics, not abstract concepts, and they need to be defined per workload, not as a single number applied across the entire system:

Transaction databases, payment systems, core banking: RPO under 15 minutes, RTO under 1 hour
POS, CRM, retail ERP: RPO 15–60 minutes, RTO 2–4 hours
Telesales/call centers, operational CRM systems: RPO 1–4 hours, RTO 4–8 hours
File systems, LMS, internal reporting: RPO 4–24 hours, RTO 8–24 hours

Setting the targets is just the first step. The next step, and the one most often skipped, is testing regularly to prove those numbers actually hold up. A "15-minute" RPO that's never been tested is no different from a number that doesn't exist.

Architecture design: from snapshot to real failover

There are 4 common DR models, with cost and level of automation increasing in this order:

Backup + restore: store backups on a schedule, restore manually when needed. Simple to deploy, low cost, but high RTO — from several hours to several days.
Snapshot-based: take VM/database snapshots more frequently. Better RPO, but restore still requires manual intervention.
Pilot light / warm standby: keep a secondary environment powered off or running at minimum capacity, ready to spin up when needed. RTO ranges from tens of minutes to a few hours.
Active-passive / active-active: two environments run in parallel, failover is nearly instant. Highest cost, but RTO can drop below 5 minutes.

Whichever model you choose, the architecture needs to cover four essentials: a backup vault fully isolated from the production environment, an immutable/lock mechanism, end-to-end encryption, and strict access control so no one can delete backups except in special cases with a full audit log. Object storage is a popular choice for a backup vault thanks to its low cost, flexible capacity, and support for immutable mode.

If your system needs to guarantee data sovereignty in Vietnam, your backup storage region also has to stay in-country — you can't casually replicate data abroad without checking the regulations first.

On cross-region: this is a layer of protection against the risk of an entire data center being affected — whether by natural disaster, a widespread power outage, or a regional network incident. If your primary system is in Hanoi, cross-region backup to Ho Chi Minh City is the minimum you should have.

Defending against ransomware: don't let your backup get encrypted too

Modern ransomware doesn't just attack production data. It goes straight after backups to delete or encrypt them, wiping out your recovery option entirely. According to CNiC Solutions, organizations with intact backups recover within a week in 46% of cases, compared to an overall 2025 rate of 53% recovering fully within a week — up from 35% in 2024. The difference comes down to exactly one thing: whether the backup is still usable.

Two key mechanisms to know:

Immutable backup (WORM/lock retention): once written, no one can modify or delete it during the set retention period. Works for most use cases and is easy to deploy on cloud.
Air-gap backup: a copy fully isolated at the network level from the primary environment, inaccessible via any credential or channel that's already been compromised. NIST SP 800-209 (IS-SS-R8) recommends considering air-gapping for systems that require recovery after a cyberattack.

The 3-2-1-1-0 reference framework is a solid starting point: 3 copies, on 2 different media types, 1 copy off-site, 1 copy immutable or air-gapped, and 0 errors on restore testing. That last part — "0 errors on testing" — is the piece most often skipped, and also the most important.

DR runbook and testing schedule: proving you can actually recover

A DR runbook isn't a document meant to sit in storage. It's a step-by-step playbook — who does what, in what order — written to be used when the system is in an actual crisis.

A proper DR test needs to check at least three things: restoring the correct data version, the system coming back online in the correct dependency order, and verifying data integrity after restore — not just whether "the system came back up."

Suggested testing schedule:

Test type	Frequency	Scope
Tabletop walkthrough	Quarterly	Entire operations team
Technical restore (partial)	Monthly	DB, files, VMs on rotation
Full DR drill	Every 6 months	Tier 1 workloads

The most common failures during testing: restoring to the wrong region, missing IAM permissions, a missing secret or a key vault that won't mount, inconsistent data between the database and storage, mismatched environment configuration. Every test needs to be logged in full, including the actual RTO/RPO measured — this is the only evidence that actually holds weight, both internally and with auditors.

For systems like PostgreSQL on Kubernetes, the failover and restore process needs to be tested separately due to the specifics of leader election and state consistency.

Backup/DR TCO: don't just look at storage pricing

Storage pricing is the most visible part of the cost equation, but it's rarely the biggest. Three components that often get overlooked:

Data egress/replication: the cost of transferring data between regions or out to the internet, typically billed per GB.
Operations and testing costs: engineering time spent running DR drills, maintaining a warm standby environment, and handling alerts.
Downtime costs: one hour of POS downtime for a 300-store retail chain can equal hundreds of millions of VND in lost revenue.

A quick look across 3 RPO scenarios:

Scenario	Target RPO	Target RTO	Relative cost
Basic	24 hours	8 hours	Lowest
Moderate	4 hours	2 hours	Medium (adds replication)
High	15 minutes	30 minutes	High (warm standby + cross-region)

The three most common cost traps: keeping retention periods too long without reviewing them, not enabling deduplication on the backup vault, and failing to forecast data growth — which leads to unexpected budget overruns after 6 months. Check the cloud pricing page to run the numbers against your system's actual capacity.

Criteria for choosing a backup/DR provider in Vietnam and Thailand

Four groups of criteria to evaluate when running systems in Southeast Asia:

Technical: what workload types are supported (VM, database, Kubernetes, file), whether snapshots integrate natively with managed databases, whether immutable/lock mechanisms are available on the backup vault, and whether encryption and key management are end-to-end and properly separated.

Operations: clearly committed recovery SLAs, 24/7 support from a local technical team, and proven experience running DR drills alongside customers.

Region: availability zones in Vietnam (Hanoi, Ho Chi Minh City) and Thailand for in-region cross-region deployment, and low latency for restore operations during an incident.

Compliance and security: granular access control with audit logs, guaranteed data sovereignty so data never leaves the country, and independently verified security certifications.

GreenNode meets all of these criteria with 6 availability zones spanning Hanoi, Ho Chi Minh City, and Bangkok, along with vBackup for data protection and disaster recovery, backed by 24/7 support from a local team of experts. For businesses that need dedicated infrastructure for Vietnam-facing workloads, this is a substantive difference compared to providers hosting infrastructure in Singapore or farther away.

30-day implementation checklist

If you don't have a clear backup/DR strategy yet, here's a practical week-by-week roadmap:

Week 1: inventory every workload, run a preliminary Business Impact Analysis (BIA), and lock in target RPO/RTO for each tier.

Week 2: design the backup vault architecture, configure replication, set up access control on the principle of least privilege, and enable encryption and immutable lock.

Week 3: roll out backup policies for each workload, and build a restore plan and DR runbook for at least one tier 1 workload.

Week 4: run a small-scale pilot DR drill (restore 1 DB + 1 VM into a test environment), measure actual RTO/RPO, summarize the gaps, and plan the next expansion.

30 days won't solve everything, but it's enough to know exactly where you stand — and to have your first real evidence of recovery capability.

Frequently asked questions

Can a backup snapshot replace DR?
No. A snapshot lets you recover data at a single point in time, but it doesn't automatically restore the entire system. You still need a runbook, the correct startup sequence, and full access permissions to bring the system back online.

If hit by ransomware, can you recover from backup?
Yes, if the backup is stored immutably or air-gapped and hasn't been compromised. If the backup shares credentials with production or has no lock retention, an attacker can delete or encrypt the backup before you even notice the incident.

How much cross-region do you need to hit your target RTO?
It depends on the DR model. With cross-region backup + restore, RTO is typically 4–12 hours. With cross-region warm standby, RTO can drop to 30–60 minutes. Only cross-region active-active reaches an RTO under 5 minutes, at a significantly higher cost.

How do you prove your system's actual RTO/RPO?
Run a DR drill and measure real elapsed time. Log everything: when the restore started, when the system came back online, when data validation was completed. This is the only evidence that holds real value, for both your internal team and external auditors.

How long should you keep immutable/air-gapped copies? Does it affect cost?
30–90 days for immutable backups is enough for most cases — long enough to catch ransomware that's dormant before it activates. Keeping it longer increases storage costs. Air-gapping adds operational cost for maintaining a separate copy. Balancing retention period against budget is something you need to revisit periodically, not decide once and forget.

Where to start

Three practical steps to move from "having backup" to "proving you can recover":

Lock in RPO/RTO per specific workload, not a single number applied across the whole system.
Design an architecture with immutable/lock, cross-region if needed, and a backup vault kept separate from production credentials.
Run your first DR test, measure actual timing, and log every gap you find.

If you're running mission-critical systems like POS, CRM, ERP, core banking, or call centers in Vietnam or Thailand and need guidance on backup/DR architecture suited to your actual workloads, get in touch with the GreenNode team to schedule an infrastructure review.

Backup vs. Disaster Recovery on Cloud: How to Design for Uptime