NUT-Server auf dem Raspberry Pi einrichten

Teststand und Geltungsbereich: USB-Kommunikation, Statusabfrage, Netzwerkzugriff und ein lokaler Windows-Shutdown über eine vorübergehend gesetzte Akkuschwelle sind im Labor dokumentiert. Ein vollständiger FSD-Abschaltzyklus, das Abschalten der USV-Ausgänge und der automatische Wiederanlauf sind noch nicht praktisch nachgewiesen. Die ergänzenden Wege für ESXi, QNAP und Synology beruhen auf Dokumentation und wurden für diesen Beitrag nicht praktisch getestet. Prüfe diese Abläufe mit Deinen konkreten Versionen in einem Wartungsfenster.

1. Was wir aufbauen

Eine USV – unterbrechungsfreie Stromversorgung – überbrückt einen Stromausfall mit ihrem Akku. Damit laufen angeschlossene Geräte zunächst weiter. Bei einem längeren Ausfall muss jedoch jemand rechtzeitig das Herunterfahren auslösen. Sonst geht irgendwann auch der USV der Strom aus.

Hier übernimmt ein Raspberry Pi diese Aufgabe. Er liest die USV per USB aus und stellt die Informationen im lokalen Netzwerk bereit. Windows-PCs, ein ESXi-Host und NAS-Systeme können darauf reagieren.

Die Software heißt NUT: Network UPS Tools. Die Bezeichnung hat nichts mit einem Notfallserver als eigenständigem Produkttyp zu tun.

Die Rollen im Aufbau:

Ältere Programme und Herstelleroberflächen sprechen noch von master/slave. In aktuellen NUT-Konfigurationen verwenden wir primary/secondary. Die Begriffe beschreiben die Überwachungsrolle, nicht das Linux-Benutzerkonto. Grundlagen: NUT-Konfiguration.

Stromversorgung und Netzwerk gehören zusammen

An batteriegepufferte USV-Ausgänge gehören der Pi mit seinem Netzteil, die zu schützenden Geräte und die notwendigen Netzwerkkomponenten. Ein Switch ohne USV-Versorgung kann beim Stromausfall die Kommunikation zwischen Server und Clients sofort unterbrechen. Bei gerouteten Netzen müssen auch Router beziehungsweise Firewall weiterlaufen.

Eine USB-Datenverbindung versorgt den Pi nicht automatisch ausreichend mit Strom. Nutze sein passendes Netzteil. Prüfe außerdem am USV-Handbuch, welche Ausgänge batteriegepuffert sind: Manche Steckdosen bieten lediglich Überspannungsschutz.

Arbeite ausschließlich mit fertigen geeigneten Netzteilen und Anschlussleitungen. Für dieses Projekt wird nichts an offenen 230-V-Anschlüssen verdrahtet.

2. Hardware, Software und Beispielwerte

Unser dokumentierter Laboraufbau

Das sind Versionsangaben des Laboraufbaus, keine Aufforderung, gezielt alte Software zu installieren. Die Paketverwaltung kann inzwischen andere Versionen anbieten. Für neuere Pi-Modelle wählst Du das dazu passende Betriebssystem und Netzteil. Beim hier verwendeten Pi 2 bleiben wir bei der dokumentierten 32-Bit-Installation. Die konkrete Modell- und OS-Auswahl erfolgt im Imager.

Zusätzlich brauchst Du ein Notebook oder einen PC, einen microSD-Kartenleser oder SD-Adapter, ein Netzwerkkabel, Router-/DHCP-Zugriff und Administrationszugriff auf die späteren Clients. Zum ersten Einrichten muss der Pi nicht mit Bildschirm und Tastatur betrieben werden: Wir aktivieren SSH bereits auf der Speicherkarte.

Neutrales Beispielnetz

Alle folgenden Adressen und Namen sind frei gewählte Beispiele. Ersetze sie passend zu Deinem Netz. Insbesondere darf eine Adresse nicht bereits anderweitig vergeben sein.

Der NUT-Gerätename ups ist ein selbst gewählter logischer Name. Er ist weder Modellbezeichnung noch Hostname. Wir verwenden ihn durchgehend; herstellerspezifische Abweichungen behandeln die NAS-Kapitel.

3. Abschaltzeiten vorab planen

Bevor Du Software installierst, kläre die Abhängigkeiten. Ein PC mit lokalen Dateien ist schnell heruntergefahren. Ein Virtualisierungshost mit mehreren VMs oder ein NAS mit laufenden Diensten braucht möglicherweise deutlich länger.

Notiere für jedes Gerät:

1. Hängt es tatsächlich an dieser USV?
2. Wie lange dauert ein sauberer Shutdown unter realistischer Last?
3. Welche anderen Systeme müssen bis dahin verfügbar bleiben?
4. Wie startet es nach Stromrückkehr wieder?

Besonders wichtig: Liegen ESXi-Datastores per NFS oder iSCSI auf einem NAS, darf das NAS seinen Speicher erst offline nehmen, wenn die darauf laufenden VMs und die Zugriffe des Hosts beendet sind. Ein gemeinsames FSD-Signal allein bildet diese Abhängigkeit nicht ab.

Ein reines Rechenbeispiel: 180 Sekunden bis zum Abschaltbeginn, anschließend 240 Sekunden für VMs und Host, danach 120 Sekunden für den Speicher und 120 Sekunden Reserve ergeben 660 Sekunden beziehungsweise elf Minuten. Das ist keine gemessene Laufzeit unserer Hardware und keine pauschale Empfehlung. Das tatsächliche Zeitbudget muss zur USV, Akkualterung, Last und Abschaltreihenfolge passen.

Plane für die Erstinstallation mehrere Stunden und ein Wartungsfenster ein. Ein vollständiger Akkuentladetest ist dafür normalerweise nicht nötig; die reale Überbrückungszeit muss trotzdem belastbar bewertet werden.

4. microSD-Karte mit Raspberry Pi Imager vorbereiten

4.1 Imager installieren

1. Öffne die offizielle Raspberry-Pi-Softwareseite.
2. Lade Raspberry Pi Imager passend zu Deinem Notebook herunter.
3. Installiere und starte das Programm.

Die Oberfläche kann je nach Version anders aussehen. Entscheidend sind die Auswahl von Pi-Modell, Betriebssystem, Zielmedium und den Anpassungen für den ersten Start. Offizielle Schrittfolge: Getting started.

4.2 Speicherkarte ins Notebook einsetzen

1. Stecke die microSD-Karte in den Kartenleser. Bei einem großen SD-Steckplatz verwendest Du einen microSD-auf-SD-Adapter.
2. Verbinde einen externen Kartenleser mit USB, falls nötig.
3. Sichere vorhandene Dateien der Karte: Der Schreibvorgang löscht deren Inhalt.
4. Entferne nach Möglichkeit andere externe Speichermedien, damit Du sie im Imager nicht verwechselst.

Eine separate Formatierung vorab ist üblicherweise nicht erforderlich. Imager schreibt das Image samt Partitionierung. Wenn Windows später eine Linux-Partition formatieren möchte, brich diese Aufforderung ab.

4.3 Modell und Betriebssystem auswählen

1. Wähle den tatsächlich verwendeten Raspberry Pi; im Beispiel Raspberry Pi 2.
2. Öffne die Betriebssystemauswahl. Je nach Oberfläche findest Du Lite unter den weiteren Raspberry-Pi-OS-Varianten.
3. Wähle Raspberry Pi OS Lite (32-bit) für unseren Aufbau.
4. Wähle die microSD-Karte als Speichermedium. Prüfe Größe und Gerätebezeichnung.

Lite enthält keine grafische Desktopoberfläche. Für den NUT-Server genügt die Verwaltung über die Kommandozeile.

4.4 Ersten Start vorbereiten

Öffne die OS-Anpassungen beziehungsweise den Einrichtungsdialog und trage ein:

Verlasse Dich nicht auf alte Standardzugänge wie pi/raspberry. Merke Dir den von Dir angelegten Benutzer. Das Linux-Passwort ist später nicht automatisch das NUT-Clientpasswort.

4.5 Karte schreiben

1. Prüfe alle Einstellungen und bestätige das Löschen des gewählten Mediums.
2. Starte das Schreiben.
3. Lass die anschließende Verifikation vollständig durchlaufen.
4. Wirf die Karte sicher aus, sofern das Programm das nicht bereits erledigt hat.
5. Entnimm die Karte und stecke sie bei ausgeschaltetem Pi in dessen microSD-Steckplatz.

5. Raspberry Pi starten und per SSH verbinden

5.1 Verkabeln

Verbinde den Pi per Ethernet mit Deinem Netzwerk. Schließe das passende Netzteil an und lasse den ersten Start einige Minuten laufen. Die USV-Datenverbindung kannst Du bereits herstellen oder nach der Grundinstallation anschließen.

Der Pi soll am Ende mit seinem Netzteil an einem batteriegepufferten USV-Ausgang hängen. Ein späterer Test muss bestätigen, dass er bei einem Netzausfall tatsächlich weiterläuft.

5.2 IP-Adresse finden und reservieren

Öffne im Router beziehungsweise DHCP-Server die Geräte- oder Leaseliste und suche nach nut01. Prüfe bei mehreren ähnlichen Einträgen die MAC-Adresse. Weise dem Pi eine DHCP-Reservierung zu, im Beispiel 192.168.50.10. Die genaue Bezeichnung kann „immer dieselbe IPv4-Adresse zuweisen“ oder „statische DHCP-Zuordnung“ lauten.

Wenn der Pi noch seine alte Adresse verwendet, starte ihn nach dem Einrichten der Reservierung neu. Verwende bei den folgenden Schritten seine tatsächlich zugewiesene Adresse.

Eine feste Zuordnung ist wichtig: Ändert sich die Serveradresse, finden die Clients ihn nicht mehr. Die Reservierung verhindert außerdem nicht automatisch Adresskonflikte mit manuell konfigurierten Geräten – kontrolliere Deinen Adressplan.

5.3 Windows-Terminal oder PuTTY

Öffne unter Windows PowerShell beziehungsweise Terminal und verbinde Dich:

ssh nutadmin@192.168.50.10

Bei der ersten Verbindung wird der Hostschlüssel angezeigt. Vergleiche den Fingerabdruck bei erhöhtem Schutzbedarf über eine lokale Konsole; bestätige die Verbindung nur zum erwarteten Gerät. Gib anschließend das Linux-Passwort ein. Dass dabei keine Zeichen erscheinen, ist normal.

Alternativ funktioniert PuTTY: Host-IP eintragen, Port 22, Verbindungstyp SSH, dann mit nutadmin anmelden.

Bei „Connection refused“ sind häufig SSH noch deaktiviert oder der erste Start nicht abgeschlossen. Bei einer Zeitüberschreitung zuerst IP-Adresse, Kabel, VLAN und Firewall prüfen.

6. Betriebssystem vorbereiten

Alle folgenden Bash-Befehle laufen in der SSH-Sitzung des Pi. Führe sie einzeln aus und kontrolliere Fehlermeldungen. Das Zeichen eines Shell-Prompts gehört nicht zum Befehl.

6.1 System prüfen und aktualisieren

hostnamectl
cat /etc/os-release
timedatectl
ip -br address
ip route
sudo -v

Damit prüfst Du Hostname, Betriebssystem, Zeit, Netzwerk und sudo-Berechtigung. Falls nötig:

sudo hostnamectl set-hostname nut01
sudo timedatectl set-timezone Europe/Berlin
sudo apt update
sudo apt full-upgrade
sudo reboot

Lies vor der Bestätigung des Upgrades die geplanten Änderungen. Nach dem Neustart verbindest Du Dich erneut per SSH.

6.2 Dateien bearbeiten

Wir verwenden nano. Öffne eine Datei mit sudo nano /pfad/zur/datei. Speichern: Strg+O, danach Enter. Beenden: Strg+X. Konfigurationsblöcke gehören in die genannte Datei und werden nicht als Befehle ins Terminal eingefügt.

Vor Änderungen an einer bereits vorhandenen Einrichtung sichere /etc/nut in ein nur für root zugängliches Verzeichnis. Darin stehen später Kennwörter; solche Sicherungen gehören nicht in ein öffentliches Git-Repository.

7. NUT installieren und USB-Verbindung prüfen

7.1 Pakete installieren

sudo apt install nut-server nut-client usbutils nano openssl
apt policy nut-server nut-client

nut-client wird auch auf dem Server gebraucht: Der Pi überwacht seine eigene Stromversorgung mit upsmon.

7.2 USV anschließen

Verbinde den USB-Datenanschluss der USV mit dem Pi und prüfe:

lsusb

Im dokumentierten Aufbau wurde eine APC-USV mit der Kennung 051d:0003 erkannt. Bei anderen Modellen kann eine andere Kennung erscheinen. Das alleine bestätigt noch keinen funktionierenden NUT-Treiber.

Vergleiche das exakte USV-Modell mit der NUT Hardware Compatibility List. Unser Beispiel nutzt usbhid-ups. Andere Geräte brauchen gegebenenfalls einen anderen Treiber oder zusätzliche Parameter. USB-Steckerform und Herstellername reichen für die Auswahl nicht aus.

8. NUT-Server konfigurieren

Wir richten zuerst den echten USB-Treiber, danach Datenserver, Benutzer und lokalen Monitor ein. Die Beispiele setzen eine frische Installation mit einer USV voraus. Bereits aktive Einträge in vorhandenen Dateien werden angepasst; dieselbe Direktive nicht unkontrolliert mehrfach ergänzen.

8.1 Servermodus: /etc/nut/nut.conf

sudo nano /etc/nut/nut.conf

Aktive Einstellung:

MODE=netserver

8.2 USB-Treiber: /etc/nut/ups.conf

sudo nano /etc/nut/ups.conf

Für unser Modell:

[ups]
    driver = usbhid-ups
    port = auto
    desc = "USB-USV am Raspberry Pi"

Der Abschnittsname ups wird später in allen Abfragen verwendet. port = auto ist hier die passende USB-Einstellung. Falls mehrere kompatible USB-USVs angeschlossen sind, muss die Zuordnung beispielsweise über Seriennummer oder unterstützte USB-Filter eindeutig erfolgen. Siehe ups.conf und usbhid-ups.

8.3 Listener: /etc/nut/upsd.conf

sudo nano /etc/nut/upsd.conf

Für die reservierte Beispieladresse:

LISTEN 127.0.0.1 3493
LISTEN 192.168.50.10 3493

Die Loopback-Adresse wird für den lokalen Monitor gebraucht. Die zweite Adresse ermöglicht den Netzwerkzugriff. Der Pi muss diese Adresse beim Dienststart besitzen. Eine Bindung an 0.0.0.0 würde alle IPv4-Schnittstellen umfassen; für diesen festen Aufbau verwenden wir bewusst die konkrete Adresse. Die Listener-Konfiguration ersetzt keine Firewall. Quelle: upsd.conf.

8.4 Kennwörter erzeugen

Erzeuge zwei unterschiedliche Kennwörter, jeweils mit einem separaten Aufruf:

openssl rand -hex 24

Speichere sie im Passwortmanager. Die Hex-Ausgabe vermeidet Leerzeichen und problematische Sonderzeichen in den folgenden Konfigurationen. Die Platzhalter PRIMARY_PASSWORT_ERSETZEN und CLIENT_PASSWORT_ERSETZEN in dieser Anleitung sind niemals produktive Kennwörter.

8.5 Benutzer: /etc/nut/upsd.users

sudo nano /etc/nut/upsd.users

[upsmon_local]
    password = PRIMARY_PASSWORT_ERSETZEN
    upsmon primary

[upsmon_clients]
    password = CLIENT_PASSWORT_ERSETZEN
    upsmon secondary

Der Primary-Zugang bleibt ausschließlich auf dem Pi. Frei konfigurierbare Clients bekommen Secondary-Rechte. Sie erhalten keine zusätzlichen Rechte für Instant Commands oder Variablenänderungen. Ein gemeinsames Secondary-Konto ist für ein kleines vertrauenswürdiges Netz möglich; getrennte Konten erleichtern Sperrung und Kennwortwechsel einzelner Clients. Quelle: upsd.users.

8.6 Lokaler Monitor: /etc/nut/upsmon.conf

sudo nano /etc/nut/upsmon.conf

Passe die vorhandenen aktiven Einträge an:

MONITOR ups@127.0.0.1 1 upsmon_local PRIMARY_PASSWORT_ERSETZEN primary
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h now"
POWERDOWNFLAG /etc/killpower
HOSTSYNC 15
FINALDELAY 5

Das Primary-Passwort muss exakt zum vorherigen Benutzer passen. 1 beschreibt die durch diese USV gespeiste Stromversorgung. MINSUPPLIES 1 verlangt eine verfügbare Versorgung. Der Pi muss dafür physisch an dieser USV hängen.

HOSTSYNC ist die maximale Wartezeit auf das Abmelden der Secondary-Monitore. Das Abmelden ist keine verlässliche Bestätigung, dass jedes Betriebssystem bereits vollständig heruntergefahren ist. FINALDELAY ist eine Verzögerung vor dem lokalen Shutdown-Befehl. Die hier gezeigten Werte sind Ausgangswerte, keine fertige Zeitplanung für ESXi und NAS. Siehe Kapitel 10 und 16 sowie upsmon.conf.

POWERDOWNFLAG markiert eine beabsichtigte USV-Abschaltung. Ob der Paket-Shutdown-Hook die Marke auswertet und den richtigen Abschaltbefehl an die USV sendet, gehört zur End-to-End-Prüfung. Ein normaler Pi-Shutdown garantiert weder das Ausschalten der USV-Ausgänge noch den späteren Neustart aller Geräte.

8.7 Dateirechte

sudo chown root:nut /etc/nut/upsd.users /etc/nut/upsmon.conf
sudo chmod 640 /etc/nut/upsd.users /etc/nut/upsmon.conf

Diese Dateien müssen für die erforderlichen NUT-Prozesse lesbar sein, aber nicht für beliebige lokale Benutzer. Keine pauschalen chmod 777-Freigaben verwenden.

8.8 Dienste starten

NUT-Pakete können unterschiedliche systemd-Treibereinbindungen mitbringen. Prüfe zuerst die tatsächlich vorhandenen Units:

systemctl list-unit-files 'nut*'

Wenn nut-driver-enumerator.service vorhanden ist, lässt Du ihn nach der Konfigurationsänderung die Treiberinstanzen erzeugen beziehungsweise abgleichen:

sudo systemctl restart nut-driver-enumerator.service

Danach:

sudo systemctl enable nut-server.service nut-monitor.service
sudo systemctl restart nut-server.service
sudo systemctl restart nut-monitor.service
systemctl --no-pager --full status nut-server.service nut-monitor.service
systemctl --no-pager --full list-units 'nut-driver*'

Wenn das Paket stattdessen einen klassischen nut-driver.service verwendet, starte diesen gemäß der installierten Paketdokumentation vor dem Datenserver. upsdrvctl start ist für manuelle Fehlersuche verfügbar; starte aber keinen zweiten Treiber parallel zu einer bereits laufenden systemd-Instanz. Hintergründe: Driver services.

8.9 Daten und Anmeldung kontrollieren

upsc ups@127.0.0.1
upsc ups@127.0.0.1 ups.status
sudo journalctl -u nut-server -u nut-monitor -b --no-pager -n 100

Im Netzbetrieb erwarten wir OL. Ein Status kann mehrere durch Leerzeichen getrennte Merkmale enthalten. Achte in den Logs auf Authentifizierungsfehler, falsche USV-Namen und Verbindungsprobleme. Ein laufender Dienst reicht als Nachweis nicht aus.

upsc ist primär eine Datenabfrage. Eine erfolgreiche Abfrage beweist nicht, dass der Monitor sich mit seinem Benutzer erfolgreich als Primary oder Secondary anmelden kann. Erst die Client-/Monitorprüfung und der spätere FSD-Test prüfen diesen Teil.

9. Netzwerkzugriff begrenzen und testen

Der NUT-Port gehört in ein vertrauenswürdiges lokales Netz oder ein kontrolliertes Managementnetz. Richte keine Internet-Portfreigabe für TCP 3493 ein. Die Beispielkonfiguration richtet keine TLS-Verschlüsselung ein; behandle Übertragung und gespeicherte Zugangsdaten entsprechend.

9.1 Beispiel mit nftables auf einem frischen Pi

Dieser Abschnitt gilt für einen frischen Pi ohne andere Firewallverwaltung. Bei UFW, firewalld oder vorhandenen nftables-Regeln wird die Freigabe in das bestehende Regelwerk integriert. Mehrere unabhängige Basisketten können sich gegenseitig beeinflussen.

sudo apt install nftables
sudo nano /etc/nftables.conf

Füge bei einer frischen Konfiguration folgende Tabelle ein. Wenn die Datei bereits Regeln enthält, ersetze sie nicht blind. Insbesondere kein pauschales flush ruleset ergänzen.

table inet nut_guard {
    chain input {
        type filter hook input priority 0; policy accept;
        iifname "lo" tcp dport 3493 accept
        ip saddr { 192.168.50.20, 192.168.50.30, 192.168.50.40, 192.168.50.50 } tcp dport 3493 accept
        tcp dport 3493 drop
    }
}

Trage nur tatsächlich benötigte Clientadressen ein. Diese Kette begrenzt ausschließlich NUT-Zugriffe; sie ist keine allgemeine Host-Firewall und lässt beispielsweise SSH unverändert zu. Die letzte Regel sperrt für diesen Port auch nicht ausdrücklich erlaubte IPv6-Verbindungen.

Syntax prüfen, Dienst aktivieren und bei der erstmaligen Einrichtung laden:

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo nft list table inet nut_guard

Falls nftables vorher schon lief, lädt enable --now Änderungen nicht automatisch neu. In dieser frischen Beispielkonfiguration kannst Du eine bereits vorhandene eigene nut_guard-Tabelle gezielt löschen und die Datei neu laden; bei anderen bestehenden Regeln ist deren vorgesehener Reload-Weg zu verwenden. Lasse dabei die SSH-Sitzung geöffnet. Wiederhole nach einem Pi-Neustart die Regel- und Portprüfung.

9.2 Vom Windows-PC testen

Test-NetConnection 192.168.50.10 -Port 3493

TcpTestSucceeded : True bestätigt nur die TCP-Verbindung. Der Test prüft weder Monitor-Anmeldung noch Herunterfahren. Bei False auf dem Pi prüfen:

sudo ss -ltnp 'sport = :3493'
sudo nft list ruleset

Wenn möglich, teste zusätzlich von einer nicht freigegebenen Adresse: Dort muss der NUT-Port gesperrt sein.

10. Wann wird heruntergefahren?

10.1 Die wichtigsten Zustände

OB allein bedeutet in unserer Grundkonfiguration noch keinen sofortigen Shutdown. Kritisch wird normalerweise OB zusammen mit LB; FSD kann die Abschaltung auch gezielt früher auslösen. Maßgeblich sind upsmon und die konkrete Clientimplementierung.

10.2 Ein ausgelesener Grenzwert ist noch keine Abschaltstrategie

Im Labor wurden unter anderem 100 Prozent Akkuladung, 16.200 Sekunden geschätzte Laufzeit sowie Low-Battery-Werte von 10 Prozent und 120 Sekunden ausgelesen. Das war eine Beobachtung im Netzbetrieb und kein Nachweis für die Laufzeit unter produktiver Last.

Für Deine Umgebung gilt:

• Herstellerwerte und gemeldete Restlaufzeit können ungenau sein.
• Fehlende Messwerte sind nicht automatisch null. Eine Anzeige von „0 W“ ist ohne vorhandene Last-Telemetrie nicht belastbar.
• Ein ausgelesener battery.runtime.low-Wert löst nicht bei jeder Treiber-/USV-Kombination automatisch die gewünschte Serverlogik aus.
• Die verbleibende Laufzeit muss den kompletten Abschaltweg einschließlich Reserven abdecken.

Wenn die USV zu spät LB meldet, kannst Du unterstützte Schwellwerte nach Prüfung anpassen oder frühzeitig einen Timer verwenden. Nicht einfach Variablen mit override.* überschreiben und davon ausgehen, dass daraus ein echtes Low-Battery-Ereignis entsteht. Die konkrete Treiberlogik muss dazu passen.

10.3 Zeitsteuerung ist nicht gleich Abhängigkeitssteuerung

Ein Client kann schon nach einer definierten Akkubetriebszeit herunterfahren. Ein anderer wartet auf FSD. Das kann sinnvoll sein, muss aber zusammen geplant werden. Ein zu früh abgeschaltetes NAS kann VMs den Speicher entziehen; ein zu früh abgeschalteter Pi verliert die Fähigkeit, weitere Meldungen auszuliefern.

Ein größeres HOSTSYNC setzt lediglich eine höhere maximale Wartezeit. Wenn alle Monitore sich früh abmelden, kann der Primary trotzdem früh fortfahren. Für eine nachgewiesene Mindestwartezeit braucht es eine passend ausgelegte Verzögerung oder einen geprüften Orchestrierungsablauf. Auf NUT 2.8.1 stehen zudem nicht automatisch alle Optionen neuerer Online-Handbücher zur Verfügung. Prüfe lokal man upsmon.conf.

11. Optional: zentraler Abschalttimer

Wenn Du nach beispielsweise drei Minuten kontinuierlichem Akkubetrieb zentral FSD auslösen möchtest, kannst Du upssched einsetzen. Die 180 Sekunden sind ein Demonstrationswert. Aktiviere diesen Abschnitt erst, wenn danach noch genug Akkuzeit für sämtliche Shutdowns bleibt.

Der Timer gilt für alle auf FSD reagierenden Clients. Er ersetzt keine Reihenfolge für voneinander abhängige Systeme. Vorhandene Benachrichtigungsskripte müssen integriert werden, statt einen bestehenden NOTIFYCMD ungeprüft zu überschreiben.

11.1 Pfad prüfen und Laufzeitverzeichnis anlegen

command -v upssched

Auf unserem Debian-basierten Beispiel erwarten wir /usr/sbin/upssched. Falls Dein Paket einen anderen Pfad meldet, verwende diesen.

sudo nano /etc/tmpfiles.d/nut-upssched.conf

Inhalt:

d /run/nut/upssched 0750 nut nut -

sudo systemd-tmpfiles --create /etc/tmpfiles.d/nut-upssched.conf

11.2 Timer konfigurieren

Öffne /etc/nut/upssched.conf und setze:

CMDSCRIPT /etc/nut/upssched-cmd
PIPEFN /run/nut/upssched/upssched.pipe
LOCKFN /run/nut/upssched/upssched.lock
AT ONBATT ups@127.0.0.1 START-TIMER outage-shutdown 180
AT ONLINE ups@127.0.0.1 CANCEL-TIMER outage-shutdown

Die USV-Bezeichnung muss zur lokalen MONITOR-Zeile passen. Bei einer späteren Umbenennung wird sie hier ebenfalls geändert. Aufbau und Timeroptionen: upssched.conf.

11.3 Aktionsskript anlegen

sudo nano /etc/nut/upssched-cmd

#!/bin/sh
case "$1" in
    outage-shutdown)
        logger -t nut-upssched "Abschalttimer abgelaufen; fordere lokalen FSD an"
        /usr/sbin/upsmon -c fsd
        ;;
    *)
        logger -t nut-upssched "Unbekannte Aktion: $1"
        ;;
esac

sudo chown root:nut /etc/nut/upssched-cmd
sudo chmod 750 /etc/nut/upssched-cmd

upsmon -c fsd ist eine Steueranfrage an den lokalen Monitor und erfordert passende Rechte. Das aus dem Monitor gestartete Skript läuft typischerweise als nut; ob diese Paketinstallation die Steueranfrage so zulässt, muss geprüft werden. Nicht mit pauschalen sudo-Rechten für Shellskripte lösen.

11.4 Benachrichtigungen aktivieren und erst ohne Shutdown testen

In /etc/nut/upsmon.conf ergänzen beziehungsweise vorhandene Einträge anpassen:

NOTIFYCMD /usr/sbin/upssched
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC

Für den ersten Timer-Test kommentierst Du im Skript die Zeile mit upsmon -c fsd aus. Passe die Logmeldung dafür zu „Testtimer abgelaufen; kein FSD“ an. Starte den Monitor neu und prüfe bei einem kurzen geplanten Netzausfall, ob Start und Abbruch funktionieren. Für den Ablauf-Test lasse den Demonstrationstimer kontrolliert auslaufen; es darf dann nur ein Logeintrag entstehen.

sudo systemctl restart nut-monitor
sudo journalctl -t nut-upssched --no-pager -n 30

Erst nach dieser Prüfung wird die FSD-Zeile wieder aktiviert und der echte Abschaltversuch im Wartungsfenster durchgeführt. Wenn Du den optionalen Timer nicht brauchst, lasse NOTIFYCMD, die EXEC-Anpassungen und diesen gesamten Zusatz weg. Grundlagen: upssched.

12. Windows als NUT-Client

Im dokumentierten Labor wurde WinNUT Client verwendet. Seine lokale Schwellenaktion hat Windows erfolgreich heruntergefahren. Die FSD-Folge war bei diesem Einzeltest ausgeschaltet; ein erfolgreicher FSD-Test lässt sich daraus nicht ableiten.

12.1 Installation und Verbindung

1. Öffne das WinNUT-Projekt und dessen Releases.
2. Lade ein geeignetes veröffentlichtes Installationspaket, nicht versehentlich nur das Quellcode-ZIP.
3. Prüfe die Voraussetzungen der gewählten Version.
4. Installiere mit lokalen Administratorrechten.
5. Öffne die Verbindungseinstellungen und trage ein:

Speichere die Einstellungen und verbinde Dich. Der angezeigte Zustand muss zu upsc auf dem Pi passen. Kontrolliere besonders USV-Name und Passwort, falls nur der Porttest funktioniert.

12.2 Abschaltung einstellen

Wähle als Aktion Herunterfahren und aktiviere Follow FSD signal beziehungsweise die entsprechende FSD-Folgeoption. Die Projektänderungen dokumentieren, dass diese Option eigens aktiviert werden muss: WinNUT Changelog.

Zusätzliche Prozent- oder Laufzeitschwellen sind möglich, lösen aber gegebenenfalls vor dem zentralen FSD aus. Stimme sie mit der Gesamtplanung ab. Hohe Werte wie 99 Prozent gehören ausschließlich zu einem beaufsichtigten Einzeltest und müssen danach entfernt werden. Eine kurze Countdownzeit ist kein Ersatz für genügend Akkureserve.

12.3 Läuft der Schutz ohne Benutzeranmeldung?

Prüfe ausdrücklich den Startmodus Deiner WinNUT-Version. Ein Autostart im Benutzerprofil läuft gegebenenfalls erst nach dem Login; eine Anwendung im Infobereich ist nicht automatisch ein Windows-Dienst. Nutze einen von der jeweiligen Veröffentlichung dokumentierten Dienstmodus, falls vorhanden. Ein solcher Modus wird hier nicht für jede Version vorausgesetzt.

Teste nach einem Neustart ohne Benutzeranmeldung, ob der Monitor tatsächlich aktiv ist und herunterfahren kann. Wenn das verwendete Paket nur nach Benutzeranmeldung arbeitet, dokumentiere diese Einschränkung und verwende für unbeaufsichtigte Server einen nachweislich geeigneten Dienstclient. Projektbeispiel für einen separaten Dienstansatz: NUTService; Konfiguration und Freigabe gehören in einen eigenen Versionstest.

12.4 Windows-Test

Schließe Anwendungen und speichere Daten. Prüfe zunächst die Statusänderung OL zu OB und zurück. Danach testest Du eine lokale Abschaltaktion und abschließend die aktivierte FSD-Folge. Nach dem Start kontrollierst Du Ereignisanzeige und Clientlog. Ein heruntergefahrener PC an einer normalen Steckdose beweist nur den Softwareweg, nicht die Batterieversorgung.

13. VMware ESXi als NUT-Client

ESXi ist kein Debian-Linux: Hier lässt sich kein apt install nut-client ausführen. Für einen einzelnen Standalone-Host gibt es das Communityprojekt NutClient-ESXi von René Garcia. Es ist kein von VMware/Broadcom freigegebener Standardbestandteil.

Geltungsbereich: Der folgende Weg ist für einen kompatiblen Standalone-Host vorgesehen. Die Projektdokumentation warnt ausdrücklich vor der Nutzung auf HA-Clusterknoten. Für Cluster, vSAN oder komplexe Speicherabhängigkeiten brauchst Du eine dafür ausgelegte Abschaltlösung.

13.1 Vorbereitungen

1. Sichere Hostkonfiguration und VMs und vereinbare ein Wartungsfenster.
2. Notiere ESXi-Version, Build, CPU-Architektur und Secure-Boot-Status.
3. Prüfe die Kompatibilität und Installationsvoraussetzungen des konkreten Community-Releases. Ein Dateiname ist kein Nachweis, dass es mit Deinem Build unterstützt ist.
4. Installiere beziehungsweise prüfe VMware Tools oder open-vm-tools in jeder VM.
5. Teste das geordnete Gast-Herunterfahren über die Hostoberfläche.
6. Konfiguriere VM-Autostart/-Shutdown, Reihenfolge, Shutdown-Aktion und ausreichende Verzögerungen passend zu Deiner Umgebung.
7. Prüfe, ob die VM-Datastores lokal oder auf einem NAS liegen. Speicher muss bis zum Ende verfügbar bleiben.

13.2 Paket übertragen und installieren

Lade das passende Offline-Bundle aus den Releases des Projekts herunter. Das zum Recherchezeitpunkt dokumentierte x86_64-Beispiel ist:

NutClient-ESXi-2.8.5-2.7.3-x86_64-offline_bundle.zip

Aktiviere SSH zeitlich begrenzt am Host und übertrage die Datei beispielsweise mit WinSCP nach /tmp. Melde Dich per SSH am Host an und installiere das tatsächlich übertragene Bundle:

esxcli software vib install -d /tmp/NutClient-ESXi-2.8.5-2.7.3-x86_64-offline_bundle.zip

Die Versionszahlen sind ein konkretes Dokumentationsbeispiel. Bei einem anderen Release muss der Pfad dessen tatsächlichem Dateinamen entsprechen. Beachte das Installationsergebnis und einen gegebenenfalls geforderten Neustart. Bei Signatur-, Acceptance-Level- oder Secure-Boot-Problemen nicht blind Sicherheitsprüfungen abschalten oder --force verwenden.

13.3 NUT-Parameter und Dienst

Im Host Client unter Host → Verwalten → System → Erweiterte Einstellungen nach UserVars.Nut filtern:

Unter Dienste den NutClient starten und „Mit dem Host starten und beenden“ aktivieren. Nach Parameteränderungen den Dienst neu starten. Die Angaben und Feldnamen stammen aus der Projekt-README.

13.4 Kontrolle

Prüfe die Verbindung und Logs auf beiden Seiten. Führe den ersten Host-Abschalttest mit Test-VMs durch und miss, ob alle Gäste geordnet beendet werden. Danach prüfst Du, dass Konfiguration und Dienststart auch nach einem Hostneustart erhalten bleiben. Deaktiviere SSH nach Abschluss wieder.

Wenn ein NAS den Datastore bereitstellt, genügt es nicht, gleichzeitig auf beiden Geräten einen Shutdown auszulösen. Diese Konstellation wird erst freigegeben, wenn die Speicherreihenfolge im Gesamttest nachgewiesen ist.

14. Synology als Netzwerk-USV-Client

DSM bietet eine integrierte Netzwerk-USV-Funktion. Die offizielle Beschreibung bezieht sich auf einen Synology-USV-Server. Ein Raspberry Pi als Gegenstelle ist dadurch nicht pauschal herstellerseitig zugesichert. Zusätzlich kann DSM USV-Name und Monitor-Zugang fest vorgeben; diese Felder lassen sich nicht wie bei WinNUT beliebig in der GUI eintragen.

Deshalb gibt es hier zwei Stufen: GUI-Einrichtung und gegebenenfalls ein versionsabhängiger Kompatibilitätsabgleich. Die zweite Stufe sollte ein Administrator durchführen. Eine allgemeingültige Klickanleitung für jede DSM-Version wäre fachlich nicht belastbar.

14.1 GUI einrichten

1. Melde Dich mit Administrationsrechten an DSM an.
2. Öffne Systemsteuerung → Hardware & Energie → USV.
3. Aktiviere die USV-Unterstützung.
4. Wähle als Verbindung den Netzwerk-/Synology-USV-Server, soweit Deine DSM-Version diese Auswahl anbietet.
5. Trage die Pi-Adresse 192.168.50.10 ein.
6. Konfiguriere das Verhalten bei Stromausfall entsprechend dem verfügbaren Zeitbudget.
7. Übernimm die Einstellungen und prüfe, ob USV-Informationen angezeigt werden.

Der Begriff „Standby“ beziehungsweise der frühere „sichere Modus“ beschreibt je nach DSM-Version das Stoppen von Diensten und sichere Aushängen von Volumes; er ist nicht mit dem sofortigen vollständigen Ausschalten gleichzusetzen. Prüfe die Beschreibung Deiner Firmware. Offizielle Hilfe: DSM USV.

14.2 Wenn DSM keine Verbindung bekommt

Prüfe zuerst Firewall und Erreichbarkeit. Wenn das stimmt, gleiche die tatsächlich von DSM benutzte Monitor-Konfiguration ab, statt vermeintlich universelle Standardpasswörter aus Foren zu übernehmen.

Für diesen Abgleich SSH in DSM zeitlich begrenzt aktivieren und als berechtigter Administrator verbinden. Eine häufig verwendete Konfigurationsdatei ist:

sudo ls -l /usr/syno/etc/ups/upsmon.conf

Existiert sie auf Deiner Version, lies die aktive MONITOR-Zeile ausschließlich in Deiner lokalen Sitzung:

sudo awk '$1 == "MONITOR" { print }' /usr/syno/etc/ups/upsmon.conf

Die Ausgabe kann ein Passwort enthalten. Nicht in Screenshots, Tickets oder öffentliche Beiträge kopieren. Falls die Datei fehlt oder keine aktive Zeile enthält, nicht mit beliebigen Systemänderungen weitermachen. Nutze die versionsspezifische Dokumentation oder Herstellerunterstützung.

Die allgemeine Syntax lautet:

MONITOR GERÄTENAME@SERVER 1 BENUTZER PASSWORT slave

Das ältere Wort slave in einer herstellergenerierten Konfiguration ist für sich genommen kein Fehler. Wichtig sind tatsächlicher Gerätename, Benutzer und Passwort. Bei unserem Basisaufbau heißt die USV bereits ups; prüfe, ob DSM genau diesen Namen erwartet.

Wenn DSM einen abweichenden festen Monitor-Benutzer verwendet, ergänze auf dem Pi in /etc/nut/upsd.users ein passendes Konto mit upsmon secondary. Übernimm den lokal geprüften Namen und das tatsächlich erwartete Kennwort, nicht den Platzhalter:

[DSM_BENUTZER_ERSETZEN]
    password = DSM_KENNWORT_ERSETZEN
    upsmon secondary

Wenn die Firmware ein schwaches festes Kennwort erzwingt, dokumentiere diese Einschränkung und begrenze den Netzwerkzugriff strikt. Die Secondary-Rolle ist kein vollständiger Schutz vor Manipulationen bei kompromittiertem Zugang.

Starte nut-server auf dem Pi neu, wende die DSM-Einstellungen erneut an und prüfe die Monitor-Anmeldung. Ändere nicht dauerhaft die von DSM erzeugte Datei: Sie kann nach GUI-Änderungen, Neustarts oder Updates überschrieben werden. Deaktiviere SSH nach dem Abgleich wieder.

14.3 Funktionsprüfung

Prüfe Statuswechsel, sicheren Zustand, FSD-Reaktion und Wiederanlauf mit der exakten DSM-Version. Notiere, ob DSM nach einem eigenen Timer reagiert und ob es bei zurückkehrender Netzspannung den Betrieb wieder aufnimmt. Wenn die Synology VM-Speicher bereitstellt, darf sie ihre Volumes nicht aushängen, solange VMs darauf schreiben.

Teststand: Die Integration mit einem konkreten DSM-Release, dessen Zugangskonventionen und FSD-Verhalten wurde nicht praktisch geprüft.

15. QNAP als Netzwerk-USV-Client

QTS und QuTS hero bieten die Betriebsart Network UPS slave. Auch hier beschreibt die Herstellerdokumentation primär den Betrieb mit einem passenden Netzwerk-USV-Master; freie NUT-Parameter sind nicht auf jeder Oberfläche verfügbar.

15.1 GUI einrichten

1. Melde Dich an QTS beziehungsweise QuTS hero an.
2. Öffne Systemsteuerung → System → Externes Gerät → USV; der Menüpfad kann abweichen.
3. Aktiviere die USV-Unterstützung, falls separat angeboten.
4. Wähle Network UPS slave beziehungsweise Netzwerk-USV-Slave.
5. Trage 192.168.50.10 als Serveradresse ein.
6. Wähle ein geplantes Verhalten bei Stromausfall, etwa Herunterfahren oder den angebotenen Schutzmodus nach einer Wartezeit.
7. Speichere und prüfe, ob USV-Daten ankommen.

Ein angebotener Auto-Protection-Modus ist nicht automatisch ein kompletter Shutdown. Prüfe in Deiner Firmware, welche Dienste und Volumes dabei gestoppt werden. Offizielle Einstiegsquellen sind das QTS-5.2-Handbuch und die QuTS-hero-USV-Einstellungen.

15.2 Namen und Zugang prüfen

Wenn der Port erreichbar ist, die Verbindung aber scheitert, prüfe wie bei DSM die tatsächlich generierten NUT-Parameter. Aktiviere SSH vorübergehend und suche zunächst nur in den üblichen USV-Konfigurationspfaden:

sudo ls -l /etc/config/ups/upsmon.conf /etc/ups/upsmon.conf

Eine „Datei nicht gefunden“-Meldung für einen der Pfade ist möglich. Verwende nur die vorhandene aktive Datei. Beispielsweise:

sudo awk '$1 == "MONITOR" { print }' /etc/config/ups/upsmon.conf

Falls die Anmeldung bereits eine Root-Sitzung ist und sudo nicht existiert, wird der Lesebefehl ohne sudo ausgeführt. Auch diese Ausgabe enthält möglicherweise ein Passwort und bleibt lokal.

Lies daraus Gerätename, NUT-Benutzer und Kennwort ab. Ergänze auf dem Pi gegebenenfalls ein entsprechendes Secondary-Konto wie im DSM-Kapitel. Ändere keine NAS-Systemdateien dauerhaft, nur damit die erste Verbindung klappt; solche Änderungen können bei einem Update verloren gehen.

15.3 Abweichender fest vorgegebener USV-Name

Erwartet Deine Firmware beispielsweise einen anderen Namen als ups, gibt es keinen automatischen Alias allein dadurch, dass IP und Passwort stimmen. Bei einem Aufbau, in dem alle anderen Clients frei konfigurierbar sind, kannst Du den echten USV-Abschnitt auf dem Pi entsprechend umbenennen.

Dabei müssen alle Verweise angepasst werden: Abschnitt in ups.conf, lokale MONITOR-Zeile, optionale Timer-Regeln und sämtliche Clientkonfigurationen. Danach Treiberinstanzen abgleichen, Server und Monitore neu starten und erneut testen. Lege nicht zwei usbhid-ups-Treiber an, die auf dieselbe USB-USV zugreifen.

QNAP und Synology gemeinsam: Falls beide Firmwares unterschiedliche unveränderliche Gerätenamen verlangen, reicht die einfache Ein-USV-Konfiguration dieses Beitrags nicht für beide nativen Clients gleichzeitig. Ein getesteter Repeater-/Proxy-Aufbau oder eine andere unterstützte Integration ist dann nötig. Eine solche Erweiterung muss Status, FSD-Weitergabe und Powerdown-Verhalten nachweislich korrekt behandeln; ein bloßes zweites Geräteetikett genügt nicht. Dieser Sonderaufbau ist nicht Bestandteil dieser Anleitung.

15.4 Funktionsprüfung

Teste nach erfolgreicher Anmeldung den Statuswechsel, die konfigurierte Aktion, FSD-Reaktion und einen Neustart des NAS. Prüfe anschließend erneut die Verbindung, damit eine nur temporär funktionierende Konfiguration auffällt. Bei iSCSI-/NFS-Datastores muss die Abschaltung mit dem ESXi-Host abgestimmt sein.

Teststand: Die Integration mit einer konkreten QTS-/QuTS-hero-Version und deren Zugangskonventionen wurde nicht praktisch geprüft. Teste die Zusammenarbeit vor dem produktiven Einsatz.

16. Den kompletten Ablauf testen

Ein Porttest und ein grünes USV-Symbol genügen nicht. Die Abnahme besteht aus mehreren getrennten Tests. Sichere Daten, beende kritische Arbeiten und plane Zugriff auf alle Systeme vor Ort ein. Ein FSD-Test kann sämtliche verbundenen Geräte herunterfahren.

16.1 Stufe 1: Zustand im Netzbetrieb

Prüfe OL, aktuelle Daten, aktive Dienste und erfolgreiche Monitor-Anmeldungen. Starte Pi und Clients einzeln neu und kontrolliere Autostart und Konfiguration. Nach einem Pi-Neustart muss auch die Firewall wieder aktiv sein.

16.2 Stufe 2: kurzer Akkubetrieb ohne geplanten Shutdown

Verwende die vom USV-Hersteller vorgesehene Testmethode. Ein Selbsttest muss nicht dieselben Statusereignisse auslösen wie ein echter Netzausfall. Falls für den Funktionstest die Netzversorgung unterbrochen wird, beachte die Herstelleranleitung und die elektrische Sicherheit; Schutzleiterverbindungen dürfen nicht unzulässig verloren gehen.

1. Kontrolliere vorher ausreichenden Akkustand und bekannte Last.
2. Lass USB, Pi-Netzteil, Switch und Clientversorgung angeschlossen.
3. Löse den vorgesehenen Netzausfalltest aus.
4. Prüfe auf dem Pi OB und auf allen Clients die entsprechende Meldung.
5. Stelle die Netzversorgung vor Ablauf aktiver Shutdown-Timer wieder her.
6. Prüfe die Rückkehr zu OL und den Abbruch optionaler Timer.

Eine unterbrochene USB-Verbindung ist ein Kommunikationsfehler und ersetzt diesen Test nicht.

16.3 Stufe 3: lokale Clientaktion

Teste jeden Client separat unter Aufsicht. Bei Windows ist das beispielsweise eine vorübergehende Testschwelle. Bei ESXi müssen alle Test-VMs geordnet herunterfahren. NAS-Systeme müssen ihren vorgesehenen sicheren Zustand erreichen. Stelle danach sämtliche Testwerte zurück.

16.4 Stufe 4: erzwungene zentrale Abschaltung

Achtung: Der folgende Befehl ist ein echter Abschaltbefehl. Er ist keine Simulation und kann den Pi sowie sämtliche FSD-folgenden Clients herunterfahren. Je nach Shutdown-Integration kann auch die USV-Ausgangsversorgung abgeschaltet werden. Erst im vorbereiteten Wartungsfenster ausführen.

Auf dem Pi:

sudo /usr/sbin/upsmon -c fsd

Prüfe vorab den lokalen Programmpfad, falls Dein Paket ihn anders installiert. Beobachte den Ablauf vor Ort; die SSH-Verbindung wird beim Pi-Shutdown abbrechen.

Notiere für jedes System Zeitpunkte von FSD-Empfang, Beginn der Abschaltung und vollständigem Ende. Kontrolliere besonders, ob NAS-Speicher verfügbar blieb, bis die letzten VM-Zugriffe beendet waren. Der Pi beziehungsweise sein Powerdown-Hook darf die gemeinsame Versorgung nicht vorzeitig trennen.

Zeitreserve korrigieren: Wenn ein Client seinen Monitor früh beendet, kann der Primary dessen abgeschlossenen Shutdown nicht daraus ableiten. Wähle eine nachgemessene ausreichend große Mindestverzögerung vor dem Pi-/USV-Powerdown, sofern noch genug Akkulaufzeit vorhanden ist, oder setze einen geeigneten Orchestrierungsablauf ein. Nur HOSTSYNC hochzusetzen löst dieses Problem nicht.

16.5 Stufe 5: realer Ausfall und Wiederanlauf

Ein erzwungener FSD bei vorhandenem Netz prüft noch nicht die Erkennung des echten kritischen Zustands oder eines Akkutimers. Ergänze deshalb den geplanten Test des tatsächlichen Ausfallpfads. Vermeide eine unnötige Tiefentladung.

Nach jedem Versuch kontrollieren:

• Ist die USV wieder stabil im Netzbetrieb?
• Wurde ein gesetztes FSD nach dem Wiederanlauf zurückgesetzt?
• Ist keine veraltete Powerdown-Markierung aktiv?
• Starten die Geräte in richtiger Reihenfolge?
• Verbinden sich alle Monitore wieder?
• Sind alle VMs, Freigaben und Anwendungen fehlerfrei verfügbar?

Ein FSD lässt sich nicht durch „Netzstecker wieder drin“ zuverlässig widerrufen. Nach einem abgebrochenen Test müssen Serverzustand und Powerdown-Markierung bewusst geprüft werden. Eine Markierungsdatei nur entfernen, wenn kein laufender Abschaltvorgang mehr darauf angewiesen ist. Details: upsmon – Testing shutdowns.

17. Wiederanlauf nach dem Stromausfall

Ein ausgeschalteter Rechner startet nicht zwangsläufig wieder, nur weil die USV inzwischen OL meldet.

Wenn die USV-Ausgänge nach dem OS-Shutdown durchgehend Spannung liefern, gibt es für ein ausgeschaltetes Gerät keinen neuen AC-Verlust-/AC-Restore-Zyklus. Genau deshalb muss die Kombination aus NUT-Shutdown-Hook und USV-Hardware getestet werden.

Plane die Rückkehr ebenfalls nach Abhängigkeiten: Netzwerk zuerst, dann Speicher, dann Virtualisierung und Anwendungen. Wiederholte kurze Stromrückkehr darf nicht zu ständigen Boot-/Shutdown-Zyklen mit leerem Akku führen. Ob eine Mindestladungsgrenze konfigurierbar ist, hängt vom USV-Modell ab.

18. Fehlersuche

USB-USV wird nicht gefunden

Prüfe lsusb, Datenkabel, USB-Port, USV-Schnittstelle und Treiberkompatibilität. Ein Ladekabel ohne Datenleitungen funktioniert nicht. Bei mehreren Strommanagementprogrammen kann ein anderer Prozess die USV bereits belegen.

USB-Zugriff verweigert

Prüfe installierte udev-Regeln und Gerätegruppe. Lade Regeln neu und stecke nur die USB-Datenverbindung neu an:

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=usb

Danach die verwaltete Treiberinstanz neu starten. Keine dauerhaften Welt-Schreibrechte auf /dev/bus/usb vergeben. In der Vorlage wurde ein USB-Rechteproblem auf diesem Weg mit anschließendem Neuanstecken behoben.

Driver not connected oder Data stale

Der Server ist möglicherweise erreichbar, hat aber keine aktuellen Treiberdaten. Prüfe:

systemctl --no-pager --full list-units 'nut*'
sudo journalctl -b --no-pager -u nut-server -u nut-monitor -n 100

Lies zusätzlich das Journal der tatsächlich aufgeführten Treiberinstanz. Erst die USB-/Treiberseite reparieren, dann Clientverbindungen bewerten.

Unknown UPS

Der verwendete Gerätename stimmt nicht mit dem Abschnitt in ups.conf überein. Zur Kontrolle:

upsc -l 127.0.0.1

Access denied oder Monitor-Anmeldung scheitert

Prüfe Benutzer, Kennwort, Rolle und Dateirechte. Nach Änderungen an upsd.users den Server neu starten. Datenabfrage und authentifizierte Monitor-Anmeldung sind unterschiedliche Tests.

Fatal error: insufficient power configured

Prüfe, ob die MONITOR-Zeile aktiv ist und ihr Power-Wert zu MINSUPPLIES passt. Für den hier gezeigten Pi mit einer USV gilt 1 und MINSUPPLIES 1. Ein Power-Wert 0 beschreibt reine Beobachtung und erfüllt diesen Bedarf nicht.

Pi lokal erreichbar, Clients nicht

Kontrolliere Listeneradresse, aktuelle Pi-IP, Firewall-Quelladressen, VLAN-Routing und TCP 3493. Prüfe nach DHCP-Änderungen auch die Clientkonfiguration. Wenn der Datenserver beim Boot an eine noch nicht vorhandene Adresse binden wollte, untersuche die Dienstlogs.

Init SSL without certificate database

Diese Meldung kann bei upsc erscheinen und bedeutet nicht automatisch einen fehlgeschlagenen Abruf. Beurteile, ob anschließend gültige Daten folgen. Sie ist ebenso wenig ein Nachweis, dass die Verbindung verschlüsselt ist.

Windows zeigt Werte, fährt aber nicht herunter

Prüfe FSD-Folge, gewählte Aktion, erforderliche Rechte und Startmodus ohne Login. Ein reiner Statusclient kann Daten anzeigen, ohne einen OS-Shutdown auszulösen.

NAS funktioniert nach Neustart oder Update nicht mehr

Prüfe, ob eine herstellergenerierte Datei überschrieben wurde oder sich feste Namen und Zugangskonventionen geändert haben. Die produktive Konfiguration muss einen Neustart überstehen; manuelle Änderungen an temporären Dateien erfüllen das nicht.

Geräte schalten ab, starten aber nicht wieder

Prüfe, ob tatsächlich ein Stromzyklus am jeweiligen USV-Ausgang stattfand. Unterscheide Betriebssystem-Halt, Abschaltung der Ausgangsgruppe und Wiederanlauf der Hardware.

19. Betrieb, Sicherung und Checkliste

Konfiguration sichern

Erstelle nach erfolgreicher Einrichtung eine geschützte Sicherung. Beispiel auf dem Pi:

sudo install -d -m 700 /root/nut-backup
sudo tar -czf /root/nut-backup/nut-config.tar.gz /etc/nut /etc/nftables.conf
sudo chmod 600 /root/nut-backup/nut-config.tar.gz

Bei aktivem Timer gehören außerdem /etc/tmpfiles.d/nut-upssched.conf und die dazugehörigen Skripte in die Sicherung. Kopiere das Archiv anschließend über einen geschützten Administrationsweg an einen sicheren anderen Ort; eine Sicherung nur auf derselben microSD schützt nicht vor deren Ausfall. Das Archiv enthält NUT-Kennwörter.

Regelmäßig kontrollieren

Prüfe Erreichbarkeit, aktuellen Status, Dienstzustand, Akkuzustand und Benachrichtigungen. Wiederhole einen passenden Funktionstest nach Änderungen an USV, Akku, NUT-Paket, NAS-Firmware, ESXi-Build oder Netzwerk. Veränderte Last und zusätzliche VMs können ein zuvor ausreichendes Zeitbudget aufbrauchen.

Abnahmecheckliste

• Pi-Modell, OS und NUT-Version dokumentiert.
• Exaktes USV-Modell und Treiber geprüft.
• Pi, relevante Netzwerkgeräte und Clients an batteriegepufferten Ausgängen.
• Pi-Adresse dauerhaft zugeordnet; Clientadressen für Firewall berücksichtigt.
• USB-Daten auch nach einem Pi-Neustart aktuell.
• Primary- und Secondary-Anmeldungen geprüft.
• NUT-Port nur für vorgesehene Quellen erreichbar.
• Windows-Schutz ohne Benutzeranmeldung geprüft.
• ESXi-VMs fahren geordnet herunter; keine unpassende HA-Konfiguration.
• NAS-Verbindungen überstehen Neustart und GUI-Neuanwendung.
• Storage-Abhängigkeiten berücksichtigt.
• Akkulaufzeit unter realistischer Last bewertet.
• FSD-Abschaltung und optionaler Timer praktisch geprüft.
• USV-Ausgangsabschaltung und Wiederanlauf getestet.
• Testschwellen entfernt und Betriebswerte dokumentiert.
• Geschützte Sicherung und Passwortverwaltung vorhanden.

Vorlage für Dein Testprotokoll

20. Offizielle Dokumentation und Downloads

Die Links sind nach Aufgaben gruppiert. Live-Dokumentation kann neuere Funktionen beschreiben als die auf Deinem Pi installierte NUT-Version. Für Optionen und Dienstnamen sind die lokalen Handbuchseiten und die Paketdokumentation Deiner Distribution entscheidend.

Raspberry Pi

• Raspberry Pi Imager und Betriebssysteme
• Raspberry Pi: Getting started
• Raspberry Pi: Remote Access
• PuTTY-Download beim Projekt

Network UPS Tools

• NUT-Projekt
• Hardware Compatibility List
• Benutzerhandbuch
• Konfigurationsgrundlagen und Treiberdienste
• USB-HID-Treiber
• ups.conf
• upsd.conf
• upsd.users
• upsmon.conf
• upsmon: Abschaltverhalten und Tests
• upssched
• upssched.conf
• Debian-Quellpaket der dokumentierten NUT-Version 2.8.1-5

Clients und NAS

• WinNUT Client: Projekt und Releases
• WinNUT: Änderungen und FSD-Folgeoption
• NUTService: separates Windows-Dienstprojekt
• NutClient-ESXi: Quellprojekt und Releases
• NutClient-ESXi: Installations- und Konfigurationshinweise
• Synology DSM: USV-Funktion
• Synology: USV-Kompatibilitätsliste
• QNAP QTS 5.2: offizielles Handbuch
• QNAP QuTS hero: USV-Einstellungen