UGREEN NAS: Täglicher Platten-Check mit Telegram-Meldung

Eine Festplatte kündigt ihren Ausfall oft Wochen vorher an: Sektoren werden umgelagert, die Temperatur steigt, im RAID fällt ein Laufwerk heraus. UGOS Pro zeigt das in der App Speicher, aber nur, wenn jemand hineinschaut. Diese Anleitung zeigt, wie ein kleiner Container jeden Morgen SMART-Werte, RAID, btrfs und Füllstand prüft und nur dann eine Nachricht per Telegram schickt, wenn etwas auffällt.

Das Prüfskript haben wir auf einer UGREEN DXP4800 Pro mit UGOS Pro 1.21.0.0190 direkt getestet, den Container mit Alpine 3.24.3 und smartctl 7.5 auf unserem Testsystem. Er ist eine vereinfachte Fassung des Aufbaus, der auf der NAS seit dem 22. Oktober jeden Morgen läuft. Zugangsdaten sind durch Platzhalter ersetzt.

Voraussetzungen

• Eine UGREEN NAS mit der App Docker, siehe Teil 64
• Ein Telegram-Konto
• SSH für den Test, siehe Teil 52
• Grundwissen zu SMART, siehe Teil 18
• Etwa 30 Minuten

Schritt 1: Einen Telegram-Bot anlegen

Schreiben Sie in Telegram dem Konto @BotFather den Befehl /newbot und vergeben Sie einen Namen. Sie erhalten einen Token. Schicken Sie Ihrem neuen Bot danach eine beliebige Nachricht und rufen Sie im Browser auf:

https://api.telegram.org/botTOKEN/getUpdates

In der Antwort steht unter chat und id Ihre Chat-ID. Speichern Sie Token und Chat-ID im Passwortmanager, nicht in einer Notiz. Löschen Sie den Aufruf danach aus dem Verlauf des Browsers, denn der Token steht in der Adresse.

Verifizieren: getUpdates zeigt Ihre Nachricht mit einer Chat-ID.

Schritt 2: Das Prüfskript

Legen Sie in der App Dateien auf dem Volume, auf dem Ihre Docker-Projekte liegen, bei uns Volume 2, den Ordner docker/platten-check mit einem Unterordner scripts an. Speichern Sie das Skript auf Ihrem Rechner als check-platten.sh und laden Sie es in diesen Ordner hoch, oder legen Sie es per SSH mit sudo nano an:

#!/bin/sh
# Einfacher Platten-Check: meldet nur Auffälliges per Telegram
TEMP_HDD_MAX=${TEMP_HDD_MAX:-55}
FUELLSTAND_MAX=${FUELLSTAND_MAX:-85}
BEFUND=""
melde() { BEFUND="${BEFUND}- $*
"; }

# SMART aller SATA-Platten, USB-Laufwerke überspringen
for d in /dev/sd?; do
  [ -e "$d" ] || continue
  case $(readlink -f /sys/block/${d#/dev/}) in *usb*) continue ;; esac
  smartctl -H -d sat "$d" | grep -q PASSED || melde "$d: SMART-Gesamtbefund nicht bestanden"
  w=$(smartctl -A -d sat "$d" | awk '$1==5||$1==197||$1==198 {s+=$10} END {print s+0}')
  [ "$w" -gt 0 ] && melde "$d: $w defekte oder wartende Sektoren"
  t=$(smartctl -A -d sat "$d" | awk '$1==194 {print $10}')
  [ -n "$t" ] && [ "$t" -gt "$TEMP_HDD_MAX" ] && melde "$d: $t Grad"
done

# NVMe-SSDs
for d in /dev/nvme?; do
  [ -e "$d" ] || continue
  smartctl -A "$d" | grep -q "Critical Warning: *0x00" || melde "$d: kritische Warnung"
done

# RAID: ein Unterstrich statt U, etwa [U_], heißt, eine Platte fehlt
grep -q '\[U*_[U_]*\]' /proc/mdstat 2>/dev/null && melde "RAID herabgestuft: $(grep -B1 '_' /proc/mdstat | head -1)"

# btrfs-Fehlerzähler und Füllstand
for v in /volume1 /volume2; do
  [ -d "$v" ] || continue
  f=$(btrfs device stats "$v" 2>/dev/null | awk '{s+=$2} END {print s+0}')
  [ "$f" -gt 0 ] && melde "$v: $f btrfs-Fehler"
  p=$(df --output=pcent "$v" | tail -1 | tr -dc 0-9)
  [ "$p" -gt "$FUELLSTAND_MAX" ] && melde "$v: zu $p Prozent voll"
done

if [ -n "$BEFUND" ]; then
  echo "$(date '+%F %T') Befunde:"; printf '%s' "$BEFUND"
  [ -n "$TELEGRAM_BOT_TOKEN" ] && curl -s -m 15 -o /dev/null \
    "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
    -d chat_id="$TELEGRAM_CHAT_ID" --data-urlencode text="NAS: $BEFUND"
else
  echo "$(date '+%F %T') alles in Ordnung"
fi
date +%s > /tmp/letzte-pruefung

Was es prüft:

• SMART der Festplatten: den Gesamtbefund von smartctl -H, die Attribute 5, 197 und 198 für umgelagerte, wartende und nicht korrigierbare Sektoren, dazu die Temperatur aus Attribut 194
• NVMe-SSDs: die Zeile Critical Warning
• RAID: in /proc/mdstat steht für jede Platte ein U, ein Unterstrich wie in [U_] bedeutet eine fehlende Platte
• btrfs: die Fehlerzähler aus btrfs device stats und den Füllstand jedes Volumes

USB-Laufwerke überspringt das Skript, weil viele USB-Gehäuse keine SMART-Werte durchreichen. Am Ende schreibt es einen Zeitstempel nach /tmp/letzte-pruefung, den der Healthcheck des Containers auswertet.

Das Skript meldet nur, wenn es einen Befund gibt. Ein Tag ohne Nachricht heißt also: alles in Ordnung.

Verifizieren: Die Datei liegt unter docker/platten-check/scripts/check-platten.sh.

Schritt 3: Das Skript von Hand testen

Bevor Sie einen Container bauen, testen Sie das Skript per SSH direkt auf der NAS, ohne Telegram-Werte:

sudo sh /volume2/docker/platten-check/scripts/check-platten.sh

Bei uns lautete die Ausgabe:

2026-11-03 16:55:33 alles in Ordnung

Ob die Erkennung greift, prüfen Sie mit einer absichtlich zu niedrigen Grenze:

sudo env FUELLSTAND_MAX=10 sh /volume2/docker/platten-check/scripts/check-platten.sh

2026-11-03 16:55:33 Befunde:
- /volume1: zu 44 Prozent voll
- /volume2: zu 23 Prozent voll

Ohne gesetzten Token schickt das Skript dabei keine Nachricht. Passen Sie die Pfade /volume1 und /volume2 an Ihre Volumes an.

Verifizieren: Ohne Grenze meldet das Skript alles in Ordnung, mit gesenkter Grenze den Füllstand.

Schritt 4: Den Container anlegen

Legen Sie in der Docker-App ein Projekt platten-check an. Zugangsdaten kommen in eine Datei .env im Projektordner mit den Zeilen TELEGRAM_BOT_TOKEN= und TELEGRAM_CHAT_ID=. Die Compose-Datei:

services:
  platten-check:
    image: alpine:3
    container_name: platten-check
    restart: unless-stopped
    init: true
    privileged: true
    environment:
      - TZ=Europe/Berlin
      - TELEGRAM_BOT_TOKEN=${TELEGRAM_BOT_TOKEN}
      - TELEGRAM_CHAT_ID=${TELEGRAM_CHAT_ID}
    volumes:
      - ./scripts:/scripts:ro
      - /volume1/docker:/volume1:ro
      - /volume2/docker:/volume2:ro
    command: >
      sh -c "apk add --no-cache smartmontools btrfs-progs curl coreutils tzdata &&
             echo '0 7 * * * sh /scripts/check-platten.sh' | crontab - &&
             sh /scripts/check-platten.sh;
             exec crond -f -l 8"
    healthcheck:
      test: ["CMD-SHELL", "test $$(( $$(date +%s) - $$(cat /tmp/letzte-pruefung 2>/dev/null || echo 0) )) -lt 93600"]
      interval: 5m
      start_period: 2m

Die wichtigsten Punkte:

• privileged: true: smartctl liest die Laufwerke direkt, btrfs device stats braucht erweiterte Rechte. Damit hat der Container weitreichenden Zugriff auf die NAS. Lassen Sie ihn deshalb ohne Ports, ohne Weboberfläche und nur mit diesem Skript laufen.
• Volumes nur lesend: Ein Ordner auf jedem Volume reicht, df und btrfs sehen darüber das ganze Dateisystem.
• coreutils: bringt das df mit, das die Spalte pcent kennt.
• command: lädt die Werkzeuge, trägt die tägliche Prüfung um 7 Uhr ein, prüft einmal sofort und startet cron.
• healthcheck: meldet unhealthy, wenn die letzte Prüfung älter als 26 Stunden ist, also wenn der Check selbst ausfällt.

Auf unserem Testsystem lief der Container nach rund einer Minute mit healthy. Setzten wir den Zeitstempel künstlich zurück, wechselte er auf unhealthy. Unser Aufbau auf der NAS lädt die Werkzeuge zusätzlich in einem Startskript mit Wiederholungen nach und schreibt jede Prüfung in eine Logdatei.

Verifizieren: Der Container zeigt nach etwa zwei Minuten healthy, und sudo docker exec platten-check sh /scripts/check-platten.sh meldet alles in Ordnung.

Schritt 5: Wissen, dass der Check selbst läuft

Ein Wächter, der unbemerkt ausfällt, ist gefährlicher als keiner. Der Healthcheck aus Schritt 4 macht einen ausgefallenen Check sichtbar, Uptime Kuma überwacht den Container mit einem Monitor vom Typ Docker-Container, siehe Teil 68. So erfahren Sie auch, wenn der Check selbst nicht mehr läuft. Wie Healthchecks in Compose-Dateien aufgebaut sind, erklärt Docker Compose absichern.

Ein Probealarm gehört zur Einrichtung. Setzen Sie für einen Lauf eine niedrige Grenze, etwa FUELLSTAND_MAX=10, und rufen Sie das Skript im Container auf:

sudo docker exec -e FUELLSTAND_MAX=10 platten-check sh /scripts/check-platten.sh

Auf dem Handy erscheint dann eine Nachricht, die mit NAS: beginnt und den Füllstand nennt.

Verifizieren: Der Probealarm kommt per Telegram an, und der Container zeigt healthy.

Schritt 6: Das Protokoll und eine Falle

Im Reiter Protokoll steht nach jeder Prüfung eine Zeile mit Datum und Ergebnis. Das Bild zeigt unseren erweiterten Aufbau auf der NAS, der zusätzlich seine Logdateien leert.

Bei uns stand dort ein Fehler: find: invalid number '5M'. Die Regel sollte Logdateien über 5 MB leeren. Alpine nutzt aber das find von BusyBox, und das versteht die Einheit M nicht. Mit Kilobyte funktioniert es:

30 4 1 * *  find /data/logs -name '*.log' -size +5120k -exec sh -c ': > "$1"' _ {} \;

Solche Meldungen fallen nur auf, wenn Sie das Protokoll ab und zu lesen. Prüfen Sie nach jeder Änderung am Zeitplan den Reiter Protokoll.

Auf unserem Testsystem bestätigte sich das: find -size +5120k lief ohne Fehler, find -size +5M endete mit invalid number '5M'.

Verifizieren: sudo docker exec platten-check find /tmp -size +5120k läuft ohne Fehlermeldung, und das Protokoll zeigt jeden Morgen nach 7 Uhr eine Zeile alles in Ordnung.

Was die Befunde bedeuten

• SMART-Test nicht bestanden: Die Platte selbst hält ihren Ausfall für wahrscheinlich. Sichern Sie sofort und tauschen Sie sie, siehe Teil 16.
• Defekte oder wartende Sektoren: Einzelne Sektoren sind unlesbar oder umgelagert. Der Check meldet sich dann jeden Morgen. Notieren Sie den Wert und vergleichen Sie ihn mit den Folgetagen, steigt er, planen Sie den Tausch.
• Zu warm: Lüfter, Staub und Aufstellort prüfen.
• RAID herabgestuft: Eine Platte fehlt im Verbund. Die Daten sind noch da, aber ohne Reserve. Handeln Sie sofort.
• btrfs-Fehler: Lese-, Schreib- oder Prüfsummenfehler. Einen Scrub starten und die SMART-Werte der Platten ansehen. Die Zähler bleiben stehen, bis Sie sie zurücksetzen. Hat sich die Ursache geklärt, setzen Sie sie mit sudo btrfs device stats -z /volume1 auf null, sonst meldet der Check jeden Tag erneut.
• Zu voll: Platz schaffen oder erweitern, denn btrfs wird bei sehr vollen Volumes langsam.

Typische Fehler

• smartctl findet keine Geräte: privileged fehlt.
• Container bleibt unhealthy: Die erste Prüfung ist fehlgeschlagen, etwa weil apk beim Start kein Internet hatte. Protokoll ansehen und den Container neu starten.
• Keine Nachricht beim Probealarm: Token oder Chat-ID falsch, oder der Bot wurde nie angeschrieben.
• df: unrecognized option: coreutils fehlt, das BusyBox-df kennt --output nicht.
• find: invalid number: BusyBox-find kennt keine Einheiten wie M. Größen in k angeben.
• Container startet ohne Werkzeuge: Beim Start war kein Internet da. Neu starten oder Wiederholungen einbauen.

Häufige Fragen

Reicht nicht die Anzeige in UGOS?

Ein eigener Check zeigt genau die Werte, die Sie für wichtig halten, mit Ihren Grenzen, und meldet schon einzelne defekte Sektoren, lange bevor UGOS die Platte als ausgefallen führt.

Wie oft soll geprüft werden?

Täglich genügt. SMART-Werte ändern sich langsam, und eine Nachricht pro Tag bei einem Befund ist besser als ständige Meldungen.

Was ist mit einem Scrub?

Ein Scrub liest alle Daten und vergleicht sie mit den Prüfsummen von btrfs. Die App Speicher bietet dafür keinen Zeitplan an, wie Sie ihn per SSH einrichten, zeigt Teil 20. Die Datenorganisation in UGOS prüft dagegen die Parität eines RAID 5 oder 6, siehe Teil 19. Unser Aufbau startet für das Volume auf den SSDs zusätzlich einmal im Monat einen btrfs-Scrub.

Fazit

Ein kleiner Container mit einem Skript von gut 40 Zeilen prüft jeden Morgen, was eine Festplatte vor dem Ausfall verrät, und meldet sich nur bei Befunden. Testen Sie das Skript zuerst von Hand, lösen Sie einen Probealarm aus und lassen Sie den Container selbst von Uptime Kuma überwachen.

Weiterführende Anleitungen und Quellen

• Teil 18: S.M.A.R.T.-Werte prüfen
• Teil 64: Compose-Projekt anlegen
• Teil 68: Uptime Kuma
• Docker Compose als Grundlage
• smartmontools
• Telegram Bot API: sendMessage