NAS hard drive sleeping and waking up after repeated failures? I spent the whole night checking logs, and only these few people secretly wrote down the tablets
first confirm whether the hard drive is sleeping, don't just look at the indicator light
The first step in
investigation is not to make up a mess, but to obtain evidence first. I have three homemade methods, each tougher than the last
| method | how to operate | reliability |
| listening and touching | at night listening to the motor sound while pressing close to the chassis, and sensing vibrations by touching the chassis and chassis | roughly, multi-drive machines can't tell who's checking status in the |
| backend | Feiniu checks the status in storage management, and Synology sees the status in storage manager | but only at the "now" moment |
| checking the start-stop count | SSH running SmartCTL, comparing the counts before sleep and in the morning | solid evidence, the number of times woken up at night was fully recorded |
the third method is key. Run this command after enabling SSH:
smartctl -a /dev/sdb | grep -iE "Start_Stop| Load_Cycle| Power_On"
Start_Stop_Count is motor start-stop count, Load_Cycle_Count is head return count. Count the numbers before bed, check again in the morning, and if both numbers increase, it means the hard drive was repeatedly woken up at night after sleeping; The number didn't budge at all, which meant it hadn't slept at all. That night, before sleeping, I recorded 1,867 start-stop cycles. When I woke up in the morning, I checked 1,912 start-stop cycles—45 start-stop times in one night, averaging every 20 minutes. This wasn't hibernation; it was the hard drive's night shift.
It's normal for
system drive to sleep, so first clarify which drive should be slept
many people go astray. To get straight to the point: it's normal for the system drive not to sleep, so don't waste time on it.
my N100 mini PC is equipped with Feiniu OS, a 256GB NVMe SSD running the system, and two 4TB Western Digital red drives as data drives. Feiniu's system logs, database, and Docker root directory are all on the solid-state, while the mechanical drive only has movies and backup files. Only in this structure can the mechanical drive sleep. If your system and data are crammed onto the same mechanical drive, and the system writes logs every few minutes, the drive basically stops going dormant. You either endure it or add a cheap solid-state drive to move the system away.
Synology users should know one more thing: DSM's system partitions are distributed across each disk, and when you write a system log, theoretically, it will touch all drives. That's why Synology's hibernation is notoriously hard to please, and the official forum is full of posts about "DS923+ sleep failure" all about this. It's not that you set it wrong, it's just that the architecture is like this. Move all the loads you can to move as much as you can; the rest depends on luck.
prime suspect: Docker containers, eight out of ten are them
qBittorrent, the real culprit of that night. Even if the download speed is 0 and no one is doing anything, it will flush the session file and the state of the session to the configuration directory every few minutes. When I first hung the configuration directory on the mechanical drive, this action woke the drive up every 5 minutes. Solution: Move the entire configuration and watch directories to the solid-drive, leaving only the download path for the mechanical drive—the disk is still awake during download, so there are no conflicts.
audio-visual services like
Jellyfin, check where the temporary directory for transcoding is listed. in my Jellyfin , if the transcoding path is written on a mechanical drive, the transcoding fragments will frantically write to the disk while watching videos—the drive is awake while watching, which is fine, but the real worry is someone setting the cache directory to the data drive and still running resident services.
monitoring container , Uptime Kuma, various dialing tools. Their historical data is an SQLite file, which is dropped every few minutes. The file wasn't large, but it was enough to wake up the plate that had just fallen asleep. Similarly, the mobile solid-state is also used.
Docker his own log. Every log the container writes to stdout is written by default to the Docker root directory of the host using the json-file driver. If your Docker root is on a mechanical drive, a chatterbox container can write to the drive endlessly. docker inspect container name, check which disk the path in LogConfig is on.
troubleshooting method is clumsy but effective: Docker PS gets the container list, stops half and half, waits 15 minutes after stopping each batch to check the disk status, and after two or three tries, it locks the container. I found the 15-minute wait too slow, so I just went straight to the next step on the iotop record.
Second Tier: indexing, scheduled tasks, and the system's own actions
Docker rule them out, then investigate these and rank them by suspicion:
photo album index . Synology's Synology Photos and Feiniu's album apps generate thumbnails and feature indexes in the background for several days after importing tens of thousands of photos. During this period, hard drive hibernation is out of the question—it's normal, and once it's running, it quiets down. How to check: Check if the index progress in the Album app is 100%.
Scheduled backup task . I use rsync to copy important directories the second disk every day at 2 a.m. backup strategy—the task itself is fine, but it wakes you up once a day, so it's reasonable to wake you up, so don't worry about it.
the SMART detection in the planning tasks. Synology has a regular SMART fast test by default, but many people don't know it exists. The SMART test requires the drive to be fully awake before testing, which means the system regularly shakes your hard drive to wake it up. Find it in the Control Panel or Task Planner, then either turn it off or reduce the frequency to once a month.
log rotation . Logrotate under /var/log is usually done at midnight with very small amounts and usually not the main cause, but under Synology's system partition and cross-drive architecture, it can affect all drives.
My Night: Using iotop to find the real culprit
all the above is a "suspect profile," and true conviction depends on catching someone in the act. Feiniu running SSH on root :
iotop -o -b -n 3 > /tmp/io.log
-o only shows processes that are actually read or written, while -b exits after three rounds. The problem is that writing is intermittent, and the three seconds you run might just be sleeping. I wrote a deadlock loop: one round every minute, output on solid-state state, and set it up before bed to close up in the morning:
while true; do date >> /tmp/io.log; iotop -o -b -n 2 >> /tmp/io.log; sleep 60; done
morning reviewing the log, the culprit was clear: starting at 1:17 AM, qBittorrent wrote small amounts of /vol1/docker/qbittorrent every 5 minutes; 3:02 AM is my own rsync backup routine; At 4:30, there was a log rotation on Dockerd. Nothing else—the album index had long been built, the Jellyfin transcoding directory was solid-state, and the monitoring container wasn't installed at all.
handle it in three steps: move the entire qBittorrent configuration directory to the solid-state Docker directory, rebuild the container (all data is in the mount directory, done in ten minutes); I accepted the rsync wake-up that time, which made sense; The log rotation is too small and ignores. The next night, I tested again. Start_Stop only rose three times overnight—once with rsync, twice with sporadic wake-ups that didn't detect, and 11W deep standby all night. That's what you call sleep.
fix it or not sleep? Some situations should be accepted
Finally, clarify "which projects are worth the hassle" so you don't get the hang of your life just to save a few kilowatt-hours of electricity:
| usage scenario | should you rely on hibernation | what to do |
| system disk (especially mechanical ones) | not to rely on | solidified state migration system, once and for all |
| pure warehouse disk (film/backup archiving) | the most valuable | sort through the above order, and you'll probably be able to sleep |
| downloader is always on the server for | little chance | just turn it off to hibernate, log it out, move it away, and then sleep on |
| surveillance tape | no chance | I put it into hibernation; writing 24/7 is my main job |
pour cold water on it again. Some people worry about hard drive lifespan when sleep fails. In fact, 3.5-inch mechanical drives are generally designed for start-stop cycles of about 50,000 cycles. Even if you do 40 times a night, that's only about 15,000 times a year. Plus, many Load_Cycle heads are rated for 600,000 resets. The real damage to the disc is high temperature and vibration, not this kind of light sleep or wakefulness. The electricity savings from a year of dormancy are just over 50 yuan according to the electricity bill. Staying up all night for it is worth it, but worrying about it every day is not worth it. Check it all over once: sleep if you can, don't sleep if you can, forget it—the hard drive is sturdier than you think.
