Most small businesses believe their website is backed up. The hosting plan mentions backups, a plugin sends a cheerful email every night, or a developer once said it was handled. Then something goes wrong, a bad update, a hacked account, a deleted page, and the business discovers that a backup and a working restore are two different things.

A backup is only valuable if it can be turned back into a functioning website within a time the business can tolerate. That means knowing what is copied, where the copies live, who can reach them, and whether anyone has actually tried bringing the site back from them. This guide walks through how to build website backups you can actually restore, and how to run a simple restore test before you need one.

Why a backup you have never restored is only a hope

Backups fail quietly. A job can run every night and still miss the database, skip the uploads folder because it grew too large, or store copies on the same server as the site itself. Credentials for the storage account can expire. A file can be complete but unusable because nobody recorded which software versions it depends on.

None of this is visible until a restore is attempted. That is why guidance aimed at serious incidents keeps returning to testing. The #StopRansomware Guide, published in October 2023 by CISA, the FBI, the NSA and the MS-ISAC, tells organizations to maintain offline, encrypted backups of critical data and to regularly test the availability and integrity of backups in a disaster recovery scenario. It also says to test backup procedures on a regular basis.

Ransomware is only one reason a website might need rescuing, but the logic applies to every failure. If the plan has never been exercised, nobody knows how long it takes, which steps are missing, or whether the copies are even complete.

Know what your website is actually made of

Before choosing tools or schedules, list what would have to come back for the site to work. For a typical content management system, that usually includes:

  • The database, which holds pages, posts, settings, users, orders and form entries.
  • Uploaded media, such as images, PDFs and downloads.
  • Themes, plugins and any custom code.
  • Configuration files and server settings that are not stored in the database.
  • Domain and DNS records, email routing, SSL certificates and third-party connections such as payment gateways, booking tools or analytics.

The last group is often forgotten because it does not live on the web server at all. A business can restore every file perfectly and still be offline because nobody knows the DNS settings or the login for the domain registrar. Record those details and the account owners in a secure place that does not depend on the website being up.

It also helps to note how often each part changes. A brochure site might change monthly, while an online store or booking site changes every few minutes. That difference drives how frequent the backups need to be.

Decide how much you can afford to lose

Two questions turn a vague backup plan into a useful one. First, how much recent work could the business lose without serious harm? If the site takes orders all day, losing a full day of database changes might mean lost orders and confused customers. If the site changes once a month, a weekly copy may be enough.

Second, how long can the site be down? A café menu site might tolerate a day offline. A business that takes bookings or payments through the site may need it back within hours.

The answers determine backup frequency, how many versions to keep, and how quickly the restore process needs to work. Write them down and share them with whoever maintains the site, because a provider cannot meet an expectation nobody stated. Keep older versions as well as recent ones, since a problem such as a compromised account or a corrupted page may not be noticed for days, and the newest copy may already contain it.

Hands in blue sleeves place a black external drive into an open lime green padded case beside a coral notebook.

Keep copies apart from the thing they protect

A backup stored on the same server, under the same login, protects against very little. If the server fails, the account is compromised, or ransomware encrypts everything it can reach, the backup goes with the site.

A long-standing rule of thumb helps here. US-CERT’s Data Backup Options paper describes the 3-2-1 rule: keep three copies of any important file, one primary and two backups; keep the files on two different media types; and store one copy offsite. The paper was written for personal and business data in general, but the principle translates well to websites.

For a small business site, that might look like the live site, a nightly backup held by the host, and a separate copy sent automatically to storage under a different account, with versions kept for a set period. The separate copy should not be deletable using the same credentials that run the website.

The #StopRansomware Guide makes a related point that is easy to miss. It notes that automated cloud backups may not be sufficient on their own, because if files are encrypted or corrupted and then synced, the damaged versions can overwrite good ones. It recommends offline, encrypted backups and also mentions keeping golden images, known-good templates of critical systems that can be redeployed. For a website, a clean copy of the core files, theme and plugins at a known version can serve a similar purpose.

Protect the backups themselves

Backups contain everything an attacker might want: customer details, order histories, user accounts and sometimes configuration files with database passwords. Treat them as sensitive data.

That means encrypting copies stored off the server, limiting who can access the storage account, using strong unique passwords and multi-factor authentication for that account, and removing access when staff or contractors leave. NIST’s Ransomware Risk Management profile, published in February 2022, sums up the priority in a short phrase: back up data, secure backups, and test restoration. It recommends that organizations carefully plan, implement and test a data backup and restoration strategy, and secure and isolate backups of important data.

Isolation matters because many attacks start with stolen credentials. If one compromised password can delete both the site and every copy of it, the backup plan has a single point of failure.

Run a restore test before you need one

A restore test does not have to be dramatic. The goal is to prove that a backup can be turned into a working website, and to learn how long that takes.

A simple test usually follows these steps:

  1. Pick a recent backup and note its date.
  2. Restore it to a separate staging environment or a temporary address, never over the live site.
  3. Check that the home page, key service pages, contact forms, images and downloads all load correctly.
  4. Log in to the admin area and confirm recent content and settings are present.
  5. For a store or booking site, confirm that recent orders or appointments appear and that test transactions behave as expected in a sandbox mode.
  6. Record how long the whole process took, what went wrong, and what had to be looked up.

That last step is the most valuable. A test that took four hours because nobody could find the storage password is a useful finding, not a failure. Fix the gap, update the notes, and test again.

How often to test depends on how much the site changes and how much the business relies on it. Testing after major changes, such as a redesign, a new plugin that stores data, or a move to a new host, is a sensible habit. A regular calendar reminder, quarterly for example, keeps the process from going stale.

A woman in a green sweater points at a laptop while a smiling man in a blue jacket watches beside her in a back office.

Write the restore plan down

When a website goes down, stress makes simple steps harder. A short written plan helps. It should cover:

  • Where each backup is stored and how to access it.
  • Who is allowed to start a restore, and who must be told.
  • The order of steps for bringing the site back, including DNS or hosting changes.
  • Contacts for the hosting company, developer, domain registrar and payment provider.
  • How to check the restored site before announcing it is back.

The #StopRansomware Guide recommends restoring from offline, encrypted backups based on a prioritization of critical services. For a website, prioritization might mean getting the contact page and phone number working first, then the booking system, then the blog archive.

Keep a copy of the plan somewhere that does not depend on the website or the server, such as a shared document or a printed sheet in the office.

Questions to ask your host or developer

Hosting plans and maintenance arrangements vary widely, so it is worth asking directly:

  • What exactly is backed up, and how often?
  • How long are backups kept, and how many versions are available?
  • Are copies stored on separate infrastructure or under a separate account?
  • Who can delete backups, and is that access protected?
  • How do I request a restore, and how long does it usually take?
  • When was a restore last tested, and what was the result?

Vague answers are a signal to dig deeper. Motta Industries’ web hosting service and ongoing website maintenance work are both places where these questions should have specific answers in writing.

Keep the plan current as the site changes

A backup plan written for last year’s website may not fit this year’s. New features often bring new data. Adding an online store, a membership area or a booking calendar means the database now holds information customers expect you to keep. Even regular content updates change what a restore needs to bring back.

Review the plan whenever the site changes significantly, and record what changed. Pair that review with a restore test, and the business will know, rather than hope, that it can recover.

Common gaps a first test reveals

First restore tests tend to uncover the same handful of problems. The backup excluded large media folders to save space. The database copy came from a different day than the files. A plugin license key or payment setting had to be re-entered by hand. Email stopped working because mail settings lived outside the site. Each of these is easy to fix once found, and each one is far easier to find on a quiet afternoon than during an outage.

The bottom line

A website backup you can restore is the result of a few deliberate choices: knowing what needs protecting, deciding how much loss is acceptable, keeping separate and secure copies, and proving the process works through regular restore tests. None of it requires a large budget or specialist software. It does require one named person to own the job and to test it before an emergency forces the question.