An existing backup is not necessarily a recoverable backup
Ransomware does not stop at production. With privileged access, an attacker can disable jobs, steal keys, delete reachable restore points and wait for healthy copies to age out. Protect the Veeam Backup & Replication (VBR) server, repository and recovery process as separate assets.
A Veeam hardened Linux repository makes backup files immutable for a configured period. This is valuable against deletion through normal management paths, but it is neither an off-site backup nor an absolute defense against someone controlling the host, hardware or retention period.
Architecture: separate failure domains
Use 3-2-1-1-0 as an operational target: multiple copies, an off-site copy, at least one immutable or offline copy, and recovery tests without errors. An immutable copy in the same building does not protect against a physical disaster.
| Component | Intended access | Risk to reduce |
|---|---|---|
| Production and hypervisor | Production operations identities | Do not let these identities administer the repository |
| VBR server | Dedicated backup admins, MFA and restricted access | A stolen account should not open the console everywhere |
| Linux repository | Separate local identity and private data path | No SMB/NFS share or stored root password in VBR |
| External copy | Independent account and retention policy | Survive loss of the repository host or site |
| Keys and configuration | Independent vault and documented recovery access | Keep the ability to decrypt and rebuild VBR |
Choose a deployment model: appliance or manual Linux
A Veeam Infrastructure Appliance used as a hardened repository authenticates with certificates; SSH is not used. A manually configured Linux server can use single-use credentials to deploy its components; those credentials are not retained by VBR. Do not assume the appliance follows the same SSH-based setup instructions as a manual server.
In both cases, limit repository roles, apply supported updates and secure physical and out-of-band access. Veeam recommends a physical server with local storage to reduce attack surface. Attached block storage can be supported, but a virtual repository shares risk with a compromised hypervisor.
Prepare storage without losing immutability support
A manually configured hardened repository needs a Linux file system supporting immutable files and extended attributes. Veeam recommends XFS for efficiency and block cloning, but the requirement is more than simply installing XFS. Use local or attached block storage, not an NFS or SMB/CIFS mount.
Reserve a separate data directory owned by the account used to connect to Linux, with 0700 permissions and no sticky bit. Verify the actual mount before adding the repository. Never reformat a disk or recursively change permissions on a repository holding backups because a generic example says so.
findmnt -T /backup/veeam -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
stat -c '%A %a %U:%G %n' /backup/veeam
df -h /backup/veeam
# These commands do not alter files, disks or permissions.Separate accounts: avoid one universal key
Immutability does not prevent root or a storage-controller administrator from causing damage. Avoid giving one identity control over production, VBR and the repository's underlying infrastructure.
- Use dedicated backup administration accounts for VBR; do not use a domain admin identity for daily console access.
- For manual Linux, use the local setup identity and single-use credentials specified by the wizard; after onboarding, retire installation-time privileges under Veeam's procedure while preserving a documented emergency access path.
- Limit guest-processing and virtualization permissions to their documented needs rather than granting standing privileges everywhere.
- Protect console access with MFA and Veeam roles; establish separate emergency accounts and monitoring; restrict administration to approved workstations and networks.
- Separate storage-platform administrators, hypervisor admins and the right to remove an external copy.
Add the repository and size the immutability window
In Backup Infrastructure, add the Linux server or appliance using the authentication method matching your deployment. Create a hardened repository on its data path and enable immutability in the wizard. Check the product build, capacity, connectivity and eligible job types before sending production backups.
For VM image-level and physical-machine backups, the Veeam 13 documentation specifies a minimum of 7 days and maximum of 9999 days. Do not select the maximum by default: immutable files cannot be merged or removed before expiry. Model daily change rates, full-backup schedules, GFS, growth and detection time. Fourteen or 30 days may be useful modelling scenarios, not universal thresholds.
An active chain can have its lock extended from the latest restore point. A failed job can leave files that have not yet been locked. Monitor actual results instead of assuming a directory's presence proves protection.
Retention, chains and copies: limitations that matter
A manual hardened repository does not accept every chain format: Veeam requires forward incremental with active or synthetic fulls, not reverse incremental or forever-forward. Backup copy jobs require GFS retention to use immutability. Confirm each existing job's format before redirecting it to the new repository.
GFS full backups can remain locked as long as their retention requires, beyond the repository's basic immutability period. Application log backups behave differently: if their lock expires before the complete chain, a point-in-time restore may fail. Capacity models must cover both, rather than multiplying VM count by lock duration.
Harden VBR, configuration and keys
Update VBR, its components and the OS in controlled windows. Isolate the management plane from user networks, close unneeded ports, monitor sign-ins and job changes, and review Security & Compliance Analyzer findings. Test MFA and role changes with an emergency account before locking down normal access.
Schedule encrypted VBR configuration backups to a protected, independent destination. Keep the encryption password and data keys in a separate vault available during an incident; verify that a fresh VBR installation can read the configuration and locate repositories. Do not keep the only key or only configuration export on the server you would need to rebuild.
Validate a restore, then simulate losing VBR
Record measured RPO and RTO. After a cyberattack, isolate restored systems and check the integrity of chosen restore points before reconnecting them to Active Directory or production. A green backup job is not proof of application recoverability.
| Test | Success criterion |
|---|---|
| Job to hardened repository | Completed session, visible restore points and confirmed lock status |
| File and application restore | Readable, consistent data confirmed by the application owner |
| Isolated VM | Boot, login and critical dependencies checked without exposing production |
| VBR rebuild | Configuration and secrets available from a clean environment; repository rediscovered |
| Off-site copy | Recovery still possible if local repository or whole site is lost |
Phased deployment and mistakes to avoid
The real question is not just how many days backups are locked. It is who can still render every copy useless, how quickly you will notice, and how long a clean recovery takes.
- Pilot: inventory jobs, choose a representative server and workload, measure write and restore performance, and verify permissions and actual locks.
- Expand: move jobs in groups; monitor space, failures, windows, copy duration and repository health; keep the old copy until the new path is restore-tested.
- Incident drill: rebuild VBR in a clean zone, recover its configuration and one critical service, measure elapsed time and improve the runbook.
- Do not mount an SMB/NFS NAS share and assume it becomes immutable merely because Linux exposes it under /mnt. Do not share the hardened repository among VBR servers.
- Do not grant VBR permanent root, open SSH to the entire network, reuse a shared password or rely only on hypervisor snapshots.
- Do not shorten immutability to solve an urgent capacity issue without understanding chains and its effects on new backups.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →