Backups or snapshots for the company

On Monday morning, the accounting system no longer opens, the shared file folder is encrypted, or important client documentation has been deleted by mistake. In moments like these, the question of whether a company needs backups or snapshots is no longer theoretical. It determines whether work resumes after a few minutes, several days, or whether some data must be restored manually.

Both solutions are important, but they do not do the same job. A snapshot helps quickly return a system to a previous state. A backup is an independent copy of data intended for restoration after a serious incident. A company that wants to control downtime, reputation, and financial risks usually does not need to choose only one of them. It needs to build a well-considered recovery architecture.

Backups or snapshots: the essential difference

A snapshot captures the state of a virtual machine, disk volume, or data system at a specific moment. It is often stored in the same infrastructure or in closely related storage. If an error occurs after a software update, a configuration is damaged, or a user accidentally overwrites a file, a snapshot can provide a very fast return to the previous working state.

However, a snapshot is not automatically a full-fledged backup. If the underlying storage is damaged, a virtual machine is deleted, an administrator is compromised, or data is encrypted across the available environment, snapshots may become inaccessible together with the original data. The risk is especially high if snapshots are located in the same data center, cloud account, or management domain.

A backup is created for a different purpose: to preserve a restorable version of data independently of the production environment. It may be located on a different storage medium, in a different location, or in a separate cloud environment. A quality backup solution includes not only file copying, but also encryption, retention policies, access control, recovery testing, and transparent audit information.

Simply put: a snapshot is a tool for quick return in everyday mistakes, while a backup is the foundation of business continuity for larger incidents.

When a snapshot is not enough

Snapshots are valuable because they reduce risk during changes. Before an ERP system version upgrade, server configuration work, or the introduction of a new integration, the IT team can create a snapshot and, if necessary, quickly return the system to a working state. This reduces downtime for planned work and allows changes to be managed more successfully.

The problem arises when snapshots are treated as the only layer of protection. For example, ransomware can encrypt not only production files but also snapshots if it has access to the hypervisor or storage management account. A similar risk exists if a cloud account is taken over using stolen administrator credentials or if an entire resource set is deleted by mistake.

There is also a practical question of retention duration. Snapshots are generally not created for long-term archiving. They consume storage resources, can complicate system performance, and are often automatically deleted after a few days or weeks. Meanwhile, a company may need the ability to restore a document from the previous quarter or verify a financial data version from a year ago.

Therefore, snapshots are suitable for short-term operational risk, but not as the sole protection against infrastructure failure, cyber incidents, or human error with broad impact.

What a company backup policy provides

Effective backup starts with business priorities, not with chosen software. Management and IT leaders must agree which systems are critical: financial data, client contracts, email, production or warehouse systems, identity management, virtual servers, and cloud data. Each system may have a different acceptable downtime and data-loss threshold.

Two metrics are useful here. RPO, or recovery point objective, determines how much data the company can afford to lose. If the RPO is four hours, backups must be made at least often enough so that no more than four hours of work is lost at recovery time. RTO, or recovery time objective, determines how quickly the system must be back in operation. Email may tolerate a longer recovery than an order-processing system that directly affects revenue.

A mature policy is usually based on the 3-2-1-1-0 principle. A company maintains at least three copies of the data, uses two types of storage, keeps one copy in a separate location, makes one copy immutable or isolated, and in regular tests allows no undetected recovery errors. This is not a formal checklist for audit purposes only. It reduces the chance that one incident will affect all available versions of the data at the same time.

An immutable copy is especially important for protection against ransomware. During a defined retention period, it cannot be deleted or changed even by an administrator with broad privileges. This does not mean the solution is absolutely protected from every threat, but it significantly increases the company’s ability to restore operations without a ransom payment or prolonged crisis.

The right approach is layered

In a small company with a few cloud services, needs will differ from those of a manufacturing company with on-premises servers, remote branches, and specialized applications. But the basic approach is similar: use snapshots for quick operational rollback, and backups for independent and verifiable recovery.

In a practical model, virtual servers can have frequent snapshots before planned changes and short recovery scenarios. At the same time, regular backups should be created to separate storage, with a defined retention period and at least one copy outside the primary environment. Cloud services should be assessed separately, because service availability does not mean the provider will recover the company’s mistakes, deleted users, or damaged documents.

Access architecture is also important. If one administrator with one password can delete production data, backups, and audit records, the company has created a single critical point of failure. Multi-factor authentication, role separation, separate backup accounts, and regular review of access rights are just as essential as storage capacity itself.

Recovery must be tested, not assumed

A backup that cannot be restored within the required time is not an adequate protection mechanism in a crisis. Often companies only check whether the backup job completed without an error message. That does not confirm that the database is consistent, the files are available, the application works, and the recovery process meets the specified RTO.

Testing should reflect real scenarios. One month, an individual file can be restored; another month, a virtual server can be restored in an isolated environment; but at least periodically, the recovery of a critical system should also be practiced. Test results should be documented: how long it took, which actions caused delays, and whether the available instructions are understandable to the person who will perform the work during the incident.

This approach is also important at management level. It provides a measurable basis for decisions about investments, insurance requirements, customer contractual obligations, and business continuity planning. In KSK IT practice, backup assessment is viewed not as a separate technical task, but as part of overall infrastructure risk management.

How to make the decision in your environment

If a company’s main risk is a failed update or accidental configuration change, snapshots will provide speed and convenience. If the risk includes cyber threats, hardware failure, cloud account compromise, or a legal need to retain information for a longer period, independent backups with controlled access are needed.

In most cases, the correct answer is not “backups or snapshots,” but a clearly defined combination of both solutions. Before making a choice, it is worth defining the critical processes, acceptable downtime, acceptable data loss, and responsible people. Then technology serves business needs instead of creating a false sense of security.

The next sensible step is to choose one critical system and practically test its recovery. This test often reveals more about a company’s readiness than any successful backup status report.