A noisy disk is obvious. A disk that is quietly accumulating errors is not. Before a maintenance window, check what the kernel and the drive itself are reporting.
First identify the actual devices. Do not assume that sda is the disk you
intend to inspect:
1lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,MOUNTPOINTS
Then review recent kernel messages for storage errors:
1journalctl -k -p warning..alert --since "7 days ago"
For a SATA or SAS drive with SMART support, request the full report:
1sudo smartctl --all /dev/sda
For NVMe, use the device's SMART log:
1sudo nvme smart-log /dev/nvme0
Do not reduce the report to a single “PASSED” line. Look for media errors, uncorrectable errors, rapidly increasing error counters, critical warnings, and temperature problems. Raw values are vendor-specific, so compare them with the device documentation and with earlier observations from the same drive.
If the device supports self-tests and the data is already protected, schedule a short test and read the result afterward:
1sudo smartctl --test=short /dev/sda
2sudo smartctl --log=selftest /dev/sda
The first command normally returns an estimated completion time. Do not power off the host mid-test, and do not start a long test blindly on a busy production disk.
This check does not predict every failure and does not replace monitoring or a tested backup. Its purpose is narrower: catch visible warning signs before a reboot, upgrade, or storage migration adds stress. If the output is suspicious, preserve the data first and investigate second.