Ransomware is no longer satisfied with encrypting production files. A capable attack also looks for the systems that could undo the damage: backup servers, management consoles, snapshot stores and cloud repositories. If attackers can delete or encrypt those copies before demanding payment, the organisation loses its safest route back to normal operations.
Immutable backups address that specific weakness. They create recovery points that cannot be changed or deleted during a defined retention period, even when an attacker has obtained powerful credentials. That makes them a core part of ransomware protection, but not a complete recovery strategy on their own. Encryption, key custody, access controls, monitoring and verified restores still matter.
For businesses that operate their own servers, Safenix provides off-site backup stored in Germany. Backup data is encrypted with a key Safenix never holds, and copies are immutable for the length of the selected retention window. The result is a recovery layer separated from the production environment and protected against unauthorised deletion. Safenix protects servers controlled by the customer; it does not provide backup plans for websites running on shared hosting.
Why ransomware attacks backup systems
Many organisations think of backup as a collection of files waiting to be restored. Attackers see something more valuable: a map of the company’s resilience. Once they gain access to a server administrator account, a virtualisation platform, a backup console or a privileged cloud identity, they may be able to discover where copies are stored and how long they are retained.
The attack sequence often includes several stages:
- Steal or guess credentials for a privileged user.
- Disable endpoint protection and monitoring.
- Move from the initial system to file servers, databases and virtualisation hosts.
- Search for backup software, repositories, snapshots and service accounts.
- Delete recovery points or reduce their retention settings.
- Encrypt production data and any backup copy that remains reachable.
- Demand payment while claiming that recovery is impossible without the attacker’s key.
A backup repository that is merely connected to the same identity system or network may therefore be exposed even if it is located on separate hardware. Physical separation is helpful, but it does not automatically make a copy safe. If a compromised administrator can issue a delete command, the repository may fail at the moment it is needed.
Ransomware protection must account for the possibility that the attacker has administrator-level access. The question is not only whether unauthorised users can reach the backup system. It is whether anyone, including a legitimate account that has been compromised, can remove the last clean recovery point.
What immutable backups actually prevent
An immutable backup is a recovery point protected against modification or deletion for a defined period. During that period, the data cannot be overwritten, altered or removed through ordinary administrative operations. The protection applies to the stored object or backup record, rather than relying solely on a policy that tells an administrator not to delete it.
Immutability is best understood as an enforcement mechanism. A retention policy says that a copy should remain available for 30, 90 or 365 days. An immutable retention policy makes that requirement technically difficult or impossible to override before the period ends. This difference becomes decisive when credentials are stolen.
Suppose a company has daily backups with a 90-day retention policy. If an attacker gains access to the backup console and changes the setting to one day, the policy has provided no practical protection. If the same recovery points are locked against deletion until their expiry dates, changing the console setting does not remove the locked objects.
Immutability does not mean that every backup is permanent. Copies normally become eligible for deletion after their retention period expires. It also does not guarantee that the data is usable. A corrupted database, incomplete application backup or untested restore procedure can still produce a recovery failure. Immutable storage protects the existence and integrity of the copy; it does not automatically validate what is inside it.
Immutability versus ordinary retention
Ordinary retention is a schedule. It determines how many recovery points a backup system should keep and when older points may be removed. That schedule is necessary for managing storage costs, but it may be controlled by the same console and administrator accounts that an attacker targets.
Immutable retention adds a technical restriction to the schedule. Once a copy is committed, it cannot be deleted before its lock expires. A good design keeps the retention decision separate from day-to-day backup administration, so a compromised operator cannot shorten the window after an incident begins.
The two controls work together:
- Retention defines how far back the organisation wants to recover.
- Immutability prevents a protected copy from being removed or changed before that point.
- Versioning can preserve multiple recovery states rather than one continuously updated copy.
- Restore testing confirms that the retained data can actually support a recovery.
Immutability is not the same as an offline copy
An offline backup is disconnected from production systems, networks or administrative interfaces. This can be highly effective because ransomware cannot directly encrypt or delete a copy it cannot reach. Tape stored away from the network is a traditional example. A removable disk that is reconnected regularly for backup may provide less protection if it remains attached during an attack.
Offline storage and immutable storage solve related but different problems. Offline copies reduce the attack surface by removing connectivity. Immutable copies remain accessible for automated backup and recovery while blocking changes during the lock period. A resilient design may use both, particularly where recovery requirements justify the operational effort.
There are trade-offs. Fully offline media can make frequent backups, monitoring and rapid restores more difficult. Someone must rotate media, protect it physically, track which version is available and ensure that it can be read when needed. Immutable online or off-site storage can be easier to operate, but it must be isolated properly from compromised identities and management systems.
The important point is not to label any disconnected copy as automatically safe. An offline disk can be lost, damaged, infected before disconnection or overwritten by mistake. It needs inventory controls, access restrictions and restore tests just like any other backup.
Access-controlled storage is not automatically immutable
Restricting access to a repository is essential, but access control alone does not prevent deletion. An administrator may be the only person allowed to access the storage and still have permission to erase every recovery point. If that administrator account is compromised, the control becomes an attacker’s capability.
Least privilege should therefore be applied in layers. The account that writes backups should not necessarily be able to delete them. The account that manages backup jobs should not necessarily be able to change retention locks. The person who approves a restore should not automatically have access to encryption keys or repository configuration.
Multi-factor authentication, separate administrative identities, network restrictions and approval workflows reduce the chance that a stolen password becomes a complete compromise. They are important safeguards, but they do not replace immutability. An attacker may bypass one control through a vulnerable endpoint, stolen session token or social engineering. A locked recovery point provides protection after preventive controls have failed.
Object lock, WORM and isolated repositories
There are several ways to implement immutable backups. The terminology varies between products, but the design principles are consistent: commit data to a protected location, apply a retention period, and prevent deletion or alteration until that period ends. Businesses should understand what is actually locked, who can change the policy, and whether the lock can be shortened by an administrator.
Object-lock storage
Object lock is commonly used with object storage. Each backup object receives a retention timestamp, and the storage service refuses delete or overwrite requests before that timestamp. Some implementations offer a governance mode that permits authorised overrides and a stricter compliance mode that is designed to prevent such overrides, including by administrators.
The distinction matters. A governance-style lock may be sufficient for routine operational mistakes but less suitable when the threat model includes a stolen administrator identity. A stricter mode provides stronger protection, although it requires careful retention planning because mistakes cannot be corrected by simply deleting the object.
Object lock can work well for large repositories and automated backup workflows. It still needs protection around the storage account, API credentials, bucket configuration, replication settings and logging. An attacker might not be able to delete locked objects, but could attempt to stop new backups, alter job schedules or attack the management layer.
WORM storage
WORM means write once, read many. A WORM system allows data to be written and read but prevents it from being changed or removed during its protection period. WORM may be implemented in object storage, specialised appliances or other storage architectures.
WORM is a useful description of the storage behaviour, not a guarantee that every product using the term offers the same security. Ask whether the retention period is enforced by the storage layer, whether an administrator can override it, how the system handles clock changes, and what happens when capacity or replication fails.
Isolated backup repositories
An isolated repository separates backup data from the production network, identity directory and management plane. Isolation can be physical, logical or both. It may include a separate account, separate credentials, restricted network routes, a one-way backup path and a dedicated administrative process.
Isolation is especially valuable when a customer operates several servers or locations. Even if one production environment is compromised, the attacker should not automatically gain access to every repository. The repository should receive only the permissions needed to ingest and serve backups, while deletion and retention changes remain protected by a separate control.
For a practical comparison of these approaches, including immutable backup and ransomware protection concepts, review current guidance on immutable backup approaches for ransomware protection alongside the technical documentation for the storage platform being considered.
Why encryption and key custody matter
Immutability prevents an attacker from deleting or changing a backup. Encryption protects the content if someone gains access to the storage, copies the data or obtains access to the underlying infrastructure. Both controls are necessary because a backup that survives ransomware but exposes payroll, customer, legal or health information creates a different security incident.
Encryption should cover data in transit and data at rest. The backup agent should send data through a protected connection, and stored backup data should remain encrypted in the repository. Encryption reduces the value of stolen storage, but only if the keys are managed separately from the data and are not available to every administrator who can access the backup platform.
Key custody deserves particular attention. If the service provider holds the only usable decryption key, a compromise of that provider’s systems or an unauthorised internal action could expose the data. If the customer controls the key, the customer gains stronger control over confidentiality, but also takes responsibility for protecting the key and maintaining a usable recovery process.
Safenix uses customer-controlled encryption keys that Safenix never holds. This approach helps separate the provider’s storage role from the customer’s ability to decrypt its own data. Businesses evaluating this model can read about Safenix’s encryption and customer-held key approach, then confirm how key generation, backup, rotation, access and emergency recovery will work in their own environment.
Key custody should be documented before an incident. Decide who can access the key, how access is authorised, where an emergency copy is kept, and how the organisation will recover if the usual key administrator is unavailable. A lost key can make an otherwise intact immutable backup unrecoverable.
Designing backup retention for ransomware recovery
There is no universal answer to the question, “How long should immutable backups be retained?” The correct period depends on how quickly an attack is detected, how long an attacker may remain unnoticed, the organisation’s legal and contractual obligations, and the time required to investigate and rebuild systems.
A short retention window may be adequate for a small environment with rapid detection and low data complexity. It may be dangerous for an organisation where a compromise can remain hidden for weeks. If encrypted or altered files are included in daily backups for 30 days before discovery, a 30-day immutable window may leave no clean recovery point.
Factors that should influence the retention window
- Detection time: Estimate how long it could take to identify unusual encryption, account abuse or silent data corruption.
- Investigation time: Preserve clean points long enough to analyse the attack without destroying evidence or restoring from a contaminated period.
- Recovery time: Include the time needed to rebuild infrastructure, validate applications and recover data in stages.
- Business impact: Critical systems may justify longer retention and more frequent recovery points.
- Compliance and contracts: Some records require longer preservation, although backup retention should not be treated as a complete records-management policy.
- Storage cost: Longer retention consumes more storage, so use tiers or schedules that match the value and change rate of each workload.
A useful approach is to combine short-interval operational backups with longer-lived recovery points. For example, an organisation may keep frequent recent copies for fast recovery, daily copies for several weeks, and selected weekly or monthly points for longer. The exact schedule should be based on recovery objectives rather than a default setting.
Do not allow retention to expire while an incident is still being investigated. If a suspected compromise is discovered, preserve relevant immutable points and extend or separately export what is needed for forensic and recovery work, subject to the capabilities of the storage design. The incident team should know which copies are locked and when they are due to expire.
Recovery when administrator credentials are stolen
Stolen credentials do not automatically defeat immutable backups. If the attacker can access the backup console but the recovery points are locked in storage, the attacker may be able to stop future jobs or disrupt operations without deleting the protected copies. That separation is one of the main reasons to use immutable storage.
The response should still be immediate and methodical:
- Isolate affected systems. Disconnect compromised servers or network segments where practical. Do not allow the attacker to continue encrypting data or reaching additional systems.
- Disable and rotate credentials. Revoke stolen sessions, reset privileged passwords and rotate service credentials. Review API keys, tokens and accounts that can access repositories or encryption systems.
- Protect the backup environment. Restrict console access, block suspicious source addresses, review administrative changes and confirm that retention locks remain active.
- Stop destructive automation. Pause jobs or integrations that might overwrite clean data, while preserving the immutable copies already committed.
- Identify the last known clean point. Use logs, endpoint evidence and application checks to determine when the compromise began. Do not assume the newest backup is safe.
- Rebuild trusted infrastructure. Restore core identity, network and management components from known-clean sources rather than reusing compromised systems.
- Restore in a controlled environment. Recover a representative system first, scan it, validate its configuration and confirm that applications and data behave correctly.
- Document decisions and evidence. Record which recovery point was used, who approved it, what was restored and what indicators of compromise were found.
Never test a recovery by restoring directly over the only remaining production copy. Use an isolated network or a separate destination where possible. This prevents a corrupt or compromised backup from damaging the clean environment and gives the response team a place to validate the recovery safely.
Restore testing is part of backup security
An immutable copy that cannot be restored is an expensive archive, not a dependable recovery plan. Backup jobs can report success while missing an application database, excluding a required configuration file, failing to capture a consistent state or producing a restore that has unresolved dependencies.
Restore testing should happen regularly and should reflect the systems the business actually needs. A file-level test is useful, but it does not prove that an entire application can be brought back online. Test several recovery types:
- Restore individual files and confirm permissions, ownership and timestamps.
- Restore a database and validate application transactions and indexes.
- Recover a complete server or virtual machine into an isolated environment.
- Rebuild a critical service when the original infrastructure is unavailable.
- Verify that encryption keys are available and usable by authorised recovery staff.
- Measure how long recovery takes and compare it with the business recovery objective.
Use test data carefully. A restore environment may contain personal or confidential information, so it needs suitable access controls and disposal procedures. Keep a written record of test results, failures and corrective actions. A test that finds a missing dependency is valuable only if the backup design is changed afterwards.
At least one exercise should simulate the loss of the production environment and the backup console. This tests whether the organisation can locate protected copies, authenticate to the recovery service, access customer-controlled keys and restore without relying on a compromised management server.
Monitoring and least privilege around immutable copies
Immutability reduces the impact of deletion attempts, but monitoring helps detect the attack before recovery becomes necessary. Watch for changes in backup frequency, unusual data volumes, failed jobs, new administrators, retention-policy changes, access from unfamiliar locations and sudden attempts to enumerate repositories.
Alerting should reach people who do not depend solely on the potentially compromised production environment. If ransomware disables email or monitoring tools, a backup failure notification delivered only through those tools may never be seen. Keep logs protected from alteration and retain enough history to investigate who accessed the backup service and what they attempted to do.
Least privilege should be reviewed periodically rather than configured once and forgotten. Remove dormant accounts, separate human and service identities, limit the source networks that can reach management interfaces, and require multi-factor authentication for privileged access. Where possible, use separate credentials for backup writing, restoration, administration and retention management.
Do not give an application server broad permission to delete repository data. A compromised server should be able to send the data required for its backup, not administer the entire backup estate. The same principle applies to agencies managing multiple client environments.
Protecting multiple client environments without making restores impractical
Agencies, managed service providers and IT teams often need to protect several businesses at once. Centralisation can improve consistency, but it can also create a high-value target. If one shared administrator account or management console controls every client repository, one stolen credential could expose the whole portfolio.
A safer multi-client model separates tenants, credentials, policies and recovery permissions. Each client environment should have its own logical boundary and clear ownership of encryption keys. A technician who needs to restore one client’s server should not automatically be able to browse or delete another client’s backups.
Operational simplicity still matters. Excessive separation can make recovery slow or confusing, especially during a major incident. Agencies should maintain a clear service catalogue for each client, including:
- Protected servers and applications.
- Backup frequency and retention window.
- Immutable storage status and expiry dates.
- Encryption-key ownership and emergency access procedure.
- Approved restoration contacts and authorisation requirements.
- Recovery priorities and dependencies between systems.
- Last successful restore test and unresolved issues.
Use standard policies where workloads are similar, but make exceptions explicit. A small file server, a database cluster and a domain controller may need different schedules and restoration sequences. Templates help prevent omissions; they should not replace workload-specific testing.
Agencies should also practise a client-isolation scenario. Assume one customer’s administrator account is compromised and verify that the incident team can suspend that tenant’s access without interrupting the others. Then perform a restore using the correct client key, approval path and destination. This confirms that security boundaries do not create an operational dead end.
Common mistakes that weaken immutable backup protection
Keeping the only backup on the production server
A local backup can be fast and useful, but it shares the production server’s risks. A ransomware process with administrator privileges may encrypt both the live files and the local backup directory. Hardware failure, fire or theft can also remove both copies at once. Local backups should support rapid recovery, not serve as the only recovery layer.
Assuming snapshots are immutable
Snapshots are convenient points in time, but many can be deleted by the same administrator who controls the production platform. Some snapshots are also exposed to ransomware through mounted volumes or inherited permissions. Treat a snapshot as immutable only when the underlying storage enforces a lock that the relevant administrators cannot bypass.
Using one account for everything
A single account that creates jobs, changes retention, deletes data and manages encryption has too much power. It also makes investigation difficult because there is no meaningful separation of duties. Use dedicated identities and document which actions each one can perform.
Ignoring the key-recovery process
Customer-controlled encryption is powerful only when the customer can retrieve and use the key during an emergency. Store recovery instructions securely, test access with authorised personnel and plan for staff absence. Do not place an unprotected copy of the key next to the backup repository.
Testing only when something goes wrong
An emergency is the worst time to discover that a backup agent excluded a database, a credential expired or a restore destination lacks capacity. Schedule tests and treat failed tests as security findings with owners and deadlines.
A practical checklist for immutable backup security
Use the following questions when reviewing an existing backup design or evaluating an off-site service:
- Can ransomware running with production administrator privileges delete the stored recovery points?
- Is the retention lock enforced by the storage layer rather than only by a backup-console setting?
- Can an administrator shorten or override the lock period?
- Are backups stored away from the production network and identity system?
- Are data in transit and data at rest encrypted?
- Who holds the encryption key, and can the organisation recover it if a key administrator is unavailable?
- Are backup, restore, deletion and policy-management permissions separated?
- Is multi-factor authentication enabled for privileged access?
- Are changes, failed jobs and suspicious access attempts monitored?
- Does the retention window account for the organisation’s likely ransomware dwell time?
- Have complete application restores been tested, not just individual files?
- Can the organisation restore if the production backup console has been compromised?
- For multiple clients, are tenants, credentials, keys and recovery permissions separated?
Immutable backups are a foundation, not the whole recovery plan
Ransomware resilience depends on layers. Endpoint protection, patching, identity security, network segmentation and staff awareness reduce the chance of compromise. Immutable off-site backups limit the damage when those controls fail. Encryption and customer-controlled keys protect confidentiality. Monitoring exposes suspicious activity. Restore testing turns stored data into a workable recovery capability.
The most important distinction is between a backup that exists and a recovery point that remains available under attack. Ordinary retention, an access-controlled repository or a snapshot on the production platform may not survive a compromised administrator. Immutable storage is designed for that failure scenario: it preserves recovery points for the agreed retention window, even when someone with stolen credentials attempts to delete them.
For businesses controlling their own servers, an off-site backup design with encryption, customer-held keys, German data storage and immutability can provide a strong independent recovery layer. The safeguards should be reviewed and tested regularly, because immutable storage does not replace verified restores. It makes a trustworthy restore possible; disciplined recovery practice proves that it will work.