Disaster Recovery & Backup Planning for SMBs

Most businesses believe they have a disaster-recovery plan because they have backups. They are different things, and the gap between them is where companies fail. A backup is a copy of data. A recovery plan is a documented, tested answer to the question of how fast and how completely you resume operating.

The distinction becomes concrete during an incident, when someone asks how long until we are running again and nobody has a number. This is how to build a plan that has one.

What is the difference between backup and disaster recovery?

A backup is a copy of your data. Disaster recovery is the full process of resuming operations — which includes restoring data, but also rebuilding systems, redirecting users, and confirming everything works. You can hold perfect backups and still be down for a week if nobody has planned the rest.

The practical test: if your main server failed right now, how long until staff are working again? If the answer is a guess rather than a tested figure, you have backups and not a recovery plan.

Define RPO and RTO before buying anything

Two numbers drive every other decision. RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time. RTO (Recovery Time Objective) is how long you can afford to be down. Set these per system, from the business side, before evaluating any product.

These numbers are business decisions wearing technical clothing, and they should not be set by IT alone. A retail business that can reconstruct an hour of orders from till rolls has a very different RPO from a clinic whose patient records have no paper equivalent.

Be honest about cost. Every reduction in RPO and RTO costs money, and the curve is steep at the low end — going from 24 hours to 4 is affordable, going from 4 hours to 15 minutes usually is not. The point of setting them explicitly is to spend where it matters and accept longer recovery where it genuinely does not.

Follow the 3-2-1 rule

Keep three copies of your data, on two different types of media, with at least one off-site. The off-site copy is what survives fire, flood, theft, and ransomware that encrypts everything reachable on your network — including the backup drive plugged into the server.

The off-site requirement has become the critical one. Modern ransomware specifically seeks out and encrypts backups before triggering, because operators know that a business with working backups will not pay. A backup that is permanently mounted and network-reachable should be assumed to be compromised alongside everything else.

For Thai businesses, flooding deserves specific consideration. An off-site copy that lives in another building on the same industrial estate is not off-site for flood purposes. Cloud backup to a different region, or physical media rotated to a genuinely separate location, is what the requirement actually means.

Test the restore, and time it

A backup you have never restored from is an assumption, not a safeguard. Schedule restore tests quarterly, time them against your stated RTO, and document the steps clearly enough that someone other than your most senior engineer can follow them under pressure.

Timing the test is the part that gets skipped and the part that produces the useful information. Businesses routinely discover their real recovery time is three to five times their assumption — because the estimate covered copying the data back and ignored rebuilding the operating system, reinstalling applications, reconfiguring the network and validating that it all works.

Write the runbook for the worst realistic case: the person who knows the system is unreachable, and whoever is holding the document has not done this before. If the plan only works when a specific individual is available, it is not a plan — it is a dependency.

• Does the restore procedure work when executed by someone who did not write it?
• How long did the last full test actually take, start to finish?
• Are backups encrypted, and where are the decryption keys kept? (Not only on the system being backed up.)
• Does the plan cover the network, not just the data — DNS, firewall rules, VPN?
• Is there a printed copy accessible when systems are down?
• For PDPA: can you still meet data-subject requests during and after an incident?

The failures we see most often

Four recur: backups that silently stopped running months ago, backups permanently connected to the network, no documented restore procedure, and a plan that covers data but not the systems and network needed to use it.

Silent failure is the most common and the most preventable. Backup jobs stop for mundane reasons — a changed password, a full disk, an expired certificate — and if nobody receives and reads a daily confirmation, the failure surfaces only when you need the backup. Alerting on backup success is a five-minute configuration change that has saved more Thai businesses than any product.