Direct answer
Detection should identify abnormal change before retention removes older clean points. Combine file-change volume, entropy or extension changes, deletion rate, backup size shifts, endpoint signals and canary objects. A suspicious backup should be retained for investigation but not automatically promoted as the preferred recovery point.
How to frame the decision
Operational confidence comes from repeatable evidence: logs, timestamps, restored-object counts and application checks. A successful backup job is an input to testing, not proof of recoverability.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
Decision table
The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Behavior baseline | Establish normal modification, deletion, compression and backup-volume patterns by workload. | Historical ranges and documented seasonal exceptions. |
| Signal correlation | Combine repository analytics with endpoint and identity alerts rather than relying on one heuristic. | A correlated alert with clear severity and owner. |
| Retention response | Freeze older recovery points when suspicious activity is detected. | A tested hold or retention-extension workflow. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Collect machine-readable evidence rather than relying on a green dashboard.
- Translate the requirement into a pass/fail test for detect encrypted or poisoned data before it ages out good backups.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
These conditions can make a compliant-looking design unusable during an actual recovery.
- High entropy flags legitimate compressed or encrypted business data.
- Detection alerts arrive after older recovery points expire.
- Suspicious data is deleted instead of preserved for analysis.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.
- Assign an owner and closure date to every failed assertion.
- A tested requirement exists for: Behavior baseline.
- A tested requirement exists for: Signal correlation.
- A tested requirement exists for: Retention response.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
Can backup software detect ransomware encryption?
Detection should identify abnormal change before retention removes older clean points. Combine file-change volume, entropy or extension changes, deletion rate, backup size shifts, endpoint signals and canary objects. A suspicious backup should be retained for investigation but not automatically promoted as the preferred recovery point. The deciding factors in this guide are behavior baseline, signal correlation, retention response.
How do entropy alerts work for backups?
Treat the answer as conditional on the actual environment and plan. Combine repository analytics with endpoint and identity alerts rather than relying on one heuristic. Retain a correlated alert with clear severity and owner.
Should suspicious recovery points be retained?
Do not rely on the product label or a successful backup job alone. Test the requirement directly: freeze older recovery points when suspicious activity is detected. Record the result with a date, operator and named exception owner.