When ransomware reaches a Modesto clinic’s file server, Acronis Cloud Backup can be a crucial recovery layer—but only if the backup is isolated, retention-protected, tied to a clean restoration plan, and measured against real EHR downtime targets. A successful backup job alone does not prove the clinic can safely resume care.
At 4:47 p.m., the front desk at a Modesto outpatient clinic is still checking patients into the EHR when the IT coordinator receives two alerts: a shared-drive encryption spike and an attempt to delete recovery snapshots. The Acronis console shows recent backups, but the decision is no longer “Did the backup run?”
The decision is whether to isolate the file server, stop replication, preserve evidence, and restore the scheduling and clinical-support systems from a known-clean point—or risk bringing the attacker back with the data. If that decision is delayed, staff may move to paper intake, clinicians may lose access to scheduling history, and the clinic’s last usable recovery point may become harder to identify.
That is the practical meaning of Acronis Cloud Backup ransomware protection: not a product checkbox, but a recovery control plane that must work under pressure.
What does Acronis Cloud Backup actually protect against?
Cloud backup helps address the availability problem ransomware creates: production files, servers, and applications may be encrypted, corrupted, or made inaccessible. But backup is only one layer of the response.
A ransomware-ready design must answer five separate questions:
- Can the attacker reach or delete the backup repository?
- Can an administrator’s compromised credentials change retention or encryption settings?
- How quickly can the organization identify the last clean recovery point?
- Can the workload be restored without reinfecting the replacement system?
- Who makes the recovery decision, and in what order are systems brought back?
Acronis Cyber Protect Cloud combines backup and recovery capabilities with anti-malware and anti-ransomware functions, and its platform documentation describes options such as full-image recovery, running a backup as a virtual machine, immutable storage, and scanning or patching during safe recovery1. Those capabilities can be useful, but the correct configuration depends on the client’s workloads, licensing, identity model, and recovery objectives.
The distinction matters: ransomware prevention attempts to stop malicious activity; backup provides a path back after prevention fails. Neither replaces the other.
CISA recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster-recovery scenario because ransomware may attempt to delete or encrypt backups that remain accessible to the production environment.2
The five-part Acronis ransomware design we use with clients
At Datapath, we evaluate an Acronis deployment as a recovery system rather than as a storage subscription. The following matrix turns that evaluation into decisions a technology leader can verify.
| Control area | Acronis Cloud Backup question | Evidence Datapath expects | Decision it supports |
|---|---|---|---|
| Backup scope | Are the systems that matter actually protected? | Workload inventory covering servers, endpoints, databases, NAS shares, Microsoft 365 data, and configurations | Determines whether the recovery plan covers the business or only selected files |
| Isolation | Can a compromised production identity reach the backup? | Separate administrative identities, MFA, least privilege, restricted management paths, and protected cloud storage | Reduces the chance that one stolen credential destroys both production and backup |
| Retention protection | Can an attacker or rushed administrator shorten retention or delete recovery points? | Documented retention policy plus immutable-storage settings and change logging | Preserves recovery points through the investigation and restoration window |
| Clean recovery | How do we know the restored workload is not carrying malware? | Isolated recovery network, malware scanning, patching, golden images, and approval before reconnection | Prevents reinfection during recovery |
| Operational proof | Can the named team restore the right service within the target? | Restoration evidence, elapsed time, application validation, and an after-action record | Converts “backup succeeded” into a defensible recovery result |
Acronis documentation distinguishes between governance mode, where administrators can adjust retention or delete backups, and compliance mode, which is designed to prevent deletion during the configured retention period. Do not confuse a product’s “compliance mode” with compliance with HIPAA, CJIS, GLBA, or any other external requirement. It is a technical control that still needs an appropriate policy, access model, and review process.
1. Protect the backup control plane
The most overlooked ransomware path is not always the backup data itself. It may be the console, service account, remote-management tool, or administrator workstation used to operate the backup platform.
We want separate administrative identities for backup management, MFA for privileged access, limited roles for help-desk users, and clear approval for destructive actions. Backup operators should not automatically have unrestricted rights across every production system. A compromised domain administrator should not be the only key to the recovery vault.
CISA specifically calls for least privilege and separation of duties when third parties or MSPs have access to an organization’s systems, and recommends formalizing security expectations in contracts.3 For a Datapath client, that means documenting who can create a protection plan, who can change retention, who can approve deletion, and who can authorize reconnection after a ransomware event.
2. Make immutability fit the threat window
Immutability is valuable only when the retention period matches the organization’s exposure and investigation window. A seven-day protected copy may be inadequate if an attacker quietly encrypts files for three weeks before triggering the ransom demand. A very long retention period may increase storage cost and complicate data-governance obligations.
We help clients decide retention by asking:
- How long could an intrusion remain undetected?
- Which systems need point-in-time recovery rather than only the latest copy?
- How long must evidence and business records be preserved?
- What is the cost of restoring an older but known-clean version?
- Who can change retention, and how is that change logged?
The answer should be written into the recovery plan—not left as an inherited default in a console.
What should a ransomware recovery test measure?
A restore test should resemble the real decision, not just confirm that a file can be downloaded. NIST’s MSP guidance says backup files should be conducted, maintained, and tested, and connects that practice to NIST Cybersecurity Framework Subcategory PR.IP-4.4
For a mid-market business in Fresno or Modesto, we may define three different targets in the same plan:
- 15 minutes: maximum tolerable data loss for a transaction database or high-volume operational system.
- 2 hours: target to bring a core file or application service online in a clean recovery environment.
- 24 hours: target for lower-priority archives, departmental shares, or nonessential reporting systems.
Those numbers are example decision targets, not universal promises. The correct values come from a business-impact discussion with the owner of each workflow.
A useful Acronis recovery test records:
- The incident assumption, such as ransomware encrypting a file server and attempting to disrupt recovery tools.
- The recovery point selected and the reason it was considered clean.
- The time to provision the isolated recovery environment.
- The time to restore the workload and its dependencies.
- Application validation, such as logging into the EHR, opening a test patient record, or verifying a database transaction.
- The person who approved production reconnection.
- Any missing credentials, licensing issue, network dependency, or configuration drift.
The final item is where many plans fail. A backup may restore the data but not the DNS record, service account, application license, firewall rule, printer queue, or integration that makes the system usable.
How does this work during EHR downtime?
For a healthcare clinic, the recovery order should follow patient-care operations rather than server size. A practical sequence might be:
- Isolate affected endpoints and servers while preserving relevant logs.
- Confirm whether the EHR vendor, identity provider, network, and backup console are affected.
- Activate the clinic’s downtime procedure for registration, clinical notes, orders, and prescriptions.
- Restore identity and core network services in a clean segment.
- Restore the EHR-supporting database or application components from a validated recovery point.
- Test user access, scheduling, clinical workflows, and interfaces before reconnecting staff.
- Reconcile paper or temporary records after normal operations resume.
HHS guidance states that HIPAA-covered entities and business associates need policies and procedures for responding to and recovering from ransomware; it also identifies frequent backups, tested restorations, offline backup considerations, and a data-backup plan as part of the contingency-planning requirements in 45 C.F.R. § 164.308(a)(7).3
That does not mean an Acronis policy automatically makes a clinic HIPAA compliant. It means the backup configuration, restoration evidence, risk analysis, incident procedures, and vendor responsibilities should fit together. Datapath can coordinate that work through our healthcare IT services and HIPAA-compliant IT services teams.
What changes for CJIS-regulated dispatch and public safety?
The same recovery logic applies to a public-safety environment, but the restoration priorities are different. A Fresno or Central Valley dispatch operation may need to preserve access to dispatch records, CAD integrations, radio-related services, identity systems, and evidence-retention workflows while avoiding changes that compromise an investigation.
The FBI’s CJIS Security Policy v6.0 identifies CP-9 System Backup and CP-10 System Recovery and Reconstitution, including backup protection and recovery planning requirements.5 A CJIS environment therefore needs more than a statement that backup data is encrypted. The agency and its providers should be able to explain where protected data is stored, who can access it, how recovery objectives and priorities are documented, and how cloud-provider responsibilities are handled.
For that workflow, we would document a recovery order before an incident:
- dispatch and communications dependencies;
- identity, authentication, and network services;
- CAD or records-management systems;
- evidence and retention repositories;
- lower-priority reporting and administrative systems.
A Datapath client can pair a protected backup architecture with our government and public safety IT, CJIS compliance services, and incident response retainer so the recovery conversation includes both technical restoration and accountable incident coordination.
Is cloud backup enough without endpoint security?
No. If ransomware is still active in the environment, restoring a server into the same flat network can simply restart the incident. A resilient design combines backup with endpoint detection and response, email and identity protection, network segmentation, vulnerability management, and a rehearsed incident process.
Acronis can be part of that layered design, particularly where the client wants backup, endpoint protection, and recovery workflows managed together. We still validate the surrounding controls: privileged access, Microsoft 365 identity, firewall rules, remote-management accounts, logging, and the security of the administrator’s workstation.
This is also why Datapath does not sell a “backup-only” answer to a ransomware question. Our managed cybersecurity services team looks at how an attacker could enter, move laterally, disable recovery, and hide evidence. Our disaster recovery services team then maps the clean restoration sequence to business priorities.
How should a buyer evaluate an Acronis Cloud Backup proposal?
Ask the provider to demonstrate the following—not merely describe them:
- Show which workloads are protected and which are excluded.
- Demonstrate how a privileged account is prevented from deleting protected recovery points.
- Explain the difference between ordinary retention and immutable retention.
- Identify the person who can approve a destructive backup change.
- Restore a representative application, not only a document.
- Test recovery with the production network disconnected.
- Scan and validate the restored system before reconnecting it.
- Produce elapsed-time results against the agreed RPO and RTO.
- Explain what happens if the backup console, identity provider, or MSP account is compromised.
- Provide a named escalation path for a weekend ransomware event.
A green status indicator is useful, but it is not the outcome. The outcome is a clinic that can resume safe scheduling, a dispatch center that can restore essential services, or a 100-plus-employee business that can keep operating without guessing which copy is clean.
The Datapath perspective
Acronis Cloud Backup can be a strong component of ransomware resilience when it is configured around isolation, protected retention, clean recovery, and measurable business priorities. It becomes a weak answer when nobody can explain the recovery order, the independent access path, or the last time a real application was restored.
Datapath serves organizations across Modesto, Ceres, Manteca, Merced, Fresno and the wider Central Valley, Modesto, and the California communities of Modesto. We bring a named team to the conversation—not commodity “IT support”—and connect uptime, accountability, and regulated-industry requirements to the systems your people actually operate.
If your current question is “Are our Acronis backups running?”, the better question is: “If ransomware starts at 4:47 p.m., which service do we restore first, from which clean point, and who is accountable for proving it works?” Start that review with our managed IT services team or contact Datapath for a recovery-readiness conversation.