Why a Backup Can Be Restored and Still Be Unusable
This chapter focuses on the storage copies that a ransomware-struck factory expects to use: what a backup, replica, point-in-time copy, or snapshot contains, what it depends on, and what must be verified before it supports production. The practical judgment is simple but demanding: a copy is recoverable only when its contents, lineage, surrounding dependencies, and trust state are good enough for the manufacturing mission that will rely on it.
Storage copies preserve different things
It is tempting to picture storage as a shelf holding data until a recovery team takes it down. Modern storage is more like a set of services that presents data to many clients through different abstractions. A block service presents fixed-size blocks that an operating system manages. A file service presents directories and files. An object service presents individually addressed objects with metadata. Virtualization can pool physical devices and present changing logical volumes. Cloud and container environments add more software-defined interfaces and management relationships.
These abstractions are useful during normal operation because they separate applications from the details of physical media. The same separation creates recovery work. A logical volume may depend on a storage pool, a mapping, a network path, a host configuration, and an authorization decision. A file share may depend on its access controls and the service that presents it. A container volume may depend on an orchestration layer and a storage plug-in. A cloud object may be present while the account, key, policy, or endpoint required to access it is unavailable or untrusted.
The implication is not that abstraction is a design mistake. It is that recovery has to cross the same boundaries that normal use crosses. If a plant restores only the visible data and not the relationships that make the data addressable, authorized, and interpretable, it has restored a fragment of a system.
The word “backup” also hides several different mechanisms. A file backup copies selected logical content such as files, directories, or data within a database schema. An image backup copies the content of an entire device or logical unit. Replication writes the same data to another location, either synchronously or with a delay. A point-in-time copy captures how data appeared at a particular moment, and a snapshot often stores only the portions that changed relative to a base.
Those mechanisms have different failure paths. A snapshot may be small and fast because it records deltas, but it may be unusable if the base data has been lost or altered. An incremental backup may contain the changes needed to reconstruct a later state but still require its baseline. A replica may be current but close enough to production that it shares the same compromise or management trust. A full backup may be independent but too old to meet the mission’s tolerance for data loss. None of these properties can be inferred from a timestamp alone.
Recovery planning uses two familiar measures here. The recovery point objective (RPO) describes how much data loss, measured backward from the disruption, the organization can tolerate. The recovery time objective (RTO) describes how long the organization can tolerate the service being unavailable before it must be restored and functional. They are useful design constraints, not declarations that a copy is clean or that a factory can produce. A copy can meet an RPO and still contain compromised credentials. A restore can meet an RTO for one application while leaving the dependent quality or identity service unavailable.
Consistency matters for the same reason. If two components must represent a compatible moment in time for a business process to work, recovering them from unrelated points can produce a system that starts but tells the wrong story. NIST’s storage guidance therefore treats application and business-process consistency as part of data protection. The question is not merely whether each component has a copy; it is whether the set can be restored into a state that the selected production mission can use.
The factory context makes these distinctions concrete. A recent copy of a manufacturing execution system might restore scheduling records, while the associated recipes, historian data, identity state, or quality records come from incompatible moments. A replica may be available quickly but inherit the production environment’s trust relationships. A snapshot may appear healthy in a storage console but depend on a baseline that has not been isolated from the attack. “The backup exists” is therefore the beginning of an investigation into copy lineage, not its conclusion.
This state model is intentionally broader than a backup job’s success status. A copy moves from creation into a lineage and dependency context. It may be exposed to the same environment as production, or it may be isolated for cyber-attack recovery. It then needs validation and staged restoration before anyone treats it as an approved input. A failed check does not mean that all recovery is impossible; it means that this copy or this restore path cannot support the decision as currently understood.
Ransomware can poison the path back
Ransomware attacks the recovery process in more than one way. It can encrypt or delete recovery copies, compromise a backup appliance, alter access to storage, or damage the services that catalogue and restore copies. It can also interfere with the backup process without immediately destroying every existing copy. Over time, new copies may capture data after an attacker has changed it, or the organization may discover that the only remaining copies are older than the business can tolerate.
This gradual poisoning matters because a recovery team usually wants a current copy. Recency is valuable when the data changes rapidly, but it is not evidence of cleanliness. The attacker may have entered before the encryption event, may have stolen credentials used by backup systems, or may have modified a management path that reports the status of snapshots and retention settings. A copy can be recent and internally consistent while still preserving an attacker’s foothold or a compromised trust relationship.
The risk extends beyond business data. NIST identifies operating-system images, software packages, firmware, and source repositories as possible rebuild inputs that can carry compromise into a reconstructed environment. Restoring data while restoring infected code defeats the purpose of a clean rebuild. This is why the guidance recommends that data and applications be separable for restoration where appropriate, and why recovered executables, applications, containers, and images need hygiene validation before deployment.
The manufacturing review describes this problem as backup over-trust: assuming that the newest or most available backup is clean, complete, and operationally suitable without verifying its compromise state, dependency consistency, or persistence risk. The point is not to make every restore decision impossibly cautious. It is to replace a single proxy—usually recency—with several questions:
- What was the copy’s relationship to production when the suspected compromise occurred?
- What baseline, catalog, key, configuration, and access path does it require?
- Can the data be checked for integrity and consistency without exposing it to an untrusted host?
- Which identities, images, and management tools would be reintroduced along with it?
- Does the copy support the particular product, line, quality process, and duration being considered?
The answer will often be incomplete. That is precisely why the selection should be documented as an evidence judgment rather than presented as an obvious consequence of the calendar. If an older copy has stronger evidence of cleanliness and can support a narrower mission, it may be more useful than a recent copy whose compromise window is unknown. The sources support that conditional reasoning; they do not establish that older copies are generally safer or that one backup technology is universally preferable.
Cyber-attack recovery requires a different separation model
A copy intended for ordinary disaster recovery may be designed for fast access from the same operational environment. It can help with hardware failure, human error, or a local outage. Cyber-attack recovery asks a harder question: can the copy remain usable even when production, ordinary backups, and the management paths connecting them have been compromised?
NIST distinguishes these purposes and recommends that organizations design for both. For sensitive systems, cyber-attack recovery copies should be held in designated separated environments. Their management systems should not be reachable through regular production credentials, and their administrators should use credentials separate from day-to-day duties. Off-site storage can reduce the chance that a compromise of the production location reaches the recovery copy. An independent full baseline avoids a chain in which every later incremental copy depends on production data that an attacker could alter.
The separation must include more than the data path. A backup that is isolated from production but managed from a compromised console is not meaningfully independent. A copy that is immutable but can be mounted directly onto an infected host can still be exposed during restoration. A copy that is off-site but uses the same compromised identity and administrative channel may preserve physical distance without preserving trust. The recovery design has to consider storage, management, credentials, network access, and staging together.
Restoration into an isolated staging environment is important for the same reason. It gives responders a place to inspect the copy, validate configurations, scan relevant images, compare expected dependencies, and test whether the recovered system behaves as intended before it is pushed into production. NIST recommends avoiding direct mounting or mapping of cyber-attack recovery copies to target hosts and applications when possible. The safer pattern is to restore into a controlled environment, then grant limited access for the specific validation or transfer that has been approved.
Immutability and air gaps help, but neither is a magic word. Immutability can prevent alteration during a retention period, yet it does not prove that the content was clean before it was locked. An air gap can reduce reachable paths, yet its strength depends on how it is implemented, how synchronization occurs, which ports or devices are exposed, and what an adversary can exploit around the separation. NIST describes stricter physical and network separation as well as less strict arrangements that open connections for controlled synchronization. The right choice depends on the value of the data and the adversary the organization is preparing to withstand.
Health checks and restore tests close another gap. A copy can be present but damaged, incomplete, inaccessible, or too slow to restore. Periodic validation should examine copy health and logged errors. For critical applications, an end-to-end test restore into a sandbox can reveal whether the full path—from copy selection through configuration and dependent services—actually completes within the desired time. A catalog should record what was copied, which tools scanned it, and what the checks found, so that a recovery team is not forced to reconstruct the history under pressure.
A successful test restore proves something valuable: the selected mechanism can produce a usable reconstruction under the tested conditions. It does not prove that the production environment was uncompromised at the point of backup, that the identities used during the incident remain trustworthy, that the restored configuration matches the physical line, or that the output will satisfy quality and supplier requirements. Storage recoverability is a necessary layer of factory recovery, not the whole decision.
The next layer is the surrounding dependency and trust fabric. The copy may be clean and staged correctly, yet still fail to support production if the directory service, keys, configuration, engineering workstation, quality data, or management identities cannot be trusted together. The recovery question has moved from “Can this copy be restored?” to “What must be restored with it, and who is allowed to use it?”