Beware the imitation: they look similar to backups but will leave you stranded

TL;DR Summary

It’s easy to tell whether something is a “genuine backup” or not – it’s about whether it can save your bacon. Regardless of how a technology is marketed or perceived, if it can’t save your bacon in all the disaster scenarios that you care about, it’s simply inadequate.

Worse still, confusing jargon and acronyms like RAID, HA, DR, CDP, Cloud Sync can trick people into a false sense of security! I’ll debunk the myths and false perceptions in this article, so you won’t find yourself unwittingly making decisions that cost you in the future.

Let’s cut the jargon and get real. What’s a “genuine backup”?

With so much I.T. jargon flying around, let’s instead go back to basics to get some clarity.

A backup is something that will save you if your main “thing” fails.

* A backup power generator kicks in when the electricity grid fails.

* Spare tires in cars are a backup in case a main tire gets punctured or fails.

* You set two alarms for an important meeting, just in case one fails.

So the only requirement for a backup to be effective is that the backup must be able to take over if the main thing fails.

This sounds super simple and obvious!

So why then do so many people confuse what is and is not an effective, “genuine backup”?

Confusion is a systemic problem perpetuated by the I.T. industry

I find that most people want to do the right thing, but unwittingly end up doing the wrong thing.

When I ask them why, I invariably discover the same problem that’s rampant in the I.T. industry – specifically that jargon and over-promises used in vendor marketing can deceive people easily.

For example, the term “Business Continuity / Disaster Recovery (BCDR)” is used by vendors of live replication products to mean “if one site goes down, the other will take over”. And it’s a legitimate scenario – if site A gets destroyed by a tornado, site B (in a different location) will take over, thereby providing business continuity.

However, the same BCDR acronym may be used by a backup software vendor to mean, “if you get infected with ransomware, you can recover from backup.” And it’s a legitimate claim – without your backup, your business would grind to a halt… but with a backup, you can recover from this disaster and continue on…

So if two products offer BCDR, it’s easy to conclude that they are equivalent. But that is far from the truth.

You’d never say to yourself, “my car has four wheels; my suitcase has four wheels, therefore my car is my suitcase”. That clearly makes no sense! But that’s what people do when they confuse genuine backups with the many imitation backups.

Let me try to make things clear now.

What are the consequences of being tricked?

I can boil down the consequences of having an imitation backup rather than an effective backup. You’ll have one of two key problems:

1. You’ll lose a substantial amount of data, AND / OR
2. The recovery will be difficult and stressful.

Neither situation is one you’ll want to experience.

At BackupAssist, we have a saying that the right backup will give you a straightforward and predictable recovery. Ultimately, that’s what matters.

So what are some imitation backups, so I don’t get fooled?

There are a number of technologies that may give you a similar sense of security as backups do, but they’re not actually going to save you from the risks you need to protect against.

Here are my top 6 list of imitations (not a real backup).

1. RAID arrays
2. Snapshots (such file system or VSS snapshots)
3. Live replication (HA / DR)
4. File sync & sharing tools like Dropbox, OneDrive, Google Drive

Some that come really close to having many properties of backup, but ultimately still fail to meet the “straightforward recovery” requirement:

5. Git and version control
6. Infinite file versions on the same cloud service

Seeing the gaps at a glance

It’s easiest to see the gaps and deficiencies of each imitation in this table of data loss and recovery scenarios (click to enlarge) –

Key insights from the table:

• No single imitation protects against all scenarios
• RAID only protects against drive failure, and nothing else
• Cloud-based solutions are vulnerable to account compromise
• Live replication fails against logical disasters (corruption, deletion, ransomware)
• Version control systems only protect what’s explicitly tracked

Now let’s look at each imitation in detail

You’re still reading? Great – you’re as passionate about backups as I am! Kudos to you!

Let’s go through each of these six, explain what they are, why they may feel like backups, but where they will be inadequate at saving the day.

1. The RAID Array

What it is: RAID stands for Redundant Array of Independent Disks. It spreads your data across multiple hard drives so that if one drive physically fails, your data remains accessible from the other drives.

What it protects against:

• Individual hard drive failure
• Continued operation while replacing a failed disk
• Hardware defects in a single disk

Where it fails:

• Accidental deletion – Delete a file, and it’s instantly deleted across all disks in the array
• Ransomware/malware – Encrypts or corrupts data across all disks simultaneously
• Fire, flood, or theft – All disks are in the same physical location and get destroyed together
• RAID controller failure – The controller itself can fail and corrupt data on all disks
• Multiple disk failures – If more disks fail than your RAID level can handle, you lose everything
• Logical corruption – Filesystem corruption affects all disks at once
• Human error or sabotage – Any intentional or accidental changes propagate to all disks immediately

In summary: RAID protects against hardware failure, not data loss. It keeps your system running when a disk dies, but it won’t save you from the most common causes of data loss – human error, malware, or natural disasters.

2. The File System Snapshot

What it is: Snapshots are point-in-time copies of your data, typically stored on the same storage system. Common examples are Windows VSS (Volume Shadow Copy Service) persistent snapshots, or on Unix systems, ZFS and BTRFS snapshots. They’re space-efficient because they only record changes rather than duplicating everything.

What it protects against:

• Accidental file deletion or modification (you can roll back to a previous snapshot)
• Failed software updates or system changes (revert to before the change)
• Quick recovery from recent mistakes (within the snapshot retention period)

Where it fails:

• Same storage location – If the underlying storage fails, becomes corrupted, or is physically destroyed, all snapshots are lost with it
• Hackers & ransomware can delete snapshots – hackers can easily delete snapshots if they have administrator access. Sophisticated ransomware is even more dangerous, automating the process.
• Limited retention – Snapshots are typically kept for short periods (hours to weeks) and automatically deleted as space fills up
• Not offsite – Fire, flood, theft, or any site-level disaster destroys both your data and all snapshots
• Administrator access – Anyone with admin rights can delete all snapshots, whether accidentally or maliciously

In summary: Snapshots are excellent for quick “oops” recovery and rolling back recent changes, but they live and die with your primary storage. They’re a convenience feature, not a disaster recovery solution.

3. Live Replication Systems (HA/DR)

What it is: Live replication maintains synchronized copies of your data, virtual machines, or databases across different servers or locations. This includes High Availability (HA) systems for automatic failover within a data center, and Disaster Recovery (DR) replication to geographically separate sites. Examples include VMware vSphere Replication, Hyper-V Replica, SQL Server Always On, Zerto, and cloud solutions like Azure Site Recovery.

What it protects against:

• Hardware failure at the primary site (the replica takes over)
• Site-level disasters like fire or flood (if replicated to a different location)
• Planned maintenance downtime (failover to replica while servicing primary)

Where it fails:

• Accidental deletion – Delete a file or database, and it’s instantly deleted on the replica
• Ransomware – Encryption propagates to the replica within seconds or minutes
• Logical corruption – Database corruption, filesystem errors, or application bugs are mirrored to the replica
• Malicious insider – An attacker with access can destroy both primary and replica
• No point-in-time recovery – You can only fail over to the current state, not to “before the problem happened”
• Software bugs – A bad update or configuration change affects both systems
• Compromised credentials – If an attacker gains access, they typically can access both locations

In summary: Replication keeps you running when hardware fails or a site goes down, but it mirrors problems just as quickly as it mirrors data. It maintains the current state, not historical states—which is exactly what you need in a disaster. You need to always ask this key question: “Can I recover from a point in time before the problem occurred?” If not, it’s replication, not backup.

4. File Sync & Sharing Tools (Dropbox, OneDrive, Google Drive)

What it is: Cloud-based file synchronization services that keep your files in sync across multiple devices and stored in the cloud. Popular examples include Dropbox, OneDrive, Google Drive, Box, and iCloud Drive. Many offer limited version history features (typically 30-90 days).

What it protects against:

• Device loss, theft, or hardware failure (files remain accessible from other devices and the cloud)
• Accidental device damage (your laptop dies, but files are still in the cloud)
• Recent file modifications (you can restore previous versions within the retention period)

Where it fails:

• Accidental deletion syncs everywhere – Delete a file on one device, and it’s deleted from all devices and the cloud within seconds
• Ransomware propagates to the cloud – If ransomware encrypts your local files, those encrypted files sync to the cloud, overwriting your good files
• Limited version history – Most consumer plans keep versions for only 30 days; after that, you can’t recover older versions
• Account compromise – If someone gains access to your account, they can delete everything from all locations. Especially dangerous is the “remote wipe” feature that allows attackers to delete data from synced devices.
• Sync bugs can cause mass deletion – Software glitches have been known to sync deletions that shouldn’t have happened
• Shared folders multiply the risk – Anyone with access to a shared folder can accidentally (or intentionally) delete files for everyone
• No true isolation – All copies are connected to the same account and authentication system
• Malware with cloud access – Modern malware can use your credentials to delete cloud copies too

In summary: File sync tools are fantastic for collaboration and accessing your files anywhere, but they’re designed for convenience, not protection. They keep multiple copies of your current files, but when something goes wrong, that wrong state propagates everywhere almost instantly.

And now for the honorable mentions

There are two technologies that I think come really close to bona fide backups, and very often lure people into not performing backups because of their similarities.

But these two imitations come with a severe flaw: while you might not lose your data, it can be difficult and time consuming to recover.

5. Git and Version Control

What it is: Version control systems like Git, Subversion (SVN), or Mercurial track every change made to files over time, creating a complete history. You can roll back to any previous version of any file. Git repositories are often distributed across multiple developers’ machines and remote servers like GitHub or GitLab.

What it protects against:

• Accidental file modifications or deletions (revert to any previous commit)
• Bad code changes (roll back to when things worked)
• Complete change history with author attribution (know who changed what and when)
• Distributed copies (multiple people have full repository history)

Where it fails:

• Only tracks committed files – If you forget to commit your work, it’s not protected
• Requires manual action – You must remember to commit regularly; there’s no automatic protection
• Doesn’t track everything – System configurations, databases, compiled binaries, and large files are typically excluded. If everything were put into version control, the repository would grow impracticably big.
• Limited to the repository – Files outside the Git repository aren’t protected at all
• Force pushes can destroy history – With the right (or wrong) commands, history can be rewritten or lost
• Repository corruption – The entire Git repository can become corrupted, taking all history with it
• Requires technical knowledge – Non-technical users often struggle with version control concepts
• Not designed for full system recovery – Can’t restore your entire development environment, just the code files. And worse still, if your remote repository gets destroyed (without a genuine backup in place), recovering can be a nightmare as code needs to be manually re-committed and pushed.
• Remote repository access – If compromised accounts have push access, malicious changes can be pushed to all copies

In summary: Git is excellent for tracking code changes and collaboration, and developers (me included!) often rely on it to recover from coding mistakes. However, it only protects what you explicitly commit, requires discipline and technical knowledge, and isn’t designed to back up entire systems or non-code assets. It’s version control, not comprehensive backup.

6. Infinite File Versions on the Same Cloud Service

What it is: Some cloud storage services offer extended or unlimited version history as a premium feature. For example, Dropbox Business offers unlimited version history, Google Workspace keeps versions for 30 days to indefinitely (depending on plan), and OneDrive for Business can be configured for longer retention. This means you can recover any version of any file from weeks, months, or even years ago.

What it protects against:

• Accidental file changes or deletions (recover from any point in history)
• Ransomware that encrypts files (restore from versions before the attack)
• Long-term mistakes (realized months later that you need an old version)
• Gradual data corruption (go back to before corruption started)

Where it fails:

• Lack of non-destructive point in time restore en masse – two of the major providers provide revert or rollback capabilities on a cloud drive, meaning once you do that, you’ll lose any changes since the target rollback time. Another major provider forces you to restore individual files from the file history. All these options are inadequate. In recovery scenarios, the utmost care must be taken, usually requiring (a) a restore to a specific point in time, (b) restoring to a different location, not over the top of existing data, (c) previewing the restore action before actually doing it.
• Single point of failure – All versions are stored with one service provider under one account, meaning a single account compromise or vendor failure leaves your primary copy of data, and version history, vulnerable.
• No true air-gapping – All versions are accessible online, making them vulnerable to sophisticated attacks
• Service discontinuation – If the company is acquired, changes business models, or shuts down, your versions could disappear – this is more likely to apply to smaller cloud storage vendors but nonetheless is still a risk.

In summary: Extended version history is significantly better than basic file sync and comes very close to being a proper backup. However, lack of proper restore features make it impractical to restore files en masse, while keeping everything with a single provider under a single account creates a single point of failure. A true backup strategy requires copies that are truly independent and isolated from your primary systems.

Now you can spot the imitation and avoid being fooled, what’s next?

It’s understandable why so many people think that the imitation backup can substitute a real one. But I trust you can now spot the differences.

So where to from here?

1. Audit what you have – Go through each technology you’re currently using and honestly assess it against the scenarios in the table above
2. Ask the right questions – When a vendor claims their product provides “data protection,” “BCDR,” or “CDP,” ask specifically: “Can I recover from a ransomware attack? Can I restore to a point in time before the problem occurred?”
3. Don’t eliminate the imitations – RAID, snapshots, replication, and cloud sync all have legitimate uses. Keep using them for what they’re good at – just don’t mistake them for backups
4. Make sure you have genuine backups – Whether you use backup software, cloud backup services, or managed backup solutions, make sure you have genuine backups that are isolated, immutable, and tested regularly
5. Test your recovery – The best backup is worthless if you can’t actually recover from it. Test regularly to ensure your recovery process is truly straightforward and predictable

When disaster strikes, you’ll be grateful you invested in the real thing.