How to Check Disk Health for VPS Wey No Get SMART

VPS disk health monitoring fit actually see wetin

Disk health monitoring for VPS dey start with one fact wey most guides dey avoid: disk no be your own. Your guest dey see virtual block device. Physical drive, plus every counter wey dey stored for am, belong to host. smartctl /dev/vda no fail because you type command wrong. E fail because nothing behind that device fit answer the question.

SMART (self-monitoring, analysis and reporting technology) na table of counters wey dey kept for the drive itself: reallocated sectors, pending sectors, power-on hours, media errors. To read that table, ATA or NVMe (non-volatile memory express) commands need path reach real hardware. Paravirtual disk no provide that path, so guest get storage wey dem don remove the telemetry from.

Tenant dey monitor effects, not hardware. Four signals dey visible from inside guest: I/O (input/output) errors for kernel log, filesystem wey remount as read-only, latency wey dey gradually increase, and space wey don finish. You fit alert on all four today, and all four fit show before user complain. Set dem up first. Division of responsibility go come for the end, because e changes where you suppose put your effort.

Prove wetin your own server dey expose

No assume which case you dey. Check am first, then read the section wey match.

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk, the usual KVM (kernel-based virtual machine) disk. The device na /dev/vda and smartctl dey stop before e send anything:

/dev/vda: Unable to detect device type
Please specify device type with the -d option.

virtio-blk na paravirtual transport wey no get ATA or SCSI command set behind am, so no channel dey to carry SMART request. -d sat and -d scsi fail the same way, because na the transport be the problem, no be the flag.

An emulated SATA or SCSI disk. The device na /dev/sda and smartctl reach far enough to identify am. The model line dey read QEMU HARDDISK. That string answer the question by itself: you dey read device wey emulator create, and e report say usable SMART capability no dey.

An NVMe namespace. sudo nvme smart-log /dev/nvme0n1 return full log, and na there people dey get confused. Check the controller identity first with sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. If model number name network storage product, e mean say the controller na software, so percentage_used and media_errors describe that emulation, no be the flash wey hold your data. If you wan know wetin your storage really be, verify the NVMe disk for Linux instead of trusting the plan description.

A container, such as LXC (Linux containers) or OpenVZ. You no get block device wey belong to you. lsblk show the host devices or nothing at all, and smartctl dey get refused because the container no hold CAP_SYS_RAWIO:

Smartctl open device: /dev/sda failed: Permission denied

One warning about the case wey e work. If smartctl for VPS return full attribute table, read the serial number before you act on am. Some hosts expose passthrough device node, and those counters belong to hardware wey every tenant for that machine dey share. If Reallocated_Sector_Ct dey rise there, open support ticket. E no mean anything about your data.

Signal 1: I/O errors for kernel log

Na tenant get highest-value signal be this one, and e no need agent.

sudo journalctl -k -p err -b
sudo journalctl -k --since "7 days ago" | grep -iE 'i/o error|remount|ext4-fs error|buffer i/o'

Failed request from virtual disk fit look like this:

blk_update_request: I/O error, dev vda, sector 2101248 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

Block layer ask host to write, but host return failure. For VPS, this one rarely mean say flash cell don spoil. Most times, na host storage layer or network path go network attached storage dey cause am, so na provider-side event. Copy timestamp, device name, and sector put for your ticket, because storage team fit match dem with their own logs.

The ext4 sequence wey matter pass na this pair:

EXT4-fs error (device vda1): ext4_journal_check_start:83: comm cron: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

Na the second line dey cause serious problem, because machine still dey up. E still answer ping, e still answer SSH, but every write dey fail. Plain HTTP check still dey pass while your application dey throw error for every request.

XFS go shut filesystem down instead:

XFS (vda1): metadata I/O error in "xfs_trans_read_buf_map+0x1c0/0x2e0" at daddr 0x2 len 1 error 5
XFS (vda1): I/O Error Detected. Shutting down filesystem

journalctl -k dey read only current boot unless journal dey stored for disk, and many images ship with volatile journal wey dey live for RAM. Turn on persistence, otherwise the evidence go disappear exactly when you reboot while troubleshooting.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

After your next reboot, journalctl --list-boots suppose list more than one boot. Even when persistence dey on, filesystem wey don become read-only no fit record wetin happen next. Na this be the clear reason to ship logs go outside the box.

Signal 2: how to catch read-only remount

Make the failure loud before you try detect am.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Look for errors=remount-ro inside the options. Ubuntu and Debian cloud images dey set am for /etc/fstab, so metadata error go make filesystem turn read-only instead of continuing on top damage. If e dey miss, add am to root entry for /etc/fstab, or set am for superblock with sudo tune2fs -e remount-ro /dev/vda1. Loud stop better pass quiet corruption.

Mount flag no be proof. Test am by writing:

touch /var/tmp/.disk-probe

For read-only root, e go print exactly:

touch: cannot touch '/var/tmp/.disk-probe': Read-only file system

Use /var/tmp, no be /tmp. For most images, /tmp na tmpfs wey dey memory, so successful write there no prove anything about your disk.

Join the write test with space check, and send heartbeat only when every check pass:

sudo tee /usr/local/sbin/disk-probe >/dev/null <<'EOF'
#!/bin/sh
set -eu
probe=/var/tmp/.disk-probe
echo ok > "$probe"
test "$(cat "$probe")" = ok
rm -f "$probe"
used=$(df --output=pcent / | tail -n1 | tr -dc '0-9')
test "$used" -lt 90
inodes=$(df --output=ipcent / | tail -n1 | tr -dc '0-9')
test "$inodes" -lt 90
curl -fsS --max-time 10 "https://status.example.com/api/push/REPLACE_TOKEN?status=up&msg=OK" >/dev/null
EOF
sudo chmod 755 /usr/local/sbin/disk-probe
sudo /usr/local/sbin/disk-probe && echo probe-ok

probe-ok for that last line mean say the whole chain work. set -eu make any failed check exit non-zero before curl line run, so no heartbeat go out. Na this inversion matter: monitor go turn red because nothing arrive, and server wey no fit write no fit describe its own problem with trust. Reads still dey work for read-only filesystem, so the script still fit start.

Run am from a systemd timer.

# /etc/systemd/system/disk-probe.service
[Unit]
Description=Disk writability and space probe

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/disk-probe

# /etc/systemd/system/disk-probe.timer
[Unit]
Description=Run the disk probe every five minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now disk-probe.timer
systemctl list-timers disk-probe.timer
journalctl -u disk-probe.service -n 20 --no-pager

systemctl list-timers suppose show the unit with a NEXT time wey dey under five minutes away. Failed run go appear for journalctl -u disk-probe.service with shell own error text, so you fit tell read-only filesystem from full one without logging in.

That push URL na Uptime Kuma push monitor. Create monitor with type Push, copy its token enter the script, and set monitor heartbeat interval small longer than timer interval so one slow run no go page you for 03:00. If you never get status page, self-hosted Uptime Kuma instance na the cheapest place to put this check.

Two honest limits dey. The probe confirm say write was accepted, but e no confirm say bytes reach durable storage, because page cache fit serve the read back. And e dey run for the machine wey e dey watch, so fully wedged server go become silent instead of reporting diagnosis.

Latency and throughput trends

sudo apt install -y sysstat
iostat -xdz 5 3

First read r_await and w_await. Dem be the average milliseconds wey read or write take, including the time wey request spend waiting for queue. Then read aqu-sz, wey be the average number of requests wey dey in flight. Ignore %util for virtual disk: e only mean say queue no empty. Device wey dey serve plenty requests in parallel fit stay near 100 percent even when e never reach the limit. await na the number wey track wetin users dey feel.

Absolute values no matter pass your own baseline, so record one quiet hour and keep am. /proc/diskstats na the raw source if you prefer collect the counters by yourself.

For deliberate measurement:

sudo apt install -y fio
fio --name=readlat --filename=/var/tmp/fio.probe --size=512M --rw=randread --bs=4k --iodepth=1 --direct=1 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.probe

Read the clat percentiles block, especially the 99th. --direct=1 bypasses your page cache. E no bypass the host cache, so the result describe the full path from your process down to the platform storage. Run am when server dey idle, because e go compete with your own workload.

If await dey rise and kernel log show no errors, e usually no mean say drive dey fail. Na contention for host, the storage version of CPU steal time from noisy neighbour. If e dey return for the same hour every day and your ticket come back clean, the answer na plan wey I/O no dey share the same way. This na the case with storage VPS over regular VPS when workload dey disk bound.

Filesystem checks wey you fit run while filesystem dey mounted

ext4 dey keep error counter for superblock, and e dey survive reboot even when your logs no remain.

sudo dumpe2fs -h /dev/vda1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'

Healthy filesystem dey print Filesystem state: clean and FS Error count: 0. clean with errors and count wey no be zero mean say kernel don hit metadata error sometime, even if nobody notice and log don roll away. Make this one command dey part of weekly check.

You no fit run fsck for mounted root filesystem, and e2fsck -n for live filesystem dey report problems wey na only data wey dey change underneath am cause. To force real check, add fsck.mode=force fsck.repair=yes to kernel command line for one boot from your provider console. systemd-fsck go then run the check before root mount as read-write.

XFS no get online check. xfs_repair -n /dev/vda1 no gree run against mounted filesystem, so e belong for rescue mode. XFS compensate for this by making the problem clear: e dey shut down the filesystem when metadata error happen instead of continuing.

For Btrfs, the counters dey built in and dem dey persist.

sudo btrfs device stats /
sudo btrfs scrub start -B /

write_io_errs or corruption_errs wey pass zero na real event, and the counters go keep their values across reboots until you reset dem. scrub dey read every block again and verify the checksum, and na the closest thing to media test wey you get for virtual disk. E dey use plenty I/O, so schedule am for quiet hour.

Free space signal 5, including the parts df dey hide

Space finish fit break server just like bad disk, and e dey happen much more often.

df -h /
df -i /
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

No space left on device while df -h dey show free space means say na inodes finish, no be bytes, and df -i dey show IUse% for 100 percent. Millions of small files for cache directory or mail spool fit cause this, and deleting large files no go help.

Space wey no return after delete usually na deleted file wey running process still hold open. sudo lsof +L1 dey list files wey their link count don reach zero. Restart the process wey dey hold one to release the space.

The journal na common quiet space consumer. journalctl --disk-usage dey report wetin e hold. Limit am with SystemMaxUse=200M for /etc/systemd/journald.conf, then run sudo systemctl restart systemd-journald, and reclaim the space now with sudo journalctl --vacuum-size=200M.

One case fit look like bug, but e no be bug. For thin provisioned host storage, host pool fit fill up while your df still dey show free gigabytes. Your writes go then fail with I/O errors for kernel log, and no space warning go show anywhere inside the guest. Errors wey happen without full filesystem na combination wey worth opening ticket for that same hour.

Wiring the signals into a metrics agent

Push probe dey answer yes or no. You need metrics agent to see trends, and Prometheus node_exporter already dey export everything above without extra configuration. Na these metric names you go use build on:

• node_filesystem_readonly go 1 when mount turn read-only. Na this one be your remount alarm.
• node_filesystem_avail_bytes and node_filesystem_files_free cover bytes and inodes separately.
• node_disk_io_time_seconds_total and node_disk_read_time_seconds_total give busy time and latency as counters wey you fit graph.

Two rules dey catch the cases wey really need page:

- alert: FilesystemReadOnly
  expr: node_filesystem_readonly{fstype!~"tmpfs|overlay"} == 1
  for: 2m
- alert: FilesystemFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
  for: 30m

The second rule go fire when the current trend reach zero within four days. This one go warn you days ahead, instead of when storage don reach 95 percent full and you get only minutes.

Na Who Responsible for Wetin

Your provider own the physical drives. Dem read SMART, run the array, and replace drive wey reallocated sectors dey increase, usually without telling you, because the array dey absorb the failure. Na wetin RAID 10 under your VPS dey do: dead drive go become rebuild instead of outage. You no fit see any of this, and na to pay for this abstraction be one main reason people rent virtual server.

You own your data, and drive telemetry no go protect am anyway. The events wey really destroy tenant data na mistaken rm, bad deploy, intruder wey get your SSH key, and platform incident wey carry the array along. SMART attributes no fit predict any of dem.

So, tenant real protection na backup wey dey outside the server and restore wey you don perform yourself. Provider snapshots dey convenient, but dem dey on the same platform as the thing wey dem protect. Na why snapshots and backups na different protections. Put a drill for calendar: once every quarter, restore the newest backup into fresh VPS, start the application, and write down how long e take. That number na your real recovery time. The first drill always dey slower pass wetin anybody guess.

When SMART dey apply to you

Guides wey dey teach smartctl correct, and dem apply as soon as the hardware truly belong to you:

• A dedicated or bare metal server, where sudo smartctl -a /dev/sda dey return the complete attribute table and smartd fit send you mail when attribute change.
• Storage plans wey pass physical disk directly to the guest. Providers dey document this clearly because e na selling point.
• Hardware wey you own, for house or for rack space wey you rent.
• A disk behind RAID controller, wey you fit reach with sudo smartctl -a -d megaraid,0 /dev/sda, or USB enclosure with -d sat.

For real NVMe, sudo smartctl -a -d nvme /dev/nvme0 and sudo nvme smart-log /dev/nvme0n1 dey report critical_warning and percentage_used directly from the drive. For real SATA, the attributes wey dey predict failure na Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) and Reported_Uncorrect (187). If any of dem move from zero, start planning replacement. Large-scale drive studies keep reaching that same short list, and most other attributes na noise.

Run the daemon instead of checking by hand.

sudo systemctl enable --now smartd
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

The self-test log suppose show Completed without error for the run wey you just start. Ubuntu and Debian ship /etc/smartd.conf with a DEVICESCAN line, current as of August 2026, so the daemon go detect every disk wey e fit see and send root mail when something change. None of this go work for virtual disk, na why the rest of this guide dey here.

FAQ

Why smartctl no dey work for my VPS?

Because the disk na virtual. For KVM guest wey dey use virtio-blk, smartctl -a /dev/vda dey print /dev/vda: Unable to detect device type, because paravirtual disk no get ATA or SCSI command channel wey SMART request fit pass through. For emulated disk, you reach device wey model read QEMU HARDDISK, but no usable SMART data dey behind am. Inside container, smartctl dey refuse am outright because CAP_SYS_RAWIO no dey. None of these na misconfiguration, and no -d flag fit fix dem.

How I go know whether my VPS disk dey fail?

Monitor the effects instead of the hardware. Check sudo journalctl -k -p err -b for blk_update_request: I/O error lines and for Remounting filesystem read-only. Run sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' to find errors wey logs don already lose. Track r_await from iostat -xdz 5 against baseline wey you record when everything dey healthy. For VPS, I/O error normally mean host storage problem, no be drive wey dey spoil. So put am for support ticket together with timestamp and sector.

Wetin I suppose alert on for VPS disk health?

Four alerts fit cover am. Read-only mount from node_filesystem_readonly == 1 or write probe wey fail. Free space and free inodes wey dey move toward zero. Any kernel I/O error for the last interval. Heartbeat from the server, so silence go page you when the box stop answering. Skip anything wey come from SMART, because for virtual disk, those values either no dey or dem describe the hypervisor's emulation.

Why my filesystem remount read-only?

ext4 wey mount with errors=remount-ro dey do this deliberately when e hit metadata error. E stop writing instead of continuing over the damage. The trigger dey for kernel log just above the remount line, usually an EXT4-fs error about aborted journal after the underlying device return an I/O error. Remounting read-write without checking the filesystem go hide the symptom and preserve the cause. Capture the log, then check the filesystem while e unmounted from rescue mode with e2fsck -fy /dev/vda1.

I fit ever read SMART data for virtual server?

For specific cases, yes. Dedicated and bare metal servers give you real attributes. Storage plans wey pass physical disk through to the guest fit do the same, and any host wey you own yourself too. Some platforms present NVMe controller to the guest and nvme smart-log dey return a log, so run sudo nvme id-ctrl /dev/nvme0 first: model number wey name network storage service mean say those counters come from software controller. And where passthrough node expose real counters for shared machine, dem describe hardware wey other tenants dey share. So the only useful action na support ticket.