Comparison · Backup and recovery
Backup vs replication vs file sync vs snapshots
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Backup keeps independent, versioned copies you can roll back to. Replication mirrors data to another site for fast failover but copies mistakes and corruption. File sync keeps files consistent across devices and also propagates deletions. Snapshots capture a point in time on the same storage and are fast but share its fate. Strong protection combines mechanisms rather than treating them as interchangeable.
Who this is for: A manager or administrator who has been told their data is protected by one of these mechanisms and wants to know what each one actually survives.
What to evaluate
Ability to go back in time
Recovering from corruption or malicious encryption requires an older clean version.
How to check: Ask each mechanism how far back versions exist and how you restore one.
Independence from the source
Protection that fails when the source system or its credentials fail is limited.
How to check: Identify whether the copy sits on separate storage, in a separate location and under separate credentials.
Recovery time
Replication can switch quickly, while restoring from a backup may take longer.
How to check: Define how long each system can be down and test whether the mechanism meets it.
Data loss tolerance
The gap between the last copy and the failure determines what work is lost.
How to check: Compare copy frequency with how much data you could afford to re-create.
Complexity and cost
Real-time replication and standby systems cost more to build and operate than scheduled backups.
How to check: Reserve higher-cost mechanisms for the systems whose downtime justifies them.
Comparison
| Mechanism | Protects against | Does not protect against |
|---|---|---|
| Backup with versions | Deletion, corruption, ransomware, hardware loss if stored separately | Slow restores if poorly planned; gaps if never tested |
| Replication | Site or hardware failure with fast failover | Accidental deletion and corruption, which replicate too |
| File sync | Convenience and device loss for synced folders | Deletion and malicious encryption spreading to every device |
| Storage snapshots | Quick rollback from recent mistakes | Loss of the storage system itself, and attackers with array access |
| Archive | Long-term retention for compliance or reference | Rapid operational recovery, since archives are not built for it |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 5 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Ability to go back in time | |||
| Independence from the source | |||
| Recovery time | |||
| Data loss tolerance | |||
| Complexity and cost | |||
| Total (max 15) | 0 | 0 | 0 |
Questions to ask before you commit
- Which mechanisms protect today each important system, and what does each one survive?
- Do snapshots live on the same storage or under the same credentials as the live data?
- Does replication include any delay or version history to recover from corruption?
- How would we recover if an attacker deleted both production data and its replica?
- What is the longest period for which we can restore a clean version?
- Who can change retention or delete copies, and are those actions logged?
- How does each mechanism handle databases that need consistent copies?
Typical trade-offs
Real-time replication versus scheduled backup
- Upside
- Near-instant failover and minimal data loss.
- Downside
- Replicates damage instantly and costs more to run.
Snapshots for speed versus backups for independence
- Upside
- Snapshots restore quickly with little overhead.
- Downside
- They fail together with the storage and credentials they depend on.
Simple single mechanism versus layered approach
- Upside
- Simplicity reduces effort and confusion.
- Downside
- A single mechanism leaves specific failure types uncovered.
Common mistakes
- Calling replication a backup. A deleted file is deleted everywhere within moments.
- Relying on snapshots stored on the same array as production data.
- Trusting file sync as protection from ransomware. Encrypted files sync like any other change.
- Ignoring the gap between copies. Measure how much work could be lost and compare with tolerance.
- Layering mechanisms without testing how they combine in a real recovery.
Related questions
Can replication replace backup?
No. Replication is for availability: keeping a second copy ready if the first fails. Because it copies changes, it also copies deletions, corruption and malicious encryption. Backup holds earlier versions that let you step back. Many resilient designs use replication for fast failover and backup for recovery from errors and attacks. If you can afford only one for a given system, choose based on whether downtime or data damage is the larger concern.
Are snapshots enough on their own?
Snapshots are valuable for quick rollbacks, such as after a bad update. Their weakness is dependence on the same storage system and often the same administrative credentials. If the array fails, is destroyed or is accessed by an attacker, snapshots can be lost. Treat them as a convenience layer and ensure an independent backup copy exists elsewhere under separate controls.
Why does ransomware defeat file sync?
Because sync clients faithfully upload whatever changes appear locally. When malware encrypts local files, the encrypted versions replace good ones in the cloud and on other devices. Some services keep version history that allows recovery, but the history is limited and sits under the same account. Combine sync with a separate backup and limit who can access shared folders to reduce impact.
Which mechanism should I use for a database?
Databases need consistency, so use methods the database supports: native backup tools, log shipping or application-aware snapshots coordinated with the database. Replication helps with availability, while point-in-time recovery relies on retained logs and backups. Test restores into an isolated environment and verify the data is usable by the application, not merely that files exist. Document the sequence for rebuilding the service.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Small business guide — National Cyber Security Centre, retrieved 27 October 2026
- Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1) — National Institute of Standards and Technology, retrieved 27 October 2026
Related guides
How to choose · Backup and recovery
How to choose a business backup solution
Choose backup by what you must restore and how fast, then test it. Look for protection of every data source including cloud applications, immutable or offline copies that attackers cannot erase, separate credentials from your main environment, encryption, and restore testing you can actually perform. A backup that has never been restored is an assumption, not a control.
Requirements · Backup and recovery
Setting recovery point and recovery time requirements
Recovery point objective is how much recent data you can afford to lose, and recovery time objective is how long a system can be unavailable. Set them per system by asking the business what an outage costs in operations, obligations and trust, then choose backup and recovery methods that meet them. Tighter objectives demand more cost and operational effort, so rank systems rather than demanding the same target for all.
Problems & fixes · Backup and recovery
Why backups fail when you need them and how to make them ransomware-resilient
Backups fail in predictable ways: attackers delete or encrypt them using stolen administrator access, jobs fail silently, restores are slow or incomplete, and keys or documentation are missing. Resilience comes from isolated or immutable copies, separate credentials, monitored jobs, regular restore tests and a rehearsed rebuild order that includes identity services.
Comparison · Identity and access
Passkeys, authenticator apps, hardware keys and text message codes compared
Methods differ mainly in how resistant they are to phishing and in how easy they are to deploy and recover. Passkeys and hardware security keys bind sign-in to the genuine site and resist phishing. Authenticator app codes are a solid, widely supported middle option. Text message codes are better than a password alone but are exposed to interception and number takeover, so reserve them as a fallback.
Cost factors · B2B software
What drives ERP implementation cost and overruns
ERP cost is dominated by effort rather than licenses: scoping, data cleanup and migration, configuration, integration, customization, testing, training and change management. Overruns usually come from unclear scope, poor data, late requirement changes, and underestimated internal staff time. Budget by workload, hold contingency for discovery, and make scope decisions explicitly rather than letting them accrete.
Cost factors · Endpoint protection
What drives the cost of endpoint protection
Endpoint protection cost depends on device count, which capability tier you license, data retention, any managed monitoring, and the staff time required to run it. Quotes that look similar can hide different definitions of a device, different support levels and add-on modules. Compare total operating effort, not only the licence line.
Cost factors · Security services and compliance
What drives the cost of penetration tests and compliance audits
Costs track scope, depth and effort. For testing, the number of applications, user roles, integrations and the manual hours required matter most. For audits, scope, organisational size, maturity of existing controls, evidence volume and the length of any observation period drive effort. Compare quotes by deliverables and assumptions, not headline figures, and budget for remediation and retesting.