Does Anyone Actually Have a Website Backup?

You are, on paper and in practice. Large shared hosts describe their backups as a courtesy provided at their own discretion, with no guarantee and no liability for lost data, and they state that keeping copies is the customer's responsibility. Your developer may keep copies as a matter of habit. Habit does not survive a career change.

That sounds like a dodge and mostly it is not. Hosts run backups across shared servers holding thousands of sites. Promising a guaranteed restore for every one of them on an eight dollar a month plan would be a promise nobody could keep, so they hedge in writing and hand the risk back to the account holder.

Which would be fine if anyone read it. What happens instead is that the owner assumes the host has it, the host has already said in writing that the owner has it, and the developer assumes somebody set something up before they arrived. Every party in the chain has a reason to believe this belongs to someone else.

Invenio IT's 2026 roundup of business continuity data cites a U.S. Chamber of Commerce Foundation finding that only 26 percent of companies keep a documented disaster recovery plan, while 94 percent believe they would recover from a disaster.

For a five-page site for a barber shop on Fourth Avenue, a formal recovery plan is overkill. One note with the registrar login, the hosting login, and the location of the file copy does most of what a plan would do, and our breakdown of what hosting actually costs a Tucson small business covers where backup add-ons land on the monthly bill.

Because backup software reports on the job it ran, not on the restore you will eventually need. Veeam's April 2026 resilience report found 90 percent of leaders were confident they could recover inside their own targets, while only 28 percent of organizations hit by ransomware fully recovered all of their affected data.

Average recovery in that same survey came to 72 percent of affected data. Picture what 72 percent of a website looks like. Home page loads, four service pages return errors, gallery shows broken image icons in a neat grid.

Kaseya's writeup on backup testing puts over half of businesses at testing their disaster recovery plan once a year or less, with 33 percent testing infrequently or never at all. Those figures come from organizations that employ IT staff, which a salon in midtown Tucson does not.

Sophos surveyed 3,400 organizations that had been hit by ransomware for its 2025 State of Ransomware report. Only 54 percent used backups to restore their data, the lowest share in six years. Every one of those companies had some kind of backup arrangement in place before the attack.

A test does not need to be elaborate. Restore the backup to a temporary address nobody links to, click through every page, submit the contact form, check that the photos loaded. An hour, once a quarter. Do it on a slow Tuesday.

Days, in most cases. GoDaddy's cPanel web hosting includes a single day of automatic backup history and sells 7, 14 and 30 day windows as a paid upgrade. Retention length decides everything, because website problems get discovered weeks after they start. A form that broke in June is outside every window by August.

Nobody watches their own site. The owner glances at the home page on a phone once a month, and anything past that gets noticed when a customer mentions it. A yard care contractor told us his contact form had been dead since spring, which he learned when a woman said she had sent three messages and then hired somebody else.

Delay is why retention windows fail people. The host still holds yesterday's copy of a site that has been broken for six weeks, which restores you neatly back to broken.

There is a harder version of this. If the hosting account lapses, or the person holding it walks away, the backups go with it, because they were stored on that same account. A server has no redemption period the way an expired domain does. We wrote up a Tucson job where the hosting disappeared along with the domain, and the site had to be reconstructed out of web archive fragments rather than restored.

Price does not track backup quality here either. A four dollar plan and a twenty-five dollar plan can both hold one day, and the expensive one might simply be faster. Ask the question directly: how many days do you keep, and what does it cost to keep more.

It changes the shape of the question. A static site carries no database and no visitor-generated content, so the whole site is plain files kept in version control, where every past version is recorded and any of them can be republished. Losing the hosting or the domain is still a live risk, and version control does nothing at all about either one.

Internet Crafters builds static sites. No CMS, no admin panel, no login for the owner to edit pages with, which sounds like a limitation and quietly removes a whole category of backup problem. Nobody overwrites a page at 11pm and loses the previous version, because content changes come through us and land in the repository as a recorded change with a date on it.

Version control also spreads the copy around. It exists on our machines, in the hosted repository, and in whatever deployment the live site runs from. Losing all of those in the same week takes a stranger sequence of events than losing one ZIP file on one laptop.

Version control holds the site's source and stops there. It does not hold your domain registration, and an expired domain makes the site unreachable no matter how many copies of the files exist. It does not hold your form submissions, which arrive as email and live in your inbox. It does not hold full-resolution originals of the photos you handed us, so keep those somewhere you can find them.

A static site also has less to compromise in the first place, which is a separate benefit worth naming. Fewer moving parts means fewer ways to get quietly modified, though as we covered in what SSL actually does and does not do, no architecture makes anyone immune, which is why the backup is the layer that matters after something has already gone wrong.