Modern ransomware attacks the backups first. PowerProtect DD can make them immutable — but most backup applications cannot drive Retention Lock. Here is how to automate it without depending on your backup software.
The weak link: the backup server itself
An attacker who compromises the backup server can, with the application’s privileges, delete or encrypt the copies before hitting production. Any protection driven by the application falls with it. The only structural defence is immutability enforced by the storage platform, outside the application’s path: that is Retention Lock’s role on PowerProtect DD.
Governance or Compliance: choosing the right mode
Retention Lock comes in two modes. Governance protects against ordinary accidental or malicious deletion: a DD security officer can intervene through an exceptional procedure — this is the usual operating mode. Compliance removes any possibility of revocation before expiry, for strict regulatory requirements: reserve it for cases where regulation demands it, because configuration mistakes are paid for until the copies expire.
The two-MTree architecture
The setup that makes Retention Lock work with any backup application relies on two distinct MTrees:
- The primary MTree — the backup application writes to it normally, knowing nothing about immutability. Veeam, NetBackup, Commvault or anything else: no application-side prerequisite.
- The Retention Lock MTree — configured with its periods (minimum and maximum retention, automatic retention, lock delay). Every night, a protected copy of the primary content is created there by fastcopy — a metadata operation, fast and space-efficient thanks to deduplication.
Once the lock delay elapses, the copy becomes immutable: neither the application, nor a hurried administrator, nor an attacker in control of the backup server can alter it before expiry. Expired copies are purged automatically — the protected MTree does not grow without bound.
The day everything goes wrong: recovery
The recovery scenario is simple because it was planned: identify in the inventory the protected copy predating the compromise, make it accessible to the backup application (on a rebuilt server if necessary), and restoration follows the application’s usual path. The attacker encrypted production and the backup server? The locked copies remained intact — that was the point.
Points of vigilance
- Test restoration before the incident — an immutable copy that has never been restored is a hypothesis, not a protection.
- Size retention to your real detection window: 14 days of immutability is useless if a compromise takes three weeks to discover.
- Lock down administrative access to the mechanism itself: dedicated accounts, authorized IP addresses, two-factor authentication.