Three HDD Makers Could Soon Be Two: The Proactive Disk-Health Playbook for MSPs and IT Teams

Here is a number that should get every IT manager's attention: Seagate and Western Digital now control roughly 90% of the hard disk drive market, according to TrendForce. Toshiba — the third player — depends on TDK for its magnetic drive heads, and both Seagate and WD are bidding to buy that TDK business. If Seagate wins, Bloomberg reports the deal could knock Toshiba out of the HDD market entirely, leaving the world's spinning storage in the hands of two suppliers.

Meanwhile, AI data centers are absorbing every high-capacity drive the remaining manufacturers can build. What that means for you: longer replacement lead times, higher prices, less vendor diversity — and an installed base of client disks (NAS volumes, backup targets, file servers, hypervisor datastores) that suddenly has to last longer and be monitored better.

If you run an MSP or an internal IT team, here is the uncomfortable truth: most of us still find out about disk problems in one of two terrible ways. Either a user calls because the file share is full, or a RAID array degrades at 2 AM and the monitoring tool notices 45 minutes later — if it is configured to check at all. In a market where the enterprise drive that used to ship in two days might now take three weeks, the gap between detection and disaster gets brutally expensive.

This post breaks down why disk failures still slip through, and gives you a practical playbook — scripts included — for catching filling and failing disks across every client from one console.

The Problem: Your Disk Alerts Were Built for a 2012 Fleet

Picture a Monday morning that will feel familiar:

• 9:14 AM — a ticket lands: users at Client A cannot save to the shared drive.
• You remote in. The 12 TB data volume on the NAS is 99% full.
• You open your RMM. It technically monitors disks, but the policy was cloned from a template in 2021 and only alerts at 5% free on boot volumes.
• You open the standalone monitoring tool — a PRTG server or a Nagios box someone built before you were hired. It watches switches and a handful of SNMP counters. No volume data.
• You open the helpdesk (ConnectWise, HaloPSA, whichever you run). No prior tickets about storage growth. No capacity history exists anywhere.
• You check vendor portals for an expansion drive. Lead time: two to three weeks, price up double digits, because AI data centers are buying everything.

That is four tools, three logins, and zero answers about when this volume started filling — and now you are doing emergency cleanup at 9:30 on a Monday while users cannot work.

Then there is the harder case: SMART failures. Modern drives almost always warn you first. Reallocated sector counts creep up, pending sectors appear, CRC errors tick higher. But in most MSP stacks, SMART data is either not collected at all, or collected by an RMM that files it as a low-priority device note nobody reads. It never becomes a ticket. It never gets correlated to the client's SLA. So the warning light blinks for six weeks until the drive dies on a Friday night.

Why do these gaps exist? Three structural reasons:

1. Siloed architecture. RMM, monitoring, helpdesk, and patching live in different products. The disk alert fires in tool A, the ticket lives in tool B, and the fix runs from tool C. Every handoff is a chance for the alert to die in a browser tab nobody refreshes.
2. Static thresholds, no trends. Percentage-free alerts are nearly useless on modern volumes. On a 16 TB volume, 10% free is 1.6 TB — you alert way too early, techs learn to ignore it, and the real problem (a volume consuming 40 GB a day that hits the wall in 18 days) sails through unnoticed. Nobody alerts on trajectory.
3. No real multi-tenancy where the data lives. When monitoring does exist, per-client policies are such a configuration nightmare that everyone inherits one global default — which fits no client well.

The business impact, in terms every IT manager will recognize:

• Users become the monitoring layer. Cannot-save-file, mailbox-full, and backup-failed tickets arrive before any alert fires, so ticket volume spikes with every storage incident.
• Emergency procurement at spot prices — in a market consolidating from three HDD vendors toward two.
• SLA misses. A preventable disk-full becomes a P1 outage because nobody saw the 90-day trend.
• Burnout and churn. The tech paged at 2 AM for a RAID rebuild a $200 SMART alert would have prevented does not stay motivated — and neither, sometimes, does the client.

Add the supply chain angle from this article: fewer drive makers plus AI demand means every preventable disk failure now costs more to fix and takes longer to recover from. Detection quality is no longer a nice-to-have. It is procurement strategy.

How AlertMonitor Closes the Gap

AlertMonitor was built for the MSP model from day one — multi-tenant, unified, and workflow-driven. Here is what changes concretely:

1. Multi-tenant disk and hardware health in one NOC view. Every server, workstation, NAS, and hypervisor host across all clients — free space, volume growth, physical disk SMART counters, RAID and array status — visible per client or side by side in a single dashboard. No per-client logins, no tab juggling.

2. Alerts on trajectory, not just thresholds. Set a policy once — warn at 15% free, critical at 8% — and add a forecast rule: alert when a volume is projected to cross that floor within 21 days at its current growth rate. The 40-GB-a-day volume gets flagged three weeks out, so you schedule cleanup on a Tuesday afternoon instead of discovering it through user tickets on a Monday morning.

3. SMART data that becomes a ticket automatically. Reallocated sectors rising, pending sectors present, disk temperature out of range — AlertMonitor correlates the signal to the client, the SLA tier, and the affected asset, then opens the helpdesk ticket with the right severity and routing. The warning light can no longer blink for six weeks unnoticed.

4. Alert-to-fix in one workflow. The alert becomes a ticket. The ticket links to the device. The technician runs the cleanup or diagnostic script remotely from the same console via integrated RMM, schedules the patch or firmware job, and the resolution logs against the SLA clock automatically. Old way: four tools and 15-20 minutes of pure context switching per incident. AlertMonitor way: one screen, one timeline, minutes.

5. Capacity reporting that writes your QBR deck. Per-client storage trend reports come out of the same data. When you walk into a quarterly review and say, "Your NAS is on track to be full in about 10 weeks, and given current drive lead times we should order the expansion now," you are not selling — you are preventing an outage. That is a much easier conversation to have with a chart than with an apology.

What You Can Do Today: A Practical Disk-Health Playbook

Whether or not you deploy a unified platform this week, do these things now. Copy, paste, adapt.

1. Baseline free space across every Windows server you manage

$servers = 'DC01','FS01','SQL01','HV01'
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
    Select-Object PSComputerName, DeviceID,
        @{N='SizeGB';E={[math]::Round($_.Size/1GB,1)}},
        @{N='FreeGB';E={[math]::Round($_.FreeSpace/1GB,1)}},
        @{N='FreePct';E={[math]::Round($_.FreeSpace/$_.Size*100,1)}} |
    Sort-Object FreePct | Format-Table -AutoSize

Anything under 15% free goes on your watch list. Anything under 8% goes on the fix list — today.

2. Check physical disk health, not just free space

Free space tells you nothing about a drive that is dying. Windows exposes the same counters dedicated SMART tools read:

Get-PhysicalDisk |
    Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus,
        @{N='SizeTB';E={[math]::Round($_.Size/1TB,1)}}

# Wear and error counters that predict failure weeks in advance:
Get-PhysicalDisk | Get-StorageReliabilityCounter |
    Select-Object DeviceId, Temperature, Wear, ReadErrorsCorrected, ReadErrorsUncorrected, PowerOnHours

Watch for: Wear climbing on any SSD, uncorrected read errors above zero, temperatures sustained above 45 C. Any of those on a spinning disk means you are shopping for a replacement on your schedule — not the drive's.

3. Verify your arrays are actually healthy

A degraded RAID volume that has been limping along since March is not a storage strategy:

Get-StorageSubsystem | Get-VirtualDisk |
    Select-Object FriendlyName, HealthStatus, OperationalStatus, SizeRemaining

Everything should read Healthy. Any OperationalStatus other than OK gets a ticket tonight, not next sprint.

4. Linux boxes count too

# Free space, human-readable, skip pseudo filesystems
df -h -x tmpfs -x devtmpfs

# SMART verdict plus the three counters that matter most
sudo smartctl -H /dev/sda
sudo smartctl -A /dev/sda | grep -E 'Reallocated_Sector|Current_Pending|UDMA_CRC'

If smartctl is missing: apt install smartmontools on Debian and Ubuntu, dnf install smartmontools on RHEL-family hosts.

5. Stop guessing growth — forecast it

Log free space daily and let simple math tell you when the volume hits the wall:

# Save as Invoke-CapacityTrack.ps1 and run daily via scheduled task
param(
    [string]$DriveLetter = 'C',
    [double]$FloorPct = 10
)

$vol = Get-Volume -DriveLetter $DriveLetter
$log = "C:\ProgramData\CapTrack\$DriveLetter.csv"
New-Item -Path (Split-Path $log) -ItemType Directory -Force | Out-Null
[pscustomobject]@{
    Date   = Get-Date -Format 'yyyy-MM-dd'
    FreeGB = [math]::Round($vol.SizeRemaining / 1GB, 2)
} | Export-Csv $log -Append -NoTypeInformation

# Forecast from the last 15 logged samples
$h = Import-Csv $log | Select-Object -Last 15
if ($h.Count -ge 2) {
    $burn = ($h[0].FreeGB - $h[-1].FreeGB) / ($h.Count - 1)   # GB consumed per day
    if ($burn -gt 0) {
        $floor = ($vol.Size / 1GB) * ($FloorPct / 100)
        '{0}: burning {1:N1} GB/day, {2}: hits {3}% free in about {4} days' -f `
            (Get-Date -Format 'yyyy-MM-dd'), $burn, $DriveLetter, $FloorPct,
            [math]::Floor(($h[-1].FreeGB - $floor) / $burn)
    }
}

That forecast line is the whole point: trajectory beats thresholds. AlertMonitor does this natively across every client — the script is your proof of concept for why.

6. Build a drive inventory now, while drives are still available

With the HDD market potentially shrinking from three vendors to two, knowing exactly what is spinning at every client site is procurement insurance:

$targets = 'FS01','FS02','HV01'
$session  = New-CimSession -ComputerName $targets
Get-PhysicalDisk -CimSession $session |
    Select-Object PSComputerName, Model, FirmwareVersion, SerialNumber,
        @{N='SizeTB';E={[math]::Round($_.Size/1TB,1)}}, HealthStatus |
    Export-Csv 'C:\Reports\drive-inventory.csv' -NoTypeInformation

Standardize on one or two enterprise models per tier, keep a shared hot-spare pool sized to your slowest-responding client, and set reorder points based on current lead times — not 2022 lead times.

7. Wire it into one workflow in AlertMonitor

The steps above work, but you are still gluing them together by hand. In AlertMonitor:

• Create a Capacity Watch policy per client tier: warn at 15%, critical at 8%, plus a forecast alert at 21 days out.
• Enable SMART collection on every disk device and map reallocated and pending sector events to automatic tickets with severity tied to each client's SLA.
• Attach saved remediation scripts (log cleanup, temp purge, backup-chain checks) so the responding technician is one click from the fix.
• Schedule the per-client storage trend report for your QBRs.

From alert to ticket to fix to documented resolution — one console, one timeline, one SLA clock.

The Lesson Hiding in the Bidding War

Toshiba's problem in this story is not technology — it is dependency. One supplier for a critical component, and a rival's purchase order away from being squeezed out of its own market.

MSPs live the same risk in miniature every day: one aging NAS holding a client's only copy of its data, one drive model across the entire fleet, one monitoring tool that — if it misses the SMART warning — leaves the helpdesk as the only sensor in the stack. The takeaway from the hardware story is the takeaway for operations: reduce single points of failure, and instrument what you cannot yet control.

Consolidating RMM, monitoring, helpdesk, and patching into AlertMonitor removes the tool-sprawl failure mode. Trajectory-based disk and SMART alerting removes the silent-failure mode. And with drive lead times headed where they are headed, catching a failing disk weeks early is not just good engineering — it is the difference between a planned Tuesday maintenance ticket and a three-week backorder with an angry client on the phone.

Related Resources

AlertMonitor MSP Operations & Team Efficiency AlertMonitor Platform Overview Book a Demo MSP Operations & Team Efficiency Resources