A backup is a copy of data created so it can be restored later in case of loss, corruption, or deletion. A backup helps you recover files, a database, or an entire system after a disk failure, a user mistake, or a failed update. It's important to understand right away that a backup is not protection against hacking or an accident. It's simply insurance for your project and all the data stored on it.
What is a backup, in simple terms
Every server stores WordPress files, images, configuration, and a database. If the server fails, just having this data on it won't help anymore. A backup creates a separate instance of the data. The key word here is "separate." If the only copy of a site sits on the same disk as the original, a disk failure will destroy both copies. A backup also differs from plain file copying and synchronization.
Backup and sync aren't the same thing
With synchronization, a service tries to keep files in the same state across multiple locations. If a file is deleted in one place, the deletion can propagate to synced devices as well. The purpose of any backup is to preserve a state of the data that you can return to later. Here's a real-world scenario: an administrator accidentally deleted the site's directory three days ago. If backups are only taken weekly, some of that data will be lost. Daily backups are designed for situations like this. It's even better to not only back up daily, but also keep several versions on hand.
A synced copy is no substitute for a proper backup system. Protecting against accidental deletion, corruption, or encryption requires separate copies and, ideally, version history. NIST specifically recommends not only creating backups, but also keeping them available and verifying that they can actually be restored.
Why you need backups: what risks they cover
Backups aren't just for large companies. Even a small website can lose data for several reasons. Let's go over the most common root causes.
Disk or hardware failure
Even the most modern, reliable drive can fail, and with it, all the site's files, the database, and the server's configuration can vanish. This is exactly why it's critical to keep backups on separate storage — that way you can recover the lost data even if the original hardware is damaged.
User error
The human factor plays a major role in IT. Unplanned incidents happen fairly often. For example, an administrator might accidentally delete a file, a directory, or a database. Or a configuration change goes wrong and breaks the application. When you have the right backup version on hand, you don't have to manually undo every change — you can simply roll back to the state that existed before the mistake.
Failed update
Sometimes failures happen as a result of updating a CMS, a plugin, a library, or system software. Here's an important tip: always create a backup before making major changes. It lets you preserve a working state and roll back if needed.
Malware and ransomware
During an attack, a bad actor often modifies, deletes, or encrypts data. A backup isn't protection against a system being breached, but it does let you restore data after an incident. That said, the backup itself also needs to be protected. If an attacker gains access to a connected backup storage, they can just as easily delete or encrypt it too. NIST and CISA recommend isolating backups and regularly testing the ability to restore from them.
Data corruption
Data doesn't always get corrupted as a result of a complete server failure. Sometimes the database gets corrupted while the site's files remain intact. Having a history of backups gives you the option to pick an earlier, working version.
Types of backups: full, incremental, and differential
Backups differ from each other based on how much data is copied after the initial backup is created.
Backup type | What gets copied | Creation time | Restoration | Size |
Full | All selected data | Longer | Simpler | Large |
Incremental | Changes since the previous backup | Faster | Requires multiple copies | Smaller |
Differential | Changes since the last full backup | Faster than full | Simpler than incremental | Grows over time |
Full backup
A full backup contains the entire selected data set. If you need to preserve 50 GB of files, a full backup copies all 50 GB. The advantage of this approach is clear: you only need one full backup to restore lost data. But there's also a downside — you'll need to store more data and spend more time and resources creating each backup.
Incremental backup
An incremental backup saves the changes made since the previous backup.
For example:
a full backup is created on Monday;
Tuesday's changes are saved on Tuesday;
on Wednesday — the changes made after Tuesday;
on Thursday — the changes made after Wednesday.
This approach saves space and reduces the amount of data that has to be copied each time it runs. But restoring is more complex: to get the system back to its full state, you still need the original full backup plus several incremental backups.
Differential backup
A differential backup saves the changes made since the last full backup. After a full backup on Monday:
on Tuesday, the changes since Monday are copied;
on Wednesday — the changes from Monday through Wednesday;
on Thursday — all the changes since the full backup.
Differential backups grow larger over time, but restoring requires fewer individual pieces than a chain of incremental backups would.
The 3-2-1 backup rule
Have you heard of the 3-2-1 rule for organizing backups? The idea behind it is extremely simple:
3 copies of the data — the original plus two backups;
2 different types of media or storage environments;
1 copy kept off-site.
This strategy is specifically recommended by CISA and other cybersecurity partners in their ransomware protection guidance.
Why does the third part of the rule matter so much? Imagine this scenario: the server and the backup drive are in the same room. A fire, a flood, equipment theft, or some other serious physical incident destroys both the original and the local copy. To prevent irreversible loss, one backup copy needs to be kept off-site — separate from your main infrastructure.
This chain typically includes:
a local copy;
a separate remote storage location.
For the last option, a dedicated FTP storage is a great fit, provided it meets your needs in terms of capacity, access, and storage conditions. That said, 3-2-1 isn't some magic rule that guarantees recovery on its own. Access protection, backup isolation, integrity checks, and regular restore tests all matter just as much.
Where to store backups
Where you store backups directly affects how genuinely useful they are.
On the same server
This is the simplest option, but it can't be considered real protection. If the server or its drive fails completely, both the original data and the backup disappear at the same time.
On a separate server or storage
The copy lives on a different system. This approach offers better protection against the main server failing. But if both servers belong to the same infrastructure or are reachable from the same compromised network, the risk remains.
In cloud storage
Moving backups outside your main infrastructure is possible with remote storage. When choosing this option, consider not just storage volume and price, but also access to the copies, file versioning, account security, and the ability to restore data without access to the original server. For critical data, it's better to combine several storage methods rather than rely on a single point of recovery.
How often to back up
There's no universal backup schedule. Frequency depends on how fast your data changes and how much data loss is acceptable. Consider two sites. The first is a small static landing page updated once every few weeks. Daily backups for it could be overkill. The second is an online store where orders, users, and database changes happen every day. Losing even a few hours of data would hurt. Clearly, this one needs a much more frequent schedule.
The simple principle is this: the more often important data changes, the more often it should be backed up. Decide in advance on the maximum amount of data you're willing to lose in the event of a failure. If a backup is created once a day and the server fails right before the next scheduled run, the changes from the last day may be lost. It's just as important to decide how much time you can afford to spend on recovery. A backup shouldn't just exist — it should let you bring a working system back online within an acceptable timeframe.
Common mistakes when working with backups
Storing all copies next to the original. Never let your live server and your only backup copy depend on the same disk, server, or location. The reason is obvious — an infrastructure failure can wipe out everything at once.
Never testing restores. A file named backup.zip doesn't guarantee the site can actually be restored from it. Periodically check your backups and test the restore process. NIST specifically points to the need to create, maintain, and test backups.
Backing up manually only. Manual backups are easy to forget after a few days or weeks. It's much better to automate the process and have it monitored and periodically checked.
Copying files but forgetting the database. For a CMS like WordPress, a site isn't just files. The database can hold entries, settings, users, comments, and other information. A proper backup strategy needs to cover both files and databases if they're required to restore the project.
Treating synchronization as a full backup. If changes automatically propagate to all copies, a deletion or corruption can propagate right along with them.
For a proper backup, you need the ability to preserve a data state and return to it later.
Conclusion
A backup isn't just a copy of files you saved to another disk once. It's a process of regularly creating, storing, and verifying backups, designed for real recovery after a failure. For basic protection, keep three key principles in mind: multiple copies of your data, separate storage, and the ability to restore information from every critical point. The 3-2-1 rule is a great tool here. It can help you build that kind of setup, and regular testing will show you whether it actually works in practice.
If your project is hosted on a server or with a hosting provider, it's best to think through your backup strategy before a problem ever comes up. A dedicated FTP storage or another independent storage location can become part of that setup, so you're not left keeping the only copy of your data right next to your live server.
FAQ
How is a backup different from file synchronization?
Synchronization keeps data in the same state across multiple locations, while a backup is designed to restore a previous state. Regular synchronization is no substitute for backups with version history.
How often should you back up a website?
It all depends on how often the site changes and how much data loss is acceptable. Frequently updated projects need backups more often than static sites do.
How many backups should you keep?
There's no universal number. Try to have several restore points on hand, so you can roll back not just to the most recent state, but also to an earlier working version, in case the problem isn't discovered right away.
What is an incremental backup, in simple terms?
It's a backup that saves the changes made since the previous backup. Each subsequent increment usually takes up less space than a full copy of all the data would.
Is one backup copy enough to protect your data?
One copy is better than no backup at all, but it creates a single point of failure. A more reliable approach is to keep multiple copies, use different storage environments, and maintain a separate copy off-site.
