Disaster planning for a business that runs on one system

A business continuity web system is the single application — a booking site, a customer portal, an e-commerce store — whose failure stops revenue. Disaster planning means a tested restore path, owned accounts, and a recovery time you have rehearsed, not a folder of backups nobody has opened. One database corruption becomes a full business stoppage without it.

Key Takeaways

• The single point of failure is usually knowledge and account access, not just the server.
• Back up the database first, then uploaded files, configuration, and DNS records — in that order.
• RPO is how much data you can afford to lose; RTO is how long you can be down. Pick both before you pick tools.
• A restore you have not tested in the last 90 days is a hope, not a recovery.
• Restore to staging, verify, then cut over — never restore directly over the live system.
• Own the registrar, hosting, and code repository accounts; do not leave them with one person who could leave.
• Write the runbook so your least technical colleague could restore the system by lunchtime.

What actually counts as "one system" for a business?

The "one system" a business runs on is rarely one server. It is a web application bound to a database, file storage, DNS, email and a payment gateway, usually inside a single hosting account, a single admin login, or a single developer's head. The true single point of failure is whichever of those nobody else can reach.

For a trekking agency in Kathmandu, that one system might be the booking portal that takes reservations and deposits; for a law firm, it is the client portal holding case files. The pattern is the same: revenue, customer records and operations all pass through one application. When it stops, the business does not slow down; it halts. A common mistake we see is treating the application as the only asset, while the registrar, hosting and code repository accounts sit in one person's name. If that person leaves, or the account is compromised, the system is gone even though the code still exists somewhere.

Why does a single-system business fail so hard when it goes down?

Blast radius is the amount of the business a failure takes with it, and a single-system business has a blast radius of one hundred percent. When orders, bookings and customer records all live in one database, a corruption or a hijacked domain takes every revenue channel offline at once. There is no second channel to fall back to, so each hour of downtime is a full stop.

In practice, the first hour is usually lost to panic and phone calls, not to recovery. Someone checks whether the site is "just slow", then whether the hosting provider is down, then whether the SSL certificate expired. Meanwhile orders queue, customers call, and staff sit idle. The cost is not only the lost transactions; it is the support backlog and the trust damage that follows. A business that depends on one system cannot treat downtime as an IT annoyance. It is the same class of risk as a shop losing its only till.

What should you back up first, and what does recoverable actually mean?

Back up the database first, then uploaded files, then configuration and DNS records, in that order for most web systems. "Recoverable" is defined by two numbers: RPO, the maximum data you can afford to lose, and RTO, the maximum downtime you can tolerate. A daily backup with a weekly, untested cron job is not a recovery plan.

For a typical business continuity web system, a real starting point is an automated nightly dump of the database to object storage outside the production host. For Postgres that is a command like pg_dump -Fc; for MySQL it is mysqldump. But the dump itself is only the first half. The second half is proving you can restore it.

pg_dump -Fc mydb > backup_$(date +%F).dump

This writes a compressed, restorable copy of the database. It does nothing for your files, your DNS zone, or your admin credentials. And a dump that has never been restored is unproven — corruption in the file, a missing table, or a wrong flag only shows up when you try to load it. A restore you have not run is a hope, not a recovery. Check the current documentation for your database version before relying on any single flag.

When do you actually need a full disaster recovery plan instead of a simple backup?

You need a written runbook when the system processes revenue, holds customer data, or is the only sales channel. A simple backup is enough for a blog that can be down for a day. The test is blunt: if the system vanished tonight, could your least technical colleague restore it by lunchtime without calling the person who built it? If not, it is a disaster recovery problem.

That test forces the right conversation. It is not about buying a standby server or a fancier backup tool first. It is about documenting where everything lives, who can log in, and what order to restore in. The simpler option often wins: a well-documented manual restore beats an automated failover nobody understands. A hosting tier also matters here. A business site still on a single shared hosting account carries more risk than one on a VPS or cloud instance with snapshots — the comparison is worth understanding before you plan around it in shared hosting versus VPS versus cloud.

How do you test a recovery without taking the business down?

Restore to a separate environment, never the live one. Spin up a staging copy from the last backup, check that the database opens, files download, and login works, then record the time it took. A restore you have not run in the last ninety days is a hope, not a recovery. Testing quarterly is the minimum that keeps the runbook honest.

The test exposes what the backup missed: a missing environment variable, a hard-coded file path, an expired API key for the payment gateway. Those gaps never appear in the backup log; they only appear when you actually load the data somewhere else. A realistic test also rehearses the human part: who has the SSH key, who can approve a DNS change, who knows the admin password. If the answer is "one person, and they are on holiday", the plan is not done.

What breaks first when the single system dies, and what do you check?

Database corruption, a full disk, an expired SSL certificate, a hijacked or expired domain, an admin lockout after a lost two-factor device, and accidental deletes lead the list. Ransomware and payment gateway outages follow. The diagnostic order is: confirm the scope, check DNS resolution, then check the database and disk before touching the application code.

Each signal rules something out. If the domain does not resolve, the problem is DNS or the registrar, not the app. If the database refuses connections, check disk space and the error log before assuming corruption. If login fails, check whether the admin account still exists and who holds the recovery codes. A common mistake we see is restarting the web server repeatedly while the database has been down the whole time. The fix is cheap when you identify the right layer first; it is expensive when you guess.

What does this cost to get wrong versus get right?

Getting it wrong costs lost revenue for every hour the system is down, plus idle staff, a support backlog, and the engineer time to rebuild from an old or partial backup. Getting it right costs engineer time to automate backups, test restores, and write the runbook, plus ongoing storage for retained copies. Storage cost scales with volume and retention, not linearly with fear.

The expensive part is rarely the backup tool. It is the unrehearsed recovery that turns a two-hour restore into a two-day rebuild, or the lost domain that was never renewed because the reminder went to a leaver's inbox. Most of the cost is operational discipline, not infrastructure. That is where ongoing website maintenance and monitoring pays for itself: someone checks that backups still run, that certificates renew, and that the accounts still work before the failure forces the issue.

A realistic recovery sequence, step by step

This is the runbook shape we use when a single system fails. It assumes the backups exist and the accounts are reachable. If either assumption is false, stop and fix the ownership first — the sequence will not save you otherwise.

1. Declare the incident and notify the one person who knows the system. If that person is unreachable, the plan has already failed. Document this dependency now, not during the outage.
2. Confirm the failure scope. Is it the application, the database, DNS, or the host? Check the domain resolution and the database error log before restarting anything.
3. Put the system into maintenance or read-only mode if the app still responds at all. This stops new writes while you restore, so you do not lose the transactions that arrive mid-recovery.
4. Restore the database to a staging environment first. This is the step that proves the backup is readable. Never restore over the live database until you have verified the copy opens cleanly.
5. Verify data integrity. Check row counts, the latest transaction timestamp, and file checksums. Compare against what the business expects to see.
6. Cut over DNS or redeploy to the restored environment. This is a state-changing step: point the domain at the recovered system only after verification, and keep the old environment untouched until the new one is confirmed stable.
7. Smoke-test the critical path. Run one order, one login, one payment end to end. If the payment gateway rejects the test, the restore is not complete.
8. Run a short post-mortem. What failed, what was not backed up, what should be automated or documented. The goal is a shorter recovery next time, not blame.

Alternatives compared

The right choice depends on downtime tolerance and who has to operate it afterwards. A manual backup is cheap to start but slow to restore. A managed service removes the cron job but not the restore test. A full standby reduces downtime but adds a second environment to patch and pay for.

Option	Typical RPO	Typical RTO	Who operates it	Best for
Manual cron + cloud storage	24 hours	Half a day or more	One technical person	Low-traffic sites that can be down for a day
Managed backup service	Hours	A few hours	Vendor plus your team	Revenue sites with modest downtime tolerance
Tested runbook, no standby	Hours to a day	Two to four hours	Any trained colleague	Small teams that value clarity over automation
Full DR with warm standby	Minutes	Under an hour	Dedicated engineer time	Booking or portal systems where downtime is lost revenue

Where does the code live if the developer disappears?

The source code is the one asset a business can lose without any server failure. If the only copy sits on a developer's laptop or a private repository you cannot access, the business continuity web system plan is incomplete. Source code escrow for a small business is the mechanism that keeps the code accessible if the relationship ends badly.

This is not paranoia; it is the same logic as owning your own domain. The client should hold the registrar login, the hosting account, the DNS control panel, and the code repository access. The developer may operate them day to day, but the business must be able to take over. A handover that depends on goodwill is not a plan.

In short: a business continuity web system is not a product you buy. It is a tested restore path, a set of accounts the business actually owns, and a runbook a non-expert can follow under pressure. Back up the database first, rehearse the restore quarterly, and document who can reach every layer. The simpler option wins until the business proves it needs a standby.

People also search for

• Who should own a business's hosting and domain accounts?
• What does source code escrow actually protect for a small business?
• Shared hosting vs VPS vs cloud — which carries less risk?
• What does a slow or down website actually cost a business?
• How do you keep an online booking system available?
• How should a small business test changes before they go live?

If your business runs on one system and you cannot say who could restore it by lunchtime, that is the first problem to fix. Our team can help you map the single points of failure, own the accounts properly, and build a recovery runbook you have actually tested — talk to us about it or see how we keep business systems running.