Performance & Slow Backups
Audience: T1 / T2 / T3
Version: 1.0
Last Updated: April 2026
Overview
This guide addresses backup jobs that complete successfully but take excessive time, or jobs with very low throughput (<5 MB/s on gigabit network).
Common symptoms:
- Job runs for hours but should complete in 30-60 minutes
- Throughput starts normal then drops to 0-2 MB/s
- Job completes but duration is 3-5x longer than expected
- VSS snapshot held for extended period causing application delays
Tier Definitions
| Tier | Scope | Expected Resolution |
|---|---|---|
| T1 | Quick checks, one-time retry | 15 minutes |
| T2 | Network diagnostics, transport optimization | 30-60 minutes |
| T3 | Infrastructure changes, proxy deployment | 1+ hours, may require architecture changes |
T1 — Quick Checks & Baseline
1. Establish Normal vs. Slow Baseline
In Veeam console:
- Right-click the job → Statistics
- Compare current run to previous successful runs
- Note:
- Data processed (GB)
- Duration
- Average throughput (MB/s)
DTC Baseline Expectations:
- Gigabit LAN (same subnet): 40-80 MB/s sustained
- Cross-subnet/VLAN: 30-60 MB/s (depends on routing quality)
- WAN/VPN: 5-20 MB/s (depends on bandwidth)
If throughput is <20% of expected: Escalate to T2.
2. Check for High Change Rate
In Veeam console:
- Expand the job session
- Look at Data Read vs Transferred
- High ratio (e.g., 200 GB read, 180 GB transferred) indicates high change rate
Action: This is expected if the source has heavy activity. Consider:
- Running backup during off-hours
- Excluding high-churn directories (temp files, logs)
- Increasing repository capacity
3. Check for Source-Side Bottleneck
On the source server/VM:
# Check if backup is I/O-bound
Get-Counter '\PhysicalDisk(*)\% Disk Time' | Select -ExpandProperty CounterSamples | Format-Table Path, CookedValue
If disk time > 90%: The source disk is saturated. Backup may be slow due to:
- Underpowered storage (single spinning disk)
- Competing I/O (database, file server load)
- Need for storage upgrade or backup window shift
4. Retry During Off-Hours
If the job is running during business hours with heavy application load:
Action: Manually run the job during off-peak hours (evening/weekend) and compare performance. If significantly faster, adjust the job schedule.
T2 — Network & Transport Troubleshooting
1. Check Network Throughput
From the BDR to the source:
# Test file transfer speed
# On BDR, create a test file
fsutil file createnew C:\temp\testfile.bin 1073741824 # 1 GB file
# Copy to source
Measure-Command { Copy-Item C:\temp\testfile.bin \\[SOURCE_IP]\C$\temp\ }
# Calculate MB/s: 1024 MB / seconds
Expected:
- Gigabit LAN: <15 seconds (68+ MB/s)
- 100 Mbps: <90 seconds (11+ MB/s)
If significantly slower: Network issue, not Veeam-specific. Check:
- Duplex mismatches
- Network congestion
- Firewall/IPS inspection overhead
2. Check for Cross-Subnet Transport Issues
If BDR and source are on different subnets:
- See Veeam Troubleshooting Playbook - Scenario 3 for MTU issues, asymmetric routing, etc.
- Consider deploying a Veeam proxy on the same subnet as the source
3. Check Veeam Transport Mode
In Veeam console:
- Right-click the job → Edit → Storage tab → Advanced button
- Check Storage optimization setting
Options:
- Local target (large blocks) - Best for LAN backup to BDR
- LAN target - Standard for most environments
- WAN target - Optimized for high-latency links
Action: Ensure Local target or LAN target is selected for LAN-based backups.
4. Disable WAN Acceleration (if enabled)
WAN acceleration should NOT be used for LAN backups.
In Veeam console:
- Right-click the job → Edit → Target tab
- Verify WAN Accelerator is not checked
If enabled: Disable it and retry the job. WAN acceleration adds overhead that hurts LAN performance.
5. Check for Veeam Throttling
In Veeam console:
Action: If throttling is enabled unintentionally, disable it for LAN backups.
6. Review VSS Snapshot Duration
On the source server:
# Check if VSS snapshot is being held for extended time
vssadmin list shadows
Long-held snapshots indicate:
- Slow read from source disk (see T1 source bottleneck check)
- Network transfer is bottlenecked
Action: Optimize network/transport before focusing on VSS.
T3 — Infrastructure Optimization & Proxies
1. Deploy Veeam Backup Proxy on Same Subnet
If cross-subnet performance is fundamentally poor:
Deploy a Veeam proxy server on the same subnet as the backup source(s). This keeps data transport local, only metadata crosses subnets.
Proxy requirements:
- Windows Server (VM or physical)
- Minimum 4 CPU cores, 8 GB RAM
- Gigabit network connectivity to both source and BDR
Setup:
- Deploy proxy server on source subnet
- Add to Veeam: Backup Infrastructure → Backup Proxies → Add VMware Backup Proxy (or Windows proxy for agent-based)
- Configure job to use the new proxy
2. Optimize Storage on BDR
If BDR repository is on slow storage (single HDD, RAID 5):
Indicators of BDR storage bottleneck:
# On BDR, check disk performance during backup
Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Write' | Select -ExpandProperty CounterSamples | Format-Table Path, CookedValue
If > 0.050 (50ms write latency): Storage is slow.
Solutions:
- Upgrade to SSD-based repository
- Improve RAID configuration (RAID 10 instead of RAID 5)
- Add NVMe cache tier (if hardware supports)
3. Enable Parallel Processing
In Veeam console:
- Right-click the job → Edit → Storage tab → Advanced button
- Parallel processing: Enable and set to 2-4 concurrent VMs/disks
Note: Only helps if:
- BDR has sufficient CPU/RAM
- Multiple VMs in the job
- Repository storage can handle concurrent writes
If single large VM: Parallel processing won't help.
4. Exclude High-Churn / Non-Critical Data
For VMs or servers with large, high-change directories:
In Veeam console:
- Right-click the job → Edit → Guest Processing tab → Applications → Edit
- Add Exclusions for:
C:\Windows\TempC:\Users\*\AppData\Local\TempC:\inetpub\logs(if IIS, large log directories)D:\Pagefile.sys,D:\Swapfile.sys
Action: Re-run the job and compare duration.
5. Consider Backup Windows & Workload Balancing
If multiple large jobs run concurrently:
Review job schedule:
- Home → Jobs → Backup → check start times
- Stagger large jobs to avoid concurrent runs
Example:
- Job 1 (Server A): 10:00 PM
- Job 2 (Server B): 11:00 PM
- Job 3 (Workstations): 12:00 AM
Action: Spread job start times across the backup window to reduce BDR resource contention.
Quick Reference — Common Causes
| Symptom | Likely Cause | Quick Fix |
|---|---|---|
| Throughput <5 MB/s on gigabit LAN | Network issue or dual-NIC asymmetric routing | Check network, see Scenario 7 |
| Job starts fast then drops to 0 MB/s | VSS writer failure mid-job | Check VSS writer status, see Scenario 1 |
| Slow only during business hours | Source disk saturated by app load | Move backup to off-hours |
| Cross-subnet backups 3x slower | Inter-VLAN routing or MTU issue | Deploy proxy on source subnet |
| Slow only for one large VM | Source disk slow or high change rate | Upgrade source storage, exclude temp files |
| All jobs slow after BDR uptime >90 days | Veeam services need restart or BDR reboot | Reboot BDR during maintenance window |
Related Documents
- Veeam Troubleshooting Playbook - Scenario 3 - Network timeout and cross-subnet issues
- Veeam Troubleshooting Playbook - Scenario 7 - Dual-NIC causing network asymmetry
- Veeam Troubleshooting Playbook - Scenario 1 - VSS writer failures
Document History:
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | April 2026 | DTC | Initial creation - performance and slow backup troubleshooting |