ZFS Pool Degraded: Missing VDEV Fix

Hardware – Hard Drives Intermediate 👁 5 views 📅 Jul 1, 2026

Your ZFS pool is degraded because a VDEV went missing. Here's the quick fix to bring it back online.

Missing VDEV? Let's Fix It Fast

You've seen it — a degraded ZFS pool with a missing VDEV. It's annoying, but I've fixed this dozens of times. The fix is straightforward. Don't panic.

The Quick Fix

Run this command to check the pool status:

zpool status -v

Look for the missing VDEV. It'll show as UNAVAIL or FAULTED. If the disk physically disconnected (happens with loose SATA cables or hot-swap bays), just reconnect it and run:

zpool online poolname vdevname

Replace poolname with your pool name (like tank) and vdevname with the device path (like sdb). Example:

zpool online tank sdb

Then check status again:

zpool status -v

If it shows DEGRADED still, wait a minute — the pool might be scrubbing or resilvering. Use zpool iostat -v 1 to watch I/O. If it's stuck, proceed to the next step.

Still missing? Replace the disk. If the disk is dead, replace it physically (same or bigger size). Then run:

zpool replace poolname oldvdev newvdev

Example:

zpool replace tank sdb sdc

Wait for the resilver to finish. Check with zpool status. It'll show scanning progress.

Why This Works

ZFS keeps metadata about every VDEV. When a disk disappears (cable fault, power glitch, or failure), the pool marks it as degraded. Running zpool online tells ZFS to check if the device is back. If it's there, ZFS re-adds it to the pool and starts a silent scrub. The disk isn't corrupt, just disconnected. The replace command swaps a dead disk with a working one, ZFS copies data from parity (raidz) or mirror partners. It's not magic — it's checksums and redundancy.

Less Common Variations

1. Missing log or cache device. If a log device (SLOG) or cache (L2ARC) is missing, the pool still works but performance drops. Fix: same zpool online command. If you want to remove it entirely:

zpool remove poolname logdevice

This only works if the log device isn't critical (no pending writes).

2. ZFS pool won't import due to missing VDEV. You see cannot import pool: one or more devices are missing. Try:

zpool import -F poolname

The -F flag forces import with a replay log. If that fails, you need to reattach the disk first. Sometimes the disk is still attached but ZFS lost track due to a kernel panic or reboot. Use zpool import -D to list all possible pools, then import with -f.

3. Disk appeared as different device name. On Linux, after a reboot, a disk might show as sdc instead of sdb. ZFS gets confused. Fix:

zpool replace poolname /dev/sdb /dev/sdc

Better yet, use persistent device IDs like /dev/disk/by-id/wwn-0x5000c500a1b2c3d4. Always use zpool status with -L to see these IDs.

Prevention

Stop this from happening again. Three things:

  • Use persistent device names. Every new disk, run ls -l /dev/disk/by-id/ and use that path when creating or importing a pool. No more /dev/sdb.
  • Check cables and power. Loose SATA cables are the #1 cause of missing VDEVs. Reseat them. If using hot-swap backplanes, test each slot.
  • Monitor pool health. Set up a cron job or script to email you on zpool status showing anything other than ONLINE. Simple script:
#!/bin/bash
zpool status -x | grep -q 'all pools are healthy' || mail -s 'ZFS Pool Alert' admin@example.com <(zpool status -v)

That script saved my ass more than once. Run it every 10 minutes.

Also: do regular scrubs. Run zpool scrub poolname monthly. It finds issues early. If you're on a production server, schedule it during low-usage hours.

That's it. You've got a degraded pool because a VDEV vanished. Fix is fast. Prevention is even faster. Go grab a coffee — your pool should be fine in a few minutes.

Was this solution helpful?