For Synology and QNAP, under normal circumstances, it is impossible to achieve the ideal state of accessing the data of a hard disk, where only the hard disk itself works, while other unrelated hard disks remain in sleep mode. Because by default, both products use raid1 technology to write critical system data to all hard disks at the same time, which will cause all hard disks to wake up when there is reading or writing. The prerequisite for solving this problem is to insert only one hard disk (preferably SSD) when initializing the nas, and then insert other data hard disks after the system is fully installed (so that all apps will only be installed and run on the SSD, so at least the operation of the system and the working factors of these apps will no longer affect other data hard disks.
Secondly, use the mdadm command to process the data hard disk. Because even if the system is installed on the SSD first, when adding data hard disks to the NAS later, Synology and QNAP will still add multiple raid1s to these hard disks to store some key data. Therefore, if you want to hibernate in an ideal state, you need to remove each data hard disk from the raid1. However, due to security considerations, you need to add the hard disk back to each raid1 briefly every day to synchronize data. For details, please refer to the actual steps below.
Note: This article only talks about Synology. Some bloggers have written very detailed tutorials on how to set up QNAP. You can search for it yourself.
First, log in to the Synology system via ssh. I don’t need to explain in detail how to ssh.
Switch to root user after ssh
sudo -iUse Commands
cat /proc/mdstatCheck how many MDs (MD stands for raid1) there are and which hard disks are used. The following picture shows my black Synology:
There are 4 raid0s here: md0, md1, md2, and md3. md0 and md1 use all hard disks, while md3 only uses 4 mechanical hard disks. md2 corresponds to the disk where the system is located. Since we recommended only inserting SSD during initialization, there is only sdf3 here.
Note: In this article, sdf refers to the SSD solid state drive, and 3 refers to the third partition of the solid state drive.
First check md0 and md1, which are similar to qnap's md9 and md13
mdadm -D /dev/md0
As can be seen from the above figure, md0 contains 4 data hard disks, namely sda, sdb, sdc and sdd, plus sdf1. 1 is the serial number of the partitions of each hard disk in this md, and the rest are similar.
mdadm -D /dev/md1
md1 also contains four data hard disks, namely sda2, sdb2, sdc2 and sdd2, plus sdf2.
mdadm -D /dev/md3
md3 only contains 4 data hard disks, namely sda, sdb, sdc and sdd. So our next goal is also clear, which is md0 and md1, because these two raids contain both data disks and system solid-state disks. So if the system reads and writes data, the 4 data disks will inevitably be awakened. Separating the 4 data disks from md0 and md1 is what we have to do next. But for everyone's own Synology system, how to distinguish which are solid-state disks and which are HDD data disks? (Why do I say HDD data disk? The local tyrants use SSD as data disk, and they will directly ask, why do they need to hibernate?) Use
parted /dev/sd(#) printThe command can find out which are HDD data disks and which are SSD hard disks. To achieve the ideal method we mentioned earlier, why do we need to install the system only on SSD? Because the disk where the system is installed must be running all the time and cannot be put to sleep. The others are HDD data disks that need to be put to sleep, so it is a prerequisite to distinguish them clearly.
parted /dev/sdf print
parted /dev/sda print
You can see that my sdf is the system solid state drive, and the other a, d, c, and b are all HDD hard disks, which are our targets. Start the operation. Use the following command to set the corresponding partitions of sda1, sdb1, sdc1, and sdd1 of md0 to fail:
mdadm /dev/md0 -f /dev/sda1 mdadm /dev/md0 -f /dev/sdb1 mdadm /dev/md0 -f /dev/sdc1 mdadm /dev/md0 -f /dev/sdd1Then re-run
mdadm -D /dev/md0
From the above figure, we can see that after running the command, the status of sda1, sdb1, sdc1, and sdd1 are all displayed as faulty. Similarly, perform the same operation on sda2, sdb2, sdc2, and sdd2 of md1:
mdadm /dev/md1 -f /dev/sda2 mdadm /dev/md1 -f /dev/sdb2 mdadm /dev/md1 -f /dev/sdc2 mdadm /dev/md1 -f /dev/sdd2Then re-run
mdadm -D /dev/md1
After running the command, the status of sda2, sdb2, sdc2, and sdd2 are also displayed as faulty
Next, set the 4 hard disks to sleep for 10 minutes respectively:
hdparm -S 120 /dev/sda hdparm -S 120 /dev/sdb hdparm -S 120 /dev/sdc hdparm -S 120 /dev/sddNote: The 120 here does not mean 120 seconds. The -S parameter of the hdparm command specifies the number of 5 seconds, because 120 * 5 = 600 seconds (10 minutes). So running this command requires a simple conversion, which I believe anyone who knows how to use a calculator can do.
After waiting for 10 minutes, check the HDD status to see if it is successful:
hdparm -C /dev/sda | grep state
success!
Here we need to talk about Black and White Synology separately. White Synology is the same as QNAP. Every time you start the computer, all mds will be restored to the initial state. Therefore, every time you shut down and restart the computer, you need to re-run the script to disconnect the HDD hard disk from md0 and md1. The script name is: disconnect_md. At the same time, you need to run the command to put the hard disk to sleep. The script name is: hdd_sleep.sh. Therefore, the recommended practice is to set these two scripts to run automatically at startup. Black Synology is different from White Synology. Restarting will not restore the status of md0 and md1, so you don’t need to run the startup script disconnect_md like White Synology, but you still need to run the script hdd_sleep.sh automatically.
Note: Originally, after -f is detached, there is also -r to delete it directly from the array. However, after my test, I found that as long as -f is detached, the mechanical hard disk can be hibernated, so there is no need to delete it with -r. Moreover, after deleting with -r, I restarted Black Synology and found that the JBOD composed of 4 mechanical hard disks had problems. Therefore, it is dangerous and it is recommended not to delete it.
Considering that the hard disk array status needs to be restored regularly every day so that the system can write system data, regardless of whether it is black or white Synology, the HDD hard disk array status needs to be restored regularly every day so that the system can write data, the script name is: rebulid_md.sh, and then disconnected after a period of time, the script name is: disconnect_md.sh. So here a total of 3 scripts are needed: hdd_sleep.sh, disconnect_md.sh, rebulid_md.sh.
vim /volume1/@userpreference/admin/rebulid_md.sh(Please make sure to confirm the specific path of your nas user) The script content is as follows:
#!/bin/bash echo Re-adding md0 mdadm /dev/md0 --re-add /dev/sda1 mdadm /dev/md0 --re-add /dev/sdb1 mdadm /dev/md0 --re-add / dev/sdc1 mdadm /dev/md0 --re-add /dev/sdd1 echo Re-adding md1 mdadm /dev/md1 --re-add /dev/sda2 mdadm /dev/md1 --re-add /dev/sdb2 mdadm /dev/md1 --re-add /dev/sdc2 mdadm /dev/md1 --re-add /dev/sdd2vim /volume1/@userpreference/admin/disconnect_md.shThe script content is as follows:
#!/bin/bash echo Disconnecting md0 mdadm /dev/md0 --fail /dev/sda1 mdadm /dev/md0 --fail /dev/sdb1 mdadm /dev/md0 --fail /dev/sdc1 mdadm /dev/md0 --fail /dev/sdd1 echo Disconnecting md1 mdadm /dev/md1 --fail /dev/sda2 mdadm /dev/md1 --fail /dev/sdb2 mdadm /dev/md1 --fail /dev/sdc2 mdadm /dev/ md1 --fail /dev/sdd2vim /volume1/@userpreference/admin/hdd_sleep.shThe script content is as follows:
hdparm -S 120 /dev/sda hdparm -S 120 /dev/sdb hdparm -S 120 /dev/sdc hdparm -S 120 /dev/sddDon't forget to give the script execution permissions:
chmod +x /volume1/@userpreference/admin/rebulid_md.sh chmod +x /volume1/@userpreference/admin/disconnect_md.sh chmod +x /volume1/@userpreference/admin/hdd_sleep.shThen run it at a scheduled time every day (I set it to run rebuild_md.sh at 19:30 and disconnect_md.sh at 20:00. You can modify it according to your actual situation):
Similarly, create the disconnect_md.sh script schedule task:
hdd_sleep is a bit different and is a triggered task:
From then on, the mission was accomplished.
照做完全成功，12盘日常待机140w，休眠后，功率下降到75w，关键是休眠能大大减轻硬盘负担，感谢楼主无私分享！全网最详细说的最明白的一个教程了，虽然有一点点瑕疵就是无法访问系统分区的提醒，感觉群晖思维很僵化，完全可以学习truenas一样，系统盘单独设置出来，或者把boot分区的选择交给用户，企业级的产品其实还是挺在意电费吧。
p.s. sleep脚本貌似也得root用户运行吧，admin用户好像无法运行。
对，肯定要root啊。不过，我虽然是以黑群晖来写得，但是我实际使用的是qnap(也做了类似的处理)，折腾了半天黑群晖，结果现在基本都没用了～。
还有个小问题，不知道大佬遇到没有，我这机器总是自动后台唤醒，就是休眠会成功，但是维持不了多久，就会唤醒。
你最开始安装系统的时候是不是只插的系统盘安装？我记得文章里说过，如果你是插上所有盘安装的系统，就相当于每个盘上都有系统代码，肯定会动不动就自动唤醒的。
安装时候没插HDD，昨天刚插的新HDD，安装系统时侯就是两个虚拟硬盘，这个让我我很困惑，现在来上班登不了SSH，回去我具体查看一下唤醒日志。
大佬，还有个小问题，rebuild_md.sh的脚本，为啥我现在一执行就提示：
bash /volume1/@userpreference/admin/rebulid_md.sh
Re-adding md0
mdadm: –re-add for /dev/sata1p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata2p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata3p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata4p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata5p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata6p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata7p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata8p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata9p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata10p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata11p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata12p1 to /dev/md0 is not possible
Re-adding md1
mdadm: –re-add for /dev/sata1p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata2p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata3p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata4p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata5p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata6p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata7p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata8p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata9p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata10p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata11p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata12p2 to /dev/md1 is not possible
全都是not possible，权限设置了，然后这个系统分区却可以在系统点修复进行恢复，这是系统暗改了么。
你这个设备路径有点奇怪啊，都是”/dev/sataxp?”，我这边正常是”/dev/sdx”这种形式,你之前说过什么虚拟盘，会不会这方面有啥问题？
我这个不知道为啥，用
cat /proc/mdstat命令查看的设备路径就是sataX，估计因为我用的是pve虚拟机直通的原因吧，不过这个应该不重要，目前倒是能休眠，大不了每天我手动同步一下阵列数据就好。I also have QNAP and Synology White, QNAP hddstandby is very mature. White skirt is not perfect, timed on and off.
The white group isn’t perfect either, I thought it was just a black group, luckily my main player is QNAP.
The blogger's method is very good, but it will cause the storage to prompt that the system partition cannot be accessed. Is there any way to block this?
Indeed, I will get a prompt as well. In fact, I usually use QNAP as my main computer, and after similar operations, it can sleep normally without any prompt. I wrote this article because I saw that no one in Synology seemed to have written this at the time. However, I only have the black Synology, and QNAP is not quite the same as the black Synology I have when booting. I am not sure if it is a problem with the black Synology, and I am not sure if there is this problem on the white Synology. In addition, it is not the main computer that needs to be turned on 24 hours a day, so I did not spend energy to study it. I can confirm that it does not affect the use, but it looks a bit uncomfortable.