A snapshot is not a backup, and a backup is not a guarantee

What actually protects our data? Is it snapshots that are created in a matter of seconds and allow you to instantly roll back to a previous state? Is it regular backups that are stored in a separate location? Or is it replication that ensures continuous operation even in the event of a site failure?

In this article, we will explain why a snapshot is not a backup at all, why replication does not replace a backup, and what requirements are placed on a modern data protection system.

At first glance, snapshots and backups do seem similar – after all, creating a snapshot allows you to return to a previous state of the virtual machine. So how is this not a backup? Though on a serious note, technically a snapshot and a backup solve fundamentally different problems and are implemented differently.

When a snapshot is created, the hypervisor captures the state of the virtual machine at a specific point in time. After this, new records are made through a copy-on-write or redirect-on-write mechanism, depending on the specific platform implementation. Instead of copying the entire virtual disk, structures are created that allow you to save the original state and record subsequent changes separately.

This is why creating a snapshot usually takes just a few seconds and is essentially independent of the virtual disk's size – the data is not copied in its entirety. If a snapshot is created with memory stored, the contents of RAM and the status of virtual devices are recorded additionally. This allows you to restore the virtual machine after recovery to almost the same state it was in when the snapshot was created.

When accessing data, the hypervisor determines where the current version of each block is located – either in the original virtual disk image or in the change files created after the snapshot.

Please note that a snapshot is not an independent copy of the data. It only captures the state of the existing storage at a certain point in time. As long as a snapshot exists, it remains linked to the original data and to the way it is stored. This is why snapshots are great for short-term rollbacks, testing, upgrades, or cloning virtual machines, but they cannot replace a comprehensive backup on their own.

Creating one snapshot by itself usually has little or no impact on performance. Problems begin to appear when snapshots are used for a long time without being subsequently consolidated or deleted.

In many virtualization platforms, snapshots are implemented through change chains. As such chains accumulate, the system has to perform additional accesses to determine where the current version of each data block is located. The longer the chain, the higher the potential overhead for read and write operations.

On a small number of snapshots, this effect is usually unnoticeable. However, long chains can increase I/O latency, create additional load on the storage subsystem, and slow down the consolidation of snapshots after they are deleted. This is especially noticeable on highly loaded virtual machines – for example, those with databases or file services – where even a small increase in disk subsystem latency can impact application response times.

This is why snapshots should be considered a temporary tool and deleted immediately after completing the operation for which they were created.

Another feature of snapshots is that in many virtualization platforms they form a chain of dependent states. Each new snapshot stores changes relative to the previous state only, and not a complete copy of the virtual disk.

In such implementations, damage to one of the chain elements can make subsequent states unavailable, since they depend on the previous levels. This is why snapshots cannot be considered independent backups – they depend on the integrity of the original data and the entire chain of changes.

It is also worth noting the difficulties that may arise when deleting snapshots. In this case, the system needs to consolidate the accumulated changes in order to integrate them into the main data storage. Modern hypervisors typically perform this operation without stopping the virtual machine, but with large volumes of modified data, consolidation can involve intensive read and write operations, increasing the load on the storage subsystem and temporarily reducing performance.

Even if a snapshot was created successfully, this does not mean that it can be used to restore the application without problems.

A snapshot captures the state of the data at a specific point in time, but this state does not always match the one that the application considers consistent. Many modern applications make extensive use of RAM to buffer operations and write data to disk asynchronously.

As a result, you can get a so-called crash-consistent snapshot that captures the state of the system as if the virtual machine had been abnormally shut down at that moment. Most log-structured file systems can automatically restore the consistency of their own metadata after such an event. Many modern DBMSs also perform recovery using transaction logs, but some changes that have not yet been written to disk may be lost.

To get an application-consistent snapshot, the state of the application and file system must be consistent before the snapshot is created. In this case, before creating a snapshot, the application completes current transactions (or brings them to a consistent state), ensures that cached data is written to disk, and temporarily suspends write operations.

Snapshots remain an extremely useful tool – they allow you to quickly roll back a failed update, test changes, create a clone of a virtual machine, or capture the system state before risky work. However, they cannot be used as a comprehensive data protection strategy. They do not create an independent copy of information, can affect performance during long-term storage – and most importantly – do not guarantee a consistent application state without additional coordination with the guest OS and the applications themselves.

A comprehensive backup requires a separate system that stores data independently of the production infrastructure, supports storage policies, deduplication, supports various storage types, and ensures guaranteed recovery.

Okay, we have sorted out the snapshots. So what should a modern virtual infrastructure backup system be like?

Historically, backup was based on installing a special agent in each operating system. This approach remains valid for physical servers and individual applications, but in a virtual infrastructure it creates additional complexities. Each agent must be installed, updated, checked for compatibility with the operating system, and monitored for its performance. With tens or hundreds of virtual machines, this becomes a separate operational task. In addition, the agent utilizes the resources of guest OS and becomes another component whose failure can lead to problems when creating backups.

Therefore, modern virtualization platforms increasingly use the agentless approach. In this case, the backup system interacts directly with the hypervisor via its API, initiates the creation of snapshots via the hypervisor API, and copies virtual disks without installing a specialized backup agent inside guest operating systems.

A modern backup system must not only create backup copies, but also manage their life cycle efficiently.

For this purpose, incremental backup schemes are used, which allow only changed data to be saved after the first full copy. Additionally, deduplication and compression are used, which reduce the volume of stored information and reduce storage capacity requirements.

Storage policies are equally important. They automatically determine how long daily, weekly, or monthly backups need to be stored and when they can be safely deleted without violating business or regulatory requirements.

In addition, modern backup systems must protect the backups themselves by supporting encryption during both data transfer and storage. This reduces the risk of backups being compromised even if an attacker gains access to the network or physical media.

Getting a virtual machine backup is not enough. It is important that applications run correctly after recovery.

If the backup is performed without coordination with the application, a crash-consistent copy is created – that is, a copy equivalent to an emergency shutdown of the virtual machine.

For modern DBMSs such as PostgreSQL or MySQL, this situation is usually not critical – the next time they are started they perform recovery using transaction logs. However, this process requires additional time, and for some applications this level of consistency is not sufficient. Therefore, application-consistent backups are used for critical services.

Even a well-created backup is useless if it is stored in the same loop as the productive infrastructure.

Modern ransomware seeks not only to encrypt work data but also to destroy backups, leaving the victim no chance. If the backup server is accessible from the same network and uses the same administrative accounts, there is a high probability that an attacker will be able to disable the recovery system as well.

Therefore, today both the classic 3-2-1 rule, and its modern 3-2-1-1-0 modification are increasingly used. It assumes at least one immutable or physically isolated copy, as well as regular verification of the possibility of recovery.

Tape libraries, S3-compatible object storages with Object Lock support, or remote sites with their own storage infrastructure can be used as such storage.

At the same time, a modern backup system must support simultaneous work with several storage types. For example, live backups can be stored on a local disk array for quick recovery, and then automatically migrated to object storage or a tape library for long-term storage and protection against ransomware.

The very fact that a backup has been created successfully does not mean that it will be possible to restore the system from it. Media corruption, data transfer errors, incremental backup chain disruptions, or repository issues – unfortunately, it is only after you vitally need your backups that you might find out about these unpleasant things. This is why one of the most important functions of a modern backup system is the automatic verification of the possibility of recovery from backups. Such verification may include testing checksums, reading data from the repository, and automatic verification of the backup integrity.

When designing a data protection system, it is important to consider that backup and replication solve different tasks.

A backup allows you to restore data after accidental deletion, logical error, file corruption, or ransomware attack. Replication, on the contrary, is intended to quickly restore functionality after a failure of hardware, storage system or the entire site.

If your infrastructure has strict recovery time objectives (RTO), a backup alone may not be sufficient, as even with a backup available, restoring a large number of virtual machines can take a significant amount of time. In such cases, replication to a backup site is used. It transmits changes synchronously or asynchronously and allows for quick switching of services to a backup infrastructure in the event of emergency. Most replication mechanisms reproduce changes with virtually no latency, so accidental data deletions, logical errors, or file encryption by malware are usually replicated to the backup site.

Both technologies are typically used together in mature infrastructures – replication ensures service continuity, while backup enables data recovery in various failure scenarios.