The backup redesign was finished about a year before the ransomware incident that tested it. At the time it looked like a sensible refresh tied to a Veeam version upgrade. In hindsight it was the single decision that made recovery possible, and the difference between a hard week and a company-ending loss.
What I inherited
The backup environment I started from had been built by a prior team and had grown alongside everything else. It worked, but it was joined to the corporate Active Directory domain, its repositories sat on aging storage spread across multiple sites, and the whole security model assumed the threat lived outside the perimeter. If a domain admin account was compromised, the backups went with it. For a manufacturer that cannot afford to lose production data, that was a quiet single point of failure sitting under everything else.
The redesign
When the organization moved from Veeam 10 to Veeam 11, I used the upgrade as a reason to rebuild the model rather than just bump the version. The hardware was replaced end to end, backup servers, proxies, and repositories, rather than carried forward. The new infrastructure was joined to a separate management domain with its own identity boundary, so a compromise in the corporate domain could not reach the backup plane at all. Immutability went on: hardened Linux repositories with immutability flags, plus S3-compatible object storage holding an offsite copy that could not be edited or deleted inside its retention window. And every job was audited against 3-2-1-1-0: three copies, two media types, one offsite, one immutable, zero verification errors.
The switch was not instant. The legacy Veeam 10 environment was still being decommissioned when the incident came. Most workloads had already moved to the new design, but a handful of repositories at outlying sites had not.
What the incident proved
When the ransomware hit, the threat actor reached the legacy Veeam 10 environment because it was still joined to the corporate domain, and those repositories were encrypted and lost. The new Veeam 11 environment, sitting behind its own identity boundary, was never touched, and every backup under the new design was usable. That single line is the whole business case for the redesign: the same attack hit both, and only the isolated one survived.
The detail that mattered most was not the immutability flag. It was the identity isolation. Immutability protects against tampering inside a window; identity isolation kept the threat actor from ever authenticating to the backup plane in the first place. Both layers were needed, and the second was decisive.
Where it sits now
After the incident the remaining Veeam 10 workloads were retired immediately and everything else was brought up to the same standard. Lab equipment, shop-floor systems, and other workloads that had lived on older storage with weaker controls were folded into the same immutable tier as the production VMs. Every backup job now runs against the model the redesign established, and the assumption baked into it, that the production domain will eventually be compromised, is treated as a design input rather than a worst case.