Why backups and redundancy are not the same thing
On this page
In web hosting, “redundant” and “backed up” are sometimes used almost interchangeably.
They shouldn’t be.
A redundant storage system can survive certain hardware failures without interrupting service. A backup can restore data after it has been deleted, corrupted, compromised, or otherwise damaged.
Those are very different jobs.
Redundancy is about keeping things running
A simple example is mirrored storage.
If a server stores the same data on two drives and one drive fails, the server can continue operating from the other. Replace the failed drive, rebuild the mirror, and ideally nobody using the website notices anything happened.
That is redundancy doing exactly what it is supposed to do.
The same principle applies at larger scales: replicated storage, redundant power supplies, multiple network paths, clustered services, or failover systems.
They are designed to reduce downtime when a component fails.
But redundancy faithfully reproduces what happens to the data.
And that is where the distinction matters.
If someone deletes a directory, the deletion can be replicated.
If a database is corrupted, the corrupted data can be replicated.
If ransomware encrypts files, the encrypted files can be replicated.
If an administrator makes a bad change, redundancy can make sure that bad change exists very reliably in more than one place.
Redundancy protects availability. It does not necessarily protect history.
A backup gives you a point in time to return to
A proper backup answers a different question:
What did this website look like yesterday, last week, or before something went wrong?
Suppose a WordPress plugin update damages a database on Monday afternoon.
A redundant database setup may ensure that the damaged database remains available despite a server failure. What you actually need, however, may be Sunday’s database.
That requires a backup.
The same applies to problems that are often more common than complete hardware failure:
- accidental file deletion;
- a broken application update;
- database corruption;
- a compromised administrator account;
- malware;
- an incorrectly executed migration;
- a configuration mistake that is only discovered days later.
In all of these situations, having another live copy of the same damaged data may not help very much.
Having an older, known-good copy can.
Backups need redundancy too
There is another important wrinkle: simply having “a backup” is not enough.
Imagine a server that stores the live website on one disk and its nightly backup on another disk inside the same machine.
Technically, there is a backup.
But if the whole server fails, both copies may disappear together.
The same problem exists when backups depend on the same storage system, the same physical location, or sometimes even the same administrative credentials as the production system.
This is why a sensible backup strategy usually includes multiple layers. For example:
Local backups can make everyday restores fast.
Off-server backups protect against failure of the production server itself.
Independent or geographically separate copies provide another layer of protection against larger failures.
Retention matters because sometimes a problem is not noticed immediately. Keeping only yesterday’s copy is of little use if corrupted data has been quietly present for a week.
“We use RAID” is not a backup strategy
This is one of the oldest misconceptions in hosting.
RAID can be extremely useful. So can replicated block storage, clustered databases and highly available infrastructure.
But none of them automatically provide the ability to go backwards in time.
That is the simplest way I know to separate the two concepts:
Redundancy helps you survive a failure. Backups help you undo one.
A reliable hosting setup generally needs both.
How we approach backups at ModHost
At ModHost, we treat backups as a separate layer of protection rather than as something provided implicitly by redundant storage.
Our standard minimum on every hosting plan is 30 days of backup retention, with backup copies maintained in two geographically separate locations. The idea is not simply to have multiple copies, but to avoid making the production server, one storage system, or one physical location the single point on which both the live website and its recovery data depend.
We also regularly test the backup and restoration process. A backup job reporting “success” is useful information, but it is not the same as knowing that the data can actually be restored when it is needed.
Just as importantly, restoring a backup should not have to mean rolling an entire hosting account back in time. Our backup interface provides granular restoration options, so in many cases a customer can restore the particular files, directories, databases, or other data they need. If two WordPress files were accidentally overwritten this morning, restoring those two files is generally a much better solution than replacing the entire account with yesterday’s copy.
That flexibility is especially useful on active websites, where an unnecessary full-account rollback could also discard legitimate changes made since the backup was created.
The restore is what really matters
There is one more uncomfortable truth about backups: creating them is the easy part.
A backup is useful only if it can actually be restored.
That means checking that backups complete successfully, keeping enough retention, knowing where the copies are stored, and periodically verifying that the restore process works.
A dashboard saying “Backup completed successfully” is reassuring.
A tested restore is better.
After more than two decades of running hosting infrastructure, I tend to think of backup systems less in terms of how many copies exist and more in terms of the failures they are intended to survive.
What happens if a drive dies?
What happens if the entire server disappears?
What happens if a file was deleted five days ago?
What happens if an attacker gains access to the website?
What happens if today’s backup contains the same corruption as production?
If all of those questions have the same answer — “we have another copy” — the backup strategy probably deserves another look.
Redundancy and backups solve different problems.
Reliable infrastructure needs to be designed with that difference in mind.