How Veeam immutable backups and a Hardened Repository resist ransomware deletion

A Veeam Hardened Repository uses Linux, single-use credentials and immutability to reduce deletion risk, but still requires isolation, monitoring and recovery testing.

1. Conclusion and scope

When the backup server, repository and production domain share the same administration path, an attacker who controls the domain may delete the backups as well. A Hardened Repository reduces this path through minimal persistent credentials and immutable backup-file attributes, but it is not automatically secure without a sound architecture.

This issue involves backup, storage, recovery and business continuity. A successful job status is not a substitute for a recovery exercise.

2. Risk signals that deserve priority

• The repository is joined to the production domain and a domain administrator can log in and delete files.
• Veeam console, Linux root, storage and virtualisation administration are concentrated in the same accounts.

3. Pre-change assessment checklist

1. Confirm Veeam release, supported Linux distribution, XFS, hardware, capacity and immutability requirements.
2. Design separate administration, single-use credentials, management network, time synchronisation and physical access.
3. Calculate peak capacity during the immutable period, including retention and synthetic operations.
4. Ensure backup copies, configuration backup, encryption keys and recovery media do not depend on the same failure domain.

findmnt -no FSTYPE,OPTIONS /backup
df -h /backup
timedatectl status
ss -lntup

4. Recommended implementation sequence

1. Use a dedicated Linux server and supported file system and keep it outside production Active Directory.
2. Use single-use deployment credentials, then disable routine SSH or tightly restrict management access.
3. Set an immutability period that matches recovery objectives and configure capacity monitoring and alerts.
4. Combine the repository with 3-2-1-1-0, offline or off-site copies and regular SureBackup or restore exercises.

5. Validation, rollback and common mistakes

• Immutable restore points cannot be deleted early from either Veeam or the operating-system layer.
• After simulating loss of the backup server, an independent process can still access the repository and restore.
• Capacity, time, certificate and immutability-state monitoring operates correctly.

Common mistakes

• Joining the Linux repository to the production domain.
• Setting a long immutable period without capacity modelling.
• Testing only deletion resistance and never restoring a VM or application.

Official references

• Veeam: Hardened Repository

Frequently asked questions

Is an immutable backup absolutely impossible to delete?

It strongly resists normal deletion during the set period, but hardware destruction, poor design and privileged control still require other safeguards.

Is an off-site or offline copy still necessary?

Yes. Immutability addresses tampering; off-site and offline copies address site, hardware and broader disasters.