## Why hardened backup repositories matter
Ransomware response conversations often focus on endpoint protection, EDR, phishing controls, and cyber insurance. Those are important, but they do not answer the question executives ask after an incident: can we restore the business?
Attackers know this. Modern ransomware crews commonly target backup servers, domain admin credentials, hypervisor management consoles, NAS shares, and cloud backup portals before encrypting production systems. If the backup platform is reachable with the same credentials and protocols used everywhere else, it becomes part of the blast radius.
A hardened Linux backup repository is one of the most practical ways to reduce that risk. It is not a complete disaster recovery strategy by itself, but it gives small and mid-sized organizations a cost-effective place to store backup restore points that are difficult to alter or delete during the retention window. When paired with offsite copies and routine restore testing, it can turn a catastrophic ransomware event into a controlled recovery project.
This guide focuses on building a Linux repository suitable for Veeam Backup and Replication environments, but the engineering principles apply broadly: isolate the storage, minimize trust, restrict network paths, use a filesystem that supports efficient synthetic operations, enable immutability where supported, and test restores under realistic conditions.
## The design goal: survivable, not merely large
Backup storage is often purchased by capacity first. That is understandable, but survivability is more important than raw terabytes. A 200 TB repository that an attacker can wipe in five minutes is less valuable than a 40 TB repository with enforced immutability, limited administrative access, and known-good restore points.
A hardened repository should meet several goals:
– It should not be joined to Active Directory or Entra Domain Services.
– It should not expose SMB or NFS shares for backup writes.
– It should use a dedicated local account, not a reusable domain admin account.
– It should restrict SSH and backup service ports to known backup infrastructure.
– It should use XFS with reflink support for efficient block cloning.
– It should support immutable restore points for a defined retention window.
– It should be monitored, patched, and restore-tested like production infrastructure.
The repository is not a place for general file storage, ISO libraries, administrator scratch space, or log archives. Treat it as a purpose-built security boundary.
## Reference architecture
A typical SMB or nonprofit deployment looks like this:
– Veeam Backup and Replication server on a management VLAN.
– VMware vSphere, Hyper-V, or physical workloads on production VLANs.
– Hardened Linux repository on a dedicated backup VLAN.
– Firewall rules allowing only required Veeam traffic from the backup server and proxies.
– Separate management access for hardware out-of-band interfaces such as iDRAC, iLO, or IPMI.
– Optional backup copy jobs to object storage, tape, or a second site.
For hardware, use a dedicated physical server when possible. A virtual Linux repository stored on the same hypervisor cluster it protects is convenient, but it is weaker from a recovery perspective. If the virtualization platform is compromised, both production and repository may be exposed.
For storage, prefer RAID 10 or RAID 6 with enterprise disks, a real hardware RAID controller or proven software RAID design, battery-backed write cache where appropriate, redundant power, ECC memory, and monitoring for disk health. Capacity planning should include retention, change rate, synthetic full behavior, growth, and the immutability window.
## Operating system selection
Veeam supports multiple Linux distributions for repositories. Choose a mainstream long-term support distribution your team can patch confidently, such as Ubuntu Server LTS, Debian, Rocky Linux, or Red Hat Enterprise Linux. Do not choose an obscure distribution simply because it is lightweight.
For this example, the commands use Ubuntu Server LTS. Adjust package names and firewall syntax for your distribution.
During installation:
– Install only the base server packages.
– Use a strong local administrator account.
– Do not install a desktop environment.
– Do not join the server to a directory domain.
– Put the operating system on separate mirrored boot disks if possible.
– Put backup data on a dedicated volume mounted under a clear path such as /repo.
Keep the OS simple. Every additional service increases the patching burden and the attack surface.
## Build the XFS backup volume
Veeam uses block cloning on XFS to improve space efficiency and performance for synthetic full backups and merge operations. The important option is reflink support.
First identify the target disk. Be careful: the following commands destroy data on the selected device.
“`bash
lsblk
sudo wipefs -a /dev/sdb
sudo parted /dev/sdb –script mklabel gpt
sudo parted /dev/sdb –script mkpart primary xfs 0% 100%
sudo mkfs.xfs -m reflink=1,crc=1 /dev/sdb1
“`
Create a mount point and mount the filesystem by UUID rather than by device name.
“`bash
sudo mkdir -p /repo
sudo blkid /dev/sdb1
“`
Add an entry to /etc/fstab. Replace the UUID with the value from blkid.
“`bash
sudo nano /etc/fstab
“`
Example fstab entry:
“`text
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /repo xfs defaults,noatime,nodiratime,nodev,nosuid 0 0
“`
Then mount and verify:
“`bash
sudo mount -a
findmnt /repo
xfs_info /repo | grep reflink
“`
You should see reflink=1 in the output. If reflink is not enabled, rebuild the filesystem before storing backup data.
## Create a dedicated service account
Avoid using root for repository operations. Create a dedicated local account for Veeam onboarding and repository access.
“`bash
sudo adduser veeamsvc
sudo usermod -aG sudo veeamsvc
sudo mkdir -p /repo/veeam
sudo chown veeamsvc:veeamsvc /repo/veeam
sudo chmod 700 /repo/veeam
“`
Veeam typically needs temporary elevated privileges during repository setup to install and manage required components. Follow the current Veeam documentation for your version, because required sudo permissions can change. A common pattern is to use single-use credentials during onboarding, then ensure privileged credentials are not stored for routine operation.
The principle matters more than the exact sudoers line: do not reuse a domain administrator, do not keep broad credentials stored unnecessarily, and do not use this account for human administration.
After the repository is added and tested, consider removing ongoing sudo rights if your Veeam configuration and support requirements allow it. Document any change and test backup and restore operations immediately afterward.
## Restrict SSH before and after onboarding
SSH is useful during setup, but it should not be open to the entire network. At minimum, restrict it to the Veeam server, backup proxies, and a small number of administrative jump hosts.
On Ubuntu, UFW can enforce a simple policy:
“`bash
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 10.20.30.10 to any port 22 proto tcp
sudo ufw allow from 10.20.30.11 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose
“`
Replace the example addresses with your Veeam server and approved management host. If your organization uses a central firewall between VLANs, enforce the same restrictions there as well. Host firewalls and network firewalls should agree.
Once Veeam has deployed its components, many hardened designs disable SSH except during controlled maintenance windows. If you do that, make sure you have console access through a secure out-of-band management network. Do not lock yourself out of the system during a recovery event.
For additional SSH hardening, disable password login and root login where operationally feasible:
“`bash
sudo nano /etc/ssh/sshd_config
“`
Recommended settings:
“`text
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers adminuser veeamsvc
“`
Then reload SSH:
“`bash
sudo systemctl reload ssh
“`
If you disable password authentication, verify key-based login from an approved management host before closing your current session.
## Open only required Veeam traffic
Veeam port requirements vary by version, topology, and transport mode. Always validate against the documentation for your deployed version. In many environments, the Linux repository needs communication from the Veeam server and proxies for control and data movement. Common examples include the Veeam transport service and data mover port range.
A tightly scoped UFW example might look like this:
“`bash
sudo ufw allow from 10.20.30.10 to any port 6162 proto tcp
sudo ufw allow from 10.20.30.20 to any port 2500:3300 proto tcp
sudo ufw allow from 10.20.30.21 to any port 2500:3300 proto tcp
sudo ufw status numbered
“`
Do not copy port examples blindly. Confirm which systems initiate traffic in your topology, especially if you use separate proxies, network mode, direct SAN access, or hardened repository features. The operational target is simple: only backup infrastructure should be able to talk to the repository.
## Enable immutability in Veeam
The key advantage of a hardened Linux repository is immutable restore points. In Veeam, this is configured when adding or editing the Linux repository. You select the option to make recent backups immutable and define the number of days.
The retention value should be long enough to outlast your realistic detection window. If ransomware could sit undetected for a week, a three-day immutability period is not sufficient. Many SMBs start with 14 to 30 days, then adjust based on capacity, risk tolerance, and recovery objectives.
Immutability is not the same as infinite retention. It prevents supported deletion or modification of protected restore points during the lock period. After that period expires, normal retention processing can remove old data. This is exactly what you want: a window of tamper resistance without uncontrolled storage growth.
Do not manually manipulate immutable backup files with chattr unless you are following vendor support guidance. Let the backup software manage the immutability flags so backup chains remain consistent.
## Separate backup administration from domain administration
One common failure mode is allowing the same people, passwords, and administrative groups to control everything. If a domain admin account can log into the backup server, the hypervisor, the repository, the firewall, and the cloud backup portal, an attacker only needs to win once.
Improve separation with these practices:
– Use dedicated backup administrator accounts.
– Require MFA for backup consoles and remote access paths.
– Do not browse email or the web from backup servers.
– Keep backup servers off general user VLANs.
– Avoid storing repository credentials in scripts, spreadsheets, or password notes.
– Use privileged access workstations or hardened jump hosts for administration.
– Monitor logins to the backup server and repository.
For smaller organizations, perfect separation may be unrealistic. Still, even basic segmentation helps. A separate local Linux account, a management VLAN, firewall restrictions, and MFA-protected backup console access are meaningful improvements.
## Patch without breaking recoverability
A hardened repository should not become an unpatched museum piece. Linux security updates matter, especially for OpenSSH, sudo, kernel vulnerabilities, and network services.
A practical patch routine is:
1. Confirm the latest backup job completed successfully.
2. Confirm at least one recent restore point is immutable.
3. Apply OS updates during a maintenance window.
4. Reboot if required.
5. Verify the repository remounts correctly.
6. Run a small backup job.
7. Run a test restore or instant recovery validation.
Example update commands on Ubuntu:
“`bash
sudo apt update
sudo apt list –upgradable
sudo apt upgrade
sudo reboot
“`
After reboot:
“`bash
findmnt /repo
df -h /repo
systemctl status ssh –no-pager
sudo ufw status verbose
“`
If you use configuration management tools, be careful not to push generic Linux baselines that enable unwanted services, rotate firewall rules, or join the system to centralized authentication without review.
## Monitor the repository like production
Backup repositories fail quietly before they fail loudly. Monitor them for capacity, disk health, filesystem errors, failed jobs, unexpected logins, and changes to firewall or SSH configuration.
Useful checks include:
“`bash
df -h /repo
sudo journalctl -p warning -S yesterday
sudo last -a | head
sudo ss -tulpn
“`
For disk health, install smartmontools if your controller exposes physical disk data:
“`bash
sudo apt install smartmontools
sudo smartctl -a /dev/sdb
“`
In hardware RAID environments, use the vendor tool for your controller. SMART visibility through RAID varies, so do not assume the OS can see every disk problem.
Capacity alerts should trigger well before the repository is full. Running out of backup storage can cause failed jobs, broken retention processing, and emergency cleanup decisions. A good starting alert threshold is 75 percent warning and 85 percent critical, adjusted for your change rate and procurement timeline.
## Test restores, not just backups
A backup job that says success is not the same as a recovery plan. You need evidence that you can restore files, application data, and entire systems within acceptable timeframes.
At minimum, schedule these tests:
– Monthly file-level restore from a recent backup.
– Quarterly application-aware restore test for critical systems.
– Quarterly instant VM recovery or full VM restore test.
– Annual ransomware simulation that assumes production credentials are compromised.
Document how long each recovery takes. If the owner of a line-of-business application expects recovery in two hours, but the last test took nine hours, you have a business continuity gap, not just an IT issue.
For Veeam environments, also test credentials and network paths required during a crisis. Many restore failures happen because the original infrastructure is unavailable, DNS has changed, the hypervisor is down, or nobody knows the encryption password.
## Avoid these common mistakes
### Joining the repository to the domain
Domain membership is convenient, but it expands the attack surface. A hardened repository should remain outside normal identity compromise paths.
### Exposing the repository as a file share
Do not make /repo available through SMB or NFS for convenience. Backup software should write through its intended transport, not through a general-purpose share accessible to administrators and malware.
### Using the backup server as a daily admin workstation
The backup server should be treated as sensitive infrastructure. Do not use it for browsing, email, vendor portals, or routine help desk tasks.
### Setting immutability too short
If you only lock backups for a few days, an attacker who delays encryption or disables jobs may still outlast your protected restore points. Match immutability to your detection and response reality.
### Forgetting offsite copies
A hardened local repository helps against logical deletion and many ransomware scenarios, but it does not protect against fire, flood, theft, or a site-wide power event. Maintain an offsite or cloud copy aligned with the 3-2-1-1-0 model: three copies, two media types, one offsite, one immutable or offline, and zero untested recoverability assumptions.
## Practical implementation checklist
Use this checklist before placing the repository into production:
– Dedicated physical server selected and documented.
– Operating system installed with minimal packages.
– Server not joined to Active Directory.
– Backup volume formatted as XFS with reflink enabled.
– Repository mounted persistently by UUID.
– Dedicated local Veeam service account created.
– SSH restricted to approved hosts or disabled after onboarding.
– Host and network firewalls limited to required backup traffic.
– Veeam repository added with immutability enabled.
– Immutability period approved by IT and business leadership.
– Backup encryption keys stored securely outside the backup server.
– Monitoring configured for capacity, hardware health, and failed jobs.
– Patch process documented.
– File and VM restore tests completed successfully.
– Offsite backup copy strategy confirmed.
## Summary and key takeaways
A hardened Linux repository is one of the highest-value backup improvements an SMB can make. It does not require a massive platform change, but it does require disciplined engineering: isolate the repository, use XFS correctly, restrict access, enable immutability, patch carefully, and test restores.
The most important takeaway is that backup security is not just a storage problem. It is an identity, network, operations, and recovery problem. The repository should be difficult for an attacker to reach, difficult to alter during the protected window, and easy for your team to restore from when the pressure is high.
Key takeaways:
– Build the repository as a dedicated security boundary, not a general-purpose Linux file server.
– Use XFS with reflink enabled for efficient Veeam repository operations.
– Keep the server out of the domain and avoid reusable privileged credentials.
– Restrict SSH and Veeam traffic to known backup infrastructure.
– Set immutability based on realistic ransomware detection timelines.
– Monitor capacity and hardware health before failures affect backup chains.
– Prove recoverability with scheduled restore tests.
– Keep an offsite or offline copy for site-level disasters.
For organizations without a full-time infrastructure team, this is an ideal project to plan with an outsourced IT partner. The configuration details matter, but the larger goal is straightforward: make sure the business can recover when production systems, credentials, and assumptions are under attack.
