Website Backup and Disaster Recovery: What to Back Up, How Often, and Who Restores It

The awkward thing about backups is that doing them well attracts no attention at all, while the day you actually need one can decide whether the business keeps running. Plenty of companies believe they have backups right up until the host has a problem, they ask for a restore, and they discover the backup contains the code but not the database — or that the last successful run was months ago.

Websites do not only break through hardware. Deleted content, an overwrite during a redesign, a plugin update gone wrong, an intrusion, an issue with a service provider account: each of these can leave a site with no way back. This article takes backup and recovery apart in practical terms, so you can audit what you have and ask the right questions.

The four things a backup has to cover

“We have backups” is too vague a sentence. A website is made of four classes of asset, and missing any one of them means you cannot restore the whole thing.

One: code and templates. The site’s own programs, theme, plugins, and custom functionality. These normally live in version control, and where that is used properly this is in fact the safest of the four.

Two: the database. Articles, products, orders, members, and settings mostly live here. It is both the most important and the most frequently missed — backing up files without the database gives you an empty shell on restore.

Three: user-uploaded files. Images, video, PDFs, attachments, documents members have submitted. These are usually outside version control, and once lost they cannot be reconstructed from the code.

Four: environment configuration and credentials. Server settings, domain and DNS records, the SSL certificate, and the keys and account ownership for every external service. This class takes up almost no space and is the one most often overlooked; without it, even with the other three in hand, getting the site running again can take days.

The way to audit your situation is direct: for each class, ask when it was last backed up, where that copy is, and who can retrieve it. Only when all four questions have answers do you really have backups.

Setting frequency and retention

There is no standard answer on frequency, and only one question decides it: how much data can you afford to lose.

• A brochure site whose content barely changes may be fine with a weekly copy.
• A site with a blog or regularly updated content is better served by a daily one.
• A site with orders, members, and payments needs daily copies plus more frequent database backups — losing half a day of orders is rarely something you can fix by retyping.

The other setting to decide alongside it is retention. The risk in keeping only the last few days is that many problems are not found the same day. Deleted records and tampered content often go unnoticed for weeks, by which time every version you can restore may already carry the damage.

The common arrangement keeps daily copies for some weeks, weekly copies for some months, and monthly copies for about a year. That pattern is generally called tiered retention, and it pairs with the 3-2-1 principle the industry talks about: several copies, on more than one kind of storage, with one of them held somewhere else. Knowing both terms is useful mainly because you can put them straight to a vendor and read up on them yourself. The point is not to copy that combination but to work out how late you might realistically notice something wrong, then set retention backwards from there.

One more principle is worth following: do not keep backups in only one place. A copy sitting on the same server and under the same account as the site disappears with it when the problem is at the account level. At least one copy should live on a different service or a different account. Your hosting model shapes what is possible here; compare the options in How to Choose Web Hosting.

An unverified backup is not a backup

This is the most painful lesson in practice: the backup job reports success every day, and when a restore is finally needed the file will not open, or the restored database is missing tables.

Backups fail for all sorts of reasons — a full disk, changed permissions, a compatibility problem after a schema change, a schedule that was switched off and never noticed. None of these raise an error on the backup side. They only appear on the restore side.

So two things are required.

Automated checking. At minimum, confirm that the backup file was produced, that its size falls in a reasonable range, and that it is not empty. When a backup fails, somebody should be notified rather than having to go looking through logs.

Regular restore rehearsals. Periodically restore a backup into a separate environment, open it, and confirm the content is correct, that you can log in, and that the critical flows run. While you are there, record how long the restore actually took — that duration is your real recovery time, and it is usually longer than people assume.

How often to rehearse can scale with how critical the system is, but at least once a year, and again after any significant architectural change.

Recovery targets: two thresholds to agree in advance

Disaster recovery planning usually revolves around two ideas, known in the trade as the recovery point objective and the recovery time objective. The acronyms matter far less than the meaning.

The acceptable range of data loss (the recovery point). When something goes wrong, how far back in time can you afford to land. This answer directly determines backup frequency — if losing even an hour of orders is unacceptable, a daily copy is clearly not enough.

The acceptable downtime (the recovery time). From discovering the problem to service being restored, how long can you tolerate. This answer determines the recovery method: a site that can accept several hours can restore from backup, while a system that can only accept a short outage needs a standby environment prepared in advance.

Both thresholds should be set by management, not assumed by engineering. Picture a shop whose main revenue arrives through online ordering: the cost of downtime during a weekend peak is nothing like the cost late on a weekday night, and the level of investment in redundancy that makes sense differs accordingly. Settle the thresholds first and everything after them has a basis.

Different disasters call for different handling

Break the word “disaster” apart and the handling diverges sharply:

• Hardware or provider failure. The blast radius is clear and restoring the most recent backup is normally enough. Speed of restore is what matters.
• Human error, deletion or corruption. Often only a single file or a single table needs to come back, so backups have to support partial restores rather than offering whole-machine recovery as the only option.
• Intrusion. You cannot simply restore and move on, or you restore the way in along with everything else. The full response sequence and where responsibility sits belong to security incident handling, covered in Website Security Basics for Businesses. On the backup side there is only one question to answer: which copy is actually clean. If you cannot establish when the intrusion began, you have to work backwards until you reach a version you can vouch for — which is exactly why retention cannot be limited to the last few days, and why the date and contents of a copy get checked before anything is restored.
• Account-level problems. A provider account suspended, or nobody knowing who owns an account after the responsible person leaves. Technical backups cannot rescue this; it takes disciplined account and permission management.

That last item deserves emphasis: every service account should be registered in the company’s name and recorded in an inventory, covering the domain, hosting, email, payments, and analytics. That inventory is itself part of your backup.

Who is responsible: put it in writing

“I assumed they were handling it” is the most common reason backups turn out not to exist. Responsibility has to land on named roles, and at minimum these points need clarifying:

• Who runs the backups, by what method, and where they are stored.
• Who is notified when a backup fails, and how quickly it must be addressed.
• Who performs a restore, and whose authorization is required.
• How often restore rehearsals happen, and who sees the results.
• Who is contacted first during an incident, and how it is handled outside working hours.

If the site is maintained by an external team, these belong explicitly in the maintenance contract rather than in a verbal understanding. For how to negotiate contract terms and service scope, compare What Website Maintenance Actually Covers.

The backup-specific clauses in a contract

The overall scope of a maintenance or development agreement is a separate discussion. What follows are the six clauses tied directly to backup and restore, which you can walk through line by line while negotiating:

1. Scope of backup. State how each of the four classes — code, database, uploads, environment configuration — is handled, and say so explicitly if one is excluded.
2. Frequency and retention. Write specific cycles and retention lengths, not simply “regular backups.”
3. Storage location and access. Where copies live, whether one of them sits under an account you control, whether you can download them yourself, and how quickly you can obtain one when needed.
4. Scope of restore service. Whether partial restores of a single file or table are possible, which situations are included in the maintenance fee, and which are billed separately.
5. Response time on failures and restore requests. How quickly you are told when backups fail repeatedly, and how quickly work begins once you ask for a restore.
6. Handover at the end of the engagement. How and when the backup data itself, account permissions, and the configuration inventory are delivered.

These clauses can be raised while you are still choosing a partner, and the way a candidate answers often says more about their operational maturity than the clauses themselves; for related questions, see How to Choose a Software Development Company.

A check you can run today

You do not have to wait for a complete disaster recovery plan. Confirm these five points today:

1. When was the last successful backup?
2. Does it include the database and user-uploaded files?
3. Where is it stored, and is it under the same account as the site?
4. When did a restore last actually succeed?
5. If the site went down completely right now, who handles it and how long until service returns?

Any question you cannot answer is the gap most worth closing. The value of a backup is never in ordinary weeks; it is in the day you need it — and that day does not announce itself in advance.

Once you have worked through those five questions, if any of them left you without an answer and you would like help auditing the rest, talk to NETVANA about your project. We do not sell fixed plans: backup and recovery arrangements get assessed case by case against the size of the system, how sensitive the data is, and the downtime you can live with, and a quote follows once the gaps are agreed. What each service covers and delivers is listed in the software services overview.

Further reading: for the items to confirm before going live, see The Website Launch Checklist. Misunderstanding how domains, hosting, and certificates fit together slows recovery down, so see Domains and DNS in Plain English. For handling backups that contain personal data, see How to Write a Website Privacy Policy. And for the risk that accumulates when maintenance is neglected over time, see Technical Debt Explained for Business Owners.