Your NAS Isn’t Dying. It’s Just Busy.
My NAS wasn’t loud because the drives were dying. It was loud because I turned it into a tiny cloud provider. Auditing unused containers, disabling unnecessary healthchecks, and trimming excessive logging dropped disk I/O from ~40MB/s to under 1MB/s. Just because you can, doesn’t mean you should.
There’s a particular sound every homelabber eventually learns to recognize.
Not the catastrophic click-click-click of a dying disk.
Not the fan screaming because you forgot to clean the dust filters since the Obama administration.
No.
This one is subtler.
A kind of… constant mechanical anxiety.
The low-level chatter of drives that never, ever get a moment of peace.
And for months, my NAS was getting progressively louder.
At first, I blamed the drives.
Then the RAID scrubbing schedule.
Then Synology.
Then Docker.
Then probably cosmic radiation.
Turns out?
The problem was me.
The “Because I Can” Phase
If you run a homelab, you know exactly how this happens.
You spin up one container.
Then another.
Then Immich.
Then Grafana.
Then Prometheus.
Then three AI tools you’ll “definitely use later.”
Then some obscure open-source project with 42 GitHub stars and a README written entirely in optimism.
And suddenly your NAS isn’t a NAS anymore.
It’s a small regional cloud provider.
The thing is: containers are deceptively cheap.
Starting one feels free.
Until you realize that every “tiny little service” comes with:
- logs
- healthchecks
- metrics
- databases
- cache writes
- retries
- background jobs
- telemetry
- scheduled tasks
- endless little disk operations
Individually? Nothing.
Collectively?
My NAS drives were processing roughly 40 MB/s continuously.
Not during backups.
Not during transfers.
All the time.
Twenty-four hours a day.
Your Drives Are Working Even When You Aren’t
That was the realization.
The disks weren’t loud because they were old.
They were loud because they were busy.
Constantly.
The NAS had effectively become a mechanical fidget spinner.
So I did something radical.
I audited everything.
Every stack.
Every compose file.
Every container.
And I asked three brutally simple questions:
- Do I actually use this regularly?
- Do I use it often enough to justify 24/7 uptime?
- Would I mind starting it manually when needed?
Those three questions are devastating.
Because they force you to confront the uncomfortable truth that half your infrastructure exists purely because you thought it was cool at 1:17 AM on a Tuesday.
The Great Container Purge
Some services survived.
Others received the digital equivalent of a Viking funeral.
By the end of the cleanup, I’d reduced the number of running stacks by more than half.
That alone cut the I/O roughly in half too.
Good start.
But not good enough.
Because the disks were still constantly doing something.
Which led to the second realization.
Healthchecks: The Tiny Disk Assassins
Healthchecks are fantastic in production.
Absolutely essential.
In a real environment with real users and real SLAs, they’re part of the operational nervous system.
But this wasn’t production.
This was my homelab.
A place where the primary user impact of downtime is me sighing loudly in the living room.
So I started experimenting.
I commented out healthchecks.
Re-tested deployments.
Verified services manually.
And… everything still worked perfectly fine.
Meanwhile, the constant background chatter dropped again.
Because when you have dozens of containers probing themselves every few seconds, logging every result, touching databases, writing state files…
It adds up.
Fast.
Then Came Logging
This was the real eye-opener.
Docker logging is useful.
Very useful.
Until you realize some containers generate logs like they’re being paid per line.
So I tried something simple:
logging: driver: "none"And suddenly the NAS went from sounding like a stressed-out data center…
…to practically idle.
Average disk I/O dropped to less than 1 MB/s.
From ~40 MB/s.
That’s not optimization.
That’s discovering your infrastructure had developed an untreated caffeine addiction.
Would I Do This In Production?
Absolutely not.
Well… mostly not.
Disabling healthchecks and logging in production is how you eventually end up explaining things to management using phrases like:
“Technically, it was running.”
But the trimming phase?
The auditing?
The ruthless questioning of whether a service deserves permanent uptime?
That part absolutely applies everywhere.
Because infrastructure has a tendency to accumulate.
Every environment eventually develops technological barnacles:
- old monitoring stacks
- abandoned experiments
- forgotten APIs
- “temporary” databases
- duplicate services
- zombie containers nobody wants to touch
And all of them cost something.
CPU.
RAM.
Disk I/O.
Complexity.
Attention.
Sometimes even sanity.
Just Because You Can…
Homelabs are dangerous because modern hardware is absurdly capable.
A single NAS today can run more services than an entire SME did fifteen years ago.
And Docker makes deployment so frictionless that spinning up infrastructure feels almost consequence-free.
But consequences don’t disappear.
They just become quieter.
Until your NAS starts sounding like it’s mining Bitcoin in the basement.
So here’s the biggest lesson from this whole exercise:
Just because you can, doesn’t mean you should.
Not every service deserves 24/7 uptime.
Not every container needs logs.
Not every healthcheck improves your life.
And sometimes the best optimization strategy isn’t Kubernetes, SSD caching, or distributed storage.
Sometimes it’s simply deleting stuff you don’t actually need.
And honestly?
That’s probably the most production-grade lesson of them all.
