Many enterprise/datacenter HDDs have “hidden” power modes that can be triggered by specific APM values or obscure smartctl commands. I’ve found that just setting the proper APM mode on my HC550s, they can enter a sort of “standby” where my entire system drops from 120w to 100w for a 6 disks array. There are many more modes with a sort of spin down from 7200 to 5400 rpm that works with the above mentioned obscure smartctl commands. You can find almost anything in the HDD manual and AI can give — with some trials and errors — some commands to try too.
It looks like they don’t care about us or our need to spin down disks. I don’t like that I have to apply patches to the OS just to make a fundamental homelab feature work. Sooner or later, I’ll need to update for security reasons anyway. If there’s still no fix by then, I’ll have to switch to another solution.
Hello Unraid or OMV…
Even though I’ve been very happy with TrueNAS so far and really like it. Power consumption is one topic… the other is heat. Especially in a small rack, where disks run all the time even when they aren’t being used for days.
The Jira ticket is still open but not assigned, even for such a small fix. It makes me think there may never be a solution… at least not in the near future.
It’s a shame standby was actively broken with one of the recent versions since it still works, but the new SMART monitoring system causes the drive to wake up every few minutes.
The people arguing that spindown is ‘bad’ don’t consider the case of a backup pool being rarely used, in my case once a day. I dont need it spinning for 99% of the day yet with these changes I have to have it on 24/7 to get a proper 321 backup.
My NAS is all SSD apart from a HDD which is used once a week in a scheduled ZFS replication. I’ve set the spindown in the UI to 5 minutes but it still periodically wakes during the day.
Having a “spindown” button that is actually useless as it will be spun back up again to check the drive temperature (of a spundown disk, so not relevant) is pretty sad.
Two thoughts. First: the so-called podcast is good for complex topics and directional clues.
Second: if I had an infrequent backup or replication schedule on my desktop system, I wouldn’t hope the OS spins down the target volumes. Hope that it leaves them alone despite other triggers such as indexing, searching, etc.
Instead, I would explicitly unmount those volumes when I want them inactive. And explicitly mount them again when I expect them to be active.
For ZFS, you’d do that at the pool level. In TrueNAS, via pool export and import_pool jobs.
But if anyone’s actually serious about spinning down between weekly or daily backup tasks, then energy usage is only one piece of that puzzle. There’s also the security principle of not leaving those disks out unnecessarily. Spin-up cycles be darned: shut down and take the backup out of play until the scheduled cold boot and backup operation — as with a time-lock safe.
However, if you try to do this in Truenas 25.10+, it still would not let you spin down the disks due to thermal monitoring accessing even unmounted pools and blocking them from spindown.
On top of this, it is quite complex to write a script that automatically unmounts a pool after all Truenas replication jobs are finished, mounts them for scrubs etc - just to spin down idle disks, a feature that used to work a expected up to Truenas 25.04.
Are you saying people should physically disconnect drives that are only used occasionally? All of your options are more complicated than using the feature that worked perfectly fine before 25.10, and still exists in the UI, just is overridden by the new monitoring system. We just want a forgotten optional feature to be supported again.
On the security principle, discussing weekly replications: yes it is good practice to airgap your last resort backup. The target repo should pull only, refuse incoming connections, and remain out of reach of potentially tainted renegade source hosts.
This shouldn’t sound complicated. Power-on; perform transfer; shut down.
Mind you, that’s not something that you’d look to a NAS appliance to tackle. NAS appliances have other mandates which could very well undercut this specific use case.
No it doesnt sound complicated it sounds cumbersome compared to what used to work. It sounds nice until you realise we dont all have 3 separate NAS devices like you have. I use my one and only NAS for both storage and backup on separate pools.
My backup pool is only used by truenas for a copy of some datasets, within the same device, from one pool to another. I shouldnt have to set up a second machine for this.
Copy to another pool is better than no backup at all, but having the backup in the same machine means that a single disaster (rogue PSU / fire / burglar…) can take both your data and the backup in one strike. So for better security you really should consider a second NAS.
To be clear: periodic backup was only one argument presented in support of spinning down drives. But given that context, it is worth noting that backup drives are exposed even when spun down.
There is also tiered very infrequent accessed data (archival) that needs to stay “hot”.. well with spindown we could call it “lukewarm”. I see no practical need to keep disks spinning that would be accessed perhaps once a year when Karen from finance needs some PDF from 17 years ago. However I do need to know that the server is up and patched (cant shut it down).
and I’d emphasize also remote breach/ransomware.