In a ransomware attack, encrypting production servers is often just the first stage. If attackers also manage to delete or encrypt the backups, the organization is left without a clean recovery point. So what is immutable backup? It is the approach designed for exactly this risk: immutable backup means a backup that, once written, cannot be deleted or overwritten until its defined retention period expires.
This guide explains how immutable backup works, the technical methods behind it (WORM storage, S3 Object Lock and hardened repositories), how it differs from traditional backup, and the mistakes most often made during setup. It also compares on-premises and cloud-based options so IT teams can choose the model that fits their environment.
Are Your Backups Within an Attacker’s Reach?
An attacker with access to the management console can wipe every backup in minutes. The MAV Cloud team can work with you to assess how well your current backup setup would hold up in that scenario.
What is immutable backup?
Technically, immutable backup is a backup method in which data, once written, cannot be modified, deleted or encrypted for a defined period. This protection is not just a setting in the backup software; it is enforced by the storage layer. Even if an attacker gains administrator rights on the backup server, delete requests against locked backup blocks or objects are rejected.
The method is built on the WORM (Write Once, Read Many) principle. Data is written once and can be read as often as needed, but it cannot be changed until the retention period ends. Once that period expires, the backup can be cleaned up according to normal lifecycle rules.
Immutable backup is frequently discussed alongside the following terms:
- WORM storage: A storage model that is written once, read many times and closed to modification.
- Object Lock: Applying a retention period or legal hold to each object version in object storage.
- Hardened repository: A Linux-based backup repository in Veeam environments, protected by an immutability flag.
- Air gap: Physically or logically isolating backups from the production network.
Why does ransomware go after backups first?
The attacker’s goal is to get the ransom paid, and the most effective way to do that is to stop the organization from recovering on its own. The U.S. Cybersecurity and Infrastructure Security Agency’s #StopRansomware Guide notes that many ransomware variants attempt to find and delete or encrypt accessible backups, and it recommends maintaining offline, encrypted backups that are tested regularly.
In a typical attack, the attacker first escalates privileges on the network, then locates the backup server, hypervisor management and storage devices. If the backups are joined to the same Active Directory domain or reachable with the same admin account, the attacker can destroy the backup chain before launching encryption. In this scenario, immutable backup ensures the locked copies stay out of reach no matter what privileges the attacker holds.
How does immutable backup work? WORM, Object Lock and hardened repositories
Immutability can be applied at different layers. The right method depends on your existing backup software, storage infrastructure and retention requirements.
Object-level locking with S3 Object Lock
In S3-compatible object storage, the immutable lock is applied to each object version individually. According to the AWS S3 Object Lock documentation, there are two modes: in governance mode, users with special permissions can change the lock, while in compliance mode no user, including the root account, can delete the object or shorten the retention period while it is in effect. Object Lock works only on buckets with versioning enabled.
Veeam hardened repository
A common approach in Veeam environments is a Linux-based hardened repository. Backup files are marked immutable for a set number of days, and access to the repository server is limited to single-use credentials. As a result, locked files in the repository cannot be deleted even if the backup server itself is compromised.
Retention period and recovery window
In an immutable backup policy, the lock period is tied to how long it might take the organization to detect an attack. Attackers sometimes remain on a network undetected for weeks; if the lock period is shorter than that dwell time, clean copies may already have been deleted once their locks expire. The retention period should balance this risk against storage cost.
Traditional backup vs. immutable backup: common practice and the right approach
In many organizations, common practice is to keep backups on a NAS device or a network share. These copies protect against hardware failure, but they are not equally resilient against ransomware. The table below compares the two approaches on the key points.
| Area | Traditional backup (common practice) | Immutable backup (the right approach) |
|---|---|---|
| Deleting and overwriting | Possible with a privileged account | Blocked at the storage layer for the retention period |
| If an admin account is compromised | Backups can be deleted or encrypted | Locked copies remain protected |
| Domain dependency | Often in the same domain as production | Separate credentials and isolated access |
| Location | Usually the same building or the same network | A different location or cloud storage is preferred |
| Recovery confidence | Uncertain whether a clean copy exists | Known-date, verified clean recovery points |
Immutable backup does not have to fully replace traditional backup. The most balanced model keeps a local copy for fast restores and adds a locked copy as the last line of defense against ransomware.
On-premises or cloud immutable backup?
An on-premises hardened repository offers restores at local network speed and suits organizations that want data to stay in-house. However, hardware maintenance, operating system hardening, physical security and the fire, flood or earthquake risk of keeping everything in one building all remain the organization’s responsibility.
Cloud-based immutable backup moves the copy to a physically separate data center and leaves hardware management to the service provider. When choosing between the two models, weigh the following criteria:
- Recovery time objective (RTO): Local restores are faster for large data volumes.
- Geographic separation: To guard against regional disasters, the immutable copy needs to be in a different location.
- Management overhead: Keeping a hardened Linux repository server up to date requires expertise.
- Data location: The country where backups containing personal data are stored matters from a regulatory standpoint.
For many organizations, the best setup combines both: a local copy for fast restores and a locked cloud copy in a different location as a safeguard against ransomware. Teams looking for S3-compatible infrastructure can also consider S3-compatible object storage as the target repository in this architecture.
Keep Your Locked Copy in a Separate Data Center
The MAV Cloud immutable backup service stores Veeam-based backups immutably in an Equinix data center in Türkiye. Retention periods and recovery windows are defined together with you based on your organization’s risk profile.
The 3-2-1-1-0 rule and where immutable backup fits
The classic 3-2-1 rule calls for three copies of your data, on two different media, with one copy stored offsite. In response to the ransomware threat, the rule has been extended with two more elements:
- 3 copies: Production data plus at least two backups.
- 2 different media: For example, a disk-based local repository and object storage.
- 1 offsite location: One of the copies in another data center.
- 1 immutable or offline copy: A backup protected by immutable backup or an air gap.
- 0 errors: No verification errors left in restore tests.
The last element is the one most often neglected. A locked immutable backup copy offers no protection if it cannot be restored; regular restore testing is an integral part of the setup. The broader picture is covered in our article on backup strategies.
Setting up immutable backup: step by step
Before configuring any technical settings for an immutable backup setup, the scope and retention policy should be clearly defined. A typical implementation follows these stages:
- Scope: Identify which servers, databases and applications need a locked copy.
- Retention policy: Define how many days daily, weekly and monthly copies will stay locked.
- Target repository: Choose a hardened repository, Object Lock-enabled object storage or a service provider’s infrastructure for immutable backup.
- Identity separation: Separate access to the backup repository from the production domain and enforce multi-factor authentication.
- First full backup and verification: Take the first copy and run an integrity check.
- Restore test: Restore selected systems in an isolated environment and record duration and integrity.
- Monitoring: Track failed jobs, capacity and lock periods on a regular basis.
Storage capacity must also be factored in when setting retention periods. Because locked data cannot be deleted before its period expires, capacity planning for immutable backup requires more care than for traditional backup.
Common mistakes and the right approach
When immutable backup is not set up correctly, the protection it provides falls short of expectations. These are the mistakes we see most often in the field:
- Keeping backups in the same domain: If the repository server is joined to the production Active Directory, an attacker can find a way in with stolen credentials. The right approach is separate, isolated identity management.
- Treating governance mode as sufficient: If an account with bypass permissions is compromised, the lock can be removed; a stricter mode should be considered for critical copies.
- Setting the lock period too short: If an attack is detected late, clean copies may be lost because their locks have already expired.
- Skipping tests: An immutable backup that has never been restore-tested can bring surprises during a real incident.
- Not patching the repository server: Security updates for a hardened Linux server still need to be tracked.
Most of these mistakes are prevented through ongoing management, not a one-time setup. Ownership of monitoring, reporting and periodic testing should be clearly assigned.
Immutable backup, data residency in Türkiye and KVKK
Backups contain all of the personal data held in production. Under KVKK (Türkiye’s Personal Data Protection Law, Law No. 6698), data controllers are expected to take appropriate technical and administrative measures, and where backups are stored and whether they are transferred abroad is part of that assessment. Locked backups stored in a data center in Türkiye simplify cross-border transfer assessments.
The relationship between immutability and your retention policy also needs attention. Where personal data must be erased or destroyed, the lock period has to align with the organization’s data retention and destruction policy. This information is general in nature and does not constitute legal advice.
MAV Cloud immutable backup: infrastructure, standards and SLA target
MAV Cloud delivers backup and disaster recovery services from an Equinix data center in Türkiye, on VMware infrastructure with Veeam-based backup. Its information security and business continuity processes are certified to ISO/IEC 27001, ISO/IEC 27701, ISO 22301, ISO 9001 and ISO/IEC 20000.
- SLA target: A 99.9% monthly availability target for the backup service.
- First-response targets: 15 minutes for critical requests, 1 hour for high priority and 4 hours for medium priority.
- Support: 24/7 expert support and 24/7 system monitoring.
- Scope: An immutable backup layer designed together with cloud backup.
The technical scope and setup options are described on the immutable backup service page.
Frequently Asked Questions
What is immutable backup?
Immutable backup is a backup that, once written, cannot be deleted, modified or encrypted for a defined retention period. Because the protection is enforced at the storage layer, locked copies remain protected even if administrator privileges are compromised.
Does immutable backup fully protect against ransomware?
A properly configured immutable backup prevents attackers from deleting or encrypting your backups, giving you a clean recovery point. It does not prevent the attack itself; it should be used alongside measures such as endpoint security, access management and monitoring.
Is WORM storage the same as immutable backup?
WORM is the storage principle of writing data once and reading it many times. Immutable backup is the approach that applies this principle to the backup process, implemented through methods such as Object Lock or a hardened repository.
How long should the lock period be?
There is no single right value. The period is set by weighing how long it takes to detect an attack, recovery needs, storage capacity and your data retention policy; very short periods create risk when attacks are detected late.
What is the difference between S3 Object Lock governance and compliance mode?
In governance mode, users with special permissions can change the lock or delete the object. In compliance mode, no user can delete the object or shorten the retention period while it is in effect.
Is restoring from an immutable backup slower?
Immutability alone does not determine restore speed. Speed depends on where the repository is located, connection capacity and data volume. That is why it is common to combine a local copy with a locked cloud copy for fast recovery.
What role does immutable backup play in the 3-2-1-1-0 rule?
The second “1” in the rule means at least one copy is kept immutable or offline. The “0” means there should be no verification errors left in restore tests.
Do Microsoft 365 data need immutable backup too?
Data on SaaS platforms can also be lost through accidental deletion, compromised accounts or ransomware. Taking an independent backup of this data and protecting that backup with immutable backup should be considered part of your overall backup strategy.
Build Your Last Line of Defense on Real Measurements
A free assessment can show how well your current backups would withstand a ransomware scenario, along with their retention periods and restore times.
For organizations just starting to research the topic, the first step is to identify which accounts can currently delete your backups. IT teams undecided between on-premises and cloud can create an immutable backup copy for one of their most critical systems and measure a restore test to make the decision based on real data. Businesses ready to build the setup can finalize their retention policy and implementation plan together with the MAV Cloud team.