Ransomware-resilient backup is a backup setup that stays recoverable after attackers get into your production systems, your administrator credentials, or part of the backup environment itself.
It rests on protected copies, isolation, separate access controls, encryption, monitoring, retention that reaches back far enough, and regular recovery tests. Those tests also give you evidence that critical systems come back within your recovery objectives.
Why do ransomware attackers target backups?
A working backup gives a victim an alternative to paying, so attackers look for the systems that would support recovery and try to take them out. CISA warns that many ransomware variants attempt to find and then delete or encrypt any backups they can reach.
Backups are usually exposed in the same handful of ways:
- They share administrator accounts with production.
- The production network can reach them.
- One administrator can delete recovery points.
- Retention is too short to reach back past the compromise.
- Nobody watches for suspicious access or policy changes.
- Nobody has ever run a representative restore.
What makes a backup ransomware resilient?
Six controls do most of the work.
Control | What it should do |
Multiple copies | Keep one failure or one attack from destroying every recovery path |
Isolation or immutability | Protect at least one copy from unauthorized encryption, modification, or deletion |
Separate access | Stop ordinary production credentials from controlling all backups |
Encryption | Protect backup data in transit and at rest |
Monitoring | Catch failures, deletion attempts, policy changes, and suspicious access |
Recovery testing | Show that protected systems and data can be restored |
No single product or storage feature covers all six. They need to sit inside a documented recovery plan.
What is the 3-2-1-1-0 backup foundation?
- Three copies of critical data: production plus at least two backups.
- Two different storage types or systems, so one technical failure does not hit everything.
- One offsite copy, for a site-level incident.
- One protected copy that is immutable, offline, or isolated.
- Zero unverified backups, which means regularly testing that the protected data restores.
Adjust this for your workloads, your risk, your compliance obligations, and your recovery objectives.
Six principles of ransomware-resilient backup.
1. Protect at least one copy.
At least one backup copy should resist unauthorized changes and deletion. The usual ways to get there:
- Immutable storage with object lock or WORM controls.
- A logically isolated backup vault.
- Storage in a separate cloud account or administrative boundary.
- A hardened repository that is not joined to the production domain.
- Offline media that is physically disconnected from the network.
These are different things. An immutable copy cannot be changed during its retention period. An isolated copy is separated from everyday production access. An offline copy is physically disconnected. Offline media sounds old-fashioned, but an attacker on your network cannot reach it while it is disconnected.
The right choice depends on data volume, recovery speed, budget, compliance obligations, and who will run it day to day.
2. Separate backup access from production.
If you can only fix one thing this quarter, fix who can delete your backups. Backup consoles, repositories, and storage accounts should use dedicated access controls wherever that is technically practical:
- Multi-factor authentication.
- Least-privilege roles.
- Separate backup and storage administrators.
- Time-limited privileged access.
- An approval step for deletions and retention changes.
- Secured break-glass credentials.
- Alerts for new administrators and role changes.
The goal is that one hijacked production account cannot hand an attacker control of every recovery copy.
3. Encrypt backup data.
Encrypt data in transit and at rest, and where you can, keep the encryption keys away from the systems and identities you are backing up. Ransomware incidents can include data theft along with encryption, so a stolen backup should be unreadable.
Write down where the keys live, who can access and rotate them, how you would recover them in a disaster, what happens if the key-management service is down, and whether encryption covers local, cloud, offsite, and exported copies.
4. Monitor the backup environment.
Failed-job alerts are the minimum. The alerts worth setting up are the unusual ones: unexpected deletion attempts, disabled jobs, retention or policy changes, new administrator accounts, logins from odd locations, repeated authentication failures, repository disconnections, unexpected restore or export activity, and sudden jumps in data-change rates.
Which of these you can get depends on your backup, storage, and security tools. Whatever you turn on, a defined team has to own the alerts and follow an escalation process, or they become noise in a mailbox.
5. Retain enough history.
Attackers can sit in an environment for a while before encryption starts, so the newest restore point may already contain malicious tools, unauthorized accounts, or configuration changes. Keep several generations of recovery points: daily for recent recovery, weekly for the medium term, and monthly or annual copies for longer requirements, plus application-specific retention for databases, email, and regulated records.
Set retention from business requirements, contractual obligations, investigation needs, detection time, storage capacity, and legal holds.
6. Test representative recoveries.
A successful backup job tells you the job ran. It does not tell you that an application or environment will come back. A representative test checks data integrity, identity and access, application dependencies, DNS and networking, security tools, recovery order, recovery time, staff responsibilities, and internal and external communications.
Where it makes sense, restore into an isolated environment and scan the recovered systems before reconnecting them to production. Then write down the result, the gaps you found, the fixes, and the actual recovery time. Compare that time with your RTO.
Do Microsoft 365 and SaaS platforms need backup?
Yes. Treat Microsoft 365 and other supported SaaS platforms as workloads that need their own independent data protection.
Recycle bins, retention settings, and version histories can help with ordinary recovery. They may not cover a compromised administrator, malicious or accidental deletion, excessive privilege, short retention periods, configuration loss, tenant-wide incidents, or legal and contractual retention requirements.
A Microsoft 365 plan should cover Exchange Online, SharePoint Online, OneDrive, supported Teams data, and the identity and configuration information you would need to rebuild access. It should use independent credentials with MFA, suitable retention, monitoring and reporting, and representative restore tests. Coverage varies by backup platform, so confirm the exact applications, data types, configurations, and restore operations the proposed solution includes.
How should an organization recover using backups?
Recovery goes best in a fixed order that you have written down and practiced before an incident.
- Activate the recovery plan
Decide in advance who can declare an incident, authorize recovery, approve emergency changes, and talk to leadership, customers, insurers, regulators, and law enforcement. NIST recommends defining the people authorized to activate the recovery plan before an incident happens.
- Contain the attack
Isolate affected systems and network segments to limit more encryption, data theft, and lateral movement. Coordinate with the incident-response team so containment does not destroy evidence or stall the investigation.
- Protect backup systems
Find out whether backup consoles, repositories, storage accounts, or credentials were exposed. Restrict console access, disable compromised accounts, rotate credentials, preserve logs, confirm retention and immutability status, and separate the backup systems from a compromised domain.
- Identify a clean recovery point
Use endpoint-security timelines, authentication records, backup logs, vulnerability information, and forensic findings to estimate when the compromise began. The newest restore point is sometimes the infected one.
- Rebuild identity and core services
Restore or securely rebuild what everything else depends on: Active Directory or other identity services, DNS and DHCP, privileged-access systems, network services, security monitoring and endpoint protection, and backup-management services. Applications may not work correctly until these are available and trusted.
- Restore into an isolated environment
Where it makes sense, restore to a sandbox or isolated recovery environment first. Scan the recovered data and systems, remove unauthorized accounts and persistence, apply required security updates, validate configurations, and monitor before reconnecting to production.
- Restore according to business priority
Prioritize systems connected to health and safety, identity and security, revenue, customer service, manufacturing operations, legal and regulatory requirements, and internal and external communications. Application owners should validate recovered data and functionality before anything returns to normal use.
How should RTO and RPO be set?
Recovery point objective (RPO) is how much data loss you are willing to accept, measured in time. Recovery time objective (RTO) is the longest a system or service can be down before it is restored.
Set both through a business-impact analysis. The inputs that move the numbers are application criticality, data-change rates, system dependencies, recovery infrastructure, network bandwidth, restore sequencing, validation requirements, staff availability, provider responsibilities, and compliance and contractual obligations. Shorter objectives generally need more frequent backups, replication, faster infrastructure, and more recovery engineering, and they cost more.
Write RPO and RTO down as architecture and service requirements. Nobody should treat them as assumptions or guaranteed outcomes.
How do you choose a backup provider?
Ask how the service behaves during an active attack, as well as during normal backup operations. Key questions:
- Can the proposed design include an immutable, offline, or isolated copy?
- Who can delete protected copies or change retention?
- Are backup credentials separate from production access?
- Is MFA enforced on backup and storage administration?
- What workloads, applications, and SaaS platforms are supported?
- How are backup failures and suspicious changes monitored?
- Who responds to alerts, and during what hours?
- How often are representative recoveries tested?
- Can systems be evaluated in an isolated recovery environment?
- What RPO and RTO assumptions are built into the architecture?
- Where does protected data reside?
- Which features and recovery services are included in the agreement?
Don’t assume every managed backup service includes immutability, offline copies, malware scanning, anomaly detection, disaster recovery, or guaranteed recovery times.
How does Magna5 approach ransomware-resilient backup?
Magna5 provides a fully managed Backup and Disaster Recovery service designed to keep critical data protected, available, and recoverable.
Our engineers manage and monitor backup operations 24x7x365, respond to backup failures and alerts, and help customers build recovery plans around their business priorities. The service can protect supported on-premises, cloud, endpoint, and SaaS workloads, including Microsoft 365.
Magna5’s approach focuses on four essential outcomes:
- Reliable protection: Encrypted backups and secure offsite copies help protect critical business data.
- Proactive management: Magna5 engineers continuously monitor backup operations and address failures and alerts.
- Recovery readiness: Recovery strategies are designed around each customer’s workload priorities and recovery objectives.
- Tested processes: Annual disaster-recovery exercises help validate the customer’s documented recovery approach. Additional testing can be included when required.
Service designs can range from straightforward cloud backup to more advanced disaster-recovery environments for organizations that require faster restoration of critical systems.
Capabilities such as immutable storage, isolated recovery environments, extended retention, additional recovery testing, and advanced recovery objectives depend on the customer’s requirements and selected service design.
Backup and Disaster Recovery can also complement Magna5’s separately scoped cybersecurity services. Backup provides a recovery path, while cybersecurity services help reduce risk and detect, contain, and respond to threats. The scope of each service is defined in the customer’s solution and service agreement.
FAQs about ransomware-resilient backup.
Q: What is the best backup against ransomware?
A: No single product is best for every organization. A strong strategy uses multiple copies, at least one protected copy, independent access controls, encryption, monitoring, retention that reaches a clean restore point, and regular recovery tests.
Q: Can ransomware delete backups?
A: Yes. Ransomware operators commonly try to find, encrypt, or delete any backups they can reach. Isolation, immutability, offline copies, separate credentials, MFA, and restricted network access reduce the risk.
Q: What is an immutable backup?
A: An immutable backup cannot be changed or deleted until its protected retention period ends. The protection holds up best when retention settings, storage administration, and privileged accounts are secured and monitored too.
Q: Is cloud backup safe from ransomware?
A: It can be, when it uses independent credentials, MFA, encryption, suitable retention, monitoring, and protection against unauthorized deletion. Putting backup data in the cloud does not make it ransomware resilient by itself.
Q: Is OneDrive a backup?
A: OneDrive gives you file synchronization, versioning, and recovery features. It is not a full replacement for an independent Microsoft 365 backup and recovery plan. How useful it is during an incident depends on retention, account security, administrator access, and how far the attack spread.
Q: How often should backups be tested?
A: There is no single right schedule. It depends on business risk, recovery objectives, architecture, and compliance obligations. A risk-based plan may include automated backup verification, regular sample restores, periodic application or system recovery tests, and at least one broader disaster-recovery exercise each year.
Magna5’s managed Backup and Disaster Recovery service includes annual disaster-recovery test exercises. Anything more frequent or broader should be written into the service design and agreement.
Q: What is the difference between backup and disaster recovery?
A: Backup creates protected copies of data. Disaster recovery combines technology, infrastructure, people, and procedures to restore systems and operations within your recovery objectives. You need both a backup that survived and a tested process for using it.
