Getting Started with Veeam: Your First Backup Job Done Properly

Short answer: Install the backup server, add a Linux hardened repository with immutability enabled, create a single backup job for a small group of virtual machines, and then immediately prove it works with a full restore. Most teams complete the first three steps and skip the fourth, which is the only one that proves anything.

We explained what the components do in our article on how Veeam works; this one covers the order in which to build them the first time.

Step 1: place the components deliberately

You need a backup server (the control layer), at least one proxy (the data mover, often the same machine at the start), and a repository (where the files land).

The most critical design decision: the repository must not sit inside the same trust boundary as the backup server. If a single compromise reaches both, ransomware takes your backups along with production. In practice that means separate authentication, a separate administrator account, and where possible a separate network segment.

Step 2: build a hardened repository

Use Linux. Enable immutability. Immutability is enforced by the kernel through the chattr flag, so for the defined period files cannot be changed, moved or deleted even by root.

Two settings decide whether this actually protects you:

The immutability period. Base it on data, not gut feeling. In Mandiant's M-Trends 2026 report, global median dwell time is 14 days, rising to 26 days when the tip-off comes from outside. Seven days falls short of both figures. Thirty days is a defensible floor.The filesystem. Format with XFS and enable block cloning (reflink). Synthetic full backups then reference existing blocks instead of copying data, which noticeably reduces I/O and storage consumption. Veeam's own guidance recommends XFS for this reason.

Step 3: create the first job

Pick a small but meaningful group of virtual machines. Set a retention policy you can explain to your auditor; we covered which records to keep and for how long, including the regulatory requirements, in our article on log retention periods.

Schedule the job outside production hours, then watch how long it actually takes; the backup window is the constraint that will shape every decision that follows. Once the first full backup finishes, measure the incremental runs separately: the number you learn on day one will mislead you.

Step 4: prove it by restoring

This is the step that separates a backup system from a backup habit.

Restore a full virtual machine to an isolated network. Start the application. Log into it. Verify the data is present and current. Record how long the whole process took, because your real RTO is that measured number, not the one in the plan. Our guide on how to calculate RPO and RTO shows how to derive the targets in the first place.

The rule to design around

3-2-1-1-0: three copies of the data, on two media types, one offsite, one immutable or offline, and zero errors after a verified restore test.

The part organizations skip is that final zero. A job reported as successful is not proof of recoverability.

A realistic 30-day learning plan

Week 1. Install in a lab, back up a virtual machine, restore it, then recover a single file from inside it. Week 2. Build a hardened repository with immutability enabled and verify you cannot delete a backup file even as root. Actually try the delete; seeing immutability enabled on screen and proving it are not the same thing. Week 3. Add a second tier: set up copy jobs to object storage or a second site and learn the retention behavior. Week 4. Run a restore drill against a realistic scenario and document the measured RTO.

We mapped out the certification side in our guide on how to learn Veeam and Zerto.

Frequently asked questions

Windows or Linux repository? Linux, for the hardened repository and kernel-level immutability.

What should the immutability period be? Longer than median dwell time. Take the 14-day median as the floor, move to 30 days, then tune to your risk profile and capacity.

If backups are immutable, do I still need replication? Not if your RTO tolerance is hours. Yes if it is minutes, because restoring large data sets takes time. We worked through the split in our Zerto and Veeam comparison.

How often should restores be tested? Monthly for critical systems, with a full application-layer drill at least once a quarter.

Sources

Veeam Hardened Linux Repository Best PracticesMandiant M-Trends 2026: the basis for the immutability periodHow we build this layer: backup and data protection