Ransomware has changed the rules of data protection. It is no longer enough to simply have backups: modern attackers actively seek out backup repositories to encrypt or delete them before launching their final attack on production data. In this scenario, the difference between a mutable and an immutable backup can be the difference between recovering your business in hours or losing it forever.
According to data from CISA (Cybersecurity and Infrastructure Security Agency), ransomware attacks increased by 74% in 2025, and 93% of incidents included attempts to destroy or encrypt backup copies. This guide explains the fundamental differences between mutable and immutable backups, and how to implement an effective immutability strategy with tools such as Veeam Cloud Connect and Object Storage S3.
What Is a Mutable Backup?
A mutable backup is a backup copy that can be modified, overwritten or deleted after its creation. This is the traditional type of backup: files are written to a disk, NAS or repository, and any user or process with the appropriate permissions can alter them at any time.
For decades, mutable backups have been the industry standard. They work well for normal operational scenarios: restoring accidentally deleted files, recovering a corrupted database, or rolling back to a previous version of an application. However, they present critical risks in today's cyber threat landscape:
- warning Ransomware vulnerability: if an attacker gains access to the backup repository, they can encrypt or delete all backup copies before launching the main attack.
- warning Insider threat risk: a disgruntled employee or a compromised administrator account can deliberately delete backups.
- warning Accidental deletion: a human error in retention policy configuration can eliminate critical restore points with no possibility of recovery.
- warning Compliance gaps: regulations such as GDPR, ENS or PCI-DSS require data integrity guarantees that a mutable backup alone cannot provide.
What Is an Immutable Backup?
An immutable backup is a backup copy that, once written, cannot be modified, overwritten or deleted during a defined retention period. Not even an administrator with root access or an attacker with compromised credentials can alter the data. Once the immutability period expires, the data can be managed normally.
Immutability is implemented through several technologies:
Immutability technologies:
- WORM (Write Once Read Many): data is written once and can only be read. Used in LTO tapes and regulated archival systems.
- S3 Object Lock: native object storage mechanism that enforces immutability at the object level with Governance and Compliance modes.
- Hardened Repository: Linux repository with immutable file attributes (chattr +i) managed by Veeam, with no direct SSH access.
- Air-gap: complete physical or logical isolation of the backup repository from the production network.
In the Compliance mode of S3 Object Lock, not even the account owner can delete objects before the retention period expires. In Governance mode, an administrator with specific permissions can shorten the period if necessary, offering a balance between protection and operational flexibility.
Comparison Table: Mutable vs Immutable
The following table summarises the key differences between both approaches:
| Feature | Mutable Backup | Immutable Backup |
|---|---|---|
| Modifiable | Yes, at any time | No, until retention expires |
| Ransomware protection | Low: can be encrypted/deleted | High: resistant to encryption and deletion |
| Regulatory compliance | Requires additional controls | Natively meets GDPR, ENS, PCI-DSS |
| Cost | Lower (standard storage) | Slightly higher due to fixed retention |
| Flexibility | High: space can be reclaimed | Lower: space reserved until expiry |
| Ideal use cases | Operational backups, dev, test | Production, critical data, compliance |
| Guaranteed integrity | No | Yes, by design |
Ransomware and Backups: a Direct Threat
Ransomware attacks have evolved dramatically in recent years. Modern campaigns no longer simply encrypt production data. Threat groups such as LockBit, BlackCat or Cl0p execute what is known as double extortion: they first exfiltrate sensitive data and then encrypt both production systems and backups, threatening to publish the stolen information if the ransom is not paid.
The statistics are concerning:
- warning 96% of ransomware attacks include attempts to compromise backup repositories (source: Veeam Ransomware Trends Report 2025).
- warning The average cost of a ransomware attack exceeds EUR 4.5 million when factoring in downtime, data loss and reputational damage.
- warning Organisations that pay the ransom recover on average only 65% of their data, and 80% suffer a second attack.
In this context, a mutable backup connected to the network is effectively equivalent to having no backup against a sophisticated ransomware attack. Attackers are familiar with the most common backup architectures and actively seek credentials for Veeam, Commvault or Veritas to destroy restore points before launching encryption.
How to Implement Immutable Backups
There are several strategies for implementing immutability in your backup infrastructure. The choice depends on your environment, budget and regulatory compliance requirements:
1. Veeam Hardened Repository (Linux)
Veeam Backup & Replication allows you to configure a Linux repository as a hardened repository. In this mode, Veeam sets immutability flags at the filesystem level (using chattr +i) and the SSH connection is used only during initial setup. After that, the Veeam data transport service operates without SSH access, which eliminates the most common attack vector.
2. S3 Object Lock
S3-compatible object storage, such as that offered by EasyDataHost through our Object Storage S3 service, supports native Object Lock. When Veeam writes a backup to a bucket with Object Lock enabled, each object receives a retention timestamp that prevents its deletion or modification. This works with both the Veeam Scale-Out Backup Repository (SOBR) and copy jobs to the archive tier.
3. Veeam Cloud Connect with immutable repository
When using Veeam Cloud Connect with a provider such as EasyDataHost, backups are sent to a cloud repository managed outside the company's perimeter. As a Veeam Gold Partner, we configure our cloud repositories with immutability enabled by default, which means that even if an attacker completely compromises your on-premise infrastructure, the offsite backups remain intact and inaccessible.
4. Physical or logical air-gap
Air-gapping consists of physically isolating the backup medium from any accessible network. LTO tapes stored in a safe or a repository completely disconnected from the network are classic examples. In modern practice, a logical air-gap using isolated networks with strict access control and no bidirectional connectivity offers a comparable level of protection with greater operational efficiency.
Cloud Immutability with EasyDataHost
Keeping immutable backups outside your organisation's perimeter adds an additional layer of protection. If your on-premise infrastructure is completely compromised (including Active Directory, hypervisors and local storage), offsite immutable backups at EasyDataHost remain available for a full restore.
Our Tier III+ data centre in Madrid offers:
- check_circle Immutable Veeam Cloud Connect repositories: each backup receives automatic immutability with configurable retention periods from 7 to 365 days.
- check_circle S3 Object Storage with Object Lock: immutable object storage compatible with Veeam SOBR, with no traffic or request charges.
- check_circle End-to-end AES-256 encryption: data is encrypted in transit and at rest, with keys managed solely by the customer.
- check_circle Data in Spain: data sovereignty and compliance with GDPR, ENS and local regulations.
For environments with stricter business continuity requirements, our Veeam DRaaS service combines immutable backups with continuous replication, enabling recovery times of minutes in the event of a disaster.
Immutability Checklist
Verify that your backup strategy meets these minimum immutability requirements:
- check_circle At least one backup copy is immutable and cannot be altered by any administrator or automated process.
- check_circle Immutable backups are offsite, outside the corporate network perimeter, at a trusted provider.
- check_circle The immutable retention period covers at least 14 days to detect slow-burn ransomware encryption attacks.
- check_circle Periodic restore tests are performed from immutable backups to verify their integrity and operability.
- check_circle Immutable repository credentials are separated from the corporate domain and use mandatory MFA.
Conclusion
Immutability is not a luxury or an advanced feature reserved for large corporations. In today's cyber threat landscape, it is a minimum requirement for any organisation that wants to guarantee the recoverability of its data. The differences between a mutable and an immutable backup are clear: while the former offers operational convenience, the latter guarantees survival against the most sophisticated attacks.
The optimal strategy combines both approaches: local mutable backups for fast day-to-day restores, complemented by offsite immutable backups at a specialist provider like EasyDataHost for disaster and ransomware protection. Implementing this combination with Veeam Cloud Connect and S3 Object Storage with Object Lock is a straightforward process that can be completed in a single day.
- arrow_right Mutable backups are insufficient as the sole line of defence against modern ransomware.
- arrow_right Immutability through WORM, Object Lock or Hardened Repository ensures your backups cannot be altered.
- arrow_right Keeping immutable backups offsite and outside the perimeter is critical for recovery from total compromise scenarios.
- arrow_right Test your restores regularly: an immutable backup that has not been verified is a false sense of security.