Website backups and recovery
Website backups: what to save, how often to make them and how to know they work
Having a file called “backup” does not mean your website can be recovered. A useful backup should answer five questions: what it contains, when it was made, where it is stored, how many versions exist and how it is restored. This guide focuses on designing backups that genuinely help when an incident occurs.
This page is about backups and recovery, not website maintenance in general
Within this cluster there are several different search intentions:
- website maintenance is for people who want preventive reviews and technical continuity;
- what to do if a website stops working is an outage response protocol;
- how to protect a website from hacking focuses on prevention;
- this guide focuses specifically on how a backup should be designed so a website can be recovered .
A website backup is a recoverable version of the project at a specific point in time
The objective is not to accumulate compressed files. The objective is to be able to return to an earlier state when data is lost, an update fails, a migration goes wrong or an incident changes the project.
For a backup to be useful, it must preserve the pieces needed to rebuild the website or recover what has been lost.
And there is an important distinction: a backup is not the same as synchronisation. If a system immediately replicates a damaged or deleted file, that synchronisation can copy the problem as well. A backup strategy keeps previous versions.
What should a website backup include?
It depends on how the website is built. On a typical WordPress website there are two separate groups: files and database .
WordPress explains in its official documentation that downloading the files from the server does not mean the database has also been copied, because they are normally stored in different systems.
Files
They may include:
- uploaded images and documents;
- theme;
- plugins;
- custom code;
- required configuration files;
- other resources that cannot easily be rebuilt.
Database
On a dynamic website it may contain content, settings, users, stored forms, orders, bookings or other information generated by the application.
A static website
If the project consists only of HTML, CSS, JavaScript and images and does not use a database, the backup can be much simpler.
Services that are not directly part of the website
Email, DNS, provider accounts, APIs or SaaS tools may need their own strategy. The fact that they are purchased together with hosting does not mean they are automatically included in the website file backup.
How often should a backup be made?
The right answer is not “daily”, “weekly” or “monthly” for everyone. Frequency should depend mainly on how much information changes between one backup and the next .
| Type of project | What changes | Suggested frequency to consider |
|---|---|---|
| Landing page or corporate website that barely changes | Few content changes. | Monthly may be enough in many cases, together with backups before important changes. |
| Active corporate website | Frequent content, form or configuration changes. | Weekly or monthly depending on the actual rate of change. |
| Ecommerce | Orders, customers, stock and statuses. | Daily or more frequently if losing one day of data would be unacceptable. |
| Bookings, memberships or users | Continuously generated data. | According to the maximum amount of information the business can afford to lose. |
| Before an update, migration or important technical change | The risk comes from the change that is about to be made. | A specific backup immediately before making the change. |
These frequencies are practical references, not a universal rule. A store with two orders a month and another with hundreds a day should not have the same policy simply because both use WooCommerce.
The key question: how much information could you afford to lose?
This question is more useful than choosing a frequency out of habit.
Imagine you make a backup every seven days. If the server fails just before the next backup, you could lose almost a week of changes.
Then ask yourself:
- would losing a week of changes be acceptable?
- what happens if orders are lost?
- could submitted forms be reconstructed?
- is there data in another system that would allow part of the information to be recovered?
- how long can the website remain unavailable while we restore it?
If losing one day of data is too much, a weekly backup is clearly not enough.
By contrast, if a landing page has not changed for three months, backing it up every day may add very little additional value.
Full, incremental and differential backups: how they differ
INCIBE distinguishes three common methods that can be combined according to storage, frequency and ease of recovery.
Full backup
Saves the entire selected set. It is usually simple to understand and restore, but uses more space and time.
Incremental backup
Saves only what changed since the last backup, whether full or incremental. It reduces storage, but restoration may require several backups in sequence.
Differential backup
Saves the changes made since the last full backup. It normally needs more space than an incremental backup, but simplifies recovery because the full backup and the latest differential backup are usually enough.
A website owner does not need to master these techniques. What matters is knowing which system the provider uses and whether complete restoration is genuinely covered.
I would not rely on a single backup stored in the same place as the website
If the only backup lives inside the same hosting account and that account is deleted, corrupted or compromised, you could lose both the website and its backup at the same time.
A well-known reference for increasing resilience is the 3-2-1 strategy:
- keep three copies of the information, including the original;
- use at least two different locations or media;
- keep at least one copy separate from or outside the main environment.
Not every simple website needs complex infrastructure, but the principle is useful: one incident should not be able to destroy every copy at once .
I would also review who can access the backups, because a backup may contain the same sensitive information as the original system.
Keeping several versions matters because the most recent backup may also be damaged
Imagine a problem started twenty days ago and nobody noticed until today. If you only keep last night’s backup, that backup may already contain the same problem.
That is why a backup policy also needs to consider retention: how many versions are kept before older ones are deleted.
The number depends on:
- backup frequency;
- available space;
- how long a problem normally takes to be discovered;
- the amount and value of the data;
- requirements applicable to the project;
- how easy it is to reconstruct older information.
“We have a backup” and “we have enough history” are two different statements.
A backup is not genuinely validated until you know it can be restored
This is one of the most important points. The file may exist and still be incomplete, corrupt or dependent on elements nobody saved.
NIST currently emphasises that effective backup management is not limited to creating them regularly: it should also include testing and reviews within recovery procedures .
A check should answer:
- can we locate the backup we need?
- do we know which date it corresponds to?
- does it contain files and the database when both are needed?
- do we have the credentials and documentation needed to restore?
- can the backup be opened or imported?
- does the recovered website work after restoration?
- are forms, users, orders or critical functions still operational?
You do not need to restore the live website every week to prove it. Testing can be carried out in a controlled way according to the risk level of the project.
Make a specific backup before updates, migrations or risky changes
A scheduled backup and a backup before an intervention serve different purposes.
If you are going to update several plugins, change PHP, migrate servers, modify important code or import information, it is sensible to have a recent version immediately before the change.
WordPress recommends making a backup before updating precisely because an update can create unexpected problems.
That backup lets you clearly establish: it worked before the change / the problem appeared after the change .
8 common website backup mistakes
1. Copying only the files and forgetting the database
On many dynamic websites you would lose essential content and data.
2. Keeping the only backup on the same hosting account
The same incident could affect both the original and the backup.
3. Keeping only the latest version
The problem may have been present in the backup for days or weeks without being detected.
4. Not knowing the date of each backup
In an emergency you may end up restoring a version that is too old or one created after the problem began.
5. Assuming the hosting provider backs up everything
You need to check what the provider actually covers, how long backups are retained and whether restoration is included.
6. Never testing restoration
Discovering that the backup does not work during an outage is too late to design the procedure.
7. Making backups at a frequency that does not match the business
Backing up a store once a month may mean losing too much data. Backing up an unchanged landing page every few minutes may be unnecessary.
8. Thinking that having a backup means you are protected from hacking
Backups help with recovery. They do not replace updates, access control or other preventive measures.
If the website is already down, do not automatically restore the most recent backup
Before overwriting the current state, it is worth knowing:
- what caused the failure;
- when it started;
- the date of the backup;
- which recent data would be lost;
- whether the backup also contains the problem;
- whether we can preserve the current state before restoring.
Especially in ecommerce, booking systems or applications with users, restoring an old database can delete valid information.
For how to respond to an outage, follow the guide on what to do if your website stops working .
Checklist: a reliable website backup should answer these 10 questions
- What exactly are we backing up?
- Do we need files, the database or both?
- How often does the information change?
- How much data can we afford to lose?
- Where is the backup stored?
- Is there at least one version separate from the main environment?
- How many versions do we keep?
- Who can access the backups?
- Have we tested that they can be restored?
- Do we know what to do and who to contact when recovery is needed?
Do you know which backups your website currently has and whether they could be restored?
We can review how technical maintenance is organised, what backup system exists and whether the frequency makes sense for the type of project. If you need a more advanced continuity or cybersecurity policy, that is assessed as a separate need.
Frequently asked questions about website backups
What should a website backup include?
It depends on the technology. On a dynamic website, both files and the database normally need to be protected, together with any configuration needed to rebuild the environment. In WordPress, copying only the files is not the same as copying the database as well.
How often should a website backup be made?
Frequency should depend on how much the website changes and how much information you would be prepared to lose. A corporate website that changes very little may need less frequent backups than an online store with daily orders, users or bookings.
Is it enough to keep the backup on the same hosting account?
It is better if that is not the only copy. If the problem affects the hosting itself, the account or storage, you could lose both the website and its backup. Keeping at least one copy separate from the main environment improves recovery capability.
Does a backup prevent a website from being hacked?
No. A backup does not prevent an attack. Its role is to help recover files and data after an incident. Reducing the risk of compromise requires other security and maintenance measures.
How do I know whether a backup works?
The reliable way to check is to verify that the backup is complete and carry out restoration tests periodically or as part of a controlled procedure. The existence of a backup file alone does not prove that it can be restored correctly.
How many backup versions should be kept?
There is no universal number. Keeping several versions is useful when a problem may be discovered late, because the most recent backup could already contain the error, malware or damaged data. Retention should reflect the rate of change and the risk of the project.
Should a backup be made before updating a website?
It is good practice before changes that could affect operation, especially major updates, migrations or changes to related components. WordPress recommends making a backup before updating.