A Recovery Plan for a Small Business Website: Decide Before Something Breaks
Why a pile of backups is not a plan
Ask a small business owner whether the website is backed up and the answer is usually yes. The host does something, or there is a plugin, or the web designer set it up years ago. Ask a follow-up question, such as who would restore it, how long that would take, and what would be missing afterwards, and the room goes quiet.
That quiet is the gap between having backups and having a recovery plan. A backup is a file. A plan is a set of decisions made in advance, written down, and tested at least once. When a site goes down at four on a Friday afternoon, nobody wants to be inventing those decisions under pressure.
None of this needs enterprise tooling. It needs an hour of honest thinking and a notebook.
Start with what can actually go wrong
Planning gets easier when you stop thinking about "disasters" in the abstract and list the specific ways a small site fails. Most of them are dull.
Updates that go sideways
The most common cause of a broken WordPress site is a change somebody made on purpose. A plugin update conflicts with the theme. A PHP version bump on the host breaks an older plugin. A page builder update changes how saved layouts are read. The site does not usually disappear. It shows a white screen, or the checkout stops working, or half the pages lose their formatting.
These failures are usually quick to notice and usually fixable by rolling back. They are also the reason a fresh backup before any update is worth more than a perfect schedule.
Hacks and quiet defacement
A compromised site is a different kind of problem, because the damage may not be visible. Spam links hidden in old posts, a redirect that only fires for visitors coming from search results, an extra admin account nobody created. The site looks fine to the owner and wrong to Google.
With this kind of failure, the question is not "do I have a backup?" but "do I have one from before the problem started?" That depends on how far back your copies go, which we will come back to.
The hosting account itself
People forget that the host is a single point of failure. Accounts get suspended over a billing problem. A server fails. A hosting company closes, or migrates customers to new hardware and something does not survive the move. If your only backups live in the same account as the site, they disappear with it.
Human mistakes
Someone deletes a page, a product category, or a whole folder through the file manager. Someone runs a find-and-replace across the database with the wrong string. Someone cancels a plugin subscription and the premium features quietly stop working. These are not attacks and not bugs. They are Tuesday.
Things outside your control
Domain names expire. DNS records get changed by a former agency. An SSL certificate lapses. These are not backup problems in the strict sense, but they take a site offline just as effectively, and a recovery plan that ignores them is incomplete. Keep a note of where the domain is registered, who has the login, and when it renews.
Write your own version of this list. Two or three lines each. You are not predicting the future, you are making sure the plan covers more than one kind of bad day.
Two numbers that shape everything else
Once you have a list of threats, two questions turn it into something you can plan around.
First, how much recent work could you afford to lose? Second, how long could the site be unavailable before it starts costing real money or trust?
The disaster recovery world calls these the recovery point objective and the recovery time objective. The names are clumsy but the ideas are not, and once you have put numbers on them, choices about backup frequency, storage and tooling mostly make themselves. If the vocabulary is new to you, this walk-through of RPO and RTO for a WordPress site translates both terms into posts, orders and minutes of downtime instead of datacentre language, and it is a good place to start before you fill in the numbers below.
Putting a number on what you can lose
Think about what changes on your site in a day. A brochure site for a local plumber might change twice a month. A bakery with online ordering might take orders every hour. A blog with an active comment section collects new text all the time.
Now picture the site breaking right now and being restored from last night's copy. What would be missing? For the plumber, probably nothing. For the bakery, a day of orders, which might also mean customers who were charged but have no record on the site. Those are very different problems, and they call for different backup schedules.
A rough way to think about it: your backup interval is the ceiling on what you can lose. If backups run once a day, you can lose up to a day. If they run weekly, up to a week. That is a worst case, not an average, and it assumes every backup actually ran. A schedule that fails silently for three nights has quietly turned a one-day ceiling into a four-day one.
Putting a number on how long you can be down
Downtime is easier to feel than data loss. Ask yourself what happens if the site is gone for an hour, for half a day, for three days.
For some businesses, an hour is nothing and three days is a nuisance. For a shop that gets most of its orders online, half a day is a visible loss. For a booking-based business, a site that cannot take bookings might as well be closed. There is no correct answer, only an honest one.
Be careful about one thing. The time a restore takes on paper is rarely the time it takes in practice. Someone has to notice the problem, work out whether to repair or restore, find the credentials, download or locate the backup, put it on a working server, wait for the database to import, and check that it works. Each step is small. Together they add up to a long afternoon the first time.
Write down both numbers, even as rough guesses. "We can lose a day of content but not a day of orders. We can be down for four hours." You will refine them later, but a bad number you can argue with is more useful than no number.
Where the copies should live
Two numbers in hand, the next question is where the backups go. The well-known rule of thumb is "3-2-1": keep three copies of your data, on two different kinds of storage, with one copy somewhere else entirely. The rule has been repeated for years because it works, not because it is fashionable.
For a small WordPress site, a practical reading looks like this.
The live site is copy number one
The files and database on your host are the working copy. They count as one, but you should not trust them to count as more than one.
A second copy on different storage
This is often a backup stored on the same server or in the same hosting account. It is convenient, and it makes restores quick, because the files are already there. It protects you against mistakes and bad updates. It does not protect you against the server or account vanishing.
A third copy somewhere independent
This is the one most small sites lack. An offsite copy means storage that is not controlled by your host and does not share its fate: an object storage bucket, a cloud drive, a separate server, even a drive in your office that receives scheduled downloads. The test is simple. If your hosting company disappeared tonight, could you still get your site back? If not, you have not got an offsite copy.
There are many ways to get there. Some people use a plugin that pushes archives to a cloud drive. Some use their host's snapshot tool and download a copy now and then. Some use an outside service that connects to the server, pulls the files and database across, and stores them elsewhere. backupyoursite is one of the services in that last group, and the general idea is the same whichever tool you choose: the copy that saves you is the one that lives somewhere your hosting account cannot touch.
Whatever you pick, check two things. Does it back up both the files and the database? A folder of images without the database is not a site. And does the storage account have its own login, separate from your hosting login, so that a compromise of one does not hand over the other?
How long to keep old copies
Most owners think about backup frequency and forget retention, meaning how many old copies you keep and for how long. Retention is where many recovery plans quietly fail.
Here is the scenario. A site is infected on the first of the month. Nobody notices until the twentieth, when search traffic drops and a customer mentions strange links. The backups are set to keep the last seven days. Every one of them contains the infection. The most recent clean copy was deleted almost two weeks ago.
The fix is to base retention on how long problems usually go unnoticed, not on how cheap storage is. If your site is only looked at when a customer complains, your detection time is long, and your retention should be too. If you have uptime monitoring and someone checks the site daily, you can get away with less.
A sensible shape for many small sites is a mix: frequent recent copies, fewer older ones, and a handful reaching back a few months. This grandfather-father-son pattern comes from tape rotation, but it scales down neatly to a single site. If you want a way to reason about it, backup retention policy best practices lays out a tiered schedule and shows what different windows cost in storage, so you can pick a window you can defend instead of copying whatever the default happens to be.
Two practical notes. First, storage for a typical small site is cheap, so the argument for short retention is mostly about habit. Second, if your business falls under any legal or contractual record-keeping requirement, retention may not be your call at all. Ask your accountant or a lawyer rather than guessing, and write down what they say.
Who does what: the one-page runbook
A runbook sounds grand. It is a single page that answers the question "the site is down, now what?" for a person who may not be the one who built it. Write it for a stressed colleague, or for yourself in a bad mood.
Keep it on paper or in a place that does not depend on the site being up. A recovery plan stored only on the server that just died is a joke with a bad ending.
What to put on it
- Who decides. One named person with authority to say "we restore". Without this, hours disappear into debate.
- Who does the work. The person who actually performs the restore, and a backup person for when they are on holiday.
- Where things are. Hosting login, domain registrar login, DNS provider, backup storage login, and where the credentials are kept. Put the location of the password manager entry, not the passwords themselves.
- Where the latest backup is. The exact storage location and how to tell which file is the most recent complete one.
- The restore steps. Short, numbered, written for the specific setup. Not a generic guide.
- Who to tell. Staff, a key client, whoever answers the phone. A one-line holding message to put on social media or the phone greeting.
- How to know it worked. A short list of things to check afterwards: homepage loads, contact form sends, checkout completes a test order, admin login works.
A note on the restore steps
Most restores boil down to the same four things: put the files back, put the database back, make sure the site configuration points at the right database and domain, and clear any caches. For a hand restore on a server with command-line access, the database part is often a single command, such as WP-CLI's wp db import to load an exported SQL file. That is exactly the kind of detail worth writing down, along with the path to the file, because nobody remembers it at four on a Friday.
If you use a tool with a restore button, write down what the button actually does. Does it overwrite the live site? Does it restore to a staging copy first? Does it also restore the database, or only files? These are the questions that cause surprises.
Watching the backups, not just making them
A backup job is a promise. Promises need checking.
The most common reason for a worse-than-expected recovery is not a bad plan. It is a backup that stopped working weeks ago and nobody noticed. The storage filled up, a password changed, the plugin conflicted with a new PHP version, the schedule was paused during a migration and never switched back on.
Build a small habit into your calendar. Once a week, look at the list of backups and confirm that the newest one is from when it should be, and that the file size is in the right range. A backup that is suddenly a tiny fraction of its usual size is almost always a failed one that produced an empty shell.
Better still, set up alerts for failures, not only for successes. Many tools email you "backup complete" every night, and people learn to ignore the email. An alert that only appears when something goes wrong is much harder to ignore. If your tool cannot do this, a simple external check can: a calendar reminder to look, or a script that tests whether the latest file is recent enough.
Check the content, not just the file
Also remember that a backup file existing is not the same as a backup being usable. Archives get corrupted. Database exports get cut off halfway through when a server times out. The only real proof is a successful restore, which brings us to testing.
Test the restore before you need it
If you do one thing after reading this article, make it this. Schedule an hour to restore your site somewhere that is not the live site.
This is the step almost nobody takes, and it is the one that turns a hopeful plan into a real one. Until you have done it, you do not know your recovery time, you do not know whether your backups are complete, and you do not know whether your runbook has a missing step.
How to do a safe test
You need a place to put the restored copy. A cheap test subdomain, a local development environment on your laptop, or a staging area on your host will all do. Do not restore over the live site for a drill.
Take the most recent offsite backup, not the convenient local one. Follow your own runbook exactly, step by step, and write down every point where you had to stop and work something out. Note the time it took from start to a working homepage.
When it is up, click around. Log into the admin area. Open a few pages and posts. Check that images load. Submit a form and see where it goes, because restored test copies sometimes send real emails to real customers, so switch email off or point it somewhere harmless before you test.
What you will probably find
Something will be missing or slower than you thought. Perhaps the credentials for the storage account are in the head of someone who left. Perhaps the database import runs into a size limit. Perhaps the restored site still points at the old domain and needs the address updated in the database before it will load properly.
Good. That is the point of a drill. Fix the runbook, note the real restore time, and put the next test in the calendar. Twice a year is a reasonable rhythm for a small site, and always after a major change such as a host move or a rebuild.
Plan for the awkward cases
A basic plan covers the standard failure. A few special cases deserve a line or two each.
E-commerce and membership sites
If the site records orders, subscriptions or user sign-ups, restoring to last night's copy loses real transactions. Part of your plan should be how to reconcile them. Payment processors keep their own records, so you can usually rebuild a list of orders from there. Decide in advance who does that work and where the lists come from. More frequent database backups, even if file backups stay daily, reduce the gap.
Sites with several editors
When many people publish content, work is lost in bite-sized pieces and nobody realises until they go looking for it. Tell the team that after any restore, recent edits may need to be redone, and ask them to keep local copies of anything long they are drafting directly in the editor.
Sites managed by an outside agency
If an agency or freelancer runs your site, ask them for the plan in writing. Ask where the offsite backups are stored, whether you have access to them independently, and what happens if you part ways. Owning your own backups, in an account under your control, is a simple protection against a bad breakup.
Changing hosts
A migration is the moment backups are most likely to be forgotten. Take a complete backup immediately before the move, keep it for a good while afterwards, and confirm that the schedule on the new host is actually running.
Keeping the plan alive
Plans rot. People leave, passwords change, the site grows, a plugin gets replaced. Put a recurring reminder in the calendar to review the runbook every few months, and use the same moment to check the following.
- Do the two numbers, what you can lose and how long you can be down, still match the business?
- Is the newest backup recent and the right size?
- Do the people named in the runbook still work with you?
- Have the hosting, registrar and storage logins changed?
- When was the last test restore?
Five questions, ten minutes. It will not make the site indestructible, but it will keep the plan from drifting into fiction.
The short version
A recovery plan for a small business site does not need to be long. It needs to answer a few questions before the pressure arrives: what you could lose, how long you could be down, where independent copies live, how long you keep them, who does what, and whether you have ever proven that a restore works.
Start this week. List the threats, put rough numbers on loss and downtime, check that at least one copy lives outside your hosting account, write the one-page runbook, and book an hour to restore the site somewhere safe. The first drill will be messy and slow. The next real problem will be much calmer because of it.
