A Backup Isn't Enough, Being Able to Restore Is What Saves You

A backup only has value if it can be restored: the right data, within an acceptable time, using a procedure that has been rehearsed. Most small businesses "have a backup" in the sense that a feature is switched on somewhere, but they have never tested a restore, so the day they need it they discover the backup is corrupt, missing the database, or weeks old. This article explains how to measure, how to test, and what level of backup makes sense for business websites and software.

Three true stories (names changed)

A furniture store: a WordPress site with a plugin backing up automatically to Google Drive. The day malware was injected, Drive showed 40 backup files. Every one of them contained the malware, because the plugin kept backing up after the infection and kept no older versions.

A distribution company: inventory software with nightly database backups stored on the same server. The server's disk failed and took the software and the backups with it.

A training center: hosting with a "weekly backup" feature. The restore was needed on a Saturday; the latest copy was from the previous Sunday, six days of course registrations gone. After restoring, the image folder was missing because the backup package only included the database.

All three "had backups". None had ever tested a restore.

The two numbers that decide everything: RPO and RTO

Before talking about methods, you need two metrics to know what you actually need. They are the shared language for working with any operations provider.

RPO (Recovery Point Objective), the maximum acceptable data loss: if you back up every night, your RPO is 24 hours, meaning in the worst case you lose a day of data. A company brochure site can accept an RPO of 7 days. An online store taking orders every hour needs an RPO of a few hours or less for its database.

RTO (Recovery Time Objective), the maximum acceptable recovery time: from the decision to restore until the system is running again. An RTO of 4 hours means replacement infrastructure and a rehearsed procedure must be ready. An RTO of "a few days" means you accept rebuilding from scratch.

Choose RPO and RTO first, then choose the backup method. Doing it the other way round is why many businesses pay for backups that do not fit.

The 3-2-1 rule in plain words

The industry standard, applicable at any scale:

• 3 copies: the live data plus at least 2 backups.
• 2 different kinds of storage: for example the server and a cloud storage service, so one kind failing does not take the other with it.
• 1 copy somewhere else: a different server, provider or region. This is exactly what the distribution company above was missing.

For small business websites and software, the practical version is: automatic daily backups to a storage service independent of the hosting, multiple daily and weekly versions retained, and at least one copy that cannot be deleted or modified from the server (so malware cannot destroy the backup).

What to back up: the list that is usually incomplete

"Website backup" sounds complete but usually misses one of these:

• The database: orders, customers, posts. The most important part, often skipped when only "files" are backed up.
• The uploads folder: product images, documents. Often large, so excluded from default backup packages.
• Source code and configuration: theme, plugins, config files, environment variables, keys for payment gateways and third-party services.
• Domain, DNS and certificates: not files, but the configuration must be documented to rebuild correctly.
• Accounts and permissions: who holds the hosting, domain and code repository accounts. Lose the accounts and there is nowhere to restore the backup to.

For custom software add: supporting services (queues, caches), deployment scripts, and documentation of startup order.

Restore-testing checklist

This is the part most businesses skip and the whole point of this article. Test a restore at least quarterly, monthly for important sites:

1. Pick a random backup from the last week, not the newest one.
2. Restore to an isolated environment (a test server or separate folder), never over the live system.
3. Time it from start until the site opens. Compare with your RTO.
4. Check the newest data in the backup: the last order, the last post. The gap to now is your real RPO.
5. Open the 5 most important pages or functions: home, a product, the cart, login, a report. Do images show, does payment connect.
6. Record the result: date, duration, errors, who did it. This document is what you compare against your operations provider.
7. Fix the procedure if any step failed, then retest within the week.

If steps 1 to 7 have never been done, treat the business as having no backup, even if the feature is switched on.

Sensible backup levels by system type

• Brochure sites and landing pages: daily backups, 30 days retention, RPO 24 hours, RTO 1 business day. Costs almost nothing when done right.
• Online stores: database every 1 to 6 hours, files daily, 30 to 90 days retention, RPO a few hours, RTO 4 to 8 hours.
• Business applications (inventory, sales, CRM): continuous or hourly database backups, 90 days retention, a standby environment for an RTO under 4 hours.
• Mini apps and mobile apps: back up the server side like a business application; for the app itself, keep source code and app store accounts safe.

What Moniro does for customer systems

In website maintenance and custom software maintenance, backups are a fixed line item, not an option:

• Automatic daily backups to storage independent of the hosting, retained daily and weekly, with a copy that cannot be modified or deleted from the server.
• Periodic restore tests in an isolated environment, with results and timings recorded in the monthly report on the service portal.
• When an incident happens, the customer opens a ticket and the operations team restores within the time commitments in the SLA.
• All accounts, domains and source code are owned by the business; Moniro is only authorized to operate them.

That last point matters: the best backup in the world is useless if the business does not own its own assets. The hidden costs of running your own website and software covers the single-person dependency risk in detail.