Skip to main content

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:

  1. Right-click the job → Statistics
  2. Compare current run to previous successful runs
  3. 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:

  1. Expand the job session
  2. Look at Data Read vs Transferred
  3. 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:

3. Check Veeam Transport Mode

In Veeam console:

  1. Right-click the job → EditStorage tab → Advanced button
  2. 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:

  1. Right-click the job → EditTarget tab
  2. 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:

  1. Main Menu → General Options → Network Traffic
  2. Verify Preferred networks and Throttling are not limiting throughput

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:

  1. Deploy proxy server on source subnet
  2. Add to Veeam: Backup Infrastructure → Backup Proxies → Add VMware Backup Proxy (or Windows proxy for agent-based)
  3. 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:

  1. Right-click the job → EditStorage tab → Advanced button
  2. 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:

  1. Right-click the job → EditGuest Processing tab → ApplicationsEdit
  2. Add Exclusions for:
    • C:\Windows\Temp
    • C:\Users\*\AppData\Local\Temp
    • C:\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:

  1. Home → Jobs → Backup → check start times
  2. 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


Document History:

Version Date Author Changes
1.0 April 2026 DTC Initial creation - performance and slow backup troubleshooting