Heimserver & Self-Hosting

USV-gesteuertes Herunterfahren eines Debian-Homeservers - Batterielaufzeit sicher nutzen

Geschrieben von Adam Muiz Aktualisiert: 14 Sep 2026 11 Min. gelesen
USV-gesteuertes Herunterfahren eines Debian-Homeservers - Batterielaufzeit sicher nutzen

Ein Homeserver kann einen kurzen Stromausfall nur überstehen, wenn weiterhin etwas Energie liefert. Doch das Überstehen ist nicht die hilfreichste Fragestellung. Wichtiger ist: Kann der Rechner erkennen, dass der Ausfall zu lange dauert, seine Schreibvorgänge abschließen, geordnet herunterfahren und zuverlässig zurückkehren, sobald die Netzversorgung wieder stabil ist?

Eine unterbrechungsfreie Stromversorgung (USV) kann das kurze Zeitfenster für diesen Ablauf bereitstellen. Die Batterie allein setzt ihn jedoch nicht in Gang. Der Server benötigt außerdem einen Kommunikationsweg, Software zur Interpretation des USV-Status und eine Abschaltrichtlinie, die mit der tatsächlichen Hardware getestet wurde. Ohne diese Bestandteile verzögert eine USV einen abrupten Stromverlust möglicherweise nur.

Dieser Artikel entwickelt einen hardwareunabhängigen Plan für einen Debian-Homeserver mit Network UPS Tools (NUT). Er erhebt keinen Anspruch über ein bestimmtes USV-Modell, eine Batterielaufzeit oder eine Installation auf Adams Server. Solche Details lassen sich ohne das Gerät, sein Handbuch, die Last und einen kontrollierten Test nicht zuverlässig ableiten.

Das Ziel ist ein geordnetes Ende, nicht maximale Laufzeit

Eine kleine USV wird oft so betrachtet, als müsse sie jeden Dienst möglichst lange verfügbar halten. Für einen Homeserver kann das das falsche Ziel sein. Bei einem längeren Ausfall verbraucht jede zusätzliche Minute Energie, die zum Beenden von Anwendungen, Abschließen von Schreibvorgängen, Aushängen von Dateisystemen und Herunterfahren des Betriebssystems benötigt werden könnte.

Vier Fragen, die Produktbezeichnungen häufig zu einer einzigen verdichten, sollten getrennt werden:

  • Kapazität: Kann die USV die angeschlossene Last versorgen, ohne überlastet zu werden?
  • Laufzeit: Wie lange bleibt bei der realen Last und dem aktuellen Batteriezustand nutzbare Batterieleistung verfügbar?
  • Kommunikation: Kann Debian von genau diesem Gerät und Treiber verlässliche Statusdaten erhalten?
  • Wiederanlauf: Kehren USV und Computer nach einem kontrollierten Herunterfahren in einen bekannten Zustand zurück, wenn die Netzversorgung wiederhergestellt ist?

Diese Fragen hängen zusammen, sind aber nicht austauschbar. Eine große Batterie belegt keine Softwarekompatibilität. Ein USB-Anschluss beweist nicht, dass NUT das Protokoll versteht. Ein erfolgreiches Herunterfahren beweist nicht, dass der Rechner wieder startet. Das praktische Ziel ist deshalb keine versprochene Minutenzahl, sondern ein gemessener Ablauf mit genügend Reserve, damit er auch bei alternder Batterie sicher abgeschlossen wird.

Den Strompfad vor der Softwareinstallation prüfen

Am Anfang steht eine Bestandsaufnahme. Erfasst werden sollten Server, Speichergeräte, Netzwerkkomponenten und alles Weitere, was für einen funktionierenden Abschaltpfad mit Strom versorgt bleiben muss. Erhält ein sekundärer Server seinen USV-Status beispielsweise über das Netzwerk, benötigt auch der beteiligte Switch während des Ereignisses Energie. Ein Monitor oder Drucker kann dagegen Batterie verbrauchen, ohne zu einem unbeaufsichtigten Herunterfahren beizutragen.

Die angeschlossenen Geräte sind mit beiden vom USV-Hersteller angegebenen Grenzen zu vergleichen, üblicherweise Watt und Voltampere (VA). Für Steckdosengruppen und unterstützte Lasten gilt das Gerätehandbuch. Eine grobe Summe der Typenschildwerte ist keine Laufzeitgarantie. Der tatsächliche Verbrauch ändert sich mit der Arbeitslast, bei der Umwandlung entstehen Verluste, der Batteriezustand verändert sich und Laufzeitkurven des Herstellers gelten für das jeweilige Modell.

Die Kommunikationsunterstützung verlangt dieselbe Sorgfalt. Der NUT-Konfigurationsleitfaden verweist bei der Treiberauswahl auf die Hardware Compatibility List. Dort sollte nach dem exakten Modell gesucht und die verknüpfte Treiberdokumentation gelesen werden. Selbst ausgewiesene Unterstützung bedeutet nicht zwangsläufig, dass jedes Telemetriefeld oder jeder Instant Command verfügbar ist. Eine belastbare Aussage entsteht erst durch Abfragen der angeschlossenen Einheit und Tests der für den Abschaltplan benötigten Funktionen.

Wie NUT die Aufgaben aufteilt

NUT ist ein Stack und kein einzelner allwissender Daemon. Der offizielle Konfigurationsleitfaden beschreibt drei relevante Schichten:

  • Ein Gerätetreiber kommuniziert über USB, seriell, SNMP oder ein anderes unterstütztes Protokoll mit der USV.
  • upsd liest den Treiberstatus, hält einen lokalen Cache und stellt die Daten autorisierten Clients bereit.
  • upsmon überwacht eine oder mehrere USV-Definitionen, löst Benachrichtigungen aus und ruft bei einer kritischen Stromsituation den Befehl zum Herunterfahren des Hosts auf.

Diese Trennung ist bei der Fehlersuche wichtig. Kann ein Treiber nicht mit der USV kommunizieren, repariert eine Änderung am Benachrichtigungsskript den Datenpfad nicht. Kann upsc plausible Werte lesen, aber das Herunterfahren beginnt nie, liegt der Fehler weiter hinten in der Kette. Ein stufenweiser Aufbau macht jede Grenze sichtbar.

Unter Debian und seinen Derivaten befindet sich die NUT-Konfiguration aus Paketen häufig unter /etc/nut. Maßgeblich sollte dennoch die Dokumentation des tatsächlich installierten Pakets sein. Upstream- und Distributionsversionen haben nicht immer identische Voreinstellungen oder Begriffe. Die aktuelle Upstream-Dokumentation verwendet die Rollen primary und secondary; ältere Anleitungen können frühere Bezeichnungen für dieselbe Beziehung enthalten.

Die Einrichtung in beobachtbaren Stufen aufbauen

1. Der Treiber muss glaubwürdige Daten liefern

Zunächst wird nur die Gerätedefinition eingerichtet. Der Treiber muss zur konkreten Kommunikationsmethode und Modellunterstützung passen. Sobald Treiber und upsd laufen, lassen sich mit dem schlanken, von Debian dokumentierten upsc-Client die Werte prüfen, welche die USV tatsächlich bereitstellt:

upsc myups@localhost
upsc myups@localhost ups.status

Der Name myups ist nur ein Platzhalter. Der NUT-Leitfaden zeigt OL für Netzbetrieb, OB für Batteriebetrieb und LB für einen niedrigen Batteriestand. Ein Gerät kann mehrere Statustoken gleichzeitig melden. Es kann außerdem Angaben zur Batterielaufzeit, Last oder andere Variablen auslassen. Automatisierung sollte deshalb nur von Daten abhängen, die an diesem Gerät bestätigt wurden.

Nicht nur eine beruhigende Momentaufnahme, sondern die Übergänge sind zu beobachten. Ändert sich der Status, wenn die Eingangsversorgung auf die vom Hersteller vorgesehene Weise getrennt wird? Kehrt er nach Wiederherstellung der Versorgung zu online zurück? Bleibt die Kommunikation stabil? In dieser Phase sollte die automatische Abschaltung noch deaktiviert oder ungefährlich sein.

2. Einen Monitor mit minimalen Rechten hinzufügen

upsmon authentifiziert sich mit einem Monitoring-Konto bei upsd. NUT-Konfigurationsdateien können Zugangsdaten und Zugriffskontrollen enthalten. Laut offiziellem Leitfaden dürfen sie daher nicht für alle Benutzer lesbar sein. Die NUT-Sicherheitshinweise empfehlen außerdem, die Schnittstellen und Firewall-Pfade einzuschränken, über die upsd erreichbar ist. Ein Monitoring-Client benötigt keinen uneingeschränkten Zugriff auf administrative Befehle.

Bei einem einzelnen Server, der direkt mit seiner USV verbunden ist, übernimmt upsmon normalerweise die Rolle primary. In einer gemeinsamen Konfiguration kann ein System die USV verwalten, während weitere von ihr versorgte Systeme secondary-Monitore über das Netzwerk betreiben. Physische Verkabelung und Softwarerollen müssen dieselbe Realität abbilden. Ein Rechner, der nur eine entfernte USV beobachtet, darf nicht versehentlich so konfiguriert sein, als würde sie ihn versorgen.

3. „Kritisch“ durch das Gerät bestimmen lassen

Der normale NUT-Abschaltpfad beginnt, wenn die USV zugleich im Batteriebetrieb ist und einen niedrigen Batteriestand meldet. Im Leitfaden erscheint dies als OB LB. Die Low-Battery-Entscheidung kann von gemeldeten Geräteschwellen und dem Verhalten des Treibers abhängen. Sie sollte nicht beiläufig durch einen universellen Prozentwert ersetzt werden, der von einem anderen Modell stammt.

Dabei gibt es eine wichtige zeitliche Einschränkung. Ist das verbleibende Intervall nach LB kürzer als die reale Abschaltdauer des Hosts, kommt der Standardauslöser zu spät. NUT unterstützt zeitgesteuerte Richtlinien über upssched. Das eigene upsmon-Handbuch beschreibt zeitgesteuerte Abschaltungen jedoch als zusätzliche Komplexität und empfiehlt, wenn möglich bei der normalen kritischen Behandlung zu bleiben. Zuerst messen; eine zusätzliche Richtlinie sollte ein beobachtetes Zeitproblem lösen.

4. Den Wiederanlauf in den Entwurf aufnehmen

Das Herunterfahren ist nur die Hälfte eines Ausfallzyklus. NUT kann einen Forced-Shutdown-Zustand setzen, abhängige Systeme stoppen, den primary herunterfahren und eine unterstützte USV spät im Betriebssystem-Shutdown zum Abschalten der Last auffordern. Das Trennen der Last kann ein Rennen verhindern, bei dem die Netzversorgung zurückkehrt, nachdem der Computer angehalten wurde, aber bevor die USV abgeschaltet hat. Ob Befehle zum Abschalten und verzögerten Einschalten funktionieren, hängt von USV und Treiber ab.

Auch die Firmware des Computers benötigt eine passende Restore-after-Power-Loss-Richtlinie. Diese Einstellung liegt außerhalb von NUT und unterscheidet sich je nach Rechner. Das kombinierte Verhalten muss getestet werden; eine Option „power on“ in einer Oberfläche beweist noch keine vollständige unbeaufsichtigte Wiederherstellung.

Tests müssen von ungefährlich zu disruptiv fortschreiten

Eine syntaktisch gültige Konfigurationsdatei belegt keinen wiederherstellbaren Stromausfall. Die Tests sollten stufenweise erweitert werden:

  1. Nur lesende Beobachtung: Status und Logs bei vorhandener Netzversorgung abfragen. Nach einem Neustart prüfen, ob Treiber-, Server- und Monitor-Dienste starten.
  2. Übergang zur Batterie: Mit einer Last innerhalb der Herstellergrenzen den vorgesehenen Wechsel auf Batterie und zurück beobachten. Benachrichtigungen und Statusänderungen prüfen, ohne sich der Entladung zu nähern.
  3. Probe der Abschaltlogik: Einen Dummy-Shutdown-Befehl oder einen reinen Benachrichtigungspfad verwenden, damit ein kritisches Ereignis protokolliert, was geschehen würde, ohne den Host zu stoppen.
  4. Kontrollierter End-to-End-Test: Ausfallzeit einplanen, wichtige Arbeitslasten sicher beenden, Konsolenzugriff bereithalten und das tatsächliche Anhalten, Abschalten der USV-Last, Wiederkehren der Versorgung und die Startreihenfolge testen.

Der letzte Schritt ist absichtlich unbequem. Sowohl das Upstream-Handbuch als auch Debians upsmon(8)-Seite beschreiben, dass upsmon -c fsd eine Forced-Shutdown-Sequenz startet. Dies ist kein harmloser Diagnosebefehl. Er kann den primary herunterfahren, secondaries benachrichtigen und zum Abschalten des USV-Ausgangs führen. Er gehört ausschließlich in einen vorbereiteten disruptiven Test.

Während dieses Tests sollten Zeitpunkte protokolliert werden: Batteriewechsel, Abschaltentscheidung, Anwendungsstopp, Anhalten des Hosts, Abschalten des Ausgangs, Rückkehr der Eingangsversorgung und Wiederherstellung der Dienste. Das nützliche Ergebnis ist kein Benchmark für andere, sondern der Nachweis ausreichender Reserve für dieses konkrete System. Der Test sollte regelmäßig sowie nach Änderungen an USV-Batterie, angeschlossener Last, Speicheraufbau, Shutdown-Jobs, Firmware-Richtlinie oder NUT-Konfiguration wiederholt werden.

Gemeinsam versorgte Systeme benötigen eine Reihenfolge

Nutzen mehrere Rechner eine USV, wird ein sauberes Herunterfahren zu einem Koordinationsproblem. Secondary-Monitore erhalten ihren Status vom upsd auf der primary-Seite. Bei einem kritischen Ereignis sollten die secondaries herunterfahren und die Verbindung trennen, bevor der primary die gemeinsame Last abschaltet. Das Upstream-Handbuch dokumentiert Synchronisationstimer, doch ihre Voreinstellungen beweisen nicht, dass eine bestimmte Datenbank, virtuelle Maschine oder ein Speicherdienst rechtzeitig fertig wird.

Die Reihenfolge sollte ausdrücklich festgelegt werden. Schreibintensive Anwendungen werden vor ihrem Speicherhost beendet. Der Netzwerkpfad bleibt aktiv, bis secondary-Monitore die Entscheidung erhalten haben. Es braucht genügend Reserve für die langsamste erwartete Abschaltung, zugleich kann der primary nicht unbegrenzt auf einen ausgefallenen secondary warten. Lässt sich dieser Kompromiss nicht zuverlässig testen, können getrennte Strombereiche oder eine einfachere Topologie sicherer sein als ausgefeilte Zeitsteuerung.

Was eine USV nicht löst

Eine USV ersetzt keine Backups. Sie kann weder eine versehentlich gelöschte Datei noch eine bereits auf die Festplatte geschriebene beschädigte Datenbank, gestohlene Zugangsdaten oder ein defektes Laufwerk wiederherstellen. Sie führt außerdem weitere ausfallfähige Komponenten ein: Batterien altern, USB-Verbindungen werden getrennt, Monitoring-Zugangsdaten werden falsch konfiguriert und Netzwerk-Clients sind nicht erreichbar.

Auch muss nicht jeder kurze Batteriewechsel sofort ein Herunterfahren auslösen. Kurze Störungen können enden, bevor sich ein Serverstopp lohnt. Umgekehrt kann das Warten bis zum letzten möglichen Batterieprozent die für einen sicheren Stopp notwendige Reserve aufzehren. Die richtige Richtlinie hängt von lokalen Ausfallmustern, den Meldungen der USV, der Abschaltdauer der Arbeitslast und den Kosten der Ausfallzeit ab. Einen ehrlichen universellen Schwellenwert gibt es nicht.

Elektrische Arbeiten bleiben außerhalb des Umfangs einer Softwarekonfiguration. Geerdete Steckdosen und unterstützte Lasten sind gemäß Herstellerangaben zu verwenden, die Belüftung muss frei bleiben, und ein USV-Gehäuse sollte nicht geöffnet werden, nur weil eine Softwareanleitung seine Batterie erwähnt.

Eine praktische Definition von Erfolg

Eine USV-Einrichtung für einen Homeserver ist erfolgreich, wenn ihr Verhalten bekannt ist, nicht wenn ihr Dashboard detailliert aussieht. Das exakte Gerät ist in den Kompatibilitätsnachweisen vorhanden; Debian kann stabilen Status lesen; Zugangsdaten und Netzwerkexposition sind begrenzt; die Abschaltsequenz endet mit gemessener Reserve; abhängige Hosts stoppen in der vorgesehenen Reihenfolge; und das System kehrt nach Wiederherstellung der Versorgung zuverlässig zurück.

Diese Definition ist bewusst bescheiden. Eine USV kann die Netzversorgung nicht zuverlässig machen, und NUT kann keine Telemetrie erzeugen, die ein Gerät nicht bereitstellt. Gemeinsam können beide ein begrenztes Batterieintervall in eine kontrollierte Entscheidung verwandeln. Die verbleibende Frage ist empirisch: Wurde der vollständige Zyklus auf der Ausrüstung getestet, die ihn später unbeaufsichtigt ausführen muss?

References