What is the difference between snapshot, backup, replication, versioning, and archive?
Daily snapshots do not always make a separate backup necessary. Nor do snapshots taken daily, or more often, make the current protection sufficient. The test is not the word snapshot. It is whether the copy disappears with the operational data, whether the same administrative rights delete all of it, whether history reaches back to before the fault was noticed, and whether it restores in an uncorrupted state.[1]
Once ransomware or credential theft enters the picture, "a copy exists" and "the copy is usable after the incident" are different problems. CISA assumes that reachable backups can be deleted or encrypted by ransomware and recommends offline backups together with regular integrity and restore verification.[2] So it is better to change the question from snapshot or backup to "which incident takes the current recovery point with it?"
By SNIA's current definitions, a snapshot is a copy at a point in time, a backup is data retained to recover a source that has been lost or made unreachable, and replication is a structure that continuously maintains copies for availability and redundancy. Versioning keeps versions from several points in time, and archive is focused on long-term retention.[3]
So AWS calling an EBS snapshot an incremental backup, or Azure offering snapshot-based disk backup, is not a misuse of terms. Those are cases where the snapshot mechanism implements a real backup strategy. Even within one product, though, where the snapshot lands, who can delete it, and what state it captures remain separate questions.[4]
Mechanism | Primary purpose | Separation | Control independence | History / retention | Immutability | Recoverability | Application consistency | Operational owner |
|---|---|---|---|---|---|---|---|---|
| Snapshot | Restore or roll back to a point in time | Varies by implementation | Varies by implementation | Possible when several snapshots are kept | May be a separate feature | Strong where volume or filesystem restore exists | May be crash-consistent or application-consistent | Needs snapshot policy, lifecycle, and restore ownership |
| Backup | Recovery when the source is lost or unreachable | Designed by policy | Can be made independent | Retention policy is a core component | Applied as required | Recovery is its reason to exist | Depends on the backup method and the application | Needs ownership of restoration, not only creation |
| Replication | Availability and redundancy | Can be raised with a remote target | Varies by architecture | Current-state oriented; journals or delay change this | Not usually a core property | Favourable for failover | Varies by replication method | Ownership of lag, state, and failover |
| Versioning | Retaining previous versions | May sit in the same store | Often the same control plane | Its native strength | May need separate delete protection | Useful for file or object level restore | Consistency across components must be checked separately | Ownership of retention period and delete rights |
| Archive | Long-term retention | Can sit in a separate tier | Can be strongly separated | Long-term retention is its purpose | Combinable with WORM and similar | Recoverable, but not aimed at immediate operational restore | Varies by retention unit | Needs a retention, disposal, and access policy owner |
Seven things to check before how often
Seven axes come before the creation interval.
The first is separation. Ask whether the snapshot disappears when the production volume does. A copy-on-write snapshot on the same physical disk and a managed snapshot separated from the source store do not share a failure mode. Do not infer this condition from the word snapshot. Confirm the actual storage location and failure domain.
The second is control independence. Even when data and snapshot are physically apart, if the same account, the same administrative credential, and the same delete permission remove both, the arrangement is exposed to credential theft and insider error. NIST CP-9 carries controls for protecting backup information and for dual authorisation on deletion and destruction as separate items alongside separate storage. Physical separation and separation of administrative authority are different problems.[1]
The third is history and retention. Logical corruption is not noticed the moment it happens. If data was corrupted on Monday and found on Thursday, Wednesday's and Thursday's snapshots were created perfectly and are already corrupt. So what matters is not that one last snapshot exists but that several recovery points survive across a sufficient window. Versioning matters in this area too.
The fourth is immutability. Immutable is the property that blocks change or deletion of a recovery point for a defined period. AWS Backup Vault Lock and Azure Immutable Vault are implementations of it. Some services are designed so that even administrative rights cannot bypass a locked retention policy. Strength varies with the implementation and the lock state.[5]
Three terms have to be kept apart here. Writing immutable as if it meant offline or air-gapped makes the protection model impossible to describe. And being immutable does not make the data correct. Store already corrupted data and the corrupted state is simply preserved beyond change. That is why integrity checks and real restore tests are needed separately.[1]
The fifth is recoverability. A Completed status in the backup console is evidence that the creation job finished. It is not evidence that a restore works. NIST CP-9 sets a separate control for testing the reliability and integrity of backup information and for restoring selected system functions from backup to confirm they recover correctly.[1]
The sixth is application consistency. A storage snapshot of a running server captures the blocks written to disk and misses data still held in memory or in OS and application caches. AWS documentation states that data cached by the application or the OS is not included in an EBS snapshot.[6] Azure and Google Cloud likewise separate crash-consistent from application-consistent snapshots. For databases, applications spanning several volumes, and systems where file and database state are linked, "the volume opens" and "the application data is consistent" are not the same statement.[4]
The seventh is ownership. A backup with a schedule and no owner looks healthy right up to the incident. Who checks failed backup jobs, who can change retention policy, who performs a restore, and who approves periodic verification must all be settled. NIST leaves frequency, retention, testing, and deletion controls for the organisation to define precisely because backup is an operational control rather than a storage feature.[1]
- Separation
- Asks whether the recovery point disappears when the source disappears.
- Control independence
- Asks whether the same account and administrative rights can delete the recovery points too.
- History and retention
- Asks whether a clean point in time survives when corruption is found days later.
- Immutability
- The property that prevents a recovery point from being changed or deleted for a defined retention period.
- Recoverability
- Asks whether the data can actually be pulled back, not whether creation finished.
- Application consistency
- Asks whether the capture is in a state the application can understand.
- Owner
- Asks who checks failed jobs, changes retention policy, performs restores, and approves periodic verification.
Concept | Meaning | Why it is not the others |
|---|---|---|
| Offline | Not directly reachable from the day-to-day operational network and systems | Offline media becomes writable again once reconnected |
| Immutable | Prevents change or deletion for a defined retention period | Storage that is online can still be immutable |
| Air-gapped | A strong isolation boundary from the operating environment | Beyond physical separation, vendors implement identity and control isolation under the name logical air gap |
Operations connected from observation to improvement — Respond using service indicators and alerts, then connect change records and incident reviews to improvements.
Looking at the failure domain changes what separate means
The phrase separate backup need not be read as one more copy at a different vendor. Draw which of storage, region, account, IAM, credential, and KMS the source and the recovery points share, and the judgment changes.
A backup in the same region can be independent enough against credential theft or volume loss. Conversely, replication to another region has low control independence if one administrative credential can delete both sides.
A system that must survive a region failure needs a recovery point that does not share a failure domain with that region. That fact should not be converted into a rule that every system must be cross-region or cross-vendor. NIST too leaves controls such as backup frequency and separate storage to be defined against the organisation's requirements and risk. Google Cloud Backup Vault likewise offers several placements, in the same region and in another.[1]
For the same reason this article does not use 3-2-1 as a pass mark. Before counting copies, it matters more to check whether those copies actually vanish together in the same incident.
Failure mode by protection mechanism
The table below is not a per-product guarantee. It is a starting point built on the general character of each mechanism, and the real outcome varies with storage location, permissions, retention, lag, immutability, and consistency settings.[3]
Replication deserves particular care here. Replicating healthy data quickly raises availability during an outage, and it replicates wrongly deleted or logically corrupted data just as quickly. Implementations that retain past state separately, such as journals or delayed replication, behave differently. Still, the presence of a replica should never be read as the presence of a backup. SNIA likewise defines replication in the context of maintaining continuous copies for availability and redundancy.[3]
Failure mode | Snapshot | Backup | Replication | Versioning | Archive |
|---|---|---|---|---|---|
| Operator error | ◎ if an earlier point survives | ◎ | △ the mistake replicates immediately | ◎ | ○ |
| Credential theft | △ vulnerable if the same rights delete it | ◎ with independent rights and delete controls | △ vulnerable if the target shares those rights | △ check who can delete all versions | ○ with independent controls |
| Ransomware | △ depends on reachability and deletability | ◎ strong with offline, immutable, independent control | △ encrypted data replicates too | ○ with delete protection | ○ depends on isolation and retention policy |
| Logical data corruption | ◎ if a pre-corruption point survives | ◎ | △ replicating the current state carries corruption along | ◎ | ○ |
| Storage or volume loss | ◎ if stored independently of the source storage | ◎ | ◎ if a secondary copy survives | △ lost together if it lives only in the same store | ○ |
| Account or control plane problem | △ access itself is blocked within the same account | ◎ with a separate control boundary | ○ with an independent secondary control plane | △ | ○ when managed independently |
| Region or AZ failure | △ depends on where the snapshot actually sits | ○ if separated from that failure domain | ◎ with remote replication | △ | ○ depends on storage location |
| Corruption of the backup itself | ○ if it is an independent second recovery point | △ the word backup does not solve it | △ | ○ if another point in time is intact | ○ if it is an independent copy |
| Application inconsistency | △ needs an application-aware snapshot | ○ with a consistent backup method | △ depends on the replication method | △ a single file or object version may not be enough | △ depends on the retention unit |
From service architecture to operating standards — Design networks and servers together with deployment paths, access controls and backup policies.
Restore evidence strengthens across five levels
The weakest evidence that a backup was made properly is looking at a list. NIST goes a step further and requires the reliability and information integrity of backup media to be confirmed and a sample backup to be used in an actual restore test. Extended into application operations, that becomes a five-level restore evidence ladder.[1]
Levels one through four unfold NIST's backup reliability and integrity checks and its restore test of selected system functions into a practical sequence. The core user journey at level five is not lifted from NIST wording; it is this article's operational extension, so that recovery of a system function is confirmed as far as the user-visible result. Setting a particular SLI or target time is out of scope here.[1]
The ladder is not an argument for cloning all of production into a giant DR exercise every time. It exists to show that an organisation that only checks backup lists and an organisation that confirms real work on the restored service hold evidence of different strength.
Level | What is checked | What it proves | What it does not yet prove |
|---|---|---|---|
| 1. Backup list and metadata | Recovery point time, status, size, retention, encryption keys and policy | Backup jobs and recovery points exist on the record | Whether the data can actually be read |
| 2. Sample file restore | Restore an arbitrary file, object, or part of a volume elsewhere | Data retrieval, permissions, encryption keys, and the basic restore path work | Database and whole-application consistency |
| 3. Database integrity check | Engine-appropriate integrity checks, transaction, index, and relation validation | The application data store is in a usable state | Whether the whole service actually starts |
| 4. Application start-up | Run it in an isolated environment with configuration, secrets, and dependencies | The selected system function can be recovered | Whether users can finish critical work |
| 5. Core user journey validation | Run representative journeys such as login, search, registration, processing | Restored data and application are usable end to end | Every feature and every failure situation |
How to tell whether your snapshot policy is enough
If snapshots run daily, put seven questions to the current policy before shopping for a new product. Does a recovery point survive the loss of production storage? If the production administrative credential is stolen, can the recovery points be deleted too? If corruption is found days later, does a clean earlier point remain? Do the recovery points you need carry delete and change protection? Is the capture consistent in a state the database and application understand? Has a recent recovery point actually been restored? Is someone accountable for backup failures and restore tests?
If all seven hold, there is no automatic reason to conclude that a snapshot means buying one more backup product. That snapshot regime is already carrying a substantial backup function. If several answers are unclear, the problem is not the snapshot interval. It is that nothing has proven how independent the current recovery points are from the failure of the source.
A recovery strategy is safer judged by failure conditions than by names. Depending on implementation and operation, a snapshot becomes part of an excellent backup strategy. Its value, though, is judged by separation from the source, control independence, retention history, immutability, application consistency, and real restore evidence — not by a settings screen reading "created daily".
