Backup is a recovery copy of active data, kept for a limited window, meant to restore something that broke, was deleted, or was encrypted. Archive is a copy of inactive data, kept for years because a rule or law says so, meant to be searched and produced, not restored in a hurry. Replication is a continuously or near-continuously updated standby copy of a running VM, meant to fail over in minutes with almost no data loss. Offsite vs. onsite isn't a fourth type of copy, it's a location decision that applies to backup and replication alike, and it's the one thing that determines whether any of these copies survives the loss of the building they started in.
Key Takeaways
Backup = short-to-medium retention, restore speed matters, protects against corruption/deletion/ransomware.
Archive = long retention, indexed and often immutable, protects against non-compliance and evidentiary gaps, not against downtime.
Replication = near-zero RPO, standby VM ready to power on, protects against host/hardware failure, but only against site failure if the target is offsite.
Offsite vs. Onsite is a location axis, not a copy type, it applies independently to backup and to replication, and each combination has a different failure mode it doesn’t cover.
The most common protection gap isn’t missing a method, it’s assuming one method’s strength (replication’s speed, backup’s frequency, archive’s permanence) covers a risk that only a different method, or a different location, actually covers.
A resilient VM strategy layers all three purposes with at least one offsite, immutable leg, the logic behind the CISA-endorsed 3-2-1-1-0 rule.
What Each Term Actually Means?
Backup
A backup is a point-in-time copy of data, made so that if the original is lost, corrupted, deleted, or encrypted, it can be restored. The Storage Network Industry Association (SNIA) dictionary defined it exactly this way: a collection of data stored for the purpose of recovery, made from a source image while it's in a consistent state. Backups are taken on a schedule, hourly, nightly, weekly, and older ones are deleted as new ones are made, following a retention policy measured in days or months, not years.
Archive
An archive is a copy of data that has stopped changing, or is no longer part of active operations, kept because a regulation, contract, or internal policy requires it to exist and be retrievable later. SNIA's data-protection literature is explicit that archives are normally used for auditing or analysis rather than application recovery, and that once data is archived the active online copy is often deleted. That single distinction, archives are searched and produced, not restored in an emergency, is what separates the two concepts operationally, even when the underlying storage looks similar.
Replication
Replication keeps a second, running-ready copy of a VM in sync with the source, using continuous or scheduled block-level updates rather than periodic backup jobs. Its output isn’t a backup file, it’s a VM that can be powered on at the target site with a recovery point measured in minutes. VMware’s own vSphere Replication documentation describes configuring a target recovery point objective and retaining multiple points in time, with supported RPOs ranging from roughly one minute up to 24 hours depending on edition and network capacity.
Offsite vs. Onsite
This pair isn't a data-copy type at all, it describes where a copy (backup or replica) physically or logically lives relative to production. Onsite means the same building, rack, or local network as the source VM. Offsite means a different site: a second data center, a colocation facility, or a cloud region with no shared power, network path, or administrative domain with production. The distinction only matters for one reason: what kind of disaster the copy can survive.
Backup vs. Archive: The Practical Differences
Dimension
| Backup
| Archive
|
Primary trigger | Scheduled job on active/production data | Data leaving active use, or a retention rule taking effect |
Retention | Days to months, rolling window | Years, often fixed by regulation or policy |
What it protects against | Deletion, corruption, ransomware, host failure | Non-compliance, failed audits, lost evidentiary record |
Restore expectation | Fast, whole-VM or whole-file restore | Slower, targeted retrieval of specific records |
Indexing/search | Usually job- or whole-file restore | Typically indexed for search and legal discovery |
Deletion of source | Source data stays active and online | Source data is often removed once archived |
The regulatory angle is worth sitting with. SEC Rule 17a-4 requires certain broker-dealer records to be preserved on non-erasable, non-rewritable media, with a defined portion immediately accessible for regulators, a requirement about indexed, tamper-evident retrieval, not about restoring a crashed server. GDPR Article 5’s storage-limitation principle works from the opposite direction: personal data generally shouldn't be kept longer than the purpose requires, though it carves out an explicit exception for archiving in the public interest and for scientific, historical, or statistical purposes. Neither rule mentions "backup", both describe an archive's job.
Backup vs. Replication: The Practical Differences
Dimension
| Backup
| Replication
|
Update pattern | Scheduled, point-in-time jobs | Continuous or near-continuous block sync |
Typical RPO | Hours (job interval) | Minutes, sometimes under five |
Typical RTO | Longer - restore, then boot | Short - power on the standby copy |
Version history | Multiple restore points retained | Usually one current state, or a short window of recent points |
Storage format | Deduplicated/compressed backup repository | A runnable VM disk at the target |
Ransomware exposure | Isolated repository can be excluded from encryption spread | Live sync can propagate encryption to the replica if not paused in time |
Infrastructure cost | Storage capacity at the repository | Standby compute plus storage at the target, often idle |
The ransomware row deserves emphasis, since it's the most common reason replication alone disappoints people. Because replication mirrors block changes as they happen, an in-progress encryption event can reach the replica before anyone notices, unless the replication engine keeps multiple retained points in time and someone rolls back far enough. A backup repository that's logically or physically separated from production, by contrast, only takes in what a scheduled job pulls, so a clean restore point from before the attack usually still exists. This is precisely why CISA’s #StopRansomware Guide calls for offline or immutable backup copies as a specific, separate control, not a substitute for replication, and not replaced by it.
Offsite vs. Onsite: The Practical Differences
Dimension
| Onsite copy
| Offsite copy
|
Protects against | Deletion, corruption, single-host/disk failure | Everything onsite |
Restore speed | Fast, local network, no WAN transfer | Slower, bound by bandwidth to the offsite target |
Cost driver | Local storage capacity | WAN bandwidth, egress fees, or physical transport |
Failure independence | Share power, network, and building with production | Independent power, network path, and physical location |
Typical mechanism | Local repository, secondary array, second cluster node | Cloud storage, a second data center, tape shipped offsite |
Neither location is optional in a serious strategy, they answer different questions. Onsite gives you speed for the failures that happen constantly (a bad patch, a fat-fingered delete, a failed disk). Offsite gives you survival for the failure that happens rarely but ends the business if you're not ready for it. Proxmox Backup Server’s own documentation illustrates the distinction cleanly at the tooling level: its cluster-level replication operates between local nodes for fast high-availability failover, while its remote sync jobs, explicitly used to pull backup data to a second PBS instance, typically across sites, are what the platform’s documentation treats as the offsite mechanism. They are not the same feature solving the same problem, even though both involve copying a VM’s data somewhere else.
Decision Matrix: Which One to Use
If the goal is...
| Use
| Place it...
| Because
|
Recover from accidental deletion or corruption fast | Backup | Onsite, primary target | Speed matters more than site independence for routine failures |
Survive a site-level disaster or ransomware hitting the primary repository | Backup | Offsite, immutable or air-gapped copy | Must be unreachable from a compromised production network |
Fail over a critical VM in minutes with almost no data loss | Replication | A genuinely separate site or availability zone | Onsite replication only survives host/hardware failure, not site loss |
Retain records for years to satisfy a legal or regulatory requirement | Archive | Indexed, often offsite or cloud-tiered | Retention length and searchability, not restore speed, are what’s tested |
Prove data wasn’t tampered with during retention | Archive (or immutable backup) | WORM/immutable storage class | Matches the intent of rules like SEC 17a-4 |
Two Field Patterns Worth Recognizing
Pattern 1: Fast replication, slow discovery of the real gap
A mid-sized company running a database cluster on VMware configured near-real-time replication to a second host inside the same server room, satisfied that a multi-minute RPO meant they were covered. A ransomware event encrypted the primary VM's disks and, within the same sync interval, propagated to the replica before anyone paused replication. The only intact recovery point turned out to be an overnight backup stored in a separate, access-restricted repository that the ransomware's credentials never reached. Recovery worked, but it came from the method with the worst RPO, because it was the only one that had actually been placed somewhere the incident couldn't touch. Nothing about the replication configuration was wrong; it did exactly what a same-site replica does.
Pattern 2: Backups that were never going to satisfy the auditor
An organization under a multi-year record-retention obligation had a well-run nightly backup rotation with a 90-day window, and assumed that was sufficient evidence retention. When a compliance review asked for records from 14 months earlier, nothing remained — the rotation had cycled through and deleted them long before, exactly as designed, because a backup rotation isn't built to remember what happened over a year ago. The gap wasn't a backup failure; the backup system did precisely what it was configured to do. What was missing was a separate archive with retention and indexing built around the regulation's timeline rather than around operational recovery needs.
Native hypervisor tooling generally covers backup and replication as two separate features, and rarely handles the offsite leg or long-term retention out of the box, which is why many teams run a dedicated VM backup platform on top. Vinchin Backup & Recovery, for example, runs the local backup job and an automated backup-copy job to a second, offsite repository from one policy, across VMware, Hyper-V, Proxmox, XenServer, KVM, RHV, and OLVM, closing the backup-to-offsite gap without requiring a second, separately managed system.
How to Validate your Backup, Archive, Replication, and Offsite Strategy
A protection plan that has never been tested is a hypothesis, not a plan. Each method covered above fails silently in a different way, a job that reports “success” for months can still be unrestorable, application-inconsistent, unreachable, or sitting behind the exact credentials an attacker already has. The checks below are what actually catch that, in roughly the order they’re worth doing.
1. Run test restores on a schedule, not only after an incident
l Pick a sample of VMs across different applications and repositories, not just the easiest ones, and restore them to an isolated network on a recurring calendar, monthly for critical systems is a reasonable baseline.
l Boot the restored VM and confirm the application inside actually starts and serves data, not just that the restore job finished without an error.
l Time the restore. A job that "works" but takes fourteen hours against a four-hour RTO commitment is a finding, even though nothing technically failed.
l Rotate which restore point is tested: the most recent one, a mid-retention one, and the oldest one still in the window, since corruption in an older chain link often goes unnoticed until it's needed.
2. Verify backups are application-consistent, not just disk-consistent
Confirm the backup job is using VSS (Windows) or a comparable application-aware quiescing mechanism (Linux pre/post-freeze scripts) for databases, mail servers, and anything else that keeps data mid-transaction in memory.
After a restore test, check the application’s own consistency tools, a database integrity check, a mail store repair utility, rather than assuming a clean boot means clean data.
Treat a “crash-consistent only” backup as a known gap for transactional workloads, and document which VMs fall into that category so it isn’t discovered during an actual recovery.
3. Confirm the offsite repository is actually reachable
Test connectivity from a machine that isn’t the production backup server itself, a network path, firewall rule, or VPN tunnel that only the primary server uses is a single point of failure hiding inside an “offsite” copy.
Confirm current bandwidth against the volume of data that would need to come back during a real recovery; a link that comfortably handles nightly incremental uploads can still be far too slow for a full-scale restore.
Periodically pull a sample restore point from the offsite copy specifically, not the local one, since a copy job can succeed while quietly writing corrupted or incomplete data at the far end.
4. Verify the offsite copy uses independent credentials and MFA
Check that the account writing to the offsite target is not the same domain-admin, root, or service account used in production, a single compromised credential should not be able to reach both.
Require multi-factor authentication on the offsite/cloud console itself, separate from whatever authentication protects the backup software’s own admin interface.
Review who and what can delete or modify retention settings on the offsite repository; if the answer is "anyone with production domain-admin rights," the offsite copy offers little protection against a compromised administrator account or a credential-based ransomware attack.
5. Match immutable, WORM, and air-gap controls to the right threat
These three terms get used almost interchangeably, but they suit different situations:
Control
| What it actually does
| Best fit
|
Immutable repository | Software-enforced lock preventing deletion/modification for a set period, while the system stays network-connected | Day-to-day ransomware resilience where recovery speed still matters |
WORM (write once, read many) | Hardware- or firmware-level enforcement that data can’t be overwritten once written, often paired with a compliance clock | Regulatory retention where the control itself may need to be demonstrated to an auditor, e.g. under SEC 17a-4-style requirements |
Air-gap | Physical or logical disconnection from any network between copy operations | The highest-value, highest-risk systems, where the goal is a copy no network-based attacker can reach at all, even with valid credentials |
In practice, these layers rather than compete: an immutable repository handles the everyday case, a WORM-classed target satisfies a specific regulatory clock, and an air-gapped copy, even one refreshed weekly rather than nightly, is the fallback for the scenario where every network-connected control has already been compromised.
FAQs
Q1: Can replication and backup run against the VM without conflicting?
Yes. Replication tracks changed blocks continuously through the hypervisor's change-tracking layer, while backup runs as a scheduled job against a snapshot. They read the same disk independently and don't lock each other out, though running both at once increases the storage I/O and network load on the source host, so most teams stagger backup windows away from peak replication sync intervals.
Q2: Is data stored in a public cloud automatically an offsite copy?
Not automatically. It's offsite in the geographic sense, but if it shares the same identity provider, the same admin credentials, or a continuous sync mechanism with production, a single compromised credential can still reach it. A copy only counts as a true offsite/DR copy when it has independent authentication and, ideally, a different write path than production.
Q3: What should be checked before trusting a secondary data center as the offsite location?
Confirm it doesn't share a power grid, ISP backbone, or regional weather-risk zone with the primary site, and confirm the credentials used to write to it aren't the same domain-admin or root account used in production. A second building on the same campus, or a cloud region in the same metro area, often fails both tests even though it looks offsite on paper.
Q4: How does Vinchin Backup & Recovery fit into a strategy that needs backup, an offsite copy, and long-term retention together?
It runs the local backup and an automated backup-copy job to a second, offsite repository from a single policy, across VMware, Hyper-V, Proxmox, XenServer, KVM, RHV, and OLVM, and supports tiering older restore points to lower-cost storage for extended retention, so the backup and offsite legs of a protection strategy aren't built and monitored as two disconnected systems.
Q5: Why does a restored VM sometimes come back application-inconsistent even though the backup job reported success?
A backup job can complete successfully at the disk level while still capturing a database or application mid-transaction if the hypervisor snapshot wasn't quiesced through VSS or a similar application-aware mechanism. The job status reflects whether the data was copied, not whether the application inside the VM was in a recoverable state at that instant — which is why application-consistent snapshot support is a separate setting from the backup schedule itself.
Conclusion
Backup, archive, and replication answer different questions: how fast can we recover, how long must we keep this, how little data can we afford to lose, and onsite versus offsite decides which disasters any of those answers actually survive. Treating one as a substitute for another is where real gaps hide. A durable strategy names each risk first, then assigns the method and location built for it.
