Skip to main content

BDR Storage Alerts & Capacity Issues

Audience: T1 / T2 / T3
Version: 1.6
Last Updated: April 2026
Applies To: Veeam BDR appliances (all models) with local repository storage

Overview

This guide addresses BDR storage capacity alerts and related backup failures. Covers both immediate remediation (freeing space quickly) and long-term solutions (capacity planning, retention optimization).

Common symptoms:

  • Backup job fails with "Insufficient disk space on repository"
  • Veeam console shows repository in red/warning state
  • NinjaRMM or monitoring alert for BDR disk space (typically <10% free)
  • Job completes but merge operation fails due to space

Tier Definitions

Tier Scope Expected Resolution
T1 Check space, identify quick wins 15 minutes or less
T2 Review retention, cleanup stale data 30-60 minutes
T3 Capacity planning, storage addition 1+ hours, may require onsite/procurement

T1 — Check Storage Usage & Quick Assessment

1. Check Current Disk Space

2. Check Windows Recycle Bin

⚠️ Quick Win: Large deleted files may be sitting in the Recycle Bin consuming repository space.

Check Recycle Bin size:

# Calculate total size of items in Recycle Bin
$recycleBin = (New-Object -ComObject Shell.Application).NameSpace(0xA)
$size = ($recycleBin.Items() | ForEach-Object { $_.Size } | Measure-Object -Sum).Sum
[PSCustomObject]@{
    RecycleBinSizeGB = [math]::Round($size/1GB,2)
    ItemCount = $recycleBin.Items().Count
}

Common scenario:

  • Failed backup job cleanup leaves 50-100GB+ VHDX/VBK files in Recycle Bin
  • Manual deletions of old backups sent to Recycle Bin instead of permanent deletion
  • Windows maintenance operations moved large temp files to Recycle Bin

Action:

  1. If Recycle Bin shows significant space (>10GB):
    • Verify no recent accidental deletions (check with team/client if unsure)
    • Empty Recycle Bin: Right-click desktop icon → Empty Recycle Bin
    • Or via PowerShell: Clear-RecycleBin -Force
  2. Recheck disk space to verify recovery
  3. If storage alert clears, document in ticket and close

Resolution time: 5 minutes or less (immediate space recovery)

RDP to the BDR and run:

Get-WmiObject Win32_LogicalDisk | Select DeviceID, @{N='FreeGB';E={[math]::Round($_.FreeSpace/1GB,2)}}, @{N='TotalGB';E={[math]::Round($_.Size/1GB,2)}}, @{N='PercentFree';E={[math]::Round(($_.FreeSpace/$_.Size)*100,2)}}

DTC Thresholds:

  • < 10% free: Critical - immediate action required
  • 10-20% free: Warning - review soon
  • > 20% free: Healthy (failure may be transient)

3. Check Repository Status in Veeam

Open Veeam Backup & Replication console:

  • Navigate to Backup Infrastructure → Backup Repositories
  • Check the Free column
  • Note which repository (usually "Default Backup Repository") is affected

4. Quick Decision

  • If > 10% free: Retry the failed job. This may have been a transient issue during a merge operation.
  • If < 10% free: Escalate to T2 for investigation.
  • If critically low (< 5% free): Flag for immediate T2/T3 attention. Merges and new backups will likely fail until space is freed.

T2 — Investigate & Identify Space Consumers

T2 scope — authorized to execute: T2 can complete all cleanup steps and actions in this section without escalating to T3 — reducing retention and running an Active Full, deleting orphaned backup chains, removing decommissioned machines from backup (Remove from backup → Delete from disk), clearing stale .deleteme/merge files, and disabling unneeded GFS. Escalate to T3 only for capacity planning, storage addition, or procurement. Destructive deletes still require the safety gate noted in each step: confirm the machine is truly decommissioned (NinjaRMM/AD/client inventory) and confirm with team lead before deleting.

1. Review Retention Settings

Check each backup job's retention policy:

  1. In Veeam console: Home → Jobs → Backup
  2. Right-click each job → Edit
  3. Go to Storage tab → Retention policy

DTC Standard Retention:

  • Workstations: 7-14 restore points (typically 15-20 in practice)
  • Servers: 14-30 restore points (200-400 restore points is normal for longer retention policies)
  • High-change environments: 7 restore points (1 week)
  • Large environments with limited repo space: 5-7 restore points

Common over-provisioning:

  • 30 restore points on a repo sized for 14 days
  • GFS (Grandfather-Father-Son) enabled when not needed
  • Incorrect retention after migration (old settings carried over)

Action: If retention is higher than DTC standard for the client, reduce to appropriate level and run an Active Full to trigger merge and space reclamation.

2. Identify Largest Backup Jobs

In Veeam console:

  1. Backup Infrastructure → Backup Repositories → right-click repository → Properties
  2. Go to Capacity tab to see breakdown by job

Or via PowerShell on the BDR:

Get-ChildItem -Path "E:\Backup\*" -Directory | ForEach-Object {
    $size = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum
    [PSCustomObject]@{
        JobName = $_.Name
        SizeGB = [math]::Round($size/1GB,2)
    }
} | Sort-Object SizeGB -Descending

(Adjust path to match your repository location - check Veeam console for exact path)

Action: Identify if one or two jobs are consuming disproportionate space. These are candidates for:

  • Retention reduction
  • Moving to separate repository (if available)
  • Splitting into separate jobs (C: vs D: drives)

3. Check for Orphaned Backups

Orphaned backup chains = backups still on disk but no longer tied to an active job (typically from decommissioned servers, deleted jobs, or migrations).

In Veeam console:

  1. Home → Backups → Disk
  2. Look for backup chains that:
    • Don't have a corresponding job in Home → Jobs → Backup
    • Are for servers or workstations that have been migrated or decommissioned
    • Show "orphaned" status or have old dates with no recent activity

Action: Right-click orphaned chain → Delete from disk (confirm with team lead first).

4. Check for Deleted VMs Still Consuming Space

In Veeam console:

  1. Home → Backups → Disk → expand each job (click the arrow next to the job name)
  2. Review each machine/VM listed under the job

What to look for:

Indicator What It Means Action
Workstation with 100+ restore points Retention misconfigured - should be 15-20 Check job retention settings, reduce if excessive
Server with 200-400 restore points Normal for server retention policies Verify matches intended retention (usually normal)
Very high count (500-1000+) Likely orphaned data or failed cleanup operations Investigate - may be old backup chain
Machine no longer exists in environment Decommissioned/migrated machine still accumulating backups Right-click → Remove from backup → Delete from disk
Old creation dates with no recent activity Backup chain from old migration/decommissioned server Verify machine status, delete if confirmed obsolete
Mismatched types in same job Servers and workstations mixed with same retention Consider splitting job types for proper retention

Example from screenshot:

workstations01 job:
- backoffice (workstation): 15 restore points ✓ (normal)
- crafton-imgsvr (server): 268 restore points ⚠️ (review - may be old data)
- craftonsvr (server): 400 restore points ✓ (normal for servers)
- doctor (workstation): 15 restore points ✓ (normal)
- scan-x1 (workstation): 15-16 restore points ✓ (normal)

Key Distinction - Servers vs. Workstations:

  • Server images: 400 restore points is normal (longer retention for critical infrastructure)
  • Workstations: 15-20 restore points is normal (standard retention)
  • Excessive counts: Look for workstations with server-level retention (100+) or servers with unusually high counts that don't match retention policy

Action steps:

  1. For machines with excessive restore points (100+):

    • Verify the machine still exists and is in production
    • Check if it was migrated/replaced (old backup chain should have been deleted)
    • If obsolete: Right-click → Remove from backup → Delete from disk
    • If still active: Investigate why so many points accumulated (check job retention, merge history)

  2. For machines that no longer exist:

    • Cross-reference with current server/workstation inventory
    • Confirm with client or check documentation
    • Delete from backup to reclaim space

  3. For machines with normal count but old dates:

    • Verify last backup date matches job schedule
    • If dates are very old (months/years): likely orphaned

⚠️ Important: Before deleting any backup data, confirm with team lead and verify the machine is truly decommissioned - check NinjaRMM, AD, or client inventory first.

✅ Validated Resolution Example:

Issue: BDR storage alert triggered (<10% free space)

Investigation: Reviewed Backups → Disk view, found:

  • Multiple machines with 15-16 restore points (normal)
  • Two machines with 268 and 400 restore points (excessive)

Root Cause: Machines had been replaced but old backup chains were never removed

Resolution: Deleted replaced computer data via:

  1. Right-click each obsolete machine → Remove from backup
  2. Selected Delete from disk
  3. Freed significant repository space
  4. Storage alert cleared

Time to Resolution: 30 minutes (T2 level)

Lesson: Always audit backup jobs after migrations/replacements to remove old chains.

5. Check for Stale Merge Files

Interrupted merge operations can leave large temporary files (.vbk/.vib/.vrb) in the repository.

On the BDR:

# Check for .deleteme files (failed cleanup operations)
Get-ChildItem -Path "E:\Backup\" -Recurse -Filter "*.deleteme" | Select FullName, @{N='SizeGB';E={[math]::Round($_.Length/1GB,2)}}

# Check for .vbm files referencing missing restore points
Get-ChildItem -Path "E:\Backup\" -Recurse -Filter "*.vbm" | Select FullName

Action: These typically need to be removed manually if Veeam console can't clean them. Verify they're not part of an active chain by checking the .vbm metadata before deleting.

6. Review GFS (Grandfather-Father-Son) Retention

Many BDRs accumulate GFS full backups without anyone realizing it was enabled.

In Veeam console:

  1. Right-click each job → Edit → Storage tab
  2. Check Configure secondary destinations (GFS configuration)

If enabled: You'll see weekly/monthly/yearly fulls accumulating. Unless explicitly required for compliance, disable GFS to reclaim space.

T3 — Capacity Planning & Long-Term Solutions

1. Calculate Current & Projected Usage

Gather data:

  • Current repository size (total GB)
  • Current free space
  • Average daily/weekly backup growth rate
  • Retention policy in restore points

Rough capacity formula:

Required Space = (Full Backup Size × 1.5) + (Daily Change Rate × Retention Days)

Example:

  • Full backup: 500 GB
  • Daily change: 20 GB
  • Retention: 14 restore points
  • Required: (500 × 1.5) + (20 × 14) = 750 + 280 = 1,030 GB minimum

Action: Document current vs. required capacity. If undersized, escalate for storage addition.

2. Restructure Jobs for Efficiency

For large environments:

  • Separate C: drives (system, frequent changes, standard retention) from data drives (D:/E:, infrequent changes, can use lower retention)
  • Run separate jobs: "ClientName - System Drives" vs "ClientName - Data Drives"
  • Apply different retention policies

Example:

  • C: drives → 14 restore points (daily)
  • D: drives → 7 restore points (weekly fulls, daily incrementals)

3. Evaluate Storage Addition Options

If capacity is legitimately insufficient:

Solution Timeline Cost Notes
Expand BDR local storage 1-2 weeks Moderate Requires onsite visit if physical appliance
Add secondary repository 1-3 weeks Moderate-High Another BDR or NAS device
Cloud repository (S3/Azure) Days-1 week Ongoing DTC standard: Backblaze B2 S3
Replace undersized BDR 2-4 weeks High For fundamentally undersized deployments

DTC Standard: Veeam S3 copy jobs to Backblaze B2 for offsite. This doesn't solve local capacity but provides DR coverage while local repo is restructured.

Action: Document findings and recommendations in HALO ticket. Engage Account Manager for client approval if cost/procurement required.

4. Schedule Onsite for Storage Addition

If physical storage addition is needed:

  1. Procure drive(s) matching BDR specs
  2. Schedule maintenance window with client (30-60 min)
  3. Onsite tasks:
    • Physically install drive
    • Initialize & format in Windows
    • Add to Veeam repository (or create new repository)
    • Optionally: migrate some jobs to new repo
  4. Post-addition: Run test backup, verify space allocation

Pre-onsite checklist:

  • Confirm BDR model and available drive bays
  • Verify drive compatibility (SATA/SAS, size limits)
  • Confirm RAID configuration (if applicable)
  • Backup current Veeam configuration

Quick Reference — Common Causes & Fixes

Issue Cause Fix
Repository suddenly full Retention too high Reduce to DTC standard, run Active Full
Slow steady growth Normal accumulation Add storage or reduce retention
Large spike after migration Old backup chains not deleted Delete orphaned backups
Merge failures consuming space Interrupted merges leaving temp files Manually clean .deleteme files
GFS fulls accumulating GFS enabled but not needed Disable GFS secondary destination
One job consuming 80% of repo Disproportionate retention or full size Split into separate jobs or reduce retention
Large files in Recycle Bin Deleted VHDX/VBK files not permanently removed Empty Recycle Bin (T1 - 5 min fix)

Escalation & Documentation

If T3 cannot resolve or capacity addition is required:

  1. Document in HALO:

    • Current capacity: X GB total, Y GB free (Z% free)
    • Current retention settings per job
    • Projected growth rate
    • Recommended solution (storage addition, retention reduction, etc.)
    • Cost estimate (if known)

  2. Engage Account Manager if client approval needed for:

    • Storage purchase
    • Onsite visit for installation
    • BDR upgrade/replacement

  3. Temporary mitigation while waiting for approval:

    • Reduce retention to minimum safe level (7 restore points)
    • Disable non-critical jobs temporarily
    • Set up manual cleanup script to run before backups

Document History:

Version Date Author Changes
1.0 April 2026 DTC Initial creation - comprehensive BDR storage troubleshooting guide
1.1 April 2026 Scott Leister Enhanced T2 Step 4 with detailed visual walkthrough of Backups → Disk view, added table of indicators for identifying cleanup candidates, included real-world example of excessive restore point counts
1.2 April 2026 Scott Leister Added validated resolution example: storage alert resolved by deleting replaced computer backup data (268 & 400 restore point cleanup)
1.3 April 2026 Scott Leister Critical correction: Updated retention standards to distinguish servers (400 points = normal) vs workstations (15-20 points = normal). Updated examples and indicator table accordingly.
1.4 April 2026 Scott Leister Added T1 Step 2: Check Windows Recycle Bin for deleted files. Addresses scenario where 90GB VHDX file in Recycle Bin consumed repository space - clearing bin freed space immediately (5-minute resolution).
1.5 April 2026 Scott Leister Added Recycle Bin scenario to Quick Reference table for easy lookup. Second real-world validation of different client with same Recycle Bin issue.
1.6 June 2026 Zachary Boogher Added T2 scope note clarifying T2 is authorized to execute all cleanup actions (retention reduction, orphaned chain deletion, decommissioned-machine removal, stale merge-file cleanup, GFS disable) without T3 escalation; T3 reserved for capacity planning/procurement. Safety gates preserved.
Back to top