Backup and Disaster Recovery for a Small Business: What Actually Works in 2026

I have walked into the aftermath of enough ransomware and accidental-deletion incidents to know what the common version of the conversation sounds like. The owner is calm at the start because the IT vendor has assured everyone that "we have backups." Two hours later we are looking at the backup share and the dates on the most recent good copy are from before the attacker was in the environment, or the backup software is happily logging successful jobs against an empty target, or the only restore the team has ever performed is the one happening right now.

That is not a technology problem. The products are fine. The problem is that backup design for a small business has not kept up with the way attackers operate, and most SMB programs are still optimized for the 2018 threat model. This is the long read on what actually works in 2026 for a 15-to-100-person business, written without the marketing gloss. If your operation runs on Microsoft 365 and a couple of on-prem servers, this is for you. For the full service write-up see our backup and disaster recovery service page.

Why backup matters more in 2026 than it used to

Two things have changed about the threat landscape since the last time most SMBs reviewed their backup plan.

The first is the speed and automation of attacks. As covered in the post on AI-driven attacker handoff times, the gap between an initial access broker landing a credential and a ransomware affiliate taking over has collapsed from hours to seconds. The attacker pipeline qualifies, prices, and routes accesses faster than any human defender can intervene. By the time a human IT contact reads a security alert, the secondary actor is already inside.

The second is that modern attackers explicitly target backup infrastructure first. This is the part that catches small businesses off guard. The playbook used by every major ransomware group in 2025 and 2026 looks the same: gain access, do reconnaissance, locate the backup server, delete or encrypt the backups, then deploy the encryptor against production. The whole point of compromising the backups before the production data is to remove the option of recovering without paying. CISA and the major IR firms (Mandiant, Unit 42, Sophos X-Ops, Coveware) have all published incident data showing this pattern in roughly 70 to 90 percent of ransomware events where the victim had any meaningful backup.

The implication for an SMB is direct. A backup that lives on a Windows file share, joined to the same Active Directory as production, mounted with a service account that the attacker can reach, is not a recovery option. It is a slightly slower second copy of the data the attacker is about to encrypt. The question is not whether your backup product is good. The question is whether the backup is reachable from the production network using credentials that exist on the production domain.

The 3-2-1-1-0 rule, explained

The classic 3-2-1 rule (three copies, two media, one off-site) has been the SMB shorthand for backup design for the better part of two decades. In 2026 it is not enough. The updated formulation, which the major backup vendors and most credible auditors now reference, is the 3-2-1-1-0 rule. The two additional digits are the ones that handle modern threats.

3 — Three copies of the data. The production copy plus at least two additional copies. The point is redundancy: if any single copy is corrupted, lost, or compromised, the other two are still available. For an SMB this typically means production data on a server or in Microsoft 365, a local backup on a NAS or backup appliance, and a cloud backup with a different vendor.

2 — Two different media or storage types. Originally about diversifying across tape, disk, and optical media. In 2026 the spirit of the rule is to avoid storing all copies on the same underlying technology with the same failure modes. Practically: local disk plus cloud object storage. Or local backup appliance plus a different cloud provider. The goal is that a single systemic failure (a firmware bug, a misconfiguration, a ransomware family that specifically targets one platform) cannot eliminate every copy.

1 — One copy off-site. At least one of the copies must be physically separated from the production environment. Cloud storage qualifies. A backup appliance carried home in a vendor's car does not. Off-site protects against fire, flood, theft, and the kind of site-level event that wipes out the building. On the Central Coast, this also means thinking about public safety power shutoffs, structure fires, and earthquakes. The PSPS continuity post covers the local angle.

1 — One copy immutable or offline. This is the digit that handles ransomware. At least one of the copies must be written to storage that cannot be modified, encrypted, or deleted by anyone (including the account owner) for a defined retention period. The mechanism is platform-specific: S3 Object Lock in compliance mode, Azure Blob immutable policies, Wasabi Object Lock, Veeam hardened repositories, Datto SIRIS immutable cloud, Acronis immutable storage. Whatever the implementation, the property is the same: once written, it cannot be undone for the retention window. Offline backups (tapes in a vault, or a backup that is air-gapped after each job) achieve the same end with a different mechanism.

0 — Zero errors after verification. Backup jobs that report "success" are not the same as backups that are recoverable. The 0 digit is the verification step: each backup is checked, ideally by an automated test restore or hash comparison, and the system reports zero errors. Most modern backup platforms (Veeam SureBackup, Datto inverse-chain technology, Acronis verification) have this built in. The cost of skipping verification is finding out during a real incident that the chain has been silently broken for six weeks.

If a backup program does not satisfy 3-2-1-1-0, it is not a 2026-ready program. The good news is that for an SMB the gap is usually one or two digits, not five.

What good SMB backup looks like in 2026

Pulling back to the architecture level, a credible small-business backup program covers five layers. Each layer has its own backup tooling, its own retention, and its own restore drill. Missing any one of them is the most common reason a program fails in a real incident.

Layer 1: Endpoint data

Workstations and laptops contain a meaningful share of the data the business produces, even in shops that try to keep everything on the server or in SharePoint. The realistic state of an SMB endpoint is that users keep working files on the desktop, in Downloads, and in local Documents folders. A backup plan that ignores endpoints is a backup plan that loses real data on every hardware failure or theft.

Two paths are reasonable in 2026. The first is a managed cloud-backup agent on every endpoint: Datto Workplace, Carbonite Endpoint, Acronis Cyber Protect, or a similar product. These run continuously, back up to a vendor-managed cloud, and retain versions. The second is Microsoft 365 OneDrive Known Folder Move, which redirects Desktop, Documents, and Pictures into OneDrive automatically. The KFM path is cheaper because it is bundled with the Microsoft 365 license, but it ships with a caveat: OneDrive is sync, not backup. If a file is encrypted by ransomware on the endpoint, OneDrive faithfully propagates the encrypted copy to the cloud and to every other device connected to the account. The third-party Microsoft 365 backup (see Layer 3) is the control that backstops this; without it, OneDrive KFM is one of the most common ways small businesses lose data.

Layer 2: On-premises servers

If the business runs any on-prem server (file server, line-of-business app server, accounting database, ERP, electronic medical record), it needs image-level backup. The image is the entire server state: operating system, applications, configuration, and data. The standard products for SMBs are Veeam Backup & Replication, Datto SIRIS, Acronis Cyber Protect, and Unitrends. Each is reasonable; the differences are in the management experience and the cloud-tier pricing.

The recommended pattern is local plus cloud. The local copy lives on a dedicated backup appliance or NAS in the same building, optimized for fast restore. The cloud copy lives in immutable object storage with a different credential set than production. Local handles the day-to-day recovery (a corrupted database, a deleted folder, a failed disk). Cloud handles the disaster (the building burns, the production network is encrypted, the local appliance is compromised). Both copies should be backed up at least daily; the cloud copy should be immutable.

The single most common architectural mistake in SMB server backup is running the backup software on a server that is joined to the production Active Directory, with a service account that has domain admin rights, writing to a share that production machines can browse to. That whole stack collapses when the attacker compromises a single domain admin credential. The fix is to either run the backup environment on a separate, locally-authenticated management plane, or to use a vendor-managed appliance with its own identity, and to write the cloud copy with credentials that do not exist on the production domain.

Layer 3: Software-as-a-Service data (Microsoft 365 and others)

This is the layer where the SMB conversation goes off the rails fastest. The widespread belief is that Microsoft 365 data is backed up because "it is in the cloud." That belief is wrong, and Microsoft is explicit about it in the Services Agreement and the Shared Responsibility model. Microsoft is responsible for the availability and integrity of the service. The customer is responsible for the data.

Microsoft 365 has retention policies, recycle bins, Litigation Hold, and a 93-day mailbox retention window after deletion. None of those is a backup in the disaster-recovery sense. They protect against some accidental deletions and provide some compliance functions, but they do not protect against:

• A compromised admin account purging mailboxes or wiping SharePoint sites.
• A misconfigured retention policy deleting content that the business needed to keep.
• A long-tail discovery (six months later) that a specific employee deleted a year of files before leaving.
• A SharePoint or Teams site that was deleted and is now past Microsoft's recovery window.
• A point-in-time restore of a mailbox to a specific calendar date.

The correct answer is a third-party Microsoft 365 backup product: Veeam Backup for Microsoft 365, Datto SaaS Protection, Acronis Cyber Protect for M365, Afi, AvePoint Cloud Backup, or a similar tool. These products take regular snapshots of mailboxes, SharePoint sites, OneDrive accounts, and Teams channels (chat, files, and configuration), store them outside the Microsoft tenant, and offer point-in-time restore. Pricing is typically $3 to $6 per user per month for a 25-user firm. The line item is small. The data exposure without it is not.

If the business uses other SaaS products that contain primary data (a CRM like Salesforce or HubSpot, a financial system like QuickBooks Online or NetSuite, a project tool like Asana or Monday with attachments), each of those needs its own backup story. Most major SaaS vendors offer some form of export; few of them offer real point-in-time restore for free. Treat each SaaS system the same way: assume the vendor is responsible for availability and you are responsible for recoverability.

Layer 4: Network configuration state

The fourth layer is the one that nobody thinks about until the network has to be rebuilt from scratch. Firewall configurations, switch configurations, wireless controller settings, DHCP scopes, DNS records (especially external DNS hosted at the registrar), VLAN definitions, and VPN tunnel configurations are all data. Most of them live on devices that are not part of the production server backup. When the building burns or the firewall dies, the rebuild time is measured in days because nobody has the configuration in a recoverable form.

The fix is mundane. Export the firewall config monthly. Export the switch and wireless configs monthly. Export the public DNS zone monthly. Store all of them in the backup repository alongside the server backups. Document the external IP addresses, the ISP account numbers, the registrar credentials, and the order in which the network comes back up. A one-page network-restore runbook saves a working day in a real disaster.

Layer 5: Identity and access state

The fifth layer is identity. In a Microsoft 365 environment that means Entra ID: user accounts, group memberships, Conditional Access policies, MFA registrations, app registrations, and Conditional Access exclusions. In a hybrid environment it also means on-prem Active Directory state. In a real disaster, the recovery question is often "who is the global admin and how do we prove it." Documenting the answer in advance, with a written MFA seed reset procedure and a hardware key or break-glass account stored somewhere offline, is the difference between a four-hour recovery and a four-day recovery. The identity hardening post covers the prevention side; the recovery side is mostly documentation.

The four failure modes I see in the field

The five layers above are what good looks like. The next section is what bad looks like, which is what most of the field actually runs in 2026. These four failure modes account for roughly every restore I have walked into in the past two years.

Failure mode 1: production-reachable backups

The backup server lives in the same VLAN as production. The backup software runs under a domain admin account. The backup share is browsable from any workstation. When the attacker takes over a single domain admin, the backups are reachable, the credentials are valid, and the encryptor walks through them as easily as it walks through the file server. The team finds out the next morning that "we have backups" and "we can restore" are not the same sentence.

Mitigation. Immutable cloud storage with a credential set that does not exist on the production domain. A separate management plane for the backup software (locally authenticated, MFA on the console, not domain-joined or in a hardened minimal domain). Network segmentation that prevents production endpoints from reaching the backup repository directly. If on-prem appliance: a hardened repository with one-way authentication. If cloud: object lock with retention set to at least 30 days.

Failure mode 2: untested backups

The backup jobs report success. The retention is configured correctly. The first time anyone has tried to restore from this system is the day the production server died. The restore fails because the chain has been corrupted, or the application-aware backup was never actually consistent, or the network credentials no longer match, or the target hardware is too different from the source.

This is the most common failure mode for SMBs that have a backup product but no backup discipline. The product works. The process around it does not.

Mitigation. A written restore-testing cadence. Monthly: a random-file restore. Pick a file from a random user's last backup, restore it to a scratch location, open it, verify the contents match. Quarterly: an image restore of a representative server to spare hardware or a virtual machine, bring up the services, verify they work. Annually: a full DR drill where the production server is intentionally taken offline (or failed over) and the team works from the DR copy for two to four hours. Each drill is documented, gaps are tracked, and the next drill closes them.

Failure mode 3: missing Microsoft 365 backup

The IT vendor or the in-house generalist heard at some point that "Microsoft handles backup" and never revisited the assumption. The business has been running for years without a real point-in-time restore for email or files. The day someone discovers that a departing employee deleted a year of project documents before leaving, or that an admin account was compromised and used to purge mailboxes, the recovery options are limited to whatever Microsoft's native retention happens to still hold. Sometimes that is enough. Often it is not.

Mitigation. Deploy a third-party Microsoft 365 backup. Veeam Backup for Microsoft 365, Datto SaaS Protection, Acronis, Afi, or AvePoint are all reasonable. Cover mailboxes, SharePoint, OneDrive, and Teams. Retain at least one year. Test the restore quarterly with a real mailbox or site. The line item is small. The gap it closes is not.

Failure mode 4: no documented RPO or RTO

The owner thinks "real time." The IT vendor thinks "nightly." The accounting team thinks "we can re-key a day of entries if we have to." The line-of-business application owner thinks "we lose two hours of data and we are dead in the water." Nobody has had the conversation, so the backup design reflects whoever happened to install the product, and the recovery experience reflects whatever happens to be configured.

Mitigation. Write down the Recovery Point Objective (how much data the business can afford to lose) and the Recovery Time Objective (how long the business can afford to be down) for each critical system. Get a signature from the owner. Design the backup and DR plan against those numbers. Review them annually. A one-page document is enough. The exercise of writing it down forces the conversation that the technical configuration is supposed to encode.

Recovery Point Objective and Recovery Time Objective for SMBs

The two acronyms get used interchangeably and they are not the same. RPO is a data measurement; RTO is a time measurement. Both are business decisions before they are technical ones.

Recovery Point Objective (RPO) is the maximum amount of data, measured in time, that the business is willing to lose. If the RPO is 4 hours, the backup system must capture changes at least every 4 hours. If the production system fails between backups, up to 4 hours of work since the last backup is gone. Tighter RPO requires more frequent backup, which costs more.

Recovery Time Objective (RTO) is the maximum amount of time the business is willing to wait for the system to be back online. If the RTO is 8 hours, the restore process must complete within 8 hours of the decision to restore. Tighter RTO requires faster restore mechanisms (instant-recovery VMs, replicated standbys, DR-as-a-service), which also cost more.

Typical 2026 SMB targets for critical systems land in this range:

• RPO of 1 to 4 hours for line-of-business applications, accounting systems, customer-facing systems. Most modern backup products can hit a 4-hour RPO at no extra cost via incremental backups every 4 hours.
• RTO of 4 to 24 hours for the same systems. The lower end of that range requires DR-as-a-service or a hot-standby configuration. The upper end is achievable with conventional restore-from-backup.
• RPO of 24 hours, RTO of 48 to 72 hours for non-critical systems (departmental file shares, internal tools, archived data). The cost savings between this tier and the critical tier are meaningful.

Cost rises non-linearly as RPO and RTO tighten. Going from a 24-hour RPO to a 1-hour RPO often doubles the storage cost. Going from a 24-hour RTO to a 1-hour RTO often triples the recovery infrastructure cost. The right answer for most SMBs is a tiered approach: tight numbers on the systems the business actually depends on, looser numbers everywhere else. Writing this down forces the trade-off to be explicit.

How to test a backup so you know it works

A backup that has never been restored is a hypothesis. The only way to convert it into a backup is to actually restore from it. The cadence that works for SMBs is three drills at three intervals.

Monthly: random-file restore. Pick a file at random from a recent backup. Restore it to a scratch location. Open it. Verify the contents match the source. This takes 15 minutes and catches the most common silent-failure modes: corrupted backup chains, broken retention, missing files, encrypted backups with no decryption key on hand. Put it on the calendar. If it is not on the calendar, it does not happen.

Quarterly: server image restore. Take a recent backup of a representative production server and restore the full image to spare hardware or a virtual machine. Bring up the services. Verify the application starts. Verify a representative workflow runs. Document the time it took. This catches the failure modes that a single-file restore cannot: application-consistency issues, license-binding to original hardware, network-configuration assumptions, broken database catalogs.

Annually: full DR drill. The hardest exercise. Schedule a two-to-four-hour window. Take the production system offline (or fail it over). Bring up the DR copy. Have the team actually work from the DR copy for the duration of the window. Document everything that broke: missing DNS entries, broken integrations, undocumented dependencies, license issues, performance gaps. The annual drill is the only time most of those problems are discoverable, and discovering them on a planned Saturday afternoon is meaningfully cheaper than discovering them on a Tuesday morning during an actual incident.

Insurance underwriters now ask about restore-testing cadence by name on cyber-insurance applications. The cyber-insurance renewal checklist covers the underwriting side; the operational side is the cadence above.

What costs what

Realistic 2026 pricing for a representative 25-user SMB with one on-prem server, running on Microsoft 365 Business Premium. All numbers per month, all-in.

• Workstation backup: $5 to $12 per user, depending on the product and the retention. Datto Workplace, Carbonite Endpoint, and Acronis Cyber Protect cluster around this range. For a 25-user firm, roughly $125 to $300 per month.
• Server image backup (one physical server, local plus immutable offsite): $150 to $400 per month for the combination of local appliance amortization, cloud storage, and the management overhead. The cloud storage piece scales with the size of the backup set.
• Microsoft 365 backup (mailboxes, SharePoint, OneDrive, Teams): $3 to $6 per user per month. For 25 users, $75 to $150 per month. Veeam, Datto, Acronis, and Afi are all reasonable.
• Disaster-recovery-as-a-service with a tight RTO (hot standby in the cloud, 1-to-4-hour failover): $300 to $1,500 per month depending on the SLA and the size of the protected workload. This is the line item that handles the worst-case scenario without adding days to the recovery.

For a 25-user firm without DR-as-a-service, total backup spend lands in the $700 to $1,800 per month range. Adding DR-as-a-service pushes it to $1,000 to $3,000 per month. The comparison point is the cost of a single ransomware event for a firm that size, which the IR firms put at $80,000 to $250,000 between recovery work, lost revenue, and notification. The math, even for the cost-sensitive SMB, is not subtle.

Ransomware-aware backup design

Everything above assumes a competent backup product, deployed and verified. The next layer is making the backup environment specifically hostile to a ransomware attacker who has gotten into production. Five properties matter.

Immutability. Already covered above. At least one copy must be on storage that cannot be deleted or modified for a retention window of at least 30 days, ideally 90. Object Lock in compliance mode, hardened repositories, or air-gapped media.

Isolated credentials. The credentials that write the backup must not exist on the production domain. A compromise of a production domain admin should not give the attacker any path to the backup repository. This means a separate identity store for the backup management plane, or a vendor-managed appliance with its own identity, or cloud storage with a service principal that production has never seen.

MFA on the backup console. The backup management interface must require multi-factor authentication for every administrative action. This is non-negotiable and most products support it natively. Phishing-resistant MFA (authenticator with number matching, or FIDO2 keys) is the right choice; SMS is no longer adequate.

Network segmentation. Production endpoints should not be able to reach the backup repository directly. The backup server pulls from production through a defined interface; production cannot push or write to the backup repository. The blast radius of a compromised production endpoint is the production network, not the backup network.

Alerts on backup-chain anomalies. The backup console should generate alerts when a job fails, when retention drops below the configured threshold, when a chain breaks, or when an unexpected administrative action is taken. Those alerts should go somewhere a human reads them. Many of the worst restore-failure incidents I have walked into had perfectly good alerts firing for weeks into an empty mailbox.

Backup is the last-resort control. Identity hardening and detection (covered in the cybersecurity service page and the MDR post) sit in front of it. But when those layers fail, backup is what is left between the business and the ransom note. It deserves the same hardening discipline.

What we are not recommending

A short list of patterns that look like backup, are not backup, and should not be relied on as such.

• Consumer-grade single-device backup. Time Machine to a USB drive on the same desk as the laptop it is backing up is a useful convenience and not a business backup strategy. The drive is on the same desk, the same power circuit, and the same threat surface.
• Backup software that lives on the same server as production. If the backup application is installed on the file server it is backing up, the compromise of the file server compromises the backup. This pattern still ships in some small-vendor configurations. It is not viable in 2026.
• "The cloud" without further specification. "It is in the cloud" is not a backup architecture. Which cloud? Which account? Which retention policy? Is the storage immutable? Who has access? Are the credentials shared with production? A real backup design names every component.
• Anything that requires an admin to remember to do something. Manual offsite rotations, scheduled scripts that nobody verifies, weekly handcrafted exports. If the process depends on a human remembering, it will fail the first time that human is on vacation. Automate it or do not count on it.
• OneDrive or Google Drive as the only "backup." Sync is not backup. A file that is deleted or encrypted in the sync source is deleted or encrypted in the sync target, fast.
• Snapshots on the same storage as production. VMware snapshots, NetApp snapshots, ZFS snapshots are all useful operational tools. They are not backups when they live on the same array as the data they are protecting.

Where this fits with the rest of the cluster

This post is the pillar piece for the Ghosxt backup and disaster recovery cluster. Backup is the last-resort control. It sits underneath identity hardening, detection, and patching. The other pieces of the program belong in the rest of the cluster:

• The backup and disaster recovery service page: the full service offering, with managed implementation and ongoing testing.
• The ransomware-how-it-gets-in post: the attacker side of why backup matters in 2026, and the playbook against which backup is the last defense.
• The AI attack speed post: why human-paced operations no longer keep up with the front of the attack and why backup is increasingly the last line.
• The identity hardening post: the prevention layer that keeps most attackers out of the environment in the first place.
• The cyber-insurance renewal checklist: the underwriting side, where backup design is now scored explicitly.
• The PSPS continuity post: the local angle on disaster recovery for Central Coast businesses where the disaster is often a planned power outage rather than a ransomware event.
• The cybersecurity service page: the broader prevention and detection program.
• The managed IT services page: the operational wrapper that keeps the backup running and tested.
• The cloud services page: the Microsoft 365 environment that the third-party backup product protects.

Backup deserves to be boring. The job is to be there, verified, immutable, and recoverable on the worst day of the year. Everything else in the program is designed to make sure that day never comes. The backup is what is left if it does.

FAQs about SMB backup and disaster recovery

Is Microsoft 365 already backing up our email and files?

No. Microsoft is responsible for the availability of the service, not for the long-term recoverability of your data. Microsoft 365 has retention policies, recycle bins, and Litigation Hold, but those are not backups. If a user empties a folder and then empties the recycle bin, if an attacker with admin rights purges a mailbox, or if a misconfigured retention policy deletes content, Microsoft will not restore that data for you. The Microsoft Services Agreement is explicit that data protection is a shared responsibility and that the customer is responsible for backup. A third-party Microsoft 365 backup product (Veeam, Datto SaaS Protection, Acronis, Afi, others) is the control that fills that gap.

Is OneDrive a backup?

No. OneDrive is file sync, not backup. The distinction matters: if a file is deleted, encrypted by ransomware, or corrupted on the endpoint, OneDrive faithfully propagates that change to the cloud copy and to every other device connected to the account. OneDrive does include a recycle bin and limited version history, and Microsoft has added some ransomware-recovery features for Personal subscribers, but the business tiers should not be treated as a recovery tool of last resort. OneDrive Known Folder Move is a useful component of an endpoint-data strategy, but it sits alongside a real backup product, not in place of one.

How often should backups be tested?

At three cadences. Monthly: a random-file restore drill where someone picks a file from a backup set, restores it to a scratch location, and verifies the contents match the original. Quarterly: a full image restore of a representative server to spare hardware or a virtual machine, with services brought up and verified. Annually: a full disaster recovery exercise where the production system is intentionally taken down (or a parallel failover is performed) and the team operates from the DR copy for two to four hours. The annual drill is where you find the gaps that the smaller drills miss: missing DNS entries, broken license bindings, undocumented dependencies. A backup that has never been restored is a hypothesis, not a backup.

What is the difference between backup and disaster recovery?

Backup is the act of making and retaining additional copies of data so that it can be recovered if the primary copy is lost or corrupted. Disaster recovery is the broader plan that describes how the business resumes operations after a significant event. Backup answers "can we get the data back." Disaster recovery answers "how does the business keep running." DR includes backup, but it also covers alternate hardware, alternate facilities or cloud failover, communication plans, succession of authority, vendor contacts, and the documented order in which systems come back up. A small business can have working backups and still not have a working DR plan.

How long should we keep backups?

Long enough to satisfy the business, regulatory, and incident-response need, but not indefinitely without intent. A reasonable default for most SMBs in 2026: daily backups for 30 days, weekly backups for 12 weeks, monthly backups for 12 months, and annual snapshots for 7 years. Microsoft 365 backups should retain mailbox and SharePoint data for at least one year to cover internal investigations and slow-discovery incidents. Industries with specific retention obligations (healthcare, finance, ITAR, legal) extend those baselines per the applicable regulation. The mistake to avoid is the open-ended "keep everything forever" policy that turns the backup repository into a discovery liability.

What is "immutable" storage and why does it matter?

Immutable storage is storage that cannot be modified or deleted for a defined retention period, by anyone, including the account owner. The mechanism varies by platform (S3 Object Lock in compliance mode, Azure Blob immutable policies, Wasabi Object Lock, Veeam hardened repositories with one-way credentials) but the property is the same: once a backup is written, it cannot be encrypted, altered, or deleted until the immutability clock expires. This matters because the dominant attacker playbook in 2026 includes a deliberate step to delete or encrypt the victim's backups before deploying the main ransomware payload. Immutable storage breaks that step. It is the single most important backup-side control against modern ransomware.

What is a reasonable backup budget for a 25-person business?

For a 25-user firm running on Microsoft 365 with one on-prem server, a credible 2026 backup program lands in the range of $700 to $1,800 per month, all-in. That covers workstation backup at roughly $5 to $12 per user, Microsoft 365 backup at roughly $3 to $6 per user, on-prem server backup with offsite immutable copy at roughly $150 to $400, and the management and monitoring time to run it. Adding disaster-recovery-as-a-service with a tighter recovery time objective pushes the number into the $1,000 to $3,000 range depending on the SLA. The reference point for whether that is reasonable: a single ransomware event for a firm that size routinely costs $80,000 to $250,000 in recovery, lost revenue, and notification expense.

Prefer to talk first? Email sales@ghosxt.com or call (831) 204-0501. For the full service write-up, see the backup and disaster recovery service page.