Installing backup software takes an afternoon. Deploying a backup and disaster recovery service that a client can rely on takes longer, because most of the work is deciding things: which systems matter most, how much data the business can afford to lose, how long it can wait, how many years of history it must keep and who is allowed to delete a backup. This free BDR deployment checklist takes an MSP through that first deployment for one client, from the systems inventory to handover. It records RPO, RTO and retention per system, designs local, offsite and immutable copies, and gets the client’s written sign-off on targets and cost before installation starts. It then locks down backup administration, seeds the first backups, proves restores against the agreed targets and hands over to daily monitoring and restore testing. When Microsoft 365 or Google Workspace data is in scope, a conditional phase covers SaaS backup.
Three recurring processes keep a client’s backups healthy after go-live, and this checklist comes before all of them. The MSP Daily Backup Monitoring Checklist asks each morning whether last night’s jobs ran. The Backup Verification & Restore Test Checklist restores a rotating sample each month and measures it against RPO and RTO. The Business Continuity Plan Testing Checklist exercises how the business keeps working while IT recovers. Each of them depends on numbers and a design that someone agreed at the start. Deployment is where they are agreed.
That is why this checklist puts the client conversation before the installation. A recovery point objective chosen by the technician who configured the schedule isn’t a target, it is a default. When a server fails, the client measures you against what they thought they were buying. Writing it down, with a cost next to it and the client’s approval attached, is what turns a backup product into a BDR service. For the wider recovery plan beyond backup, see our disaster recovery checklist guide.
Targets: whatever the default schedule happens to deliver.
Copies: often one local and one cloud, under the same admin login.
Proof: a green dashboard on the first morning.
Client view: “we’re backed up”, with no idea what that means.
Targets: RPO, RTO and retention per system, signed off by the client.
Copies: local, offsite and immutable, with separate admin credentials.
Proof: measured file, application and full-system restores.
Client view: a one-page recovery summary they approved.
Seven phases take one client from inventory to handover. Phase 5 appears only when Microsoft 365 or Google Workspace data is in scope.
Run this phase with the client’s decision-maker, not only their IT contact. Recovery targets are business decisions.
Shown only when SaaS data is in scope. On-premises-only clients go straight to Phase 6.
The 3-2-1 rule is old and still useful. A 2012 US-CERT paper, now published by CISA, puts it as three copies of important data, on two different media types, with one copy stored offsite. Ransomware added a requirement it didn’t anticipate: an attacker with administrator access can delete every copy that is online and reachable. The NCSC’s guidance responds with offline backups kept separate from your network, multiple copies with different solutions and locations, and MFA on backup accounts. Its principles for ransomware-resistant cloud backups add immutable storage, deletion delays and alerting on significant changes.
Many MSPs now design to 3-2-1-1-0, an industry extension rather than a government standard: one copy immutable or offline, and zero errors when restores are verified. The table maps each element to what to check during deployment.
| Element | What it protects against | What to check at deployment |
|---|---|---|
| 3 copies | A single backup that turns out to be unreadable | Production plus at least two backups for every tier-1 system |
| 2 storage types | One technology failing for every copy at once | The local target and offsite copy don’t share hardware or a storage account |
| 1 offsite | Fire, flood or theft at the client’s site | Region, data residency and a replication lag that still meets the RPO |
| 1 immutable or offline | An attacker or insider deleting or encrypting backups | Retention lock applied, deletion delay set, credentials used nowhere else |
| 0 errors | Backups that complete but can’t be restored | File, application and full-system restores measured in Phase 6 |
Clients asked for an RPO usually say “nothing lost”, and asked for an RTO they say “straight away”. Tiers make the conversation practical, because each one has a price. Treat the figures below as an illustration of the structure, not a recommendation:
UK GDPR Article 32 expects the ability to restore the availability of personal data in a timely manner after an incident, and a process for regularly testing security measures. The signed recovery summary and the Phase 6 restore evidence are a straightforward way to show both.
The approval task halts the install until the account manager has attached the client’s written approval of the targets, retention and cost. When a client later asks why a server had a 24-hour RPO, the answer is on the record.
One answer in Phase 1 decides whether conditional logic adds the Microsoft 365 and Google Workspace phase. Clients without SaaS data get a shorter checklist, and SaaS clients can’t skip workload coverage.
Measured restore times, screenshots and the runbook stay attached to the client’s deployment. The first monthly restore test has a baseline to compare against, and insurers or auditors can see what was proved on day one.
BDR deployment is one of the client onboarding projects the MSP process management guide recommends running from a standard checklist. CheckFlow for MSPs runs it alongside the MSP Client Onboarding Checklist, so a new client’s backups go live as part of onboarding.
Once backups are live, the Ransomware Response Checklist covers recovery from an attack, and the Disaster Recovery Audit Checklist reviews the whole recovery capability each year.
BDR stands for backup and disaster recovery. In an MSP agreement it usually means more than backup software: agreed recovery targets for each system, local, offsite and immutable copies, monitoring of every job, scheduled restore testing and a runbook for recovering the client’s systems after a major failure. Backup on its own copies data. BDR includes the plan and the tested ability to bring systems back within an agreed time.
Put a price next to each target. Ask what each system does, what an hour or a day without it would cost and how much re-keyed work the business could tolerate. Then show two or three tiers with their monthly cost. Most clients move quickly from “everything is critical” to one or two genuinely critical systems. Record the tier for each system and the client’s reason, and have them approve it in writing.
Two things. The extra “1” is a copy that is immutable or offline, so an attacker with administrator access can’t delete or encrypt it. The “0” means zero errors when backups are verified, which in practice means restores are tested rather than assumed. It is an industry framing, not a government standard, but it matches the direction of CISA and NCSC ransomware guidance on offline copies and tested backups.
Generally not. If the backup console signs in with domain credentials, an attacker who takes over the domain can sign in to the backups too, and deleting backups is a common step before ransomware is deployed. Use separate accounts with MFA, limited to the few people who need them, and keep immutable copies under credentials that are used nowhere else. The NCSC also recommends protecting backup accounts with MFA.
It depends on the volume of data and the upload bandwidth, and the arithmetic is worth doing before you promise a date. Two terabytes over a 100 Mbps uplink takes roughly 44 hours at full speed, before overheads, and longer if the link is shared with the working day. Where the first offsite copy would take more than a few days, many services accept a seed on a shipped encrypted drive, with only changes sent afterwards.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
