Ask whoever looks after your website how quickly they could put it back after an attack, and you will almost certainly get an answer about backups. How often they run, how long they are kept, where they are stored. All useful, and none of it an answer to the question you asked.
The question you asked is: if the site goes down badly tomorrow morning, when is it selling again? That number has a name, it is worth knowing, and almost nobody in this industry will tell you theirs.
The number you are given is about backups, not about recovery
There is a reason for the substitution. Backup frequency is a setting. Recovery time is a promise, and it depends on things your provider does not control — how big your site is, how it is hosted, whether the last clean copy is actually clean, and how long it takes someone to notice something is wrong at 2am on a Saturday.
So the industry talks about capture instead. Kinsta runs automatic daily backups and sells add-ons at every six hours for $20 a month per site, or hourly for $100. WP Engine keeps backups for “no less than 30 days and no longer than 60 days.” SiteGround offers “up to 30 daily backup copies” on shared hosting. GoDaddy’s cPanel hosting comes with “an automatic 1-day daily backup.”
Every one of those describes how often your data is photographed. Not one describes how fast your business comes back.
What the hosts actually commit to
Two of the large managed hosts do say something about restore duration, and it is worth reading closely because they are being honest.
Kinsta, on restoring from a backup: “Depending on how large your site is, this may take a couple of minutes.”
WP Engine, on the same operation: “The automated restore process can take anywhere from a few minutes to several hours. This largely depends on the size of your site and the number of files.”
Those are not contradictions. They are the same statement at different levels of candour, and both describe the easy case — pushing a known-good copy back over a site that is merely broken. Neither is a commitment, and neither appears in a service level agreement. The uptime percentages the hosts do put in writing, usually 99.9% or 99.99%, are about availability, and pay out in service credits.
The maintenance and security companies look different, and are not. Sucuri publishes a response ladder tied to price: 30 hours on its entry plan, 12 on the next, 6 on business, 4 on custom. FixRunner guarantees “a one-hour response time for all requests.” Wordfence sells a one-hour response and a 24-hour time to resolution. MalCare publishes expert response times from 72 hours down to 6.
Read those again. Every one is a clock that starts when you ask for help and stops when somebody answers. That is a response time: it tells you when a person will look at your problem, not when your website will be working.
Two numbers worth writing down
The people who plan for this properly use two numbers, and they come from a standard rather than a marketing page. The US National Institute of Standards and Technology defines both in its contingency planning guidance.
Your recovery time objective is “the overall length of time an information system’s components can be in the recovery phase before negatively impacting the organization’s mission or mission/business processes” — how long you can be down before the damage stops being technical and starts being commercial.
Your recovery point objective is “the point in time to which data must be recovered after an outage” — how much recent work you can afford to lose.
The second one is where daily backups quietly fail people. A daily backup means a recovery point objective of 24 hours — a full working day of orders, form submissions and content, simply gone. Nobody presents it that way, because “daily backups” sounds like diligence and “we may lose a day of your orders” does not.
Work out your own two numbers before asking anyone else for theirs. It takes about ten minutes, and it changes the conversation: you stop asking whether backups exist and start asking whether what you pay for meets a figure you set.
A restore is not a recovery
This is the distinction that costs companies the most money, and the reason the honest answer to “how fast can you restore my site” is sometimes “restoring it is the wrong move.”
If your site simply broke — a bad plugin update, a failed migration, a developer’s mistake — restoring a backup is exactly right, and the few-minutes-to-several-hours estimate is roughly what to expect.
If your site was compromised, restoring a backup puts the site back and puts the vulnerability back with it, usually along with whatever access the intruder still holds. It also overwrites the evidence — the file timestamps, the logs, the modification history that would have told you how they got in and what they reached. Restore first and you have bought a working website that will be compromised again, and no way to explain to an insurer, an auditor or a customer what happened.
That is why recovery after an incident is measured in days rather than minutes. You preserve the evidence, find the entry point, clean or rebuild, close the hole, then bring it back. Sophos’s State of Ransomware 2025, a survey of 3,400 IT and cybersecurity leaders across 17 countries, found 16% of affected organizations fully recovered within a day and 53% within a week — which also means nearly half took longer than a week, and it was three months before 97% were back. Those are organizations with security teams.
What “we can restore your site” leaves behind
If you are on a hosted platform, check what its restore actually covers. The exclusions are published, and they are substantial.
Wix does offer version restore, and documents what does not come back: content in Wix Stores, Wix Blog, Wix Events, Wix Bookings, Wix Video, Wix FAQ, Wix Restaurants and Wix Hotels. Contact details gathered over time, chat history and inbox messages do not revert, and neither do CMS collections or SEO settings.
Squarespace’s export is a migration tool, not a backup, and says so plainly: “It’s not possible to export content from one Squarespace site and import it into another.” Shopify’s documented way of backing up store information is that you export CSV files yourself — the responsibility is the merchant’s, and a CSV export is not a site.
None of this makes those platforms a bad choice. It makes them a choice with a recovery point objective you should know before something goes wrong rather than during it.
Five questions that get you a real answer
Ask whoever is responsible for your site, in writing:
- How long would it take to have this site serving customers again, and is that a target or a commitment?
- How much recent data would we lose — orders, enquiries, content — in a worst-case restore?
- When did you last actually perform a restore of our site, and how long did it take?
- If the site is compromised rather than broken, does the process change?
- Who pays for the recovery?
The third question separates a real arrangement from a hopeful one. A backup nobody has ever restored is a theory.
What we tell people who ask us
We publish our figure because so few people do. For a compromised site, our recent WordPress recoveries — cleaning, rebuilding, and moving the site onto secure hosting — have taken five to eight days. That is not a guarantee dressed up as a number; it is what the work has actually taken, and a rebuild after a serious compromise is a different job from pushing a backup back into place.
We also work the question the other way round: investigate first, restore second, and hand over a written report covering the entry point, the timeline, what was reached and what changed — the document an insurer or an auditor asks for and almost nobody produces. And on an active web management plan, if a site we look after is compromised or goes down, we fix it at no extra cost, because recovery belongs in the arrangement rather than in an emergency invoice.
If you do not know your own two numbers, start there; you do not need us to work them out. If you do know them and suspect what you are paying for does not meet them, that is worth a conversation.
Sources: NIST SP 800-34 Rev. 1, via the NIST Computer Security Resource Center glossary; Sophos, The State of Ransomware 2025; and the published plans and support documentation of Kinsta, WP Engine, SiteGround, GoDaddy, Sucuri, FixRunner, Wordfence, MalCare, Wix, Squarespace and Shopify, read September 2026.