The scenario every host claims to have solved
A plugin update goes wrong at 11pm. Or a hard drive in a shared server rack finally gives out after years of use. Or someone on the team accidentally deletes the wrong database table while cleaning up test data. These aren't rare hypotheticals. They're the three most common reasons a website goes down that has nothing to do with traffic, hacking, or your own code.
Every hosting company's sales page says some version of "don't worry, we take backups." Almost none of them explain what that actually means in practice: how often, stored where, and whether "backup" is even the right word for what they're describing. The terminology gets blurred on purpose, because "we protect your data" sounds reassuring whether it's true in a meaningful way or not.
What a backup actually is
A backup is a complete, point-in-time copy of your website's files and database, taken on a schedule and stored somewhere separate from the live server, ideally encrypted and off the same physical hardware entirely. Its entire purpose is to let you go back in time. If your site is corrupted, hacked, or a bad update breaks something, a backup gives you a known-good version to restore from.
The key details that determine whether a backup is actually useful:
- Frequency: how much work could you lose between backups? Nightly means you could lose up to a day's changes.
- Location: if the backup sits on the same physical drive as your live site, a hardware failure takes both down together. It needs to live somewhere genuinely separate.
- Retention: one backup isn't enough if the problem isn't noticed for a few days. Multiple retained snapshots let you go back further than "last night."
- Restorability: a backup nobody has ever tested restoring is a backup you don't actually have. It should be a routine, verified process, not a theoretical one.
What replication actually is
Replication is a different mechanism solving a different problem: hardware failure and downtime, not data loss over time. Rather than taking a periodic snapshot, replication continuously copies the live state of your server, at the storage block level, to separate physical hardware. WebSpaceBar uses ZFS replication specifically, which uses the ZFS file system's native snapshot and send/receive capability to duplicate file system blocks to an independent host every 300 seconds, or five minutes.
The result is a near-live standby copy of your entire server sitting on hardware that isn't the hardware currently serving your site. If the primary server's disk fails, or a RAID controller dies, or any other piece of physical infrastructure gives out, that standby copy is already up to date within minutes, and traffic can be redirected to it instead of waiting hours or days for a failed drive to be replaced and a backup restored from scratch.
Side by side
| Replication | Backups | |
|---|---|---|
| Protects against | Hardware failure, server-level downtime | Data loss, corruption, bad updates, human error |
| How current is the copy? | Minutes old | Hours to a day old |
| Can you "go back in time"? | No, it mirrors the current state, mistakes included | Yes, that's its entire purpose |
| Recovery speed after failure | Very fast (minutes) | Slower, a full restore takes longer |
| Protects against a hacked or corrupted database | No, corruption replicates too | Yes, if a clean prior snapshot exists |
Why you need both, not either
This is the part that gets glossed over in most hosting marketing: replication and backups solve opposite failure modes, and having one does not cover you for the other. If your only protection is replication and a bad plugin update corrupts your database, that corruption gets faithfully copied to the replica within minutes. You now have two broken copies of your site instead of one, and no way to go back to a working version.
Conversely, if your only protection is nightly backups and the physical server hardware fails, you're looking at however long it takes your host to provision new hardware and restore from last night's backup, potentially losing a day of orders, form submissions, or content in the process. A serious hosting setup runs both layers simultaneously, because they're defending against genuinely different things.
Questions to ask any host
Whether you stay with your current provider or you're evaluating a new one, these questions will tell you more in two minutes than any marketing page will:
- "When you say backups, how often do they run, and where are they stored?"
- "Is the backup on the same physical server as my live site, or somewhere genuinely separate?"
- "If your server hardware failed right now, how long before my site is back online?"
- "Can I request a test restore to confirm a backup actually works, before I need it in an emergency?"
- "Do you have anything beyond backups, some form of live replication or failover?"
A host with a genuinely solid answer will give you specifics without hesitating: exact timeframes, exact locations, exact mechanisms. Vague reassurance is usually a sign the honest answer is "we're not entirely sure either."
How WebSpaceBar handles this
Every WebSpaceBar hosting account runs both layers as standard, not as a paid add-on. ZFS replication copies your file system blocks to independent hardware every 300 seconds, so a hardware failure on the primary server doesn't mean starting from scratch. On top of that, nightly encrypted backups push a separate, retained snapshot offsite, specifically so a bad update, plugin conflict, or accidental deletion can be rolled back to a clean point, which replication alone can't undo.
See the full architecture
We've written up the complete technical breakdown of how replication, backups, and failover fit together on WebSpaceBar's platform.
Frequently asked questions
Is server replication the same as a backup?
No. Replication continuously copies your live server state to separate hardware so you can fail over quickly if the original server breaks. A backup is a point-in-time snapshot stored separately, kept specifically so you can roll back after data loss, corruption, or a mistake, which a live replica cannot protect against by itself.
If I have replication, do I still need backups?
Yes. Replication protects you from hardware failure by keeping a near-live copy elsewhere, but if your site is deleted, corrupted, or hacked, that damage typically replicates too. Backups exist specifically to let you roll back to a clean point before the problem happened, which replication alone cannot do.
How often should a host back up my website?
Nightly backups are the standard for active business websites, since they limit potential data loss to at most a day's worth of changes. Sites with frequent transactions, like WooCommerce stores, benefit from more frequent backup or replication cycles measured in minutes rather than hours.
What is ZFS replication?
ZFS replication is a method of copying file system blocks from a live server to separate hardware at the storage layer, using the ZFS file system's built-in snapshot and send/receive capabilities. It allows a near-real-time copy of a server to exist on independent hardware, ready to take over quickly if the original fails.