Synology’s health check missed 9527 errors on the drive, which I only found by direct querying.

My first NAS was an unfamiliar device to me. I accidentally won it, and for the first two years it sat in my storage room because I was a sophomore living in the dorms. After graduating and returning home, I started using it.

For years it was just used for volume storage, as it was a weak two-bay DS218j NAS. But last week an online article led me to check the SMART data of my drive. Synology’s DSM only showed me a healthy state, but I wanted to see what led to that verdict.

What the Synology dashboard will show you

Every screen says healthy, and none of them say why

I’m not an expert in disk and storage technology, but since I have several storage devices, I keep an eye on the news. Last week I read about hard drive research, which led me to examine hard drive data as well. My old Synology NAS has only one Toshiba HDD installed.

I think if you are familiar with NAS and storage devices, you are already familiar with SMART. If not, every modern drive has a built-in monitoring system called Self-Monitoring, Analysis and Reporting Technology, or SMART.

As usual, I opened the DSM to check the stats, hoping that the Synology would give me the information I needed. More specifically, I was looking Five SMART attributes of Backblaze — 5, 187, 188, 197 and 198.

• 5 – redistributed_sector_CT,

• 187 – reported_uncorrectable_errors,

• 188 – Command_Timeout,

• 197 current_pending_sector,

• 198 – Offline_Correctable.

Together, they include remapped sectors, unreadable data, command problems, and pending/uncorrectable sectors, and Backblaze uses them to flag failed drives. In Storage Manager, the overview page showed only a green icon with a healthy sign. Nothing else. Then I went to the HDD/SSD section and checked the HDD health information. Again the health information window didn’t give me anything important, just basic information.

The overview tab showed me a record of 36°C and 29336 hours on. The SMART tab offered quick and advanced tests and the final test result showed a healthy state. Finally, the History tab, which has nothing. I even tried a quick test, but the results varied.

I was expecting five Backblaze attributes, but Synology didn’t reveal any of them and gave a simple sign that my drive was OK. But I didn’t want to stop there and take Sinology’s word for it. So I stopped looking for the DSM GUI and started looking for the SMART data underneath.

What the disk reports when you ask directly

Three are pure numbers and two are not

Since the DSM diagnostics proved useless, the next obvious thing was to ask the disc to give me these numbers. I enabled SSH access to the NAS via port 22, connected to it via Termius and started smartctl -d sat -A /dev/sdb.

Starting with the good news, it turns out that my Toshiba drive only reported 5, 197, and 198 of the five Backblaze attributes, and they were all clean. The baseline values ​​reported for all three were 0. Maybe that’s why DSM looked healthy on the dashboard.

But there is a catch. The reported THRESH value for SMART 5 was 5 and the RAW_VALUE report was 0, so it is clean with no remapped sectors. The calculated THRESH value for SMART 197 and 198 was 0. This means that drives 197 and 198 never clear their fault flag. Anyway, the seller labeled them both as aging indicators (Old_age), so I didn’t dig deep.

The two attributes that the drive did not report were 187 and 188. It wasn’t something the DSM was hiding. As far as I can tell, this particular Toshiba drive doesn’t add them to the SMART table. Both of those were important pointers, but since they’re not at all, I’ll leave them out.

I started looking for five Backblaze attributes. I found three of them and none of them gave me great results. But looking at the full SMART table, I found another attribute that was strange.

One number that scared me

9,527 errors, not a single error in 25,000 hours

Another completely different attribute was the SMART 199 when looking at the full SMART table. The table reported it as UDMA_CRC_Error_Count. It wasn’t one of Backblaze’s five, but it looked really scary. The reported cost of raw materials was 9,527.

After some quick research, what I understand is that this is a report when the drive executes a command and returns with an error. Thus, the number of errors was 9,527, and the log only stores the last five of them with their respective running hours. These five errors appear to be interface CRC (ICRC) errors, usually checksum failures on the cable. And the highest numbered bug (#9527) was the most recent and occurred at 4312 on-hours.

I remember seeing my drive’s on clocks in DSM; I quickly went to the Storage Manager to match them. Recorded power-on hours were 29,339. This means that the last reported error occurred about 25,000 operating hours ago and has not occurred since then. At the time, the scary number was less of a concern, as the report became history instead of a living bug.

I expected DSM to give me detailed statistics of my hard drive, but it only gave me one word: “Health”. It didn’t show the five Backblaze attributes, nor the 199 counters it took directly from the disk from the SMART table. If DSM had tracked these errors over time, I could have rebuilt when the other 9522 errors occurred.

Drive passed, I’m still not sure

It was just one drive, one 6-year-old NAS, and one snapshot of its SMART data. Even if the reported Backblaze SMART attributes look good and the DSM shows a healthy sign, it does not mean that the drive is in good condition and will never fail. I know my car. I know I am old enough to retire. But the attributes say otherwise. So SMART data is useful, but it shouldn’t be the only data to consider as the final deciding factor.