Website backups are often treated as a formality that can be dealt with after development is complete. A hosting provider supposedly creates copies automatically, so the business owner does not check what exactly is being backed up, how long the archives are stored or whether the website can actually be restored from them.
The problem becomes obvious only after something goes wrong. An unsuccessful update breaks part of the functionality, an employee accidentally deletes important data, a server fails or malicious code infects not only the website but also the available backups. At that point, the business may discover that the last usable copy was created several months ago or contains only website files without the database.
A reliable backup is not simply an archive containing a website folder. It is a complete system that allows you to return the website to a working state within an acceptable period and with minimal data loss.
In this article, we explain what should be included in a website backup, how to determine the right backup frequency, where copies should be stored and how to check whether they are actually suitable for recovery.
What Is a Website Backup?
A website backup is a separate copy of files, databases, configurations and other project components that can be used to restore the website after a technical failure, human error or cyberattack.
Depending on the type of website, a backup may include:
- CMS files, themes, plugins and program code;
- a database containing products, orders, pages and user information;
- images, documents, videos and other uploaded content;
- server and web server configurations;
- domain, SSL certificate and system settings;
- environment variables and integration parameters;
- email templates and notification settings;
- scheduled tasks, queues and automated processes.
For a simple landing page, a copy of the website files and basic settings may be sufficient. For an online store or web service, this is not enough. The most valuable information is often stored in the database, where new orders, customers, payments and stock changes appear continuously.
Why Back Up a Website That Is Working Normally?
A backup is not needed only after a serious security breach. Many website problems occur during normal maintenance and everyday work.
A CMS update may be incompatible with an older plugin. A content manager may accidentally delete a page or product category. A developer may make an error while changing the code. An integration may overwrite correct data with incorrect values. A hosting provider may experience a hardware or software failure.
It is especially important to create a backup before:
- updating the CMS, plugins, modules or website theme;
- moving the website to another server;
- changing the database structure;
- importing a large number of products or content;
- connecting payment, delivery or CRM systems;
- installing third-party software;
- launching a redesign or major functionality update;
- changing the PHP, Node.js or database version;
- modifying the server environment.
Even when automatic daily backups are configured, a separate recovery point should be created before a potentially risky change. It allows the website to be returned to the exact state it was in before the work began.
Why a Hosting Provider’s Backup May Not Be Enough
Automatic backups offered by a hosting provider are a useful foundation, but they should not be treated as the only level of protection.
Backup frequency, retention period, included data and restoration procedures may differ depending on the hosting plan. Some providers create copies every day, while others do so every few days or once a week. On a VPS or dedicated server, automatic backups may not be included at all.
Before relying on your hosting provider, you should clarify several important details.
What Exactly Is Being Backed Up?
In some cases, the archive contains website files but not the database. In other cases, the database is saved without media files, server configurations or uploaded documents.
How Many Backup Versions Are Available?
If only the most recent copy is stored, it may already contain an error, corrupted data or malicious code. A reliable system should provide a history of recovery points created on different dates.
Where Are the Backups Physically Stored?
A backup stored on the same server or physical drive does not protect the website against complete hardware failure. At least one copy should be kept separately from the production server.
Who Can Delete the Archives?
When the website and its backups are controlled through the same account, an attacker who gains access may be able to delete both the working data and all available recovery copies.
How Does the Restoration Process Work?
You need to know whether the website can be restored independently through the hosting control panel or whether you must contact support and wait for the request to be processed.
A hosting backup is useful, but a secure strategy should include at least one additional independent storage location.
How Often Should You Back Up a Website?
There is no single backup frequency suitable for every website. Backups should be created often enough to prevent the business from losing a critical amount of information.
The main factor is not the size of the website but how frequently its data changes.
If a corporate website is updated once a month, losing several hours of changes may not cause serious damage. For an online store, even one hour of missing data may mean lost orders, payments, customer information and stock updates.
Recommended Backup Frequency by Website Type
Website typeRecommended backup frequencyLanding page or brochure websiteDaily or weekly, as well as before every important changeCorporate websiteAutomatic daily backupBlog or content portalDaily, or several times a day when publishing frequentlyOnline storeWebsite files daily, database every 15–60 minutesBooking or appointment websiteDatabase every 15–30 minutes or more frequentlyCRM, client portal or web serviceEvery few minutes or through continuous replicationWebsite under active developmentBefore every release and major change
These are not strict rules but a practical starting point. The exact schedule depends on the number of transactions, the value of the data and the acceptable period of website downtime.
RPO and RTO: How to Define Real Backup Requirements
When planning a backup strategy, it is useful to define two indicators: RPO and RTO.
What Is RPO?
RPO, or Recovery Point Objective, defines the maximum amount of recent data the business can afford to lose.
For example, if an online store cannot lose more than 30 minutes of orders, its database should be backed up at least every 30 minutes. A single daily backup would not meet the actual needs of the project.
What Is RTO?
RTO, or Recovery Time Objective, defines how long the website may remain unavailable before the downtime becomes unacceptable for the business.
For a small informational website, restoration within one working day may be acceptable. For an online store, payment platform or booking service, even several hours of downtime may result in significant losses.
RPO answers the question, “How much data can we afford to lose?” RTO answers, “How much time can we spend restoring the website?”
These indicators help determine not only the backup frequency but also the appropriate storage and recovery technology. A standard daily archive may be suitable for a corporate website but insufficient for a system that processes transactions continuously.
Types of Website Backups
The backup method affects storage requirements, creation speed and recovery complexity.
Full Backup
A full backup contains all selected website files and data. It is usually the easiest type to restore because only one complete archive is required.
The disadvantage is its larger size and longer creation time. For this reason, full backups are often created once a week and combined with other methods between full backup cycles.
Incremental Backup
An incremental backup saves only the data that has changed since the previous backup.
This method saves storage space and makes it possible to create recovery points more frequently. However, restoration may require the original full backup and the entire sequence of incremental archives.
Differential Backup
A differential backup contains all changes made since the most recent full backup.
It usually requires more storage than an incremental backup but simplifies the restoration process. In most cases, only the latest full backup and the latest differential archive are required.
Server Snapshot
A snapshot records the state of a virtual server or disk at a specific moment. It can be useful before a system update, server configuration change or software test.
However, a snapshot should not always be considered a complete replacement for a backup. If it is stored within the same infrastructure as the server, it may be lost together with the original system.
Where Should Website Backups Be Stored?
The most important rule is that a backup should not exist only in the same location as the production website.
A copy stored in a neighbouring folder on the same server may help after the accidental deletion of a file. However, it does not protect against server failure, disk failure, loss of account access or a wider infrastructure incident.
Separate Storage Provided by the Hosting Company
This is a convenient option for quick automatic restoration. However, you should confirm that the backup storage is physically or logically separated from the production server.
A Different Server
Backups can be transferred automatically to a separate VPS or file server. Ideally, the second server should be located with another provider or in a different data centre.
Cloud Object Storage
Cloud object storage is suitable for large archives, automated transfers, retention policies and restricted access.
For additional protection, you can use an immutable storage mode that prevents a backup from being changed or deleted during a specified retention period.
Local Storage Device
An external drive or protected network storage device may serve as another layer of backup protection. However, manual copying can easily be forgotten, and equipment stored in the same office does not protect against theft, physical damage or local disasters.
Offline Backup
An offline backup is not permanently connected to the production infrastructure. As a result, malicious software cannot automatically encrypt or delete it together with the working data.
For critical projects, it is advisable to combine remote cloud storage with an offline or immutable backup.
The 3-2-1 Backup Rule
One of the most practical backup storage models is the 3-2-1 rule:
- maintain three copies of the data, including the original;
- store them on at least two different types of media or in two separate systems;
- keep one copy outside the primary infrastructure.
For a website, this strategy may look like this:
- The production website is hosted on the main server.
- An automatic backup is stored in a separate system provided by the hosting company.
- An additional copy is transferred to cloud storage or a server operated by another provider.
For stronger protection, one copy can be made offline or immutable. This is especially important during ransomware incidents or attacks in which the intruder attempts to delete every available recovery point.
What Must Be Included in a Website Backup?
Copying only the website folder is often not enough. Before configuring the backup process, you should create a complete map of the project’s components.
Website Files
These include program code, templates, themes, plugins, modules, images, documents and other uploaded content.
Database
The database may contain pages, products, customers, enquiries, orders, appointments, CMS settings and system information.
The database should be copied using a consistent method so that related tables are not saved in different states while transactions are still being processed.
Server Configuration
This may include web server settings, software versions, redirect rules, scheduled tasks, system services and security parameters.
Environment Variables and Access Credentials
Configuration files may contain API keys, database connection parameters and other sensitive information. If they are included in the backup, the archive should be encrypted and access to it must be restricted.
Data Stored in External Services
Not all website information is physically stored on the main server. Some data may be located in a CRM, cloud database, payment platform, email service or external file storage.
Each connected service should be checked separately to determine whether it provides change history, data export or a recovery mechanism.
How Long Should Website Backups Be Stored?
Keeping only the latest backup is risky. A problem may remain unnoticed for several weeks, and every newly created archive may already contain corrupted or infected data.
A basic retention policy for a business website may include:
- daily backups stored for the last 7–14 days;
- weekly backups stored for 1–3 months;
- monthly backups stored for 6–12 months;
- separate recovery points created before major updates;
- annual archives where required by business processes or internal policy.
An online store may require longer retention periods because it contains financial and operational records. At the same time, personal customer data should not be kept indefinitely without a valid reason. The backup policy should take both technical risks and data protection obligations into account.
How to Protect the Backups Themselves
A complete website archive may contain more sensitive information than the publicly accessible website. An unprotected backup can therefore become a serious security risk.
A secure storage process should include the following measures:
- encrypt data during transfer and while stored;
- use separate accounts for backup storage;
- grant access only to people who genuinely need it;
- enable two-factor authentication;
- never store archive passwords next to the archives;
- record backup creation, download and deletion activity;
- configure notifications about failed backup jobs;
- restrict mass deletion where possible;
- use immutable or offline copies for critical data.
A website archive should not be sent through an unprotected messenger or stored in a publicly accessible cloud folder.
Why Automatic Backups Must Be Monitored
The presence of an automated task does not guarantee that the backups are actually being created.
The process may stop because the storage is full, a password has changed, a connection has failed, the storage subscription has expired or the server software has been updated.
A reliable system should not only run the backup process but also report its result. The responsible person should monitor:
- the date and time of the latest successful backup;
- the size of the archive;
- whether the database is included;
- how long the backup process takes;
- file transfer errors;
- remaining storage capacity;
- the number of available recovery points.
A sudden reduction in archive size from several gigabytes to just a few megabytes may indicate that part of the website is no longer being included.
How to Check Whether a Backup Actually Works
A backup should not be considered reliable until the website has been successfully restored from it.
The archive may be corrupted, incomplete or incompatible with the current environment. Restoration may also fail because an important configuration file, access key, software version or external service connection is missing.
How to Perform a Test Restoration
The safest approach is to restore the backup in a separate test environment rather than replacing the production website immediately.
After restoration, check whether:
- the main pages open correctly;
- the administration panel works;
- images and documents are available;
- the latest expected records are present in the database;
- contact and order forms work;
- a test order can be completed;
- integrations start correctly;
- there are no critical errors in the server logs.
For a standard corporate website, a restoration test may be performed several times a year. For an online store, CRM or service containing critical data, testing should be conducted more frequently and after major infrastructure changes.
Creating a Backup Before Updating a Website
A separate recovery point should be created before making changes, even when automatic daily backups are already active.
A safe workflow looks like this:
- Check the date of the latest successful automatic backup.
- Create a separate copy of the website files and database.
- Confirm that the backup completed without errors.
- Perform the changes in a test environment whenever possible.
- Update the production website.
- Test the main website functions.
- Do not delete the pre-update backup immediately after launch.
As part of ongoing website technical support, creating a recovery point before risky changes should be a standard stage of work rather than an optional precaution.
What to Do If the Website Has Already Failed
Do not immediately restore the newest available copy over the production website. First, determine what caused the problem.
If the failure was caused by an unsuccessful update, restoring the latest stable version may be sufficient. If there are signs of a cyberattack, restoring an infected archive will simply bring the same problem back.
A safer recovery process involves several stages.
1. Prevent Further Changes
If necessary, place the website in maintenance mode, temporarily restrict access to the administration panel or isolate the affected server.
2. Preserve the Current State
Even a damaged website may contain important logs and technical evidence that can help identify the cause of the incident.
3. Find the Latest Clean Recovery Point
Do not rely only on the date when visible problems first appeared. The website may have been compromised earlier without obvious symptoms.
4. Restore the Backup in a Test Environment
Before returning the website to the main domain, check the backup for functionality, integrity and malicious modifications.
5. Remove the Root Cause
Close the vulnerability, update outdated software, change compromised passwords and review user access.
If there are signs of infection, you should first check the website for malware. Only after the malicious code and security weakness have been removed should the website return to normal operation.
6. Test the Website After Restoration
After recovery, test contact forms, payments, the shopping cart, customer accounts, third-party integrations, analytics and other business-critical features.
Common Website Backup Mistakes
Storing the Archive on the Same Server
This type of copy may help after the accidental deletion of a file, but it will not protect the website if the entire server fails or access to it is lost.
Backing Up Only Website Files
For a CMS, online store or dynamic website, the most important information is often stored in the database.
Keeping No Version History
A single recent backup may already contain an error. Recovery points from different dates are required.
Relying on Manual Backups Without a Schedule
If the process depends on one person remembering to create a backup, it will eventually be forgotten before an important change.
Never Testing Restoration
Archives may be created every day but still prove unusable during an actual emergency.
Using the Same Account for the Website and Backup Storage
Compromising one account may give an attacker access to both the production website and every backup.
Using an Insufficient Retention Period
Some problems are not detected immediately. If archives are stored for only a few days, a clean recovery point may no longer be available when the issue is discovered.
How to Build a Website Backup System
Most business websites can establish a reliable backup process through several practical steps.
Create an Inventory
Identify where website files, databases, images, configurations, CRM data, email settings and connected service data are stored.
Assess the Importance of the Data
Determine how much information the business can afford to lose and how long the website may remain unavailable.
Choose the Backup Frequency
A static website may need a daily or weekly copy. An online store should have its database backed up much more frequently.
Configure Two Independent Storage Locations
One copy may remain with the hosting provider, while another is transferred to separate cloud storage or another server.
Define the Retention Period
Keep daily, weekly and monthly recovery points, as well as separate archives created before major changes.
Enable Monitoring
The responsible person should receive notifications if a backup fails or the storage is running out of available space.
Test Restoration
Perform a test recovery and document the complete sequence of actions.
Assign Responsibility
The business owner should know who monitors the backups, where they are stored and who is responsible for starting the restoration process.
If the backup system has not been configured or the website needs to be restored after a failure, a professional developer can analyse the code, server and database, then configure a safe recovery process.
What Does a Reliable Backup Strategy Look Like?
A reliable website backup system should meet several requirements:
- backups are created automatically;
- the frequency corresponds to the rate at which new data appears;
- files and databases are copied consistently;
- several recovery points are available;
- at least one copy is stored outside the main infrastructure;
- access to archives is restricted;
- backup data is encrypted;
- failed jobs are monitored;
- restoration is tested regularly;
- a clear recovery procedure is documented.
The goal is not to create as many archives as possible. The purpose of a backup strategy is to ensure that the website can be returned to operation within the required period and without critical data loss.
Conclusion
Website backup is an essential part of business continuity. It protects not only code and images but also customer enquiries, orders, client data, content and the work completed by your team.
For a small website, a daily copy and a separate archive before major changes may be sufficient. An online store, CRM or service that processes continuous operations requires frequent database backups, several independent storage locations and a tested recovery procedure.
Do not wait for the first serious failure to discover whether your backups work. Checking the system today costs significantly less than recovering lost data after an incident.
Need to Check Your Website Backup System?
We will analyse what is included in your backups, where the copies are stored, how many recovery points are available and whether the website can be fully restored from them.
If necessary, we will configure automatic backups, independent storage, error monitoring and a clear restoration procedure.
CTA button: Check My Backup System
FAQ
How often should a website be backed up?
A corporate website should usually be backed up automatically once a day. For an online store or service that processes frequent transactions, the database should be copied every 15–60 minutes. A separate backup should also be created before updates and major changes.
Is an automatic hosting backup enough?
Not always. You need to check what the provider backs up, how long the archives are stored and where they are located. It is safer to maintain an additional copy in an independent storage system.
Should I back up website files or the database?
A complete restoration of a dynamic website usually requires both the files and the database. You may also need server configurations, environment variables, uploaded documents and integration settings.
Where is the best place to store website backups?
One backup may be stored in a separate system provided by the hosting company, while another should be kept in cloud storage or on a server operated by a different provider. Critical data should also have an offline or immutable copy.
How many backup copies should be maintained?
A basic strategy uses three copies of the data: the production version and two backups. You should also maintain archives from different dates rather than several identical copies of the latest state.
How long should website backups be kept?
Daily backups are often kept for 7–14 days, weekly copies for 1–3 months and monthly archives for 6–12 months. The exact period depends on the website type, business requirements and the nature of the stored data.
How can I tell whether a backup is valid?
The most reliable method is to perform a test restoration in a separate environment. Check the pages, administration panel, database, forms, images, orders and integrations.
Can a website be restored from a backup after being hacked?
Yes, provided that a clean backup created before the infection is available. Before restoration, you should identify the cause of the breach, inspect the archive and close the vulnerability to prevent reinfection.
What is the difference between a snapshot and a backup?
A snapshot records the state of a server or disk at a particular moment and may allow quick rollback. However, it is often stored within the same provider’s infrastructure and should not be used as the only backup.
Who should be responsible for website backups?
Responsibility should be assigned to a specific person or technical team. The business owner should know where the backups are stored, who monitors their creation and how the recovery process is initiated.
