Why NAS Backups Fail During Ransomware Attacks: RAID, Snapshots, and Shared Access Explained

A NAS can have healthy RAID, scheduled snapshots and successful backup jobs yet still lack a usable recovery path after ransomware. The deciding questions are whether a clean earlier state survives, whether the attacker can change it, and whether you can restore it without relying on compromised credentials or systems.

The October 2026 Synology ransomware reports are a timely starting point, but this is an analysis of storage architecture rather than a claim about every victim. RAID, snapshots, synchronization and independent backups solve different problems. Recovery fails when their boundaries are misunderstood or when apparently separate copies share the same authority.

Header photograph: Korrupt / Wikimedia Commons, CC BY 4.0. Cropped and resized; the photographic crop retains that license. Contextual NAS hardware photography, not a verified affected device or incident scene.

Why Is NAS Storage a Ransomware Target?

A NAS makes information available over a network, usually to several people, applications or computers. This is its purpose. It also means there are multiple ways for unwanted changes to reach files. An attacker might compromise the NAS itself, take over an authorized account, or control a workstation with a writable network share.

These routes do not require identical defenses. Patching a management-service vulnerability does not remove an infected workstation's existing share permissions. Conversely, limiting a user's writable folders does not repair a vulnerable management application. The incident analysis in the companion C3RB3R and DSM article explains why distinguishing the access path matters.

Recovery adds a second question: can the same identity or control plane damage the copies intended to help afterward? If so, the number of disks, enclosures or cloud destinations can exaggerate the actual separation. Count independent failure boundaries as carefully as copies.

Does RAID Protect Data from Ransomware?

Redundant RAID configurations are designed to tolerate specified disk failures. They do not decide whether a legitimate-looking write contains a useful document or encrypted garbage. In a RAID 1 example, an authorized application overwriting a file produces writes that the mirror also preserves. The array may remain healthy while the file becomes unusable.

The mechanism is not a special ransomware bypass. Mirroring is doing its normal job: maintaining the current storage state across members. It does not inherently retain a selectable clean version from yesterday. RAID 0 is not redundant at all; different RAID levels must not be treated as offering identical failure tolerance.

RAID remains useful. A disk failure during ordinary work need not become a service outage in a properly functioning redundant configuration. The mistake is expecting disk resilience to provide historical recovery, access separation or protection against losing the entire enclosure. The RAID versus backup guide examines that distinction in more detail. Synology's NAS backup guidance likewise treats recovery copies as a separate planning concern.

Can Ransomware Delete or Encrypt NAS Snapshots?

A snapshot can be an effective response to unwanted file changes. In many snapshot implementations, modifying live files does not overwrite the older blocks preserved for a snapshot. Malware with ordinary file-share permissions therefore should not automatically be assumed to possess snapshot-administration privileges.

The important distinction is between changing files and controlling the mechanism that preserves earlier states. Ordinary snapshots may be deletable by a sufficiently privileged administrator. Others have additional protection. Synology documents immutable snapshots for supported systems, with time-bound restrictions that also protect containing storage structures from deletion during the applicable period. It would be inaccurate to claim administrators can always delete every snapshot.

Ask which snapshots exist, which controls protect them, and when their protection expires. A short retention window may leave only post-encryption versions by the time damage is noticed. Local snapshots also do not create another physical device: theft, physical destruction or loss of the underlying storage remain different recovery problems.

Why Can Network Backups Be Compromised Together?

Consider a primary NAS copying files to a second NAS every night. If the primary system stores credentials that can overwrite the destination and delete its old versions, compromising that primary can threaten both copies. A different enclosure has introduced hardware separation without necessarily introducing administrative separation.

The same reasoning applies to cloud storage. A repository can be geographically distant while its deletion credentials remain stored on a compromised host. The UK's NCSC guidance on offline backups addresses connected local and cloud copies and the importance of controlling client access. Physical distance alone does not limit what an authorized API request can delete.

Network segmentation can help reduce reachable services, but an allowed connection with broad permissions can still be dangerous. Evaluate the actual job identity, repository administration and retention permissions. “Different network” and “different account” are useful starting descriptions, not proof that a destructive request will be rejected.

Sync vs Backup: Why Are They Different?

Synchronization normally tries to make destinations reflect changes in the source. Imagine a laptop directory synchronized to a NAS. Malware encrypts the laptop's files, and the sync client uploads the changed content. A successful sync status can accurately describe a failed recovery outcome: the destination now faithfully contains the damaged current files.

Version history or deletion recovery may improve that outcome, but only if the relevant earlier versions remain accessible. Check the retention period, how rapid changes are handled, whether the attacker can purge history, and whether the application protects the actual folders you care about. The label “sync” alone answers none of these questions.

A useful backup arrangement intentionally retains a recoverable state that can differ from today's source. It must survive long enough to cover discovery and response. A copied folder that is continually overwritten is not equivalent to a repository whose older versions are retained under separately protected controls.

Why Does a 3-2-1 Backup Strategy Matter?

CISA's Data Backup Options describes the familiar baseline: three copies of important information, including the working copy; two media types; and one copy offsite. The aim is to avoid one local failure destroying every copy. It is a useful inventory framework, rather than a guarantee against every attack.

Offsite describes location. Offline describes connectivity. Immutable describes restrictions on changes for a defined period. A cloud repository may be offsite and continuously reachable; a disconnected USB drive may be offline but stored beside the NAS. Neither description substitutes for the other.

For ransomware, extend the inventory with questions about who can alter each copy and whether a clean version will outlast the incident. CISA's ransomware guidance recommends offline, encrypted backups and regular recovery testing. Backup encryption protects confidentiality; it does not, by itself, prevent an authorized attacker from deleting the encrypted repository.

What Makes a Backup Truly Independent?

Independence is a relationship between a recovery copy and a particular failure, not a property conferred by buying another disk. Start by assuming production administration has been compromised. Can that administrator erase the repository, reduce retention, revoke recovery access or remove the only copy of an encryption key?

Separate identities and enforced permissions can limit that reach. A backup writer may be allowed to create new recovery points without permission to purge protected older ones. Repository administration and recovery credentials can be held separately from production. Verify the product's actual permission model; not every protocol supports that separation.

Pulling data from a backup server can keep some credentials away from the production NAS, but “pull” is not inherently secure and “push” is not inherently unsafe. Examine where credentials reside and what each can do. An offline rotation also needs a controlled reconnect procedure: a previously isolated drive becomes reachable during its next backup session.

How Do You Know Whether a Backup Can Be Restored?

A completed job is evidence of a completed operation, not evidence that your intended service can be recovered. Test restoration into a clean destination. Open representative documents, recover important permissions and confirm that any application database is consistent with its files. Also establish whether the selected point predates the unwanted changes.

Recovery point objective, or RPO, describes the acceptable data-loss interval. Recovery time objective, or RTO, describes the acceptable time to restore service. An hourly schedule does not prove a one-hour RPO if recent recovery points are corrupt or unavailable. A fast file restore does not prove the entire service meets its RTO.

As an illustrative lower bound, transferring 2 TB of decimal data through a 1 Gbit/s link takes about 4.4 hours at perfect utilization. Real recovery adds overhead, verification, small-file handling and application work. This calculation is not a NAS benchmark. It shows why a recovery target should be measured against the entire workflow.

NIST's backup-planning publication emphasizes conducting, maintaining and testing backups. Its data-integrity recovery guide also treats trustworthy recovered information as an objective. Availability of bytes and confidence in those bytes are related but distinct outcomes.

What Does a Ransomware-Resilient NAS Architecture Look Like?

A practical design combines layers rather than declaring one feature sufficient. Production shares have limited write access. Supported redundant RAID handles appropriate disk failures. Snapshots provide useful earlier states, with protected retention where available. A separately controlled backup repository and an isolated or appropriately immutable copy preserve additional recovery options.

A hypothetical small office might use short-interval local snapshots for accidental edits, a separately administered versioned repository, and a rotated disconnected copy kept elsewhere. That arrangement is an example to evaluate, not a claim about any October victim or a universal prescription. Data sensitivity, available staff and recovery objectives determine the details.

Trace one important dataset through the design. Identify its last known-good point, the credentials needed to restore it, the location of the keys and the clean machine that can read it. Then repeat the exercise while assuming the production NAS is unavailable. Missing steps reveal more than a dashboard showing several green backup jobs.

FAQ

Does RAID 1 keep an unencrypted copy if ransomware changes a file?

No. Mirroring normally preserves the current writes, including unwanted changes made with sufficient access. It is not an automatic historical copy. Recovering an earlier state requires a surviving snapshot, versioned backup or another suitable source.

Are snapshots useless against ransomware?

No. They can preserve earlier states and support fast recovery. Their protection depends on permissions, retention, implementation and available immutability controls. A local snapshot also shares physical dependence on its storage system, which is a different boundary from file-level protection.

Is an offsite cloud backup automatically isolated?

No. Offsite means a different location, not necessarily a different authority or an offline connection. Check who can delete versions, whether production holds those credentials, and whether protected history remains available after an account compromise.

Does encrypting a backup stop ransomware from deleting it?

No. Encryption protects the confidentiality of backup contents. Deletion authority is a separate issue. Protect repository permissions and retention, and keep recovery keys available through a process that does not rely solely on the compromised system.

How long should snapshots and backup versions be kept?

There is no universal duration. Retention must cover how long unwanted changes could remain unnoticed, investigation time and recovery needs, within storage constraints. See the ransomware file-version retention guide for the clean-point planning problem. Test that the selected policy leaves an accessible clean recovery point rather than only recent damaged versions.

What is the most useful first recovery test?

Restore an important dataset into a clean location using the credentials and tools you would have during a real outage. Verify file contents, permissions, application consistency and elapsed time. Then check whether the result meets the accepted data-loss and downtime targets.

Conclusion

RAID, snapshots and backups remain valuable when their roles are understood. The deeper failure is allowing working data and every recovery option to share one destructive authority, or discovering too late that a retained copy cannot be restored. Count copies, but also examine permissions, isolation, retention and tested recovery. The Synology incident analysis examines the other half of that problem: what public evidence does and does not establish about initial access.