Designing Backup and Recovery for Clients

Design first, then run the process

The daily discipline – job review, test restores, runbooks, exit criteria – lives in the backup and DR process. That process assumes a design already exists for each client: which systems are protected, how, where the copies live, how long they are kept, and what happens on the bad day. Most backup failures at small MSPs are design gaps found during a restore, not failed jobs.

Gather recovery objectives per system, not per client

Ask a client for an RTO and RPO and you get "immediately" and "zero." Ask per system, with a cost attached, and you get a real answer. Walk the inventory with the owner and an operations lead and ask three questions about each server, application, and data set: how long can you work without it, how much rework can you afford to lose, and who would you call first if it were gone. The practice-management or ERP database gets hours and minutes; the file share gets a day and a few hours; the archive nobody has opened since 2021 gets a week.

Record the result as a signed schedule to the business continuity plan: system, owner, RTO, RPO, tier. It sets scope for everything below and turns "you never told us the CRM needed backing up" into a line item the client saw and signed.

3-2-1-1-0 and what immutability actually buys

Three copies, two media, one offsite – plus two more digits. The extra 1 is a copy that is offline, air-gapped, or immutable: object lock in cloud storage or a retention lock on the appliance that no administrator credential, including yours, can shorten before it expires. The 0 is zero errors on automated verification: the image boots, the database mounts, the checksum matches.

The immutable copy defeats the attacker's playbook. Ransomware crews sit in an environment for days, find the backup console, and delete copies before detonating. A cloud mirror synced by the same service account is not a defense; a locked copy with a window longer than typical dwell time is. Set immutability to at least 14–30 days, and put the BDR platform's admin access behind phishing-resistant MFA on an identity separate from your RMM. The cyber insurance questionnaire asks about exactly this.

Image-based, file-based, and SaaS backup

Most designs need all three.

• Image-based captures the whole volume – OS, applications, configuration, data – so a machine can boot as a virtual machine or restore to different hardware. It is the only approach that meets an RTO measured in hours. Every server gets it, plus the few workstations whose loss would stop the business.
• File-based captures selected folders. Cheap, light, adequate for general workstations and for archives where you need the document, not the machine. It cannot rebuild a server in useful time.
• SaaS backup captures data the client does not host. Microsoft 365 data is not backed up by default – Microsoft runs the service, the customer owns the data, native retention is not a point-in-time copy, and tenant configuration is not retained at all. Treat it as mandatory and list the platforms in scope in writing.

Local appliance plus cloud, or cloud-only

Appliance plus cloud replication. A local device takes image backups over the LAN, can boot a failed server as a VM in minutes, and replicates to immutable cloud storage. It fits any client with a tier-1 server, an RTO under a day, or more than a few terabytes.

Cloud-only. Agents send backups straight to cloud storage; recovery means restoring over the internet or booting the image in the provider's cloud. No hardware, lower entry cost, right for clients with no on-premises servers or a tolerable RTO. The constraint is bandwidth: a 2 TB full restore on a 100 Mbps link takes most of two days, so cloud-only with a four-hour RTO is a contradiction unless cloud failover is in the plan.

Choose per client from the RTO schedule, not from what you already own.

Retention design and what it costs

Storage is billed per gigabyte-month, and every extra recovery point is paid for every month it is kept. A defensible default: daily points for 30 days, weekly for 90, monthly for a year. Regulated clients need longer for specific data – medical and financial records typically six to seven years – but apply that to the archive data set, not to every workstation image.

Two rules keep it affordable: long-term points are file-level or deduplicated archives rather than full images, and retention is set per tier rather than as one global policy. Get the client's legal and compliance requirements in writing first. Under-retention is a liability; over-retention is a margin leak.

DRaaS failover tiers

DRaaS answers "where does the server run while we rebuild." Tier it to match the RTO schedule:

• Local virtualization on the appliance – minutes to boot, but dependent on the office and its network being intact.
• Cloud failover of the replicated image – hours to bring up, works when the building is gone, needs a plan for how users reach it.
• Restore to new hardware – days; the fallback for everything below tier 1.

Cloud failover is often included in appliance pricing for a limited runtime and billed per day beyond it. Put the runtime allowance and the failback procedure in the design – failback is harder than failover and nobody rehearses it.

Testing cadence and evidence

The process article sets the cadence – quarterly file and boot tests, an annual DR exercise for tier-1 clients – and the design decides what evidence those tests produce. Each test records the system, restore type, elapsed time against contracted RTO, age of the point used against contracted RPO, and who validated the result – stored in the client's documentation, not a technician's inbox.

Mapping the design to price tiers

The design maps onto three tiers, typically sold per protected device plus per user for SaaS:

• Standard – file or endpoint backup, cloud-only, 30-day retention; typically $5–15 per workstation per month.
• Business – image-based server backup, immutable cloud copy, 90-day retention, cloud failover on request; typically $50–150 per server per month.
• Critical – appliance with local virtualization, cloud replication, extended retention, DR exercise included; typically $250–500 per server per month.

Microsoft 365 backup at $3–5 per user per month sits under all three.

Documenting the design so it survives turnover

Keep the design in the client's documentation record: the RTO/RPO schedule, protected systems and the backup type for each, storage locations and immutability settings, retention per tier, failover tier and runtime allowance, test evidence, and the recovery runbook. Write it to your documentation standards, at the level a new technician can execute. Review it at onboarding, whenever a system is added, and annually.

Bottom line

Backup design is a negotiation about time and money, recorded per system and signed. Get real recovery objectives, keep an immutable copy the attacker cannot reach, use image backups for anything with a tight RTO, match appliance-or-cloud to the schedule, set retention deliberately, and write it down where the next technician can find it.