How to Build Backup and Disaster Recovery: From RPO/RTO Targets to Immutable Offsite Copies and Restore Drills (Three Budget Tiers and a 90-Day Roadmap)

Halfway through the restore, the backup file turned out to be 0 KB

An industrial-parts trading company lost a server disk on a Friday night. Their IT vendor said there were daily backups, so no need to worry. During the actual restore they discovered the scheduled job had not completed successfully since the server was migrated three months earlier, the last complete backup was 97 days old, and nobody had ever received a failure alert. They rebuilt quotes and stock levels by hand from shipping notes and spreadsheets. It took 11 days and cost an estimated NT$1.8 million. The question was never whether backups exist. It is when the last successful restore happened and how long it took. Most SMEs cannot answer the second part.

When it fits, and when it does not

Invest now if

• Core operations run on a self-hosted box or a single cloud VM (ERP, inventory, web orders) and one day of downtime stops shipping
• The database is over 5 GB with hundreds of daily transactions that cannot realistically be re-keyed
• You have already been hit once by ransomware or accidental deletion, or customers and auditors are now asking for documented backup and recovery procedures
• The system was built by a departed employee or a vendor whose contract has ended, and nobody can say which machine or account the backups run under
• Website, admin panel, file server and customer-service logs are spread across three or more different providers

Do not spend this money yet if

• Everything runs on SaaS and you have individually confirmed each provider's retention policy and export path is sufficient
• Your data is under 1 GB and rarely changes, so one weekly encrypted export already covers the risk
• You have not yet inventoried which data you cannot afford to lose. Spend three days on the inventory first, do not buy tools first
• Nobody is willing to own alert monitoring and drills. A backup nobody watches is just a different flavour of false comfort

Alternatives matrix: choosing between four approaches

The decision comes down to two questions: how much data can you lose and still operate (RPO), and how long can you be down and still operate (RTO). RPO of 24 hours with an RTO of 3 days means A or B is enough. RPO of 1 hour with an RTO of 4 hours means you need D. The AWS disaster recovery whitepaper names these four tiers backup and restore, pilot light, warm standby and multi-site. Each step up roughly doubles the cost.

The full build: eight weeks, six phases

• Week 0 — asset and risk inventory (3–5 days): list every database, file directory, key and third-party account. Deliverables: asset register, an RPO/RTO table per data set, retention-period review. Tools: Google Sheets, Notion.
• Weeks 1–2 — architecture design: decide where the 3-2-1 copies land (three copies, two media types, one offsite) and design key custody and handover. Deliverables: architecture diagram, key custody document. Tools: draw.io, 1Password or AWS KMS.
• Weeks 3–4 — implementation: consistent database backups with Percona XtraBackup or pg_dump, deduplicated encrypted file backups with Restic, then rclone pushes to Cloudflare R2 and Backblaze B2 under two separate accounts. Deliverables: re-runnable scripts and a retention policy.
• Week 5 — immutability and monitoring: enable Object Lock so backups cannot be deleted inside the retention window, even by an administrator. Wire a Healthchecks.io dead-man switch that alerts when a backup fails to report success, delivering to both email and LINE. Deliverable: alert rule table.
• Week 6 — first full restore drill: restore from zero on a clean machine, with a stopwatch running. Deliverables: a runbook with commands, expected duration and named owners, plus a measured RTO.
• Weeks 7–8 — handover and training: two staff members each run the runbook independently. Deliverables: training recording, quarterly drill schedule.

Real cost breakdown, in three tiers

• Entry, NT$120,000–180,000: one system, daily backups, two cloud destinations, basic alerting. Suits databases under 10 GB with an acceptable RTO of 8 hours.
• Standard, NT$220,000–350,000: three to six systems, hourly incrementals, Object Lock immutability, full runbook and quarterly drills. The usual fit for a multi-system SME.
• Advanced, NT$400,000–650,000: adds an offsite standby environment, automated failover scripts, an RTO under 4 hours and quarterly measured failover tests.

• Hidden costs most people forget: object storage fees (Cloudflare R2 standard at US$0.015 per GB-month with zero egress; Backblaze B2 at US$6.95 per TB-month), roughly NT$700 per month for 1 TB across two clouds
• Offsite standby server: NT$1,200–8,000 per month
• Restore drill labour: 8–16 hours per quarter, roughly NT$40,000–80,000 per year of internal cost
• Monitoring and key custody services: NT$300–1,500 per month
• Bulk egress charges when pulling large volumes back out of AWS S3 (official S3 pricing), which only bite on the day of the actual disaster. That is exactly why we default to R2 and B2 for backup targets

What clients imagine versus what actually happens

• Clients imagine the job is done once the schedule is installed. In reality, a backup that has never been restored is not a backup. A meaningful share of first drills fail on permissions, character sets or a missing config file.
• Clients imagine the cloud provider handles backups. In reality, most provider snapshots retain under seven days and live in the same account. If the account is compromised, the snapshots go too.
• Clients imagine restoring takes minutes. In reality, pulling 500 GB back from cold storage, decrypting it and rebuilding indexes commonly measures at 3–6 hours. That is your true RTO.
• Clients imagine spending stops once the build ships. In reality, an undrilled backup quietly dies within six months. System upgrades, expired credentials and full disks all stop it silently.

Common traps and how to avoid them

• Trap 1: backups live on the same box or the same cloud account as production. Fix: the offsite copy must use a different provider under a different account with its own keys.
• Trap 2: nobody reads the success emails, so nobody notices the failures. Fix: switch to a dead-man switch that alerts on the absence of a success signal rather than waiting for a failure message.
• Trap 3: copying the MySQL data directory directly. Fix: take a consistent snapshot with Percona XtraBackup or mysqldump --single-transaction, otherwise indexes come back corrupted.
• Trap 4: uploading unencrypted backups. Fix: encrypt at source (Restic does this by default), store keys in a password manager and name two custodians.
• Trap 5: ransomware encrypts the backups too. Fix: turn on Object Lock and version retention so you have the offline or immutable copy that CISA recommends for small businesses.
• Trap 6: backing up the database but forgetting uploaded files and .env configuration. Fix: tick off the inventory item by item, and include user upload directories, certificates and environment variables in scope.

Success metrics and a 90-day roadmap

• Day 30: backup success rate at or above 99%, mean alert response under 30 minutes, first full restore drill completed with a recorded RTO.
• Day 60: measured RTO cut by at least 30% versus the first drill, file and config coverage brought to 100%, Object Lock verified to actually block deletion.
• Day 90: run an unannounced drill executed from the runbook by someone who did not build the system, review storage cost against retention settings, and put the drill schedule into the annual calendar.
• Three numbers to watch forever: backup success rate, measured RTO, and days since the last successful restore. Past 90 days is a red flag.

Decision checklist: twelve yes/no questions

• ☐ Can you name the date of your last successful restore?
• ☐ Do you know your measured RTO in hours, rather than a guess?
• ☐ Is at least one copy held under a different provider's account?
• ☐ Are backup files encrypted at source?
• ☐ Does a second person hold the encryption keys?
• ☐ Will someone know within an hour if a backup fails to run?
• ☐ Is delete protection (Object Lock) enabled for the retention window?
• ☐ Are user uploads and .env configuration included in scope?
• ☐ Are database backups transactionally consistent?
• ☐ Is there a runbook naming commands and owners?
• ☐ Are drills on the calendar rather than dependent on memory?
• ☐ If the main owner is on leave, can a second person restore alone?

Fewer than eight ticks and your backup is most likely a comfort blanket.

Frequently asked questions

What is the difference between backup and disaster recovery?

Backup means keeping a copy of the data. Disaster recovery means getting the service running again within a defined window. Backups without a runbook and drills are a pile of parts with no assembly instructions. The real cost difference sits in RTO: going from three days to four hours typically moves the budget from around NT$150,000 to NT$400,000 or more.

Does an SME really need an offsite copy? Is a NAS in the office not enough?

A NAS can be the second of your three copies, but it cannot be the only one. Fire, theft, a burst pipe or ransomware moving laterally will take out every copy in the same building at once. An offsite copy on object storage costs under NT$700 per month for 1 TB, which is the highest-value line item in the whole budget.

We already own backup software. Do we need to replan?

Run a restore drill first, then decide. For most companies the problem is not the tool. It is incomplete coverage (uploaded files or config left out), alerts nobody receives, and an RTO that has never been measured. We also take standalone backup health checks and restore drills without rebuilding anything.

How long does the build take, and will it disrupt operations?

The standard tier runs six to eight weeks. Restore drills happen in an isolated environment and never touch production, so no downtime is required. The real client commitment is the week 0 inventory interviews, roughly six to eight hours.

Next step

ScriptWalker's backup and disaster recovery build starts at NT$120,000 and covers asset inventory, RPO/RTO definition, a 3-2-1 immutable backup architecture, alert monitoring and the runbook from your first full restore drill. If you would rather just find out how exposed you are today, we also run a standalone backup health check: we perform an actual restore and hand you a real RTO figure with a gap list.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p