Veeam Backup Configurations That Have Saved My Clients

Backups are insurance. You hope you never need them, but when you do, nothing else matters. After recovering multiple clients from ransomware, hardware failures, and user mistakes, I've developed strong opinions about Veeam configuration.

The Philosophy

The 3-2-1 rule is the minimum:

• 3 copies of your data
• 2 different storage types
• 1 copy offsite

Most of my clients exceed this because storage is cheap and data loss is expensive.

Test your restores. A backup that doesn't restore isn't a backup. Every Veeam deployment includes scheduled SureBackup verification and periodic manual restore tests.

Encrypt everything. Backup repositories contain your entire business. Encryption at rest is mandatory.

Veeam Backup & Replication: Core Configuration

Repository Setup

Don't use the Veeam server's local storage as primary. It's tempting for small deployments, but you've now made that server a single point of failure for both backups AND the data being backed up.

Recommended repository architecture:

Primary:

• Dedicated NAS or SAN with sufficient IOPS
• ReFS or XFS filesystem (block cloning for synthetic fulls)
• 10GbE connection to Veeam server minimum

Secondary:

• Different physical location
• Can be cloud, different site, or rotated USB drives
• Lower performance acceptable since it's secondary

Repository configuration:

• Use per-machine backup files (easier restore, no chain dependency)
• Enable inline deduplication
• Align backup blocks to 4KB
• Enable encryption with strong password

Backup Job Configuration

My standard VMware/Hyper-V backup job:

Job Settings:
- Mode: Incremental
- Schedule: Daily at 8 PM (after business hours)
- Active full: Every Sunday
- Synthetic full: OFF (use active fulls instead for reliability)
- Retention: 14 restore points (two weeks)

Storage:
- Repository: Primary Backup Repository
- Enable inline data deduplication
- Compression: Optimal
- Storage optimization: Local target (16TB+ drives)
- Enable encryption

Guest Processing:
- Enable application-aware processing
- Enable guest file system indexing

Why active fulls instead of synthetic:

Synthetic fulls are faster and save storage, but they create chain dependencies. If any incremental in the chain corrupts, you lose everything after it. Active fulls take longer but create known-good recovery points every week.

Application-aware processing matters:

For domain controllers, SQL servers, Exchange, and any transactional workload, you need VSS to get consistent backups. Without it, you might restore a corrupted database.

Copy Jobs (Offsite)

Primary backups are local for fast recovery. Copy jobs replicate to offsite storage.

Backup Copy Job:
- Source: Primary backup repository
- Target: Cloud repository (Wasabi, Backblaze B2, Azure Blob)
- Copy every: 1 day
- Restore points to keep: 14
- GFS: Enabled
  - Weekly: Keep 4 (monthly anniversary)
  - Monthly: Keep 12 (first week of month)
  - Yearly: Keep 3 (first backup of year)

GFS (Grandfather-Father-Son) is critical. Ransomware increasingly has delayed activation. If an attacker encrypts your files but waits 30 days before triggering the ransom, your two weeks of daily backups are all useless. Monthly and yearly retention gives you recovery points from before the infection.

Agent Backup for Physical Servers and Workstations

Not everything is virtualized. Physical servers, workstations with critical data, and laptops need protection too.

Veeam Agent configuration:

Backup Mode: Entire computer (bare metal capable)
Schedule: Daily
Retention: 7 restore points
Target: Network share or Veeam repository

For laptops:
- Backup when connected to company network
- Cache locally when offline
- Or: Direct-to-cloud to company cloud repository

Critical workstations I always protect:

• Bookkeeper's machine (QuickBooks data)
• Owner's laptop
• Any machine running local databases
• Design workstations with large project files

SureBackup: Automated Restore Testing

This is the feature most people skip and most regret skipping.

SureBackup configuration:

Create a Virtual Lab:

• Isolated network (no production access)
• Proxy appliance for network masquerading

Create Application Group:

• Add critical VMs (DC, file server, application servers)
• Define startup order (DC first, then dependencies)

Configure verification:

• Heartbeat: Is the VM responsive?
• Ping: Does it have network connectivity?
• Application: Can specific scripts/tests connect?

Schedule:

• Weekly SureBackup runs
• Email results to me

What SureBackup catches:

• Corrupted backups that won't restore
• OS boot failures
• Application startup issues
• Domain trust problems

Finding out your backup doesn't work BEFORE you need it is invaluable.

Real Recovery Scenarios

Ransomware Recovery (Recent)

Situation: Client clicked malicious email attachment Friday evening. Ransomware encrypted mapped drives and spread to file server. Discovered Monday morning.

Recovery:

1. Isolated all affected systems from network
2. Identified infection timestamp from file modification dates
3. Found clean restore point (Thursday night backup)
4. Restored file server VM from Veeam
5. Performed antivirus scan on all workstations
6. Restored user files from pre-infection backup
7. Total downtime: 6 hours

What made this possible:

• Daily backups with 14-day retention
• Offsite copies (attacker couldn't delete them)
• SureBackup had verified this backup worked 3 days prior
• Documented recovery procedures

Hardware Failure (Catastrophic)

Situation: Dell PowerEdge had multiple drive failures in RAID 5 array. Server unbootable. Rebuild would take days assuming data was even recoverable.

Recovery:

1. Ordered replacement hardware (next-day)
2. Installed fresh ESXi on new hardware
3. Connected to Veeam repository
4. Performed Instant VM Recovery for critical VMs
5. VMs running from backup repository within 1 hour
6. Storage vMotion to migrate to local storage (background, no downtime)
7. Total impact to users: 2 hours (during business hours)

Key Veeam feature: Instant VM Recovery boots the VM directly from compressed backup files. It's slower than local storage but gets users working immediately while you properly restore to production storage.

Accidental Deletion (Common)

Situation: User deleted project folder with 6 months of work. "I didn't mean to delete it permanently."

Recovery:

1. Identified when folder last existed (backup browser)
2. Used Veeam Explorer for Microsoft Windows
3. Mounted backup, browsed to folder
4. Restored folder to original location
5. Time to resolve: 15 minutes

This happens monthly. Having granular file recovery means the answer is always "let me check our backups" rather than "it's gone."

Configuration Mistakes I've Fixed

• No encryption: Found backup repository on network share accessible to users. Ransomware would have encrypted backups too. Added encryption and moved to isolated network.
• Retention too short: 7 days of backups. Discovered corruption that happened 10 days ago. Nothing clean to restore. Extended to 30 days minimum for this client.
• No offsite copy: All backups local to site. Building had water damage. All local storage destroyed. Now require offsite for everyone.
• No testing: Client assumed backups worked for 2 years. First restore attempt failed - repository had corrupted months ago. SureBackup would have caught this.
• Backing up to same array: Backups stored on same SAN as production VMs. SAN failure took out both. Separate storage is mandatory.

My Checklist for New Veeam Deployments

Infrastructure:

• [ ] Dedicated backup server (not shared with production workloads)
• [ ] Separate storage for repository (not production SAN)
• [ ] Sufficient bandwidth for backup window
• [ ] Encryption configured and password documented securely

Jobs:

• [ ] All VMs included in backup job
• [ ] Application-aware processing enabled for databases
• [ ] Schedule avoids business hours
• [ ] Retention set to minimum 14 days
• [ ] Active full weekly

Offsite:

• [ ] Copy job to offsite location configured
• [ ] GFS retention enabled (weekly, monthly, yearly)
• [ ] Offsite credentials secured separately from primary

Testing:

• [ ] SureBackup configured for critical VMs
• [ ] SureBackup scheduled weekly
• [ ] Manual restore test documented
• [ ] Recovery procedures documented

Monitoring:

• [ ] Email notifications configured
• [ ] Job success/failure monitored
• [ ] Repository space monitored
• [ ] Alerts for failed jobs escalated immediately

Final Thought

The best time to configure backups properly is before you need them. The second best time is right now.

Every recovery story I have happened because backups were configured correctly BEFORE the incident. The clients who didn't have proper backups don't have recovery stories. They have data loss stories.

Configure Veeam right, test it regularly, and sleep better at night knowing that when (not if) something goes wrong, you can fix it.