Backup Strategy: How to Design One That Actually Protects Your Business

According to the 2026 Kaseya State of the MSP Report, 50% of MSPs reported year-over-year revenue growth in BCDR services, making it the second strongest growth area after cybersecurity. Download the full report here.

Having backup software installed and having a backup strategy are not the same thing. The distinction matters enormously when something goes wrong.

A backup strategy is a defined, documented approach to protecting data, what gets backed up, how often, where copies are stored, how long they’re retained, and how quickly recovery needs to happen. Without it, backup becomes a series of ad hoc decisions made independently, covering some systems but not others, meeting some recovery requirements but not all, and providing false confidence that’s revealed only when recovery is attempted under pressure.

This guide covers how to design a backup strategy that is comprehensive, aligned to business recovery requirements, and resilient against the specific threats that target backup infrastructure.

Start With Recovery Requirements, Not Backup Technology

Most organizations start backup conversations with technology: which software, which appliance, which cloud service. The right starting point is the business question: what does recovery need to look like?

Two metrics define recovery requirements:

Recovery Time Objective (RTO), the maximum time a system or service can be down before the impact becomes unacceptable. An RTO of four hours means that IT has four hours from the point of failure to restore service. RTOs should be defined per system based on business impact of downtime, not as a single figure for the whole environment.

Recovery Point Objective (RPO), the maximum amount of data loss that is acceptable, measured in time. An RPO of 24 hours means the organization accepts losing up to 24 hours of data. An RPO of one hour means backup must happen at least hourly for covered systems.

Once RTO and RPO are defined for each system tier, backup technology selection becomes a question of which solutions can meet those requirements. A system with a four-hour RTO needs instant or near-instant recovery capability, image-based backup with virtualisation recovery, or a BCDR appliance that can spin up the protected system in the cloud within minutes. A system with a 24-hour RTO can use conventional file backup with daily full backups.

This sequencing prevents the common mistake of selecting backup tools based on cost or familiarity, then discovering at incident time that recovery takes far longer than the business can tolerate.

Classifying Data and Systems by Recovery Priority

Not all systems require the same investment in backup speed, frequency, and retention. Tiering systems by recovery priority allows backup investment to be focused appropriately:

Tier 1, Mission critical. Systems whose failure immediately stops business operations: core business applications, databases, domain controllers, ERP systems, payment processing. Tier 1 requires the lowest RTO and RPO, typically sub-hour. Technology: image-based backup with local virtualization, BCDR appliance with cloud continuity, and CDP for highest-criticality databases.

Tier 2, Business important. Systems whose failure significantly impairs operations but doesn’t immediately stop them: email servers, file servers, secondary business applications. Tier 2 can accept slightly longer RTOs (typically a few hours) and RPOs (typically a few hours to one day).

Tier 3, Standard. Endpoints, development environments, non-critical applications. Tier 3 can accept daily backup with multi-day recovery times. Technology: daily file/image backup, cloud-only copies, standard retention.

This tiering framework isn’t just about cost management, it’s about ensuring that the most critical systems have the recovery capability the business actually requires, and that investment in more expensive recovery technology is concentrated where it delivers the most value.

Choosing the Right Backup Architecture

On-premises appliance + cloud is the most resilient architecture for organizations with significant on-premises infrastructure. The appliance provides local backup for fast recovery from common failure scenarios; the cloud copy provides the off-site, isolated backup that survives site-level events and ransomware targeting local storage. Datto SIRIS exemplifies this architecture, a hardened Linux appliance with local virtualization capability for rapid on-site recovery and automated cloud replication for off-site protection.

Cloud-first backup suits organizations with predominantly cloud or SaaS infrastructure, or those without on-premises data centers. Backups go directly to cloud storage, with immutable object storage providing isolation from ransomware. Recovery is from cloud to cloud or cloud to on-premises.

Hybrid backup covers multi-environment organizations with both on-premises and cloud workloads. Different tools are typically required for different environments, an appliance-based solution for on-premises, cloud-native backup for cloud infrastructure, and SaaS backup for SaaS applications. The critical requirement is centralized management that provides visibility across all backup environments from a single console.

BCDR-focused architecture prioritizes recovery speed over backup cost efficiency. BCDR appliances can virtualize protected systems locally within minutes of a failure event, maintaining business operations while recovery to primary hardware proceeds in the background. This architecture is appropriate for Tier 1 systems with sub-four-hour RTO requirements.

Retention Policies: How Long to Keep What

Retention policy is one of the most strategically important backup decisions and one of the least carefully considered. Two competing forces drive retention length:

Ransomware dwell time argues for longer retention. Modern ransomware attacks commonly involve weeks or months of reconnaissance before the destructive payload is deployed. If an organisation’s backup retention is 30 days and the attacker established access 45 days before deploying ransomware, every backup copy may be within the compromise window, potentially containing encrypted or infected files. Organizations need retention extending well beyond their expected maximum dwell time to ensure clean restore points are available.

Storage cost argues for shorter retention. Longer retention means more storage consumed.

The resolution is a tiered retention policy:

• Recent backups (last 7–30 days): frequent intervals, high granularity, fast access
• Monthly backups: retained for 12 months
• Annual backups: retained for 3–7 years (driven by compliance requirements)

Compliance obligations also drive retention minimums. HIPAA requires backup of covered data with appropriate retention. GDPR imposes data retention limitations that must be balanced against backup retention requirements. Sector-specific regulations (financial services, healthcare, government) often specify minimum retention periods for audit and legal hold purposes.

Immutable backup copies that cannot be modified or deleted for their defined retention period protect against both ransomware and inadvertent deletion, ensuring that historical restore points remain available regardless of what happens in the primary environment.

Backup Security: Protecting the Recovery Path

Backup infrastructure has become a primary attack target. Over 90% of ransomware attacks target backups, attackers understand that an organisation with intact backups won’t need to pay a ransom, so eliminating recovery options is part of the attack strategy.

Backup security requires:

Isolation from the production network. Backup systems accessible via standard SMB file shares or domain credentials are reachable by ransomware that has compromised domain accounts. Backup infrastructure should use separate credentials, separate network segments, and ideally appliance-based or cloud-only storage that doesn’t present a standard Windows file system attack surface.

Immutable storage. Object storage with WORM (Write Once Read Many) configuration or vendor-provided immutability prevents backup copies from being modified or deleted, even by ransomware with administrative credentials.

Encryption. Backup data should be encrypted both in transit and at rest. This protects against data theft from backup repositories, increasingly a secondary attack objective alongside ransomware deployment.

Access controls and MFA. Backup management consoles should require MFA and role-based access. The credentials to manage backups should be separate from the credentials used in the production environment.

Ransomware scanning. Backup platforms that scan backup copies for malware before committing them provide confidence that restore points are clean, preventing the scenario where recovery from backup restores the ransomware alongside the data.

Testing and Verification: The Most Important Part Nobody Does

A backup that has never been tested is an assumption. Hardware fails. Configurations change. Software updates break compatibility. The backup job that completed successfully last month may not produce a restorable image today.

Backup testing should include:

Regular restore tests. Restore specific files, databases, or entire systems from backup on a defined schedule, monthly for critical systems, quarterly for others. Document what was restored, from which backup, and how long it took.

Full DR tests. At least annually, simulate a complete failure scenario: restore the production environment from backup in a test environment, verify that applications function correctly, and measure actual RTO against target. This is the only test that validates whether the backup strategy delivers the recovery performance the business requires.

Automated backup verification. Modern backup platforms can automatically test recoverability after each backup job, booting a virtualized instance of the backed-up system and checking that it comes up correctly. This provides continuous confidence without manual testing overhead. Datto’s Screenshot Verification feature does exactly this, automatically capturing a screenshot of each backed-up system post-backup to verify it boots cleanly.

The discipline of regular testing frequently surfaces problems before they become incident-time discoveries, wrong backup scope, retention gaps, or technology that can’t deliver the required RTO.

Backup Strategy for MSPs

For MSPs, backup strategy sits at the intersection of client protection and service delivery:

Standardized baseline with per-client customization. Define a standard backup architecture and retention policy that applies to all clients by default, with documented per-client variations where client-specific requirements differ. This is more scalable and more auditable than building bespoke approaches for each client independently.

RTO/RPO documentation per client. Client agreements should document the recovery objectives the MSP is committing to, and backup configuration should be verified to support those commitments. An undocumented RTO creates liability when recovery takes longer than the client expected.

Backup monitoring and reporting. Backup job status across all client environments should be monitored with automated alerting on failures. Client-facing backup reports demonstrating protection coverage and job success rates are both a service delivery and a retention tool.

Backup as a sellable service. Many SMB clients are inadequately protected and either don’t know it or don’t understand what comprehensive protection looks like. MSPs that can articulate the difference between what a client has and what they need, in business terms, using RTO/RPO language and the cost-of-downtime framing, can grow backup revenue from existing client relationships.

Explore why MSPs need cyber resilience now

Key Takeaways

• Start with recovery requirements (RTO and RPO by system tier), not technology, the right backup solution is whichever one can meet those requirements at acceptable cost.
  
• Tiering systems by recovery priority focuses investment on the systems where fast recovery is genuinely required, rather than applying the same approach to everything.
  
• Ransomware has made backup security a first-order concern: immutable, isolated backups with separate credentials are now foundational requirements, not optional hardening.
  
• Regular restore testing is the most neglected and most critical element of any backup strategy, untested backups provide false confidence that fails at the worst possible moment.