Backup and Disaster Recovery Process

The standard: 3-2-1 plus immutability

The baseline design for every client is 3-2-1 – three copies of the data, on two different media, one offsite – with a modern, non-negotiable addition: at least one copy must be immutable or air-gapped, because ransomware operators hunt backup infrastructure first and encrypt or delete it before touching production. This is no longer just good practice: tested offline/immutable backups are on the standard 2025–26 cyber insurance minimum-controls list, and some carriers now ask for documented restore tests. A BDR design that can't produce evidence is, to an underwriter, no backup at all.

Roles: one tech owns daily job review (rotate weekly so it doesn't rot), the account manager owns per-client RTO/RPO agreements and test-restore sign-off, and the owner/service manager declares disasters and runs recovery events.

Define RTO and RPO per client tier

Recovery objectives are a business negotiation you document, not a technical default. Agree an RTO and RPO per client – ideally per system – write them into the business continuity plan and the service agreement, and price them honestly. A typical tiering:

Tighter objectives cost more – local virtualization hardware versus direct-to-cloud is largely what separates the price points. Clients who refuse Tier 1 pricing for Tier 1 systems should sign that decision.

What gets backed up

• Servers: image-based backup, always – file-level alone can't hit any meaningful RTO.
• Endpoints: decide per client and put it in writing. At minimum, key-person machines; "workstations aren't backed up unless contracted" stated explicitly beats an assumption discovered during a loss.
• Microsoft 365 / SaaS – the day-one must-sell. Microsoft's shared-responsibility model is explicit: Microsoft protects the service, the customer owns the data – and Microsoft's own Services Agreement recommends third-party backup. Native tools are retention features, not backup: recycle-bin and versioning windows top out around 93 days, retention policies aren't restorable point-in-time copies, and tenant configuration (users, groups, Conditional Access) isn't backed up at all. Ransomware, malicious insiders, departed-employee license cleanup, and admin error all fall outside Microsoft's recovery obligations. For the MSP, it's the easiest attach in the catalog: agentless API deployment, typically ~$2–3/user/mo cost, clean margin, and it's the first thing a client actually uses ("restore Bob's deleted mailbox"). Every client is already in M365 – a 100% attach rate is realistic.

Vendor options (brief, as of 2026)

• Acronis Cyber Protect Cloud – MSP-focused backup for physical, virtual, cloud, and SaaS workloads, with optional cloud disaster recovery managed through the same console; a fit for providers that want to consolidate backup and recovery management.
• Datto (Kaseya) SIRIS/ALTO – the appliance BCDR reference: instant local and cloud virtualization, all-in pricing. Killed High Watermark billing in Dec 2025 and cut prices roughly 10% in Jan 2026 under competitive pressure; post-acquisition frustration in the community is real (see Slide, the Datto founder's new BCDR startup explicitly courting unhappy partners).
• Axcient x360Recover – direct-to-cloud or appliance, pooled storage, flat per-device fair-use pricing; the most common Datto alternative at MSP volumes.
• Cove Data Protection (N-able) – cloud-first, storage included, flat per-device plus per-user M365 rates, no appliance capex; excellent for lean new MSPs.
• Veeam – powerful and license-heavy, with price rises of 4–8% in Jan 2026 (second straight annual hike); best fit for server-heavy or VMware-centric clients.
• M365/SaaS backup: Acronis Backup for Microsoft 365 (Exchange Online, OneDrive, SharePoint, Teams, and Entra ID), Datto SaaS Protection (3x daily, per-license, unlimited storage), Dropsuite (channel-only, now NinjaOne-owned), Afi (~$3/user/mo list, negotiable), Cove.

Pick one platform and standardize – one backup product across all clients is what makes daily monitoring and restore testing operationally possible.

Monitor jobs daily

A backup silently failing for three weeks is the classic MSP negligence story – and it's preventable:

1. Every business morning, the rotation owner reviews the previous night's jobs – failures and warnings, not the wall of green.
2. Every failure becomes a PSA ticket, closed only with a root cause and a subsequent successful job.
3. Track last-good-backup age per protected system; anything exceeding the agreed RPO is escalated as an incident that day, not filed as a note.
4. Alert on silence too – an agent that stops reporting is more dangerous than one reporting failure.

Tested restores on a schedule

An untested backup is a hypothesis. Insurers have caught up to this – documented restore tests are increasingly requested at renewal.

• Quarterly, per client: one file-level restore and one image/VM boot verification, rotating through systems so everything gets exercised over the year. Log evidence – ticket, screenshots, timing – in the client's documentation.
• Annually, per Tier 1 client: a DR exercise against the runbook – a live failover or a rigorous tabletop. Measure actual recovery time against the contracted RTO and update the runbook with what broke.
• Automated boot-verification screenshots are table stakes, not a substitute – they prove the VM boots, not that the application works.

Recovery runbooks and the DR communication plan

Each client gets a recovery runbook in your documentation platform, maintained per your documentation standards: restore order and dependencies (domain controllers before applications), where credentials live, vendor and ISP support numbers, and the decision tree – restore in place, virtualize locally on the appliance, or fail over to cloud DRaaS.

The communication plan answers, in advance: who declares a disaster, who is the single voice to the client, what the update cadence is (a typical commitment: an update every 2–4 hours during active recovery, even if the update is "still restoring"), and what the out-of-band channel is when email is down – which it will be, since mail servers and M365 access are often part of the outage. If the cause is a security incident rather than a failure, the incident response process leads and this process executes the recovery step.

Exit criteria for a recovery event

A recovery event is closed only when all of the following are true:

1. Data and systems restored, and validated by the client's owner of each system – not just "the VM boots."
2. If the cause was ransomware or compromise: restore points verified clean and the initial-access vector closed before reconnection, under IR-process direction.
3. Backups re-established on restored systems, with the first new job completed and verified.
4. Client sign-off in writing that operations are restored.
5. Post-event review completed within two weeks: actual RTO/RPO vs contracted, what failed, runbook updated, and any remediation sold as roadmap items.

Cadence at a glance

• Daily: job review, failure tickets, last-good-backup age check.
• Monthly: per-client backup status in reporting; verify coverage of newly added systems.
• Quarterly: test restores with logged evidence; review RTO/RPO tiers for changes.
• Annually: DR exercise for Tier 1 clients; revisit vendor pricing and immutability settings.

Backup is the one service where the work is invisible until the worst day of a client's business – run the discipline daily and rehearse the bad day before it happens.