A Backup Is Not a Restore. Most Small Business Owners Find That Out Too Late.

A backup is a file. A restore is the moment your business comes back online. Most hosting plans sell you the first and quietly hope you never need the second.

Reviewing our incident log this morning, I counted three sites we restored from backup in the last fortnight. None were ours. All three were prospective customers ringing in a panic because their previous host could produce a backup file but had no functioning process to put it back where it belonged. Two of them lost an entire trading day waiting for a support ticket to escalate.

That gap between "we have your backup" and "your site is back online" is where small businesses lose money, customers, and search rankings. And almost nobody markets it, because it does not fit on a feature comparison table.

The Question Your Backup System Has Probably Never Answered

When was the last time your backups were restored?

Not tested. Restored. As in: somebody pulled a backup file, fed it into a fresh environment, and verified that the WordPress site rendered, the database connected, the media library survived, and the checkout still worked. If the answer is "never" or "I assume my host does that", you do not have a backup strategy. You have a backup file and a hope. Most backups, as we have written about before, never actually get tested until the moment they are needed.

This is not me being theatrical. The 2024 Veeam Data Protection Trends Report, surveying 1,200 IT leaders across organisations of every size, found that less than a third of companies believe they could recover quickly from even a small attack. Only somewhere between one and three percent of organisations could restore systems within a day. Roughly a third needed up to a week. Around a quarter said up to two weeks. Those are not numbers for unprepared cowboys. Those are organisations with dedicated IT.

A small business owner with one WordPress site and a tab labelled "Backups" in the hosting panel is doing dramatically less than that, and getting dramatically worse outcomes.

What Most Hosts Actually Mean by "Backup"

Read the small print on a typical shared hosting plan and you will see something like "daily backups included". What that usually means in practice:

A copy of your WordPress files and a database dump get written to disk, often on the same physical server as your live site. It runs at some point in the small hours. Whether the job completed successfully is rarely surfaced to the customer. Whether the resulting file is actually usable is almost never tested. And the restore process, when you eventually need it, is a support ticket. You log in, you wait, somebody on a different timezone gets to it eventually, files get moved, the site comes back. Hours later. If you are lucky.

Industry survey data on this is grim. Recent backup-industry research suggests roughly six in ten enterprise backup jobs actually complete successfully, and the proportion of restore attempts that fully deliver the expected data sits somewhere around the same range. Of those who actually experienced data loss, less than half recovered all of their data. Those numbers shift around by sector and methodology, but the headline does not. Backups fail far more often than the marketing copy suggests, and restores fail more often than backups.

If you are a small business owner running a busy WooCommerce site, those are not industry curiosities. They are the odds your business is exposed to every night. Building a defensible position here is what the complete WordPress security and backup playbook for Irish websites is built around.

Restore Time Is the Number That Decides Whether You Survive

Operations teams have a phrase for this: Recovery Time Objective, or RTO. In plain English, RTO is the maximum time you are willing to be offline between something going wrong and the site being usable again. It is not the same as the backup frequency. A site can have hourly backups and a forty-eight-hour RTO if the restore process is slow, manual, or queued behind sixty other tickets.

For most small business owners I speak to, the realistic RTO is whatever they can survive financially. A brochure-only site can probably survive a few hours offline. A lunchtime takeaway running online orders cannot survive the lunchtime rush going to its competitor. Atlassian's incident management research puts the cost-per-minute of downtime for small businesses somewhere in the range of one hundred forty to four hundred and thirty dollars. The exact number is less important than the principle: a site that goes down at 11am Friday and comes back at 5pm Monday has not had a backup problem. It has had a restore problem.

And the restore problem is the one your hosting provider does not want to talk about.

The Day Restore Becomes the Most Important Word in Your Vocabulary

Picture this scenario, because some version of it happens to a small business website almost every week. The site has been running quietly for two years. The owner runs a plugin update that morning while having coffee. By afternoon, customers ring to say the contact form is broken. The owner logs in, sees a database error on the dashboard, panics, and tries the rollback button on the plugin. The rollback half-completes. Now the front of the site is showing a fatal error message. The phone keeps ringing. It is 3pm.

This is the moment when the difference between a hosting plan with backups and a hosting plan with restores becomes visible. With the first, the owner opens a support chat, explains the situation, gets told the on-call engineer will look at it as soon as possible, and waits. The site sits broken. Search engines crawl the error page and start re-indexing it. Customers who tried to fill the contact form go to a competitor. Three hours later somebody finally restores last night's backup, by which time the morning's enquiries are gone for good.

With the second, the owner clicks a button labelled Restore, picks last night's snapshot, and the site is back in roughly the time it takes to make a cup of tea. They lose the morning's plugin change. That is the only loss.

That is the entire delta between a hosting plan that costs six hundred euro a year and a hosting plan that costs sixty.

What a Real Restore Workflow Looks Like

A restore process worth having, in practice, looks like this. The hosting platform takes nightly automatic backups. It also takes safety snapshots immediately before and after sensitive operations like core updates or plugin updates. Every backup is verified at the point of capture, not assumed. The backup files live somewhere other than the production server, because backups on the same disk as the live site are theatre. The restore action is exposed to the customer directly, not buried in a support ticket queue. The customer can pick a specific point in time, not just "yesterday". And the system rolls back any changes that happened since the chosen restore point cleanly, without asking the customer to manually reconstruct the missing pieces.

That is what verified restore actually means. Most hosting plans satisfy two or three of those conditions. Almost none satisfy all of them.

The hosts that do tend to be in the managed WordPress category and tend to charge a multiple of what shared hosting charges. The reason for the price gap is that running a real restore process is expensive: you need verified storage, a restore orchestration layer, exposed UI, monitoring, and an operations team that has actually run restore drills against the platform.

You can have all of that for sixty euro a year, but only because we built it on a stack that is shared across thousands of sites and operated from one Irish data centre with one Irish operations team. The detail of how the Web60 platform delivers verified restore on Irish-sovereign infrastructure is the engineering side of the same answer. That is genuinely the only way the unit economics work.

How Web60 Treats Restore as the Feature, Not the Backup

What this looks like in practice on Web60. Every site gets automatic nightly backups, kept off the production server. The dashboard exposes one-click restore against any of those backups. Every WordPress core update, plugin update, and theme update triggers a pre-update safety snapshot, so if a deploy breaks something, you can roll back to a known-good state captured seconds before the change. You can also take manual on-demand snapshots, which is the move a sensible operator makes before any significant edit.

In practical terms, that means a Galway retailer who breaks their checkout at 4pm on a Saturday is not waiting for a support engineer in Manila to clock on. They click Restore, the staging environment is reset to this morning's snapshot, they verify the checkout works in staging, and they push the staging snapshot to production. Total elapsed time: minutes, not hours.

Sync Reality Check, because honest is the only register that survives contact with reality. A nightly backup is nightly. If you take fifty new orders between the last backup at 2am and the moment something breaks at 6pm, you do not get those fifty orders restored from a backup. You restore the database to 2am and you have lost the day's WooCommerce activity. That is the deal. The alternative is real-time replication, which is a different product at a different price point. For most small business sites, the cost of losing one day of changes once every few years is dramatically lower than the cost of paying for hot replication every month for ever. But know the trade-off.

When the Cheaper Option Genuinely Holds Up

Honest concession, because agitation without it is just a pitch. If you run a brochure site that updates twice a year, where your "data" is a phone number and an opening hours block, and your traffic is twenty visitors a week, the difference between a one-hour restore and a six-hour restore is not material. A standard cheap shared host with daily backups and a slow ticket-based restore is genuinely sufficient for that workload. You do not need verified restore. You need a phone number that points somewhere alive.

The break point is somewhere around the moment your website is doing real work for your business. Taking enquiries that decay if not answered. Taking orders. Booking appointments. Showing live menu information. The minute the site has a job to do during business hours, restore time stops being theoretical and starts being the metric that decides what kind of week you are about to have.

The Restore Drill Worth Running Once

This is the single most useful thing a small business owner can do this quarter. It takes about an hour. You only have to do it once, properly, on whatever hosting platform you are on right now.

How to Run a Restore Drill in Five Steps

Clone production to staging. Use whatever staging facility your host provides. If it does not provide one, that is itself the answer to the drill.

Restore an older backup into staging. Pick a backup from a few days back, not last night's. You want to verify that the older snapshots are usable, not just the most recent one.

Verify the staging site renders end to end. Walk the homepage, a product page, a contact form, the checkout if you have one. Open the database manager and confirm the orders or enquiries from that day are present.

Time the whole thing. From "click restore" to "I am confident the site works", note the actual elapsed minutes. That is your real RTO. It is almost certainly slower than you assumed.

Document the result. One short note saying when you ran the drill, how long it took, and what broke. This document is the difference between a backup strategy and an aspiration.

The first time I ran this exercise on a host I had quietly trusted for years, the restore took four hours and produced a site missing all the images. Would not make that assumption again.

Conclusion

A backup is the easiest hosting feature to advertise and the easiest one to ship without actually building the rest of the system around it. A restore is the part that takes real engineering, real operations, and real accountability for outcomes. The two get sold together as if they were the same thing, and small business owners discover the gap between them at the worst possible moment.

Once you stop treating backups as an end state and start treating restore time as the metric, the conversation about hosting changes. The right question is no longer "do you take backups?" because everyone says yes. The right question is "how long does it take you to restore my site, what happens to data captured since the last backup, and can I run that process myself without ringing you?" That is the question to put to whoever currently hosts your business.

Run the drill. Time it. Decide from there.

Frequently Asked Questions

How often should a small business website be backed up?

For most small business websites, a nightly automatic backup combined with the ability to take a manual on-demand snapshot before any significant change is sufficient. The exception is high-volume eCommerce sites where losing a single trading day's worth of orders would be material. In that case, you want either more frequent automated backups or near-real-time replication, and you should expect to pay more for the infrastructure to support it.

What is the difference between a backup and a snapshot?

In day-to-day language, the terms get used interchangeably. Operationally, a backup is usually a regularly scheduled copy taken on a fixed interval like nightly. A snapshot is usually an on-demand copy taken before a specific risky operation, like a plugin update or a theme switch. Web60 takes both: nightly backups automatically, plus pre-update safety snapshots before any core, plugin, or theme change.

How long should a WordPress restore actually take?

For a typical small business WordPress site of a few gigabytes, a one-click restore on properly engineered managed hosting completes in single-digit minutes. If your host's restore takes hours, the bottleneck is almost never the file size. It is the queueing, the manual steps, and the fact that the restore is gated behind a support ticket rather than exposed as a customer action.

Will I lose data if I restore from a nightly backup?

Yes, you will lose anything that happened on the live site between the backup time and the moment of failure. That is the deal with point-in-time backups. The mitigation is to take an on-demand snapshot before any change you suspect could break things, so the worst case is losing minutes of activity rather than a whole day. Real-time replication is a different product class at a different price point.

Are backups stored on the same server as my website?

On many cheap shared hosts, yes, which is the worst of both worlds. If the server fails, your backups go with the site. Web60 stores backups separately from the production environment so a disk-level failure on one does not affect the other. If you are unsure where your current host stores its backups, that question alone is worth raising with their support team.

Can I take my Web60 backups with me if I leave?

Yes. The backups are your data. You can download them from the dashboard at any time, and our migration team will help you restore them on whatever platform you move to. We do not believe in lock-in. If you leave, we want it to be because something genuinely better came along, not because we made it painful to go.

Sources