Troubleshoot MABS disk capacity issues affecting replicas, recovery points and backup jobs.
Identify which storage pool is actually full — replica, recovery point, or SQL/DPMDB — since each has a different fix.
Never delete MABS-managed VHDX or replica files directly — always resize or clean up through the MABS console or PowerShell cmdlets.
Determine whether the problem is on replica storage, recovery point storage, SQL storage or the operating system volume.
Identify which volume is actually full
MABS uses Modern Backup Storage (a single storage pool for replica + recovery points in MABS/DPM 2016+) or, on older deployments, separate replica and recovery point volumes. Check pool utilization directly rather than guessing from a generic "disk full" alert:
Get-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining, SizeAlso check the DPMDB/MABSDB volume separately — a full SQL database volume produces a different set of symptoms (job scheduling failures, console errors) than a full storage pool (failed recovery points, replica inconsistency), even though both surface as "storage" problems.
Check what's actually driving growth
Before adding capacity, confirm whether growth is expected or a symptom of something else. Common non-obvious drivers: a datasource's change rate increased sharply (a database that started logging verbosely, a file share that started receiving large uploads), retention was recently extended without a corresponding storage increase, or a recovery point job has been failing and retrying, leaving partial data behind. Check the protection group's recent recovery point sizes in the console — a sudden jump points to a data-side change, not a storage-side one.
Review storage allocation against current workload
MABS calculates recommended storage based on data size and expected daily change rate at the time the protection group was configured — that estimate doesn't update itself as the protected workload grows. In the console, compare each datasource's original allocation against its current actual usage under Protection Group properties, and increase allocation for any that's grown meaningfully since setup rather than only reacting once the pool is already full.
Check for non-MABS consumers on the same volume
If the storage pool volume is shared with anything else (logs, temp files, another application), rule that out before resizing the pool:
Get-ChildItem -Path E:\ -Recurse -File -ErrorAction SilentlyContinue |
Sort-Object Length -Descending |
Select-Object -First 20 FullName, @{N='SizeGB';E={[math]::Round($_.Length/1GB,2)}}Dedicated MABS storage pool disks generally shouldn't have anything unexpected on them, but this is worth a quick check before assuming the growth is entirely backup-related.
Never delete MABS-managed files directly
Replica and recovery point volumes/VHDXs are tracked in the MABS database — deleting or shrinking them outside the console breaks that tracking and can corrupt the protection state for that datasource, often requiring a full replica rebuild (a lengthy re-baseline) to recover. To reclaim space, use the console: reduce retention range for the protection group, or remove and re-add a datasource if it needs a smaller allocation, rather than touching files on disk.
Validate after remediation
After adding capacity or adjusting retention, confirm free space with Get-Volume again, then trigger a manual synchronization and a manual recovery point for the affected datasource from the console. Don't consider the incident closed until a full recovery point completes successfully — freeing space doesn't guarantee the replica itself is still consistent if it was already degraded before the fix.