"But we have snapshots." That sentence is probably heard more often in IT than you would think. And it is usually well meant. After all, snapshots are created regularly, data can be pulled back quickly when needed, and in day-to-day operations the whole thing works beautifully.
Except: a snapshot is still a long way from being a backup.
At first glance that sounds like splitting hairs. It isn't. The moment a storage system fails, an administrator accidentally deletes the wrong data, or a ransomware attack hits not just the production systems but the existing backups as well, a small technical difference suddenly becomes a very big deal.
1. Snapshot or backup – what is the difference?
A snapshot freezes the state of a system or a data set at a particular point in time. It usually sits on the same storage as the production data and serves as a fast way back.
A backup is an independent copy that remains available even when the original system no longer exists.
So the decisive difference is not the technology, it is the dependency: a snapshot shares the fate of the system it sits on. A backup does not.
2. What exactly is a snapshot?
Put simply, a snapshot records the state of a system or a data set at a particular point in time. That is extremely convenient: a virtual machine was configured incorrectly? Back to the previous state. A file was overwritten by accident? It may well be recoverable from an older snapshot.
Snapshots are therefore above all one thing: fast. They are a little like the "undo" function in a Word document – only for entire systems or data sets. And for exactly that purpose they are excellent.
3. But what happens when things really break?
Picture a simple scenario: a company runs its virtual machines on a storage system. The snapshots sit on it too. Then the storage system fails. The production data is gone. And the snapshots? Gone as well.
Or take a different scenario: an attacker gains access to the infrastructure and starts encrypting data. If the existing snapshots are reachable and modifiable for them as well, those recovery points become a target too.
4. Snapshot, replication and backup are not the same thing
The three terms are happily mixed up in everyday use. Yet they serve completely different purposes.
5. The good old 3-2-1 rule – and its extension
One of the best known foundations for backup concepts is the 3-2-1 rule: three copies of the data, on two different media, one of them outside the primary site. The goal behind it is simple: a single defect, an operator error or damage at one site should not take every copy down with it.
Given today's threat landscape, this principle is often extended – to the 3-2-1-1-0 rule. Sounds a bit like a combination lock? It is actually a rather good mnemonic.
6. Immutable backups: nothing may be changed here any more
A central term in this context is immutability. An immutable backup set cannot be changed or deleted after the fact during a defined retention period – not even by someone with administrative rights.
That is particularly interesting if you want to protect yourself against ransomware. Because what good is the finest backup if an attacker with sufficient rights simply says: "let's delete that too"?
This is precisely where one of the decisive differences lies between an additional copy and genuinely resilient data protection. That said, "immutable" is not something you simply tick off and consider done.
7. "Backup successful" is not the same as "data recoverable"
This is perhaps the most important point of all. Backup software reports "job completed successfully". Splendid. Except that this message answers not a single one of the questions that matter when it counts.
RPO and RTO: the two numbers that should be settled in advance
Two metrics decide whether a concept fits the business. Neither value belongs to the IT department alone; both belong on the table of the business units. Because "as fast as possible" is not a number.
8. Where modern infrastructure platforms come in
Things get interesting once virtualisation, storage, replication and backup are no longer treated as entirely separate concerns. Modern platforms increasingly try to interlock these functions more closely. That can simplify operations and means snapshots, replication and recovery no longer have to be handled as separate building sites.
VergeOS follows this integrated approach as well: the platform combines virtualisation, storage and networking with functions for data protection and disaster recovery within a shared infrastructure. Immutable snapshots are part of the feature set.
That does not mean, however, that every backup concept is automatically taken care of. Even with an integrated platform, retention, recoverability, physical separation and the specific requirements of the particular environment all have to be considered.
Conclusion: snapshots are useful – but not a backup
In the end the most important question is always the same: what happens if everything really does go wrong tomorrow?
Snapshots are useful. Very much so. They make many everyday tasks easier, enable fast recoveries and can be an important part of a modern infrastructure. But they are not automatically a backup.
A good data protection concept consists of several building blocks and should account not only for normal operations but also for the rather unpleasant day after. Hardware can fail. People make mistakes. Software can behave differently than expected. And sometimes somebody turns up at the door who was never invited.
A snapshot simply is not a backup. But a good snapshot can be a pretty good start.
Frequently asked questions about snapshots and backups
A snapshot freezes the state of a system at a point in time and usually sits on the same storage as the production data. A backup is an independent copy that remains available even when the primary system fails. The difference lies in the dependency, not in the technology.
No. If the storage system fails or the environment is compromised, production data and snapshots are usually affected at the same time. A snapshot protects against operator error, not against system loss.
Three copies of the data on two different media, one of them outside the primary site.
It extends the 3-2-1 rule by an immutable or offline copy ("1") and by zero errors when verifying recoverability ("0").
Backups that cannot be changed or deleted during a defined retention period – not even with administrative rights. They are a central building block in protecting against ransomware.
At least once a year, more often for critical systems – and always after major changes to infrastructure or applications. What matters is that the test covers the complete recovery, not just retrieving individual files.