A copy is not ransomware-resistant because the product has “backup” in its name. It becomes resistant when the account or host that is compromised cannot delete every restore point.
Synchronisation is not a backup
Synchronisation keeps files in several places. When an encrypted or deleted file is correctly synchronised, the change may reach all of them. Version history helps only if retention is long enough and the same user cannot clear it.
A backup keeps points in time and has its own retention policy. It can still be exposed if a production administrator may delete the repository or if the backup device stays connected to an infected host.
The credential boundary
The backup service should use a separate account that is not used for email, web browsing, or daily administration. A production account may send data into the backup, but it should not be able to remove the whole history.
The backup console, object store, hypervisor, and domain should not all fall with one account. MFA helps protect a console, but it does not correct excessive permissions or a session left open on a shared workstation. This is a practical case of isolation.
Offline and immutable mean different things
Offline is a copy without a permanent write path from production: disconnected media, or a repository available only during a controlled window. Media rotation, condition, and storage location still need an owner.
Immutable means a stored version cannot be changed or deleted for a defined period — including by an ordinary administrator account. Its strength depends on configuration: who can shorten retention, remove the whole account, or change the policy. A product label does not replace testing those permissions.
In practice, more than one type of boundary is useful. A cloud configuration error should not also erase a disconnected copy, and failure of local media should not leave the business without another point.
Retention answers “how far back”
Ransomware may be discovered after some time. If every version is short-lived or overwritten before detection, the newest backup may already contain encrypted data or a persistence mechanism.
Set retention from the rate of data change, detection time, storage cost, and required recovery point. Record at least:
- which systems and data are covered;
- backup frequency and version lifetime;
- who may change the policy or delete the repository;
- where job logs and failure alerts are kept;
- who approves deletion of the last known good points.
Test the restore, not the green badge
A successful job says that data was written. It does not say that a service can run from it. Restore testing should take place in a separated environment and check a file, database, or system to the depth that matters to the business.
Record the backup point, start and finish time, gaps, dependencies, and application check. The backup restore test worksheet helps structure the exercise. A test does not have to cover the whole company at once, but it should be repeatable and periodically include critical systems.
Encryption protects confidentiality, not deletion
Encrypt backups at rest and in transit where the data risk requires it. Keys, passwords, and the recovery procedure must remain available after loss of the production domain — and unavailable to an account that can be compromised with it. Losing the key makes a sound backup unusable.
Full-disk encryption protects powered-off media from being read. It does not stop ransomware running inside an unlocked system, and it does not prevent file deletion.
During an incident, do not attach the only backup to a suspect environment. Establish scope first and prepare a clean restoration location. CISA’s #StopRansomware Guide provides broader backup and response guidance, but the design still has to fit your systems and responsibilities.