## Why immutable backups matter now
Ransomware has changed the backup conversation. A few years ago, many organizations treated backup as an operational insurance policy: protect against accidental deletion, hardware failure, or a bad software update. Today, backup is also a security control. Attackers routinely search for backup servers, delete restore points, encrypt repositories, disable jobs, and compromise domain accounts that have access to backup infrastructure.
Immutable backups address that specific problem. An immutable backup is written in a way that prevents modification or deletion for a defined retention period, even if an administrator account is compromised. That does not make the environment ransomware-proof, but it can prevent a bad day from becoming an unrecoverable business event.
The challenge is that immutability is often implemented as a checkbox instead of an architecture. Teams enable object lock, buy a deduplicating appliance, or add a hardened repository, then discover during an incident that recovery is too slow, too expensive, or too manual. Good immutable backup design protects restore points without sacrificing recovery time objectives.
This article focuses on a practical architecture for SMBs, nonprofits, and midmarket IT teams that need ransomware-resilient backups but cannot afford enterprise complexity.
## The real design goal: protected restore points and usable recovery
Immutability is not the goal by itself. The goal is to preserve clean, recoverable data long enough to respond to an incident. That means your design must answer four questions:
1. Can an attacker delete or encrypt the backups?
2. Can an attacker shorten retention or disable future backup jobs?
3. Can you restore the systems that matter within the required time?
4. Can you prove the backups are clean and recoverable before leadership needs them?
Many backup failures occur because the first question receives all the attention while the other three are ignored. For example, an organization may copy backups to immutable cloud object storage, but if every restore requires pulling multiple terabytes across the internet, the recovery plan may not meet business requirements. Similarly, a hardened local repository may provide fast restores, but if it is the only protected copy in the same building, it does not solve disaster recovery.
The best practical pattern is layered protection: fast local recovery, immutable local or nearline retention, and offsite immutable retention.
## A reference architecture for ransomware-resilient backups
A strong design usually includes these tiers:
### Tier 1: Production storage snapshots
Storage snapshots are not a replacement for backup, but they are useful for quick recovery from minor incidents. They can help roll back a file share, VM, or database volume quickly. However, snapshots often live on the same storage system as production data, and many can be deleted by administrators. Treat them as convenience recovery, not ransomware recovery.
Recommended use:
– Short retention, often hours to a few days
– Fast rollback for accidental deletion or bad updates
– Protected with storage admin MFA and role separation
– Not counted as your only backup copy
### Tier 2: A hardened local backup repository
This is the workhorse tier for most recoveries. It should be close enough to production to support fast restores, but isolated enough that ordinary domain compromise cannot destroy it.
For many organizations, this means a Linux-based hardened repository with single-purpose access, no domain membership, restricted SSH, and filesystem-level immutability. Backup products such as Veeam commonly use this approach, but the principles apply broadly.
Key design points:
– Do not join the repository to Active Directory
– Use a dedicated local account for backup software
– Disable password SSH login after deployment
– Use MFA or privileged access controls for management access
– Use XFS or another supported filesystem when required by the backup platform
– Keep the repository on a separate management network where possible
– Monitor for failed logins, repository changes, and unexpected capacity growth
Example Linux hardening steps for a dedicated repository might look like this:
“`bash
# Create a dedicated backup user
sudo adduser backuprepo
sudo usermod -aG sudo backuprepo
# Disable root SSH login
sudo sed -i ‘s/^#PermitRootLogin.*/PermitRootLogin no/’ /etc/ssh/sshd_config
sudo sed -i ‘s/^PermitRootLogin.*/PermitRootLogin no/’ /etc/ssh/sshd_config
# Prefer key-based authentication
sudo sed -i ‘s/^#PasswordAuthentication.*/PasswordAuthentication no/’ /etc/ssh/sshd_config
sudo systemctl restart sshd
# Enable automatic security updates on Ubuntu/Debian
sudo apt update
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure –priority=low unattended-upgrades
“`
The exact commands depend on your distribution and backup vendor requirements, but the concept is consistent: the backup repository should not be managed like a normal file server.
### Tier 3: Immutable offsite object storage
Offsite immutable object storage protects against building loss, storage failure, insider misuse, and attackers who gain access to the local backup environment. Amazon S3 Object Lock, Azure immutable blob storage, and compatible object storage platforms can enforce retention at the storage layer.
For AWS S3, object lock must be enabled when the bucket is created. You cannot enable it later on an existing bucket. A simplified example:
“`bash
aws s3api create-bucket \
–bucket company-backup-archive-prod \
–region us-east-1 \
–object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration \
–bucket company-backup-archive-prod \
–object-lock-configuration ‘{“ObjectLockEnabled”:”Enabled”,”Rule”:{“DefaultRetention”:{“Mode”:”GOVERNANCE”,”Days”:30}}}’
“`
Governance mode allows privileged users with special permissions to bypass retention. Compliance mode generally does not. Compliance mode can be appropriate for regulated archives, but it is unforgiving. If you lock large volumes of data for too long, you may create a costly storage problem that even cloud administrators cannot quickly undo.
For many SMB and midmarket environments, governance mode with tightly controlled permissions is a practical starting point. Highly regulated environments may require compliance mode after careful testing and legal review.
## Separate backup administration from domain administration
One of the most common ransomware recovery mistakes is allowing the same identities to administer production systems and backups. If a domain administrator can delete production servers and backup restore points, the backup system is not meaningfully isolated.
Recommended practices:
– Use separate accounts for backup administration
– Require phishing-resistant MFA where supported
– Do not synchronize backup admin credentials from Active Directory unless the risk is understood
– Limit who can change immutability and retention settings
– Use separate cloud IAM roles for writing backups and administering bucket policies
– Alert on policy changes, retention changes, and deletion attempts
A useful cloud pattern is to separate write permissions from administrative permissions. The backup application often needs permission to write objects, read objects, and list buckets. It should not necessarily have permission to delete buckets, disable object lock, or change retention policies.
For example, avoid assigning broad policies such as administrator access to a backup service account. Instead, define a narrow role for backup operations and reserve storage policy administration for a separate, heavily protected identity.
## Retention design: do not lock everything forever
Immutable retention needs to be long enough to outlast attacker dwell time and detection delays, but not so long that it creates runaway cost. Many organizations start with one of these patterns:
– 14 to 30 days of immutable local backups for fast restore
– 30 to 90 days of immutable offsite backups for ransomware recovery
– Longer archive retention for compliance, stored separately from operational backups
The right number depends on your threat model and business requirements. If attackers commonly sit in an environment for weeks before detonation, a seven-day immutable window may not be enough. On the other hand, locking every daily backup for seven years in premium object storage is usually unnecessary and expensive.
A reasonable starting model for many organizations is:
### Operational recovery retention
Keep frequent restore points locally for 14 to 30 days. This supports the majority of restores, including deleted files, failed patches, and recent ransomware events.
### Security recovery retention
Keep immutable offsite restore points for 30 to 90 days. This gives the organization time to identify a clean recovery point if compromise occurred before encryption.
### Compliance archive retention
Keep monthly or yearly archives according to legal, insurance, or regulatory requirements. These should be designed as archives, not as the primary fast-restore tier.
## Avoid the slow-restore trap
Immutability can unintentionally push organizations toward architectures that are safe but painfully slow. A common example is relying entirely on cloud object storage for recovery. Cloud storage is durable and useful, but large-scale restores may be constrained by internet bandwidth, egress cost, API throttling, and the time required to rehydrate archived data.
To avoid this problem, design backward from your recovery time objective.
Ask:
– Which systems must be restored first?
– How much data must be restored to resume operations?
– What bandwidth is actually available during a disaster?
– Can critical servers be recovered directly from the backup repository?
– Can virtual machines be started instantly or staged to alternate hardware?
– Are cloud archive tiers being used, and how long does retrieval take?
If your ERP system has 8 TB of data and your usable internet throughput is 500 Mbps, a full cloud restore could take more than a day under ideal conditions before accounting for overhead. That may be acceptable for archive data but not for a mission-critical workload with a four-hour RTO.
This is why a hardened local repository is so valuable. It gives you a fast recovery tier while the immutable offsite copy protects against site-level or repository-level loss.
## Use backup networks and repository isolation
Backup traffic should not be an afterthought. In smaller environments, backups often run over the same VLANs used by workstations, printers, and general server traffic. That makes performance unpredictable and increases the attack surface.
Where practical, create a dedicated backup network or VLAN. Restrict access so only backup proxies, hypervisors, storage systems, and repositories can communicate on required ports.
Example firewall policy concept:
“`text
Allow: Backup server -> vCenter/Hyper-V management endpoints
Allow: Backup proxies -> ESXi/Hyper-V hosts on backup transport ports
Allow: Backup proxies -> hardened repository on required repository ports
Allow: Backup server -> object storage endpoint over HTTPS
Deny: Workstation VLAN -> backup repository
Deny: General server VLAN -> backup repository except documented agents
Deny: Backup repository -> internet except OS updates and approved monitoring
“`
This does not need to be overly complicated. The goal is to prevent every compromised workstation or server from being able to probe the backup repository.
## Monitor backups like a security system
Backup monitoring often focuses on job success or failure. That is necessary but not sufficient. Ransomware-aware monitoring should also detect suspicious backup administration activity.
Alert on:
– Backup job deletion or disabling
– Repository removal
– Retention policy reduction
– Immutability setting changes
– Unusual numbers of deleted restore points
– Failed administrative logins
– New backup administrator accounts
– Unexpected repository capacity spikes
– Object storage policy changes
– Failed attempts to delete locked objects
Send these alerts somewhere outside the backup server itself. If the backup console is compromised, alerts stored only inside that console may be useless. A SIEM, managed detection platform, syslog server, or even a separate ticketing integration is better than silent failure.
Cloud audit logs are especially important. For AWS, enable CloudTrail events for bucket policy changes and object lock configuration changes. For Microsoft Azure, monitor storage account immutability policy changes and role assignment changes. The exact tooling matters less than making sure policy changes are visible.
## Test restores, not just backups
A backup job that completes successfully is not the same as a successful recovery. Restore testing is the only way to validate the design.
At minimum, test these scenarios:
### Single-file restore
Can helpdesk or IT staff quickly restore a file without escalating to a senior engineer every time?
### Application-aware restore
Can you restore a database, domain controller, or line-of-business application to a consistent state?
### Full virtual machine restore
Can you restore or instantly recover a critical VM onto alternate compute resources?
### Bare-metal or infrastructure-loss recovery
If the backup server is gone, can you rebuild the backup console and import the repository or cloud backups?
### Clean-point recovery after compromise
Can you identify a restore point from before the attacker modified systems? This often requires coordination between backup logs, endpoint detection data, identity logs, and SIEM timelines.
A useful operational habit is to document restore results in a simple table:
“`text
System: Accounting SQL Server
Restore type: Application-aware VM restore
Backup source: Hardened local repository
Data restored: 1.8 TB
Target environment: Isolated recovery VLAN
Recovery time: 2 hours 35 minutes
Validation: Database mounted, application login successful
Issues found: Missing DNS dependency documented for next test
“`
This turns backup from a vague assurance into measurable business continuity evidence.
## Do not forget identity and configuration backups
Ransomware recovery is not only about virtual machines and files. Many organizations discover too late that they cannot easily recover firewall configurations, switch configurations, SaaS settings, identity provider policies, or backup software configuration.
Include these in your plan:
– Firewall and VPN configuration exports
– Switch and router configurations
– Hypervisor host configuration
– Backup server configuration database
– Microsoft 365, Google Workspace, or identity provider settings
– Conditional access policies
– DNS zone exports
– DHCP scope exports
– License keys and installer locations
– Documentation for privileged break-glass accounts
Network device configuration backup can be automated with tools such as Oxidized, RANCID, vendor controllers, or managed network platforms. Even a scheduled export is better than relying on memory during a crisis.
## Common mistakes to avoid
### Using immutability without access control
If every administrator can change the retention policy, immutability may not protect you from compromised admin credentials. Limit and monitor policy changes.
### Keeping the backup server on the same trust plane as production
A backup server joined to the domain and administered by the same domain admins may be easy to manage, but it is also easy for attackers to target after privilege escalation.
### Relying only on archive-tier cloud storage
Archive tiers reduce cost but may introduce retrieval delays. They are useful for compliance archives, not always for urgent operational recovery.
### Never testing full-system recovery
File restores are helpful, but they do not prove that critical applications can be recovered in the right order with the right dependencies.
### Ignoring backup software updates
Backup platforms are high-value targets. Keep them patched, restrict console access, and review vendor security advisories.
## Practical implementation checklist
Use this as a starting point for your own environment:
– Identify critical systems and assign RTO/RPO targets
– Build or validate a hardened local repository
– Remove backup infrastructure from unnecessary domain dependencies
– Enable immutable retention locally where supported
– Create immutable offsite storage with carefully scoped permissions
– Separate backup operator, backup administrator, and cloud storage administrator roles
– Restrict backup repository network access
– Monitor administrative changes and failed deletion attempts
– Test single-file, application, VM, and full-environment restores
– Document recovery order for critical systems
– Include network, identity, and SaaS configuration backups
– Review retention and storage cost quarterly
## Summary and key takeaways
Immutable backups are one of the most important defenses against ransomware, but they only work when they are part of a complete recovery architecture. The strongest designs combine fast local recovery, hardened repositories, offsite immutable storage, identity separation, monitoring, and routine restore testing.
Key takeaways:
– Immutability protects restore points, but it does not automatically guarantee fast recovery.
– Keep a hardened local backup tier for operational restores and an immutable offsite tier for disaster and ransomware resilience.
– Separate backup administration from normal domain administration.
– Use object lock and immutable storage carefully, with retention periods that match risk and cost realities.
– Monitor backup policy changes as security events, not routine administration.
– Test restores regularly and document actual recovery times.
For SMBs, nonprofits, and midmarket organizations, the goal is not to build the most complex backup environment possible. The goal is to build one that attackers cannot easily destroy and your team can actually restore from when the business needs it most.
