I've checked and I've got the version 0.13, which works. Honestly I don't know.
Install fatrace and use this command
nohup fatrace -t -o /path/to/a/log.log &
Specify a log location on the system drive which is not supposed to sleep and run the command.
It will run in the background; let it run for some hours without using the server.
Then kill the process and open the file.
Fatrace will record every access including system drive. Filter HDDs entries that start with /srv/dev-disk-by-label: you will see what files have been accessed and you'll guess which service accessed them.
And how can I track down that service?
It can be challenging and you'll need third party tools.
How many disks do you have and where OMV is installed? What apps/docker/plugins have you installed?
Note this is out of scope of the thread/guide.
Hi, Sorry to ask a dumb question but do SSD's need to be spun down?
No, they don't and simply don't have such feature, so don't worry about them.
Everything looks good. If your drives don't spin down means some service is using them.
I've followed your guide, but none happened unfortunately. Can you pls help solve this annoying issue?
System: rock 64 Transformer, OMV5.5
I've followed your guide step by step. However, the log doesn't seem to be created, so I can't even tell what's causing all this
Can you show the hd-idle configuration?
Also run this command and show the output: service hd-idle status
Thanks for your answer.
I still have to think about how to set up a proper redundancy for data safety. SnapRAID sounds really interesting. However it still occupies a full hard drive. As most of my data is not backup-worthy I feel like this might still exceed my needs. I was thinking about occasionally copying the important files (private photos & documents) to an external hard drive, which could then be unmounted (or powered off via a smart plug). This would reduce power consumption and make it save against a theoretical total system failure, am I right?
This is what you always think at the beginning, but you can't predict hardware failures, you can only prevent them.
An external hard drive is a good backup solution, this is what I use to make my first backup and manually connect it once a week.
Onboard and dedicated Intel CPU use virtually the same power when idle, which is most of the time of a home server. The difference would be seen under heavy load.
I don't like the lack of expandability as well, but Intel is bad and changes CPU socket every generation or so, so when you will want to upgrade you'll have to change the motherboard anyway.
I would still buy a separate CPU and motherboard, because you have more freedom on the features you need.
RAID might not be necessary, but redundancy is!!!
The build makes sense. Cost effective yet powerful (x86-64) if you want to run some stuff.
I would not buy a passive cooler, I recommend the one I used in my build, it's pretty effective and silent.
Small PSU don't make sense if you want to use many drives, which this case can have. Check how many SATA ports has the BeQuiet.
ECC is very expensive and is not worth for a home user IMHO.
If you'd like to use SnapRAID instead of standard RAID, you can take advantage of two technologies which mitigate the lack of ECC: periodic check of existing parity data and re-hash of the data during parity calculations. Additionally don't forget to make backups and keep them offline.
ECC is unofficially supported by AMD systems. I really like AMD CPUs but based on motherboard/CPU availability you'd might be better stick with Intel and no ECC.
but isn't the CPU kind of an overkill for that purpose?
I wanted a decent CPU for a fast system.
Moreover I use Plex transcoding (sometimes) and Handbrake to encode movies. These tasks are heavy on resources and also use Intel's GPU.
What is the reason that you split your boot drive (USB) and the docker & downloads (NVMe SSD)?
Just because when you install OMV it needs to format the whole drive.
I wanted something clean and separate apps from OS, but you could use a SSD and make two partitions after install.
Hi, automatic recycling was not working during my trials with a test-smb-share.
Have you turned off you server or was always running? My server is not on all day, and apparently this might be one the causes.
Thanks for testing though.
Hi, as a side note, can you let me know if automatic recycling works on your side?
Me and someone else are facing the issue that this feature does not work, but the dev could not replicate it.
Is the Debian buster-backports version of hd-idle so old it isn't useful?
Yes, because the official Hd-idle has been abandoned and left with many bugs. There is a re-implementation in Go of hd-idle which is great and updated, but can only be added with another repo.
Appreciate the new guide, well done!
Nevertheless there seems an additional safeguard required if hd-idle had been installed manually before.
I was in the same situation (the repo thing is pretty new) and I simply re-installed the package. The config file should not be deleted, but make a copy to be safe.
If you like to spin-down your hard drives but you’re having trouble in doing so, you’re not alone.
Not all hard drives like hdparm, the utility used by Debian and OpenMediaVault. There’s an alternative called hd-idle which does the job but introduces another issue: it will eventually fail if you use standby/hibernation on your server, plus other inconveniences.
Hd-idle has been abandoned many years ago and was left in a buggy state, but we finally have a solution: a re-implementation of hd-idle with this bug fixed, along with many other improvements.
Thanks to adelolmo on Github for rewriting and keeping hd-idle alive.
The new hd-idle can be installed in two ways: via an external repository or manually. I recommend the repository approach because it’s easier and will keep the program updated when you’ll run omv-update.
Follow the instructions posted by the developer to add his repository:
Update apt with apt-get update, then you're ready to install hd-idle with apt-get install hd-idle. You don’t have to worry about the old and buggy version that is still in Debian’s repo, apt will install the new version.
Note: If you manually installed hd-idle and now you want to use the repo, just uninstall the package and start over. The config file should not be removed, but always make a copy before uninstalling.
Download the latest package, linked here wget https://github.com/adelolmo/hd-idle/releases/download/v1.12/hd-idle_1.12_amd64.deb
Install the package dpkg -i hd-idle_1.12_amd64.deb
Before you begin, disable any spin-down in the OMV Web interface. Browse to Storage > Disks, edit each disks and ensure
- Spindown time is set to Disabled
- Advanced Power Management is set between 128 and 255. Lower values may interfere with hd-idle.
The configuration file is placed in /etc/default/hd-idle. Edit this file with your favourite file editor.
There's a lot to be said about hd-idle but this guide will only cover the basics. Check out the full documentation here.
To actually enable hd-idle, change START_HD_IDLE=false to START_HD_IDLE=true.
The default (commented) configuration is very simple:
- -i 180 sets the spin-down time in seconds
- -l /var/log/hd-idle.log sets the log location, which is optional
When using this configuration, all drives will be put in spin-down after 3 minutes of inactivity. It’s a bit aggressive: I would rather use a more conventional amount of 20 minutes (1200 seconds) to avoid stressing your drives.
You may still want to use a short spin-down time if you have a very very very inactive drive such as a SnapRAID parity drive that is woken up only once per day for the sync job. If this is the case, you can further customize the configuration by using disk UUID or label. Do not use device name (eg:/dev/sda1) because they can change and things can get messy.
In this example I've set the spindown time for HDD1 to 3 minutes, and other drives to 20.
Trick: use the parameter -i 0 at the beginning (like above) to disable spin-down of not explicitly specified HDDs.
I recommend enabling the log because can help troubleshooting if your server’s drives don’t sleep.
However the log can grow a lot over time but logrotate can solve this problem.
NOTE: This new version of hd-idle also writes spin-down/wake-up events in syslog.
Browse to /etc/logrotate.d/ and create a new file called hd-idle containing
Logrotate will pick up the new configuration automatically.
- Run this command to enable the new hd-idle at boot systemctl enable hd-idle
- Run this command to start hd-idle right away systemctl start hd-idle
If you get the error service is masked when trying to configure hd-idle, run the following commands
You're ready to finally enjoy hard disk spin down! (done properly)
Please note the full hd-idle documentation is available here. The new developer has done a great job explaining configuration options and log entries.
If you need help with hd-idle, please write a post in the original discussion since you can't reply to this guide.
Can you please share such a script?
Is it also possible to have the script that does display all the file changes just save the changes to a log file and send out an email saying that it ran and with a short summary? This way emails are readable and if there are problems then one can refer back to the full log.
That's what my script does!
Please send me a PM so I don't forget (quite busy during these days)
If you have a backup you should not worry too much.
The drive has reallocated sectors and this is potentially dangerous. The drive could survive for some time, but it's still better to replace it.
You could also consider HDSentinel for Linux. I've set it to send me an email every Sunday. It produces a nice report and exitates the life of the drive.
It's just another safety measure but it only runs when invoked so it's still good to keep OMV SMART monitoring enabled.
Thank you. I know how to apply environmental variables, but I was wondering how to address this case.
I checked my own docs and apparently I am already using OMV_MONIT_DELAY_SECONDS set to 20 seconds, because I was getting many errors during startup.
When I shut down my server, sometimes the monitoring service triggers reporting one of the file systems can't be read. This is expected, because the file system has been unmounted for shutdown, but this email should not be sent.
This leads to heartbreaking moments, because this email is only sent when the system is back on.Code
I found a couple of environment variables but I don't know if they fit the case and how they should be configured:
About the backup: yeah I'll probably end up plugging a usb once in a while and doing an autobackup when the usb is detected, something like a cold backup.
I do this every week as part of my 3-2-1 backup strategy for my data.