# How to Check SSD Health in Linux
SSD and NVMe drives are extremely reliable, but like any storage device, they can eventually develop problems. On a Linux server, regularly checking SSD health can help you identify increasing wear, overheating, media errors, or RAID problems before they cause unexpected downtime or data loss.
Linux provides several useful tools for checking storage devices. In this guide, we will cover how to identify your SSD, check SMART health information, monitor NVMe drives, check Linux software RAID, and perform additional storage checks.
> **Important:** Always make sure you have a current backup before performing filesystem or RAID maintenance.
## 1. Identify Your SSD or NVMe Drive
The first step is to determine which storage devices are installed and how Linux identifies them.
Run:
“`bash
lsblk
“`
For more useful information, including the device name and serial number:
“`bash
lsblk -o NAME,SERIAL
“`
Example:
“`text
NAME SERIAL
sda S6XXXXXXXXXXXX
├─sda1
└─sda2
nvme0n1 S5XXXXXXXXXXXX
├─nvme0n1p1
└─nvme0n1p2
“`
This is particularly useful on servers containing multiple SSDs because you can match the Linux device name with the physical drive’s serial number.
For more detailed information:
“`bash
lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINT
“`
This can show something like:
“`text
NAME MODEL SERIAL SIZE TYPE FSTYPE MOUNTPOINT
sda Samsung SSD 870 EVO S6ABC123 1.8T disk
nvme0n1 Samsung SSD 970 EVO S5XYZ789 1.8T disk
“`
## 2. Install smartmontools
The `smartctl` command is part of the `smartmontools` package.
On RHEL, AlmaLinux, Rocky Linux, and similar distributions:
“`bash
dnf install smartmontools
“`
On older systems using `yum`:
“`bash
yum install smartmontools
“`
On Debian or Ubuntu:
“`bash
apt install smartmontools
“`
Check the installed version:
“`bash
smartctl –version
“`
## 3. Check the Basic SSD SMART Health
For a SATA SSD, use:
“`bash
smartctl -a /dev/sda
“`
Replace `/dev/sda` with the correct drive.
The command displays information such as:
* Drive model
* Serial number
* Firmware version
* Power-on hours
* Temperature
* Total data written
* Total data read
* SSD wear
* Reallocated sectors
* Uncorrectable errors
* SMART health status
Look for:
“`text
SMART overall-health self-assessment test result: PASSED
“`
A `PASSED` result is a good sign, but it does not mean you should ignore all other SMART values. A drive can still have warning signs even when the overall SMART result says `PASSED`.
## 4. Check SSD Wear and Percentage Used
Modern SSDs normally provide a health or endurance indicator.
For example, an NVMe drive may report:
“`text
Percentage Used: 18%
“`
This generally means the controller estimates that approximately 18% of the drive’s rated endurance has been consumed.
A lower percentage is generally better.
Also check:
“`text
Available Spare: 100%
Available Spare Threshold: 10%
“`
An available spare of 100% is a healthy result.
The exact SMART attributes differ between manufacturers, so avoid comparing individual SMART attribute numbers between different SSD models without checking the manufacturer’s documentation.
## 5. Check SSD Temperature
Temperature is particularly important for NVMe SSDs because high temperatures can cause thermal throttling and may reduce performance.
For an NVMe drive:
“`bash
smartctl -a /dev/nvme0
“`
Look for:
“`text
Temperature: 45 Celsius
“`
Some drives also report multiple temperature sensors:
“`text
Temperature Sensor 1: 45 Celsius
Temperature Sensor 2: 47 Celsius
“`
The exact acceptable temperature depends on the SSD model and workload.
For a server, it is a good idea to monitor temperatures regularly, especially when the SSD is handling heavy database, backup, virtualization, or hosting workloads.
## 6. Check an NVMe SSD Directly
NVMe drives normally appear as:
“`text
/dev/nvme0
“`
or:
“`text
/dev/nvme0n1
“`
For SMART information, use the NVMe controller:
“`bash
smartctl -a /dev/nvme0
“`
You can also use the Linux NVMe utility.
Install it on RHEL-based systems with:
“`bash
dnf install nvme-cli
“`
Then run:
“`bash
nvme list
“`
This displays the installed NVMe devices.
For example:
“`text
Node SN Model
/dev/nvme0n1 S5XXXXXXXX Samsung SSD 970 EVO Plus 2TB
“`
To view the NVMe health log:
“`bash
nvme smart-log /dev/nvme0
“`
Important values include:
“`text
critical_warning
temperature
available_spare
percentage_used
data_units_read
data_units_written
power_cycles
power_on_hours
unsafe_shutdowns
media_errors
num_err_log_entries
“`
## 7. Pay Attention to Media Errors
One of the most important NVMe values is:
“`text
Media and Data Integrity Errors
“`
Ideally, this should be:
“`text
Media and Data Integrity Errors: 0
“`
An increasing number of media/data integrity errors deserves investigation.
Do not automatically replace a drive because of every entry in the NVMe error log, however. Some error-log entries can be caused by software or unsupported commands rather than physical NAND failure.
For example:
“`text
Error Information Log Entries: 92
“`
is not automatically equivalent to 92 bad sectors or 92 hardware failures.
You should examine the actual error type.
## 8. Examine the NVMe Error Log
You can view the NVMe error log with:
“`bash
nvme error-log /dev/nvme0
“`
Or with:
“`bash
smartctl -x /dev/nvme0
“`
An error such as:
“`text
Invalid Field in Command
“`
can indicate that software sent a command or parameter that the controller did not accept.
This is different from errors indicating data corruption or media failure.
When investigating an SSD problem, look at the complete picture:
* Media errors
* Data integrity errors
* Critical warnings
* Available spare
* Percentage used
* Temperature
* Kernel messages
* Filesystem errors
* RAID status
## 9. Check Linux Kernel Messages
Linux kernel logs can reveal storage problems that SMART alone may not show.
Search for SATA or SCSI-related errors:
“`bash
dmesg | grep -iE ‘error|fail|ata|scsi’
“`
For NVMe:
“`bash
dmesg | grep -i nvme
“`
On systems using systemd, you can also check:
“`bash
journalctl -k | grep -iE ‘error|fail|nvme|ata|scsi’
“`
Look for messages involving:
* I/O errors
* Controller resets
* Timeouts
* Link failures
* Filesystem errors
* NVMe resets
* Device disconnects
Repeated I/O errors should be investigated immediately.
## 10. Check Linux Software RAID
If your Linux server uses software RAID, checking the physical SSDs is not enough. You also need to check the RAID array itself.
For Linux MD RAID, run:
“`bash
cat /proc/mdstat
“`
A healthy RAID array might look similar to:
“`text
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
1953381376 blocks super 1.2 [2/2] [UU]
“`
The important part is:
“`text
[UU]
“`
For a two-drive RAID1 array, `[UU]` means both members are online.
If you see:
“`text
[U_]
“`
one member is missing or failed.
For a RAID5 array, you might see:
“`text
[UUU]
“`
meaning all three members are currently active.
## 11. Get Detailed RAID Information
Use:
“`bash
mdadm –detail /dev/md0
“`
Replace `/dev/md0` with your actual array.
Example:
“`text
/dev/md0:
Version : 1.2
Raid Device : raid1
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
“`
The values you want to see include:
“`text
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
“`
The exact output depends on the RAID level and configuration.
## 12. Check for a RAID Rebuild
After replacing a failed drive, Linux may rebuild the RAID array.
Check:
“`bash
cat /proc/mdstat
“`
You may see:
“`text
[>………………..] recovery = 5.2%
“`
or:
“`text
rebuild = 25.4%
“`
During a rebuild, disk performance can be affected.
Do not remove or disconnect another RAID member during a rebuild unless you fully understand the consequences.
## 13. Check RAID Member Devices
You should also identify which physical drives belong to the RAID array.
Run:
“`bash
mdadm –detail /dev/md0
“`
Then match the devices with:
“`bash
lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE
“`
This is extremely useful when replacing a failed SSD.
For example:
“`text
/dev/sda Samsung SSD 870 EVO S6ABC123
/dev/sdb Samsung SSD 870 EVO S6XYZ789
“`
Knowing the serial number helps prevent accidentally removing the wrong physical drive.
## 14. Check Filesystem Health
SMART checks the physical storage device, while filesystem tools check the filesystem structure.
For an XFS filesystem, you can use:
“`bash
xfs_info /mountpoint
“`
For ext4, filesystem checks are performed using:
“`bash
fsck
“`
However, **do not run a repair filesystem check on a mounted production filesystem unless you know it is safe to do so**.
For example, an ext4 filesystem generally needs to be unmounted before running a repair:
“`bash
fsck -f /dev/sda1
“`
On a production server, schedule filesystem checks during appropriate maintenance periods.
## 15. Check Disk Usage
A completely full filesystem can cause problems that may look like storage failures.
Check filesystem usage:
“`bash
df -h
“`
For inode usage:
“`bash
df -i
“`
For example:
“`text
Filesystem Size Used Avail Use% Mounted on
/dev/md0 1.8T 1.2T 600G 67% /
“`
Also check whether any individual directory is consuming excessive space:
“`bash
du -sh /* 2>/dev/null
“`
For a hosting server, also pay attention to `/var`, `/home`, `/backup`, and other directories depending on your configuration.
## 16. Check SSD Performance
Health information tells you about the condition of the drive, but performance testing can help identify unusual slowdowns.
For basic sequential performance testing, tools such as `fio` can be used.
However, **be careful with disk benchmarking on production servers**.
Some benchmark commands can generate large amounts of I/O and may affect live websites, databases, backups, or virtual machines.
Never blindly run destructive `fio` commands against a production device.
## 17. Run an SSD Self-Test
Some SATA drives support SMART self-tests.
First check:
“`bash
smartctl -c /dev/sda
“`
If supported, a short test can be started with:
“`bash
smartctl -t short /dev/sda
“`
After the test completes:
“`bash
smartctl -a /dev/sda
“`
For a long test:
“`bash
smartctl -t long /dev/sda
“`
A long test can take considerably longer depending on the drive.
Always check the manufacturer’s documentation and consider the workload of a production server before running extended diagnostics.
## 18. A Useful SSD Health Checklist
For routine Linux server monitoring, check the following:
### Physical SSD
“`bash
lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE
“`
### SATA SMART
“`bash
smartctl -a /dev/sda
“`
### NVMe SMART
“`bash
smartctl -a /dev/nvme0
“`
### NVMe health
“`bash
nvme smart-log /dev/nvme0
“`
### NVMe devices
“`bash
nvme list
“`
### Linux RAID
“`bash
cat /proc/mdstat
“`
### Detailed RAID information
“`bash
mdadm –detail /dev/md0
“`
### Kernel storage messages
“`bash
dmesg | grep -iE ‘error|fail|nvme|ata|scsi’
“`
### Filesystem usage
“`bash
df -h
“`
### Inode usage
“`bash
df -i
“`
## 19. When Should You Consider Replacing an SSD?
Consider replacing or investigating an SSD when you see one or more of the following:
* Increasing media/data integrity errors
* Critical SMART warnings
* Very high SSD wear
* Available spare approaching its threshold
* Repeated I/O errors
* Frequent NVMe controller resets
* Repeated filesystem corruption
* Drive disappearing from the operating system
* Persistent SMART self-test failures
* Unusual and persistent performance degradation
* RAID repeatedly reporting the drive as failed
Do not rely on a single SMART value. A drive reporting `PASSED` can still have other warning signs.
Likewise, an error-log entry does not automatically mean that the physical SSD is failing.
## 20. Example: Complete SSD Health Check
For a server containing an NVMe SSD, you could start with:
“`bash
lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINT
“`
Then:
“`bash
smartctl -x /dev/nvme0
“`
Next:
“`bash
nvme list
“`
Then:
“`bash
nvme smart-log /dev/nvme0
“`
Check the kernel:
“`bash
dmesg | grep -i nvme
“`
And if Linux software RAID is being used:
“`bash
cat /proc/mdstat
“`
Finally:
“`bash
mdadm –detail /dev/md0
“`
This gives you a much better picture than checking only whether SMART says `PASSED`.
# Final Thoughts
Regular SSD health monitoring is especially important on Linux servers where storage failure can affect websites, databases, email, backups, virtual machines, and other services.
The combination of `lsblk`, `smartctl`, `nvme-cli`, `mdadm`, `dmesg`, and filesystem tools provides a powerful set of diagnostics without requiring expensive monitoring software.
For production servers, make SSD health checks part of your regular maintenance routine. Most importantly, **SSD health monitoring should never replace a proper backup strategy**. RAID can protect against some hardware failures, but RAID is not a backup.
A good monitoring routine should track **SSD wear, temperature, media errors, RAID status, filesystem health, and kernel I/O errors over time** rather than checking the drive only after a problem occurs.