Why Immutable Backups Can Still Be Compromised
Why Immutable Backups
Can Still Be Compromised
Backups are frequently compromised in ransomware attacks. In some cases DriveSavers has handled, the affected backup solution was marketed as immutable.
Immutable backups are a standard defense against ransomware, often paired with air-gapping those backups. But immutability does not guarantee that data will be recoverable after an attack.
What Is an Immutable Backup?
An immutable backup is a copy of data that can’t be changed or deleted for a set retention period, even by an administrator. That write-once design makes immutability a standard defense against ransomware, since, in theory, attackers can’t tamper with a backup they can’t modify. But immutability protects only the data, not the software and credentials that manage it.
In October 2025, Akira ransomware reached a customer’s Nakivo backup repository, a platform marketed on its immutable storage. The Nakivo backups were deleted, while virtual machine data on the volume was encrypted.
The customer’s IT team ran recovery utilities against the volume for several days without success. They also copied 15TB of production data onto the same storage the deleted backups had occupied. That process overwrote portions of the deleted backup data.
DriveSavers imaged the drives and manually rebuilt missing BTRFS mapping information to reach backup data the volume had already released. Recovery on the priority database server reached 99.4 percent from the backup repository alone. Merging the unencrypted regions of the production virtual disks with the backup data brought the success rate to 99.91 percent.
Without those 15TB of overwrites, it would have been a complete recovery.
Immutability and air gapping get mentioned in the same breath, and they do different jobs.
Veeam draws the distinction clearly. An air-gapped backup is isolated from the network, either physically by removing the drive or disconnecting the ports, or digitally by blocking network traffic to it. An immutable backup cannot be changed or deleted until its retention period expires, but immutability does not require it to be offline. It may remain reachable over the network.
Veeam names the weakness of each. Physical logistics slow recovery from an air gap. Immutable backups remain accessible over the network, posing a risk when the controls around them are weak.
Immutability stops a backup from being altered. An air gap stops it from being reached. A compromised management layer cannot affect a backup it cannot reach.
Ask your vendor one question: can an administrator with full privileges override the immutability setting on this platform?
The answer will depend on how immutability is implemented. On some systems, users with sufficient privileges can override the protection; on others, no user can remove it until the retention period expires.
Then ask where the write-once protection is enforced. Immutability implemented by the backup application depends on that application staying trustworthy. Immutability enforced at the storage layer, through object lock on S3-compatible storage or a hardware appliance with WORM protection, does not depend solely on the backup application to enforce it.
Once you understand how your immutable backups are protected, take steps to protect the infrastructure around them:
Harden the management layer
Keep the backup console on separate credentials rather than the production directory, so compromising the domain does not hand over the backups with it. Require multi-factor authentication on the console.
Limit administrative access
Restrict the number of accounts with full privileges and review that access regularly.
Re-test after administrative changes
Verify the immutability policy whenever a backup administrator changes rather than assuming the inherited configuration is still working as intended.
Test the backup infrastructure as a target
Attackers target recovery capability. Include backup infrastructure in penetration testing rather than treating it as outside the attack surface.
Based on their survey of more than 900 senior IT, security, and risk leaders, Veeam’s Data Trust and Resilience Report 2026 found that 90 percent of organizations were confident they could recover from a cyber incident. Among respondents who had actually experienced a ransomware incident, only 28% fully recovered all affected data. 44% recovered less than three-quarters of it, leaving significant gaps.
Deleted or encrypted is not the same as not recoverable. When DriveSavers takes on a ransomware data recovery job, the work starts by identifying what remains on the media and what can be rebuilt from it.
Our engineers repair the structural damage encryption causes to virtual disks, backup files, and databases. When a decryptor has already run and left files corrupt, we may be able to repair the resulting damage. When a virtual disk is partially encrypted, DriveSavers uses its tools and techniques to identify and recover data from unaffected areas. We also recover older or unaffected versions of the data, including from copy-on-write systems, and we search alternative sources such as tape and cloud assets.
Disconnect affected devices from the network as soon as you can. Disconnect external storage and prevent affected systems from accessing connected cloud storage.
Disconnecting is not the same as shutting down. Powering a machine down can erase evidence held in volatile memory, so treat it as a last resort when disconnection is not possible.
Most importantly, do not write new data to storage containing deleted or damaged backups. Restoring data or continuing to use the affected storage can overwrite data that may otherwise be recoverable.
Turn off shared network resources and disable remote access to the infected devices. Keep the ransom note and any suspicious emails or attachments. Then call before anything is restored or rebuilt.
Paying the ransom demand does not close the gap either. In Veeam’s 2025 research, 17 percent of organizations reported they could not retrieve their data, despite meeting the attacker’s demands.
Decryptors can fail on large files, such as databases and backup files. Incomplete encryption can also cause a decryptor to fail. If an attack is interrupted during encryption, a file may be altered without reaching the complete encrypted state the decryptor expects, leaving the decryptor unable to restore it.
DriveSavers frequently works with clients who have obtained a decryptor but still need data recovery because the decryptor has failed to restore their data or has left files corrupted.
Deterrence and prevention get most of the attention, and they should. But Incident Response guidance often treats ransomware data recovery services as a last resort, discovered mid-crisis rather than planned for in advance.
The wrong time for an organization to start planning solutions is after the backups have already been targeted, and standard recovery methods have failed. Time is critical in a ransomware response: determining whether data is recoverable can take hours or days, while decisions about business continuity and ransom negotiations may need to be made much sooner.
Whoever is making the calls is doing so under pressure, and there should already be a trusted data recovery provider in the response plan. We are seeing cyber insurers ask whether the data is recoverable before they will negotiate a ransom payment, so naming a provider in advance can fast-track the whole recovery.
If your organization needs help assessing whether data recovery is possible after an attack, we offer professional ransomware data recovery services trusted by insurers and incident response firms.
Contact DriveSavers at 1 (888) 282-2227.
English (United States) 
English (Australia) 
French (France) 
English (UK) 
French (Canada) 
English (Canada) 
Spanish (Mexico) 
German 
Dutch 
Italian 
Finnish 
Polish 
Norwegian 
Swedish 
Danish 
Spanish (Spain) 
Chinese 
Japanese 
German (Austria)