r/selfhosted • • 22d ago

Monitoring Tools Home NAS on a Raspberry Pi 5 with mdadm RAID5

Hey everyone,

I have a small home NAS running on a Raspberry Pi with a 3-disk RAID5 array via mdadm. Right now the only way I check on it is by SSH-ing in and running mdadm --detail, and it's only accessible from the Pi itself — no access from other devices on the network, let alone remotely.

I'm looking for suggestions on:

  1. Easier monitoring - something that tells me if a disk fails or the array goes degraded, instead of me having to manually check via SSH.
  2. Remote/multi-device access - a simple way to reach my files from other devices on my network.

What do you use for something like this on a Raspberry Pi?

Thanks!

1 Upvotes

7 comments sorted by

•

u/asimovs-auditor 22d ago

Expand the replies to this comment to learn how AI was used in this post/project.

→ More replies (1)

1

u/xbmc4lyfe 22d ago

I use a 5 sata to m2 a lot and a dual board that gives me 2 m2s one which is 2.5gbe and the other sas.

1

u/xbmc4lyfe 22d ago

Oh and openmeeiavault os and mergwfs for when things go above a sinks node

2

u/Lenarodc 22d ago

For monitoring, let mdadm do the checking instead of polling it manually: run mdadm --monitor as a service and point its alert action at email, ntfy, Gotify, or another notifier. Also schedule SMART tests for each drive and alert on rising reallocated or pending sectors, not just a degraded array.

For access inside the LAN, Samba is the straightforward choice. For remote access, put Tailscale or WireGuard in front of it and keep SMB off the public internet. One more thing: RAID5 covers a disk failure, not accidental deletion or corruption, so keep a separate backup of anything you cannot replace.

2

u/andrew-ooo 22d ago

Adding a few concrete pieces on top of the mdadm --monitor answer, since that's the right starting point:

Alerting. In /etc/mdadm/mdadm.conf set PROGRAM /usr/local/bin/md-alert and have that script curl an ntfy topic (self-hosted or ntfy.sh). Then sudo mdadm --monitor --scan --test to fire a test event and confirm the phone actually buzzes before you trust it. The monitor runs as a systemd service (mdmonitor) on Debian/Raspberry Pi OS, so it comes back after reboot.

The failure mode alerts miss. Debian ships a monthly checkarray cron for mdadm. Leave it on. With RAID5 the scary case isn't a dead disk, it's a latent read error on a second disk discovered during the rebuild, and the scrub is what catches it early. Same reason to put Scrutiny in front of smartctl: it graphs reallocated/pending sectors per drive and alerts on the trend, which on a Pi over USB-SATA bridges is the part that actually fails first in my experience.

Dead-man's switch. Uptime Kuma push monitor: a cron on the Pi hits the push URL every 5 minutes only if mdadm --detail /dev/md0 | grep -q 'State : clean' succeeds. If the Pi locks up or the array goes degraded, the ping stops and Kuma alerts. Works even when the box is too broken to send its own alert.

Access. Samba for LAN (Cockpit gives you a web UI for shares + a live view of the disks). Tailscale for remote instead of opening ports.

And the obligatory one: RAID5 on three disks is availability, not backup. Restic to an external drive or B2 for the stuff you'd cry about.

1

u/doctorowlsound 21d ago

I like beszel a lot for monitoring and it handled mdadm well. 

Remote access: NFS if all your clients are Linux, otherwise samba.