How I would design immutable backup for a small enterprise

I would make administrative separation the non-negotiable design choice. Backup is only a recovery control if an attacker who reaches routine production administration cannot also erase, weaken or quietly alter every retained copy; the rest of the architecture follows from that assumption.

Not every workload needs instant failover. Every business-critical workload does need a known-good recovery path. Immutability is one control in that path, not the strategy on its own: it can stop a compromised administrator or backup process deleting retained recovery points, but it cannot identify a clean restore point, rebuild identity or make an application work after restoration. Immutable backup has important limits as well as protections.

This is a bounded design for an organisation of roughly 50 to 300 people: a largely virtualised on-premises estate or small private-cloud footprint, Microsoft 365 or similar software-as-a-service (SaaS) services, a handful of line-of-business applications, limited internal IT staff and no realistic appetite for 24-hour operational cover. A managed service provider (MSP) can operate parts of it, but the organisation must retain ownership of its recovery decisions, accounts and documentation.

Start with the recovery promise, not a storage purchase

Backup projects go wrong when someone asks a supplier for “immutable backups” before deciding what must work, for whom and by when. Start with a short recovery matrix, signed off by service owners. Don’t start with a sizing-tool estimate.

Recovery point objective (RPO) is the maximum acceptable data loss measured in time. Recovery time objective (RTO) is the time allowed to restore a usable service. Both are business choices constrained by cost and operational reality; neither is a product promise.

For many small enterprises, a four-hour RPO for the genuine core and daily protection for the rest is a defensible starting point. An RTO measured in hours rather than minutes is equally defensible when the alternative is permanent replication, a duplicate production environment and people to maintain it. That’s a major cost increase, not a backup feature.

The architecture: two recovery paths with different failure modes

The recommended architecture has two destinations: a local hardened repository, sized for rapid recovery of recent backups, and immutable object storage outside the normal administrative boundary. The first handles routine restores. The second is there to survive ransomware, deletion, repository failure and loss of the primary premises.

The local repository is not merely a cache. It is the working recovery copy: where you restore a deleted file, database or virtual machine without waiting for an internet transfer. Use a dedicated Linux-based repository or equivalent hardened appliance, with separate administrative credentials, restricted management access and no reason for ordinary users to reach it. The backup application should have only the permissions needed to write and expire backup data, not a general-purpose repository administrator account.

Give the local copy an immutability period too. Fourteen to 30 days for frequent backups is a sensible starting point if capacity permits. The exact period should reflect the likely time between compromise and detection, the organisation’s change rate and the cost of keeping more data. Don’t choose it because a vendor default happens to be 14 days.

The off-site copy is the survival copy. Store it in object storage with a time-based write-once-read-many (WORM) retention policy, ideally in a dedicated cloud account or subscription that isn’t administered through the same everyday identity path as production. Both Azure Blob immutable storage and Amazon S3 Object Lock can prevent protected objects being overwritten or deleted during their retention periods, though their implementation and operational traps differ. (learn.microsoft.com)

Off-site retention will normally outlast local retention: for example, 90 days of daily immutable restore points plus monthly points held for a year, subject to legal, contractual and data-minimisation requirements. Monthly copies matter because ransomware may be discovered late, and accidental corruption can be backed up faithfully for weeks before anyone notices.

There is no universal retention number. A legal practice, insurer, finance business or public body may need much longer records. Retaining every daily copy for years, though, is an expensive substitute for making a retention decision. Object-store retention is intentionally difficult to unwind. AWS describes compliance mode as preventing deletion or overwriting even by the account root user before the retention date; Azure likewise warns that locked policies and versioning choices need careful testing before use. (docs.aws.amazon.com)

Where immutability belongs, and where it doesn’t

Enforce immutability at the repository and off-site storage layers. Don’t infer it from a successful backup job. A successful job proves only that the backup application wrote something; it doesn’t prove that a hostile administrator can’t remove the copy, shorten retention or disable the next job.

Protect the local repository against routine deletion and alteration by the backup platform. Put the object-storage copy under a locked time-based retention policy after a short pilot period. Governance-style retention, where a suitably privileged identity can override retention, can be useful during testing and for narrowly defined operational exceptions. It is not enough for the copy intended to survive a full administrative compromise. AWS notes that governance retention can be bypassed by identities with the appropriate permission, whereas compliance retention cannot be shortened or removed before expiry. (docs.aws.amazon.com)

Legal holds are not a replacement for routine backup retention. They are for exceptional preservation requirements and need documented authority to apply and release. Mixing them casually into normal operations makes cleanup harder and can create unnecessary storage bills.

Encryption matters, but treat it soberly. Encrypt backups in transit and at rest; record where the encryption keys live, who can recover them and what happens if the normal identity service is unavailable. A backup encrypted with a key accessible only to a compromised tenant administrator isn’t a resilient recovery copy.

Protect the control plane as if it will be attacked

Most small-enterprise backup weaknesses are not about media. They are about identity. If the same privileged Microsoft Entra, Active Directory, cloud or password-manager identities can administer production, alter backup software, delete the repository and change off-site retention, the design has one large blast radius.

Separate ordinary administration from backup and recovery administration. Use named, role-limited accounts; prohibit shared daily admin credentials; require phishing-resistant multi-factor authentication where the platform permits it; and keep recovery credentials in a controlled offline process rather than in the backup console alone. The backup software should not sit in the same broad group of highly privileged accounts used to run everything else.

For cloud services, maintain at least two documented emergency-access accounts outside any on-premises federation or synchronisation dependency. Microsoft recommends cloud-only emergency accounts, authentication methods distinct from routine admins, secure credential storage and regular validation. (learn.microsoft.com) This isn’t an unmonitored superuser. It avoids discovering, during an incident, that a broken directory or Conditional Access rule has locked the organisation out of the place where recovery must begin.

The object-storage account needs its own recovery runbook. Identify the account owner, billing contact, root or emergency-account custody, hardware security keys where used, logging location, encryption-key ownership and the exact restore-authorisation process. If an MSP operates the account, the customer still needs a tested route to regain control if that supplier is unavailable.

An immutable copy in the same cloud tenant is useful, but insufficient. It may resist object-level deletion, yet an attacker with tenant-wide control can still disrupt identities, networking, billing, monitoring or the recovery team’s ability to operate. Separate accounts and credentials don’t make compromise impossible; they make an attacker’s job harder and recovery more feasible.

Identity and SaaS are recovery dependencies, not side projects

Don’t put Active Directory or Entra recovery at the bottom of a virtual-machine restore list. Identity determines who can sign in, who can administer systems and whether applications can reach their dependencies. Preserve system-state or equivalent identity backups, directory documentation, privileged-group records, DNS and DHCP configuration, and a tested sequence for bringing identity back without immediately reintroducing compromise.

Microsoft 365 needs its own recovery decision. Native recycle bins, version history and service resilience are valuable, but they do not automatically meet every organisation’s recovery-window, granular-restore or independence requirements. Microsoft 365 Backup, for example, has defined restore-point behaviour and coverage for Exchange Online, SharePoint and OneDrive; its documented restore-point frequency varies by workload and restore age. (learn.microsoft.com)

The recommendation isn’t “always buy a separate SaaS backup product”. Document the recovery scenarios instead: a deleted mailbox, a malicious SharePoint rollback, a departed user, a compromised administrator and a tenant-wide configuration problem. Then test whether native capabilities, Microsoft 365 Backup or an independent provider meets them. Don’t leave email, identity and OAuth-connected applications until after the storage design is complete.

Testing is what turns retained data into recovery

A green dashboard is not evidence of recoverability. The US Cybersecurity and Infrastructure Security Agency (CISA) and the UK’s National Cyber Security Centre (NCSC) advise organisations to maintain protected backups and test restoration regularly; the NCSC also warns that attackers may disrupt recovery processes or destroy copied files before encryption begins. (cisa.gov)

Keep the testing programme modest enough to happen, but substantial enough to expose awkward dependencies:

• Every week: review failed jobs, missed protection, capacity trends, immutability status and off-site-copy completion. Someone accountable should read the exceptions, not merely receive alerts.
• Every month: restore representative files and one application data set to a non-production location. Check that the data is usable, not simply that the job completes.
• Every quarter: restore a Tier 1 server or application stack into an isolated recovery network. Involve the service owner, measure elapsed time, validate logins and transactions, and record what slowed the process.
• Every year: rehearse a ransomware scenario in which normal admin identities and the primary backup console are unavailable. Practise accessing the off-site copy, building clean infrastructure and deciding which restore point is safe.

Use an isolated recovery network for serious tests. Restoring an infected image straight onto the production local area network (LAN) isn’t validation; it is an avoidable second incident. Include malware scanning and application-level checking, because a technically clean restore can still contain corrupted data or compromised credentials.

Record the real RTO and the gap against the planning target. If a supposedly four-hour recovery takes 14 hours because the database licence, DNS record, firewall rule and service-account password were missing, that is useful evidence. Better that than a compliance tick-box.

What this design deliberately does not buy

It doesn’t begin with continuous replication to a second production site. Replication is valuable for genuinely low-RTO services, but it can replicate deletion, corruption and ransomware quickly. It also demands duplicate capacity, networking, licensing, monitoring and people. For most small enterprises, immutable backups and rehearsed recovery are the better first investment.

It doesn’t require tape on day one. Tape remains reasonable where long retention, low ongoing media cost, air-gap requirements or limited connectivity make it the right fit. But tape brings handling, drive compatibility and restore-time discipline that many small teams do not operate well. An immutable, separately administered object-store copy is usually more practical, provided egress bandwidth, provider access and account recovery have been tested.

Nor does it prescribe a particular backup product. The product needs application-consistent protection, separate repository credentials, immutable retention at the selected destinations, reporting that exposes failed copies, and restores into an isolated environment. A dedicated hardened repository may be right for one team, while a software appliance may suit another; choose based on operational ownership and recovery requirements, not branding. Repository architecture is a recovery design decision, not just a product choice.

The recommended approach in one page

Protect Tier 1 systems at least every four hours and the rest daily where that matches the agreed RPO. Write first to a local hardened repository with roughly two to four weeks of immutable recovery points. Copy to separately administered immutable object storage daily, retaining daily points for around 90 days and monthly points for a year unless compliance or business need says otherwise.

Keep backup, repository and off-site storage administration separate. Maintain emergency access to identity and cloud services. Preserve recovery paperwork, licences, configuration exports and encryption-key records outside systems that may be compromised. Test file restores monthly, Tier 1 application restores quarterly and an identity-plus-ransomware recovery annually.

For Channel Islands organisations, make one final practical check: connectivity. Off-site backup is only a recovery asset if data can be retrieved within the stated RTO. Measure real restore throughput to the selected location, allow for contention during an incident, and decide in advance whether the local repository can cover the first days of recovery. A design that assumes perfect wide area network (WAN) capacity at the worst possible moment isn’t a design; it’s a hope.

It isn’t glamorous. It is a practical small-enterprise architecture: quick for everyday mistakes, resistant to destructive change, survivable beyond the primary site, and tested often enough to show whether the organisation can actually use it.