Server-Hardware – Grundlagen für IT-Support

Warum Server-Hardware für IT-Allrounder wichtig ist

Du musst keine Server selbst zusammenbauen – aber du wirst regelmässig vor einem Rack stehen, einen Alarm im Monitoring sehen oder via iDRAC auf einen Server zugreifen müssen, ohne dass jemand vor Ort ist. Wer die Grundbegriffe kennt, kann schneller reagieren, mit dem Hersteller-Support sprechen und den Unterschied zwischen einem harmlosen Alarm und einem kritischen Ausfall einschätzen.

Diese Seite gibt dir das Rüstzeug dafür: Formfaktoren, Sizing, Remote-Management, Firmware-Lifecycle, RAID, Storage-Anbindung, Predictive Failure Analysis, Stromredundanz, USV, Rack-Grundlagen und sichere Ausserbetriebnahme – alles, was du als IT-Allrounder im KMU wissen musst.

Formfaktoren: Tower, Rack, Blade

Server kommen in drei grundlegenden Bauformen. Die Wahl hängt davon ab, wie viele Server du betreibst und wie du sie unterbringen willst.

Tower-Server sind der einfachste Einstieg: kein Rack nötig, günstig im Kauf, einfach aufzustellen. Nachteil: Nehmen viel Platz weg, sind lauter als Rack-Server und schwerer zu organisieren wenn es mehrere werden.

Rack-Server sind der Standard sobald du mehr als einen Server betreibst. Sie werden in ein 19-Zoll-Rack eingebaut und sind in Höheneinheiten (U) gemessen. Ein 1U-Server ist 4,45 cm hoch, ein 2U-Server doppelt so hoch – und damit meist leistungsfähiger und besser zu warten.

Blade-Server sind das Maximum an Dichte: Ein Chassis (z.B. ein 10U-Gehäuse) beherbergt bis zu 16 Blade-Module. Jedes Blade ist ein vollständiger Server. Netzwerk, Strom und Kühlung werden über das Chassis geteilt. Das spart Kabel und Platz, ist aber teuer in der Anschaffung und bei Ausfall des Chassis problematisch.

Server-Sizing und Kapazitätsplanung

Bevor ein neuer Server bestellt wird, muss klar sein, wofür er reicht – und wofür nicht. Falsches Sizing ist teuer in beide Richtungen: Zu klein dimensioniert bedeutet ständige Performance-Probleme und einen frühen Ersatzkauf, zu gross dimensioniert verbrennt Budget, das anderswo fehlt. Besonders bei Virtualisierungs-Hosts (siehe Virtualisierung – Grundlagen, Hyper-V, VMware ESXi) lohnt sich eine saubere Rechnung, weil hier mehrere VMs um dieselben physischen Ressourcen konkurrieren.

CPU-Sizing und Overcommitment

Ein Hypervisor kann mehr virtuelle CPUs (vCPU) an VMs vergeben, als physische Kerne (pCPU) vorhanden sind – das nennt man CPU-Overcommitment. Das funktioniert, weil selten alle VMs gleichzeitig ihre volle CPU-Leistung brauchen.

RAM-Sizing

Bei RAM ist Overcommitment deutlich riskanter als bei CPU: Wenn der physische Arbeitsspeicher voll ist, beginnt der Hypervisor zu swappen (Disk-Swap) oder greift zu Ballooning/Transparent Page Sharing – beides kostet spürbar Performance. Faustregel für produktive KMU-Cluster:

• Physischer RAM des Hosts = Summe der zugesagten VM-RAM-Werte + 10–20% Reserve für den Hypervisor selbst
• Kritische Workloads (SQL Server, ERP) bekommen fest zugewiesenen RAM statt Dynamic Memory/Ballooning
• Bei Hyper-V: Dynamic Memory nur für unkritische VMs, mit sauber gesetztem Minimum/Maximum

IOPS-Sizing und RAID-Penalty

Storage-Performance wird in IOPS (I/O-Operationen pro Sekunde) gemessen. Wichtig: Ein RAID-Verbund braucht für jeden Schreibvorgang mehrere physische Schreiboperationen (RAID-Penalty), abhängig vom RAID-Level:

Beispiel: Eine Applikation braucht 1’000 Lese-IOPS und 500 Schreib-IOPS auf RAID 5. Benötigte Raw-IOPS = 1’000 + (500 × 4) = 3’000 IOPS, die die zugrundeliegenden Platten liefern müssen – nicht 1’500. Bei Datenbanken mit hohem Schreibanteil ist das oft der Grund, weshalb RAID 10 trotz höherer Anschaffungskosten (50% Kapazitätsverlust) die bessere Wahl ist.

N+1-Planung für Cluster

Bei einem Virtualisierungs-Cluster mit mehreren Hosts gilt die N+1-Regel: Die verbleibenden Hosts müssen im Fehlerfall die Last des ausgefallenen Hosts mittragen können, ohne dass alle VMs in die Knie gehen. Bei einem 3-Host-Cluster heisst das: Jeder Host darf im Normalbetrieb nur maximal 2/3 seiner Kapazität verplant haben, damit beim Ausfall eines Hosts die übrigen zwei die komplette Last übernehmen können.

Rack-Grundlagen

Ein Server-Rack ist der Schrank, in dem Rack-Server, Switches, Patch-Panels und andere Geräte eingebaut werden. Einige wichtige Kennzahlen:

Ein 24U-Rack hat also Platz für bis zu 24 1U-Server – in der Praxis belegen aber Switches (1U), Patch-Panels (1U), KVM-Switche (1U) und Leerblenden weitere Höheneinheiten.

Was in ein gut organisiertes Rack gehört:

1. Patch-Panel oben: Alle strukturierten Kabel enden hier, von hier geht es mit kurzen Patchkabeln zum Switch.
2. Switch(es) direkt neben dem Patch-Panel: Kurze Kabelwege.
3. Server in der Mitte, sortiert nach Funktion (z.B. Virtualisierungs-Host, Fileserver, Backupserver).
4. USV unten: Schwer, daher Gewichtsschwerpunkt nach unten. USV-Ausgang zu einer eigenen Steckdosenleiste im Rack.
5. Leerblenden überall wo kein Gerät sitzt: Verhindert Wärme-Kurzschluss (Kaltluft strömt durch und wird nicht direkt wieder angesaugt).

Remote Management: iDRAC, iLO, IPMI

Das ist das Feature, das echte Server von Workstations unterscheidet: Out-of-Band Management (OOB). Es gibt dir Zugriff auf den Server, auch wenn:

• das Betriebssystem nicht mehr antwortet
• der Server im BIOS hängt
• du den Server booten musst und keiner ist vor Ort

Das funktioniert über einen eigenen Chip auf dem Mainboard (Baseboard Management Controller, kurz BMC) mit einem eigenen Netzwerkanschluss und einer eigenen IP-Adresse. Die Lösung ist vom Hauptbetriebssystem vollständig unabhängig.

Was du damit machen kannst

• Virtueller Bildschirm (vKVM): Du siehst, was auf dem Server-Monitor wäre – auch im BIOS, beim Booten, beim BSOD.
• Virtuelles Laufwerk: Du kannst eine ISO einbinden, als wärst du mit einem USB-Stick vor Ort. Ideal für OS-Reinstallationen aus der Ferne.
• Power Management: Server remote ein-/ausschalten, neu starten, Hard Reset.
• System Event Log (SEL): Hardware-Ereignisse wie Festplattenausfälle, RAM-Fehler, Überhitzung – alles wird hier protokolliert.
• Hardware-Monitoring: Temperaturen, Lüfter-RPM, Stromverbrauch in Echtzeit.

Zugriff per Kommandozeile (IPMI)

IPMI ist das offene Protokoll, das hinter allen OOB-Lösungen steckt. Mit dem Tool ipmitool kannst du grundlegende Operationen skripten:

# Stromstatus abfragen
ipmitool -I lanplus -H 192.168.1.200 -U admin -P geheim power status

# Server neu starten (Hard Reset)
ipmitool -I lanplus -H 192.168.1.200 -U admin -P geheim power reset

# System Event Log anzeigen (letzten 20 Eintraege)
ipmitool -I lanplus -H 192.168.1.200 -U admin -P geheim sel list

# Sensoren anzeigen (Temperaturen, Spannungen, Luefter)
ipmitool -I lanplus -H 192.168.1.200 -U admin -P geheim sensor list

# System Event Log loeschen (nach Analyse!)
ipmitool -I lanplus -H 192.168.1.200 -U admin -P geheim sel clear

iDRAC per SSH

# Direkt auf iDRAC verbinden
ssh root@192.168.1.200

# Auf der iDRAC-Shell: RACADM-Befehle
racadm getsysinfo
racadm serveraction hardreset
racadm racdump   # Kompletten Status-Dump ausgeben

Firmware- und BIOS-Lifecycle-Management

Firmware ist die Software, die direkt auf der Hardware läuft – BIOS/UEFI, der BMC selbst (iDRAC/iLO/XCC), RAID-Controller, Netzwerkkarten, Netzteile und sogar die Festplatten/SSDs haben eigene Firmware. Veraltete Firmware ist einer der häufigsten Gründe für scheinbar unerklärliche Hardware-Probleme, Kompatibilitätsfehler mit neuer OS-Version oder ungepatchte Sicherheitslücken – Firmware-Pflege ist deshalb Teil eines soliden Server-Hardening und gehört ins Change-Management.

Welche Komponenten Firmware haben

Empfohlene Update-Reihenfolge

Firmware-Updates sollten nicht wild durcheinander eingespielt werden – die Reihenfolge beeinflusst, ob der Server danach überhaupt sauber bootet:

1. BMC-Firmware zuerst (iDRAC/iLO/XCC) – der Controller, der die restlichen Updates orchestriert, muss selbst aktuell sein.
2. BIOS/UEFI – danach, nie gleichzeitig mit dem BMC-Update (beide verlangen einen Reboot, das führt sonst zu Warteschlangen-Konflikten).
3. PSU-Firmware separat und ungestört – Netzteil-Updates dauern 30–60 Minuten und dürfen währenddessen nicht durch Aus-/Einschalten oder Stromunterbruch gestört werden, sonst drohen dauerhaft defekte Netzteile.
4. RAID-Controller / HBA, danach NIC-Firmware.
5. Laufwerks-Firmware zuletzt, meist im laufenden Betrieb ohne Reboot möglich.

Fleet-weites Firmware-Management

Bei mehr als ein paar Servern lohnt sich zentrales Firmware-Management statt manueller Einzel-Updates:

• Dell OpenManage Enterprise (OME): Verwaltet mehrere PowerEdge-Server zentral. Unter Configuration → Firmware wird eine Firmware-Baseline erstellt: Ein Katalog (Ziel-Firmwarestand) wird einer Gruppe von Zielservern zugeordnet. OME zeigt danach pro Server den Compliance-Status an (“konform” / “abweichend”) und erlaubt das Einspielen fehlender Updates direkt aus der Konsole.
• HPE iLO Amplifier Pack: Ein Inventar- und Update-Werkzeug, das bis zu 10’000 ProLiant-Server per iLO-Discovery erfasst, ein detailliertes Hardware- und Firmware-Inventar liefert und Updates gegen eine definierte Baseline batchweise ausrollt (online oder offline, mit “Baseline Automatic Update” für minimalen manuellen Aufwand).
• Lenovo XClarity Administrator: Vergleichbares Konzept für ThinkSystem-Server.

# Beispiel: Firmware-Inventar eines Dell-Servers per Redfish-API abfragen
$cred = Get-Credential
Invoke-RestMethod -Uri "https://192.168.1.200/redfish/v1/UpdateService/FirmwareInventory" `
  -Credential $cred -Method Get -SkipCertificateCheck |
  Select-Object -ExpandProperty Members

RAID-Controller

RAID (Redundant Array of Independent Disks) kombiniert mehrere Festplatten so, dass entweder Performance, Redundanz oder beides verbessert wird. In Servern kommt meist ein Hardware-RAID-Controller zum Einsatz – eine eigene Karte mit Prozessor und gepuffertem Cache.

Die wichtigsten RAID-Level

Praxistipp für KMU:

• Betriebssystem/Bootlaufwerk: RAID 1 mit 2 SSDs
• Dateiserver / VM-Datastore: RAID 5 oder RAID 6 mit 4–8 HDDs/SSDs
• Datenbank / hohe IOPS-Anforderung: RAID 10

Eine ausführlichere Gegenüberstellung inklusive Rebuild-Verhalten und Kapazitätsrechnung findest du auf der Seite RAID-Level im Detail.

Hardware-RAID vs. Software-RAID

Ein Hardware-RAID-Controller (z.B. Dell PERC H730, HPE Smart Array P408i) hat einen eigenen Prozessor und einen batteriegepufferten oder Flash-gesicherten Cache (BBU / Capacitor). Das bedeutet:

• Writes werden im Cache zwischengespeichert und bestätigt – viel schneller als direktes Schreiben
• Bei Stromausfall rettet der BBU / Capacitor die Cache-Daten
• Der Host-CPU wird nicht belastet

Software-RAID (Windows Storage Spaces, Linux mdadm) ist kostenlos, belastet aber die CPU und ist bei grossen RAID-Arrays langsamer. Für unkritische Einsätze oder wenn kein Hardware-Controller vorhanden ist, aber im Serverumfeld nicht die erste Wahl.

RAID-Status überwachen

# Dell PERC Status mit MegaCLI (Windows)
# MegaCLI64.exe -LDInfo -Lall -aAll

# Dell OpenManage Storage Management (OMSS) - Status via PowerShell
Get-PhysicalDisk | Select-Object FriendlyName, OperationalStatus, HealthStatus, Size

# Windows Storage Spaces Status
Get-StoragePool | Select-Object FriendlyName, HealthStatus, OperationalStatus
Get-VirtualDisk | Select-Object FriendlyName, HealthStatus, OperationalStatus, ResiliencySettingName

Storage-Anbindung: PCIe-Lanes, NVMe, U.2 vs. M.2

Moderne Server-Datastores laufen zunehmend über NVMe-Laufwerke, die direkt über PCIe angebunden sind statt über einen klassischen RAID-Controller mit SAS/SATA. Wer NVMe-Storage plant, muss zwei Dinge verstehen: die Formfaktoren und das Lane-Limit der CPU.

PCIe-Lanes: Die begrenzte Ressource

Jede CPU stellt eine feste Anzahl PCIe-Lanes zur Verfügung (bei aktuellen Server-CPUs von Intel Xeon und AMD EPYC je nach Generation zwischen rund 80 und über 128 Lanes pro Sockel). Jedes NVMe-Laufwerk belegt in der Regel 4 Lanes (x4), Netzwerkkarten oft 8 oder 16 Lanes, RAID-Controller/HBAs ebenfalls mehrere Lanes. Diese Lanes werden von allen Erweiterungskarten und NVMe-Slots geteilt – bei einem vollbestückten Server mit vielen NVMe-Bays, mehreren 25/100G-NICs und einer GPU kann es knapp werden. Ein PCIe-Switch oder Retimer im Backplane kann mehrere Laufwerke über weniger CPU-Lanes bündeln, das kostet aber etwas Bandbreite pro Laufwerk.

U.2 vs. M.2: zwei Formfaktoren, gleicher Bus

Beide Formfaktoren sprechen elektrisch dasselbe PCIe-x4-NVMe-Protokoll, unterscheiden sich aber deutlich im Einsatzzweck:

Praxisregel: M.2 für das Betriebssystem-/Boot-Laufwerk (wird selten getauscht), U.2/U.3 für alles, was im laufenden Betrieb austauschbar sein muss – also produktive VM-Datastores oder Datenbank-Volumes. Mehr zum grösseren Storage-Kontext (SAN vs. NAS, iSCSI/Fibre Channel) findest du unter NAS vs. SAN vs. DAS und SAN-Grundlagen.

Predictive Failure Analysis: SMART-Werte auslesen und interpretieren

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) ist ein Überwachungssystem, das praktisch jede Festplatte und SSD mitbringt. Ziel ist Predictive Failure Analysis (PFA): Warnzeichen erkennen, bevor die Platte tatsächlich ausfällt, damit ein geplanter Austausch statt eines ungeplanten Ausfalls stattfindet.

SMART-Werte auslesen

Auf Linux/Server-Hardware ist smartctl (Teil von smartmontools) das Standardwerkzeug:

# Alle SMART-Werte einer Platte anzeigen
smartctl -a /dev/sda

# Nur den Gesundheitsstatus pruefen (PASSED/FAILED)
smartctl -H /dev/sda

# Kurztest anstossen (wenige Minuten)
smartctl -t short /dev/sda

# Ergebnis des letzten Selbsttests anzeigen
smartctl -l selftest /dev/sda

Unter Windows liefert Get-PhysicalDisk bereits den generellen Health-Status, für die Detail-Attribute braucht es Hersteller-Tools (Dell OpenManage, HPE Smart Storage Administrator) oder smartctl für Windows.

Die wichtigsten Attribute

Integration in Server-Hardware

Dell iDRAC und HPE iLO werten SMART-/PFA-Daten selbständig aus und erzeugen bei Grenzwertüberschreitung automatisch einen Alarm im System Event Log sowie einen “Predictive Failure”-Status im Storage-Bereich – ohne dass du manuell smartctl aufrufen musst. Für eine zusätzliche, herstellerunabhängige Kontrolle lohnt sich trotzdem ein automatisierter nächtlicher Check:

# Cronjob-Beispiel: taeglicher SMART-Check mit Mail bei Fehlern
# /etc/cron.daily/smart-check
for disk in /dev/sd?; do
  smartctl -H "$disk" | grep -q "PASSED" || \
    echo "SMART-Fehler auf $disk" | mail -s "SMART Alarm $(hostname)" it@example.com
done

Mehr zur Automatisierung solcher Prüfungen findest du unter Cron-Jobs, Task Scheduler und generell im Bereich Monitoring – Grundlagen.

USV – Unterbrechungsfreie Stromversorgung

Eine USV (Unterbrechungsfreie Stromversorgung), auf Englisch UPS (Uninterruptible Power Supply), ist kein optionales Zubehör – sie ist Pflicht für jeden Server im KMU. Sie erfüllt zwei Aufgaben:

1. Kurzzeit-Puffer: Überbrückt Stromausfälle von wenigen Sekunden bis Minuten (je nach Akku-Kapazität und Gerätelast).
2. Sauberes Herunterfahren: Gibt dem Server genug Zeit, alle Prozesse ordentlich zu beenden, Dateisysteme zu synchronisieren und geordnet herunterzufahren.

USV-Typen

Für Server im KMU ist Line-Interactive meist ausreichend. Typische Hersteller: APC by Schneider Electric, Eaton, Riello, Cyberpower.

Stromredundanz: Dual-PSU, PDU und ATS

Eine USV allein schützt nur vor Stromausfall – nicht vor einem defekten Netzteil oder einer durchgebrannten Sicherung im Rack. Für echte Stromredundanz braucht es mehrere Bausteine:

• Dual-PSU-Server: Praktisch jeder Rack-Server ab Einstiegsklasse hat zwei redundante Netzteile (Hot-Swap-fähig). Fällt ein Netzteil aus, übernimmt das zweite unterbrechungsfrei.
• Getrennte Stromkreise: Der Nutzen von zwei Netzteilen verpufft, wenn beide an derselben Sicherung/demselben Stromkreis hängen. Netzteil 1 gehört an Stromkreis A / USV A, Netzteil 2 an Stromkreis B / USV B – idealerweise sogar an unterschiedliche Sicherungsgruppen im Gebäude.
• PDU (Power Distribution Unit): Die “Steckdosenleiste” im Rack, oft mit Fernüberwachung und einzeln schaltbaren Ports. In einem redundanten Setup gibt es zwei PDUs (A-Feed und B-Feed), jede an eine eigene USV angeschlossen.
• ATS (Automatic Transfer Switch): Für Geräte mit nur einem Netzteil (z.B. ein einzelner Switch ohne Dual-PSU) schaltet ein ATS automatisch zwischen den zwei Stromquellen (PDU A / PDU B) um, falls eine davon ausfällt – das Gerät bemerkt den Wechsel gar nicht.

USV-Monitoring und automatisches Shutdown

Eine USV ohne Monitoring ist nur halb so gut. Verbinde sie per USB, RS232 oder Netzwerkkarte und richte die Software ein:

APC PowerChute (Windows): Überwacht APC-USV-Geräte und fährt den Server automatisch herunter wenn der Akku unter einen Schwellwert fällt.

NUT – Network UPS Tools (Linux):

# NUT installieren (Debian/Ubuntu)
apt install nut nut-client

# USV per USB erkennen
upsc apc@localhost

# Status abfragen
upsc apc@localhost ups.status
# Rueckgabewert: OL = Online (Netz), OB = On Battery, LB = Low Battery

Wichtige USV-Warnzeichen:

• Akku-Alarm: Nach 3–5 Jahren degradieren Blei-Akku-Zellen. Akkutests regelmässig durchführen, idealerweise alle 6 Monate.
• Überlast-Alarm: Zu viele Geräte angeschlossen. USV-Kapazität in VA und Watt prüfen, nicht überlasten.
• Bypass-Modus: USV ist defekt oder in Wartung – kein Schutz aktiv!

Sichere Server-Ausserbetriebnahme und Datenvernichtung

Am Ende des Lebenszyklus eines Servers (Hardware-Ende, Leasingrückgabe, Ersatzbeschaffung) steht die geordnete Ausserbetriebnahme. Das ist mehr als “Stecker ziehen” – gerade bei Firmen- und Kundendaten.

Ablauf der Ausserbetriebnahme

1. Daten-Inventar prüfen: Welche Daten liegen auf dem Server (produktiv, Backup-Reste, Log-Dateien)? Sind alle Backups vorhanden und woanders gesichert?
2. Dienste sauber abmelden: AD-Objekt entfernen, DNS-Einträge löschen, aus Monitoring und Backup-Jobs austragen, Lizenzen deaktivieren.
3. Out-of-Band-Management zurücksetzen: iDRAC/iLO auf Werkseinstellungen zurücksetzen, damit keine internen Zugangsdaten oder IP-Konfigurationen beim nächsten Besitzer verbleiben.
4. Asset aus dem Inventar austragen: Siehe IT-Dokumentation & Inventar und IT-Asset-Lifecycle-Management.
5. Datenträger vernichten oder sicher löschen – siehe unten.

Datenvernichtung nach DIN 66399

Die deutsche Norm DIN 66399 definiert Sicherheitsstufen für die Vernichtung von Datenträgern. Festplatten und SSDs fallen in die Materialklasse “H” (magnetische bzw. elektronische Datenträger), mit sieben Sicherheitsstufen (H1 bis H7) – je höher die Stufe, desto kleiner die zulässige Partikelgrösse und desto höher der Aufwand:

Löschmethoden in der Praxis

• Crypto-Erase (bevorzugt bei SSD/NVMe): SSDs verteilen Daten über Wear-Leveling auf viele Zellen, ein klassisches Überschreiben erreicht nicht garantiert alle Bereiche. Der sanitize- bzw. crypto erase-Befehl des Laufwerks löscht stattdessen den internen Verschlüsselungsschlüssel – die Daten sind dadurch unlesbar, dauert Sekunden statt Stunden.
• Software-Wipe (mehrfaches Überschreiben): Für klassische HDDs geeignet, für höhere Schutzklassen bei sensiblen Daten meist nicht ausreichend dokumentiert/zertifizierbar.
• Physische Zerstörung: Für ausgemusterte Platten mit sensiblen Daten der sicherste Weg – durch einen zertifizierten Entsorgungsdienstleister mit Vernichtungsnachweis (Zertifikat mit Seriennummern, Datum, angewandter Sicherheitsstufe).

Typische Supportfälle und Troubleshooting

Server reagiert nicht mehr – Vorgehen

1. Ping-Test: ping <server-ip>
   → Kein Ping: Netzwerk-Problem oder Server komplett abgestürzt
   → Ping ok, aber kein RDP/SSH: OS-Crash, Dienst abgestürzt

2. OOB-Management nutzen (iDRAC / iLO):
   → Webinterface aufrufen
   → System Event Log (SEL) prüfen: Gibt es Hardware-Fehler?
   → Virtuellen Bildschirm (vKVM) öffnen: Was zeigt der Server?
   → Power Management: Soft Reboot > Hard Reset (nur wenn nötig)

3. Nach dem Neustart:
   → Windows-Ereignisanzeige: System-Log auf Fehler prüfen
   → Hardware-Monitoring in iDRAC/iLO: Temperaturen, RAID-Status

RAID-Alarm: Degraded

Ein “Degraded”-RAID bedeutet, dass eine Festplatte ausgefallen ist und das RAID mit verminderter Redundanz weiterläuft. Vorgehensweise:

1. Welche Platte ist ausgefallen? (iDRAC/iLO > Storage > Physical Disks)
2. Ist das RAID noch funktionsfähig? (1 Platte bei RAID 5/6 = OK, nicht sofort Panik)
3. Gleiche Platte (Hersteller, Modell, Kapazität) bestellen
4. Hot-Swap: Bei laufendem Server die defekte Platte tauschen – RAID startet Rebuild automatisch
5. Rebuild-Fortschritt überwachen (kann Stunden dauern)
6. Während des Rebuilds kein weiterer Plattenausfall tolerierbar – kein guter Moment für riskante Aktionen

# Windows: Physische Platten anzeigen
Get-PhysicalDisk | Select-Object FriendlyName, OperationalStatus, HealthStatus, MediaType

# Ereignisanzeige nach Storage-Fehlern durchsuchen
Get-EventLog -LogName System -Source "disk" -EntryType Error -Newest 20

USV-Akku gewechselt – Batterie-Test

# APC USV Akku-Test per apcaccess (Linux, NUT)
apcaccess status | grep -E "STATUS|BCHARGE|TIMELEFT|BATTDATE"

# STATUS:    ONLINE    (Netz verfuegbar)
# BCHARGE:   100.0 Percent (Akku-Ladestand)
# TIMELEFT:  12.0 Minutes (Laufzeit bei aktueller Last)
# BATTDATE:  2024-03-15   (Datum des letzten Akkuwechsels)

Crosslinks

Diese Seiten bauen direkt auf den hier besprochenen Grundlagen auf oder ergänzen sie sinnvoll:

• Virtualisierung – Grundlagen: Was auf der Server-Hardware läuft – VMs, Hypervisor, Konzepte
• Hyper-V – Grundlagen: Microsoft-Virtualisierung direkt auf Windows Server
• VMware ESXi – Grundlagen: Sizing und Kapazitätsplanung in der Praxis auf ESXi-Hosts
• RAID-Level im Detail: Tiefere Betrachtung der RAID-Level, Rebuild-Verhalten, Kapazitätsrechnung
• NAS vs. SAN vs. DAS und SAN-Grundlagen: Storage-Architektur jenseits des lokalen Servers
• Windows Server Backup und 3-2-1-Backup-Regel: Backup-Strategien – ergänzt den RAID-Abschnitt
• Monitoring – Grundlagen: Server-Hardware überwachen, Alerts konfigurieren, Dashboards
• NAS – Grundlagen: Wenn kein vollständiger Server nötig ist – NAS als Alternative
• IT-Notfallplanung / Disaster Recovery: Stromredundanz und Ausfallszenarien im grösseren Kontext
• IT-Asset-Lifecycle-Management und IT-Dokumentation & Inventar: Server über den ganzen Lebenszyklus verwalten
• DSGVO/nDSG in der IT-Praxis: Rechtlicher Rahmen für Datenvernichtung und Aufbewahrungspflichten

Weiterlernen

• Thomas-Krenn Wiki – Server Hardware – Ausführlichste deutschsprachige Quelle zu Server-Hardware, RAID-Controller, BMC
• Dell iDRAC Dokumentation – Offizielle Anleitung zur iDRAC-Konfiguration auf PowerEdge-Servern
• HPE iLO Benutzerhandbuch – Offizielle HPE-Dokumentation zu iLO
• Dell PowerEdge: How to update every Important Component – Offizielle Firmware-Update-Reihenfolge für PowerEdge-Server
• HPE iLO Amplifier Pack – Firmware Update – Fleet-weites Firmware-Management für ProLiant-Server
• smartmontools / smartctl Dokumentation – Referenz für SMART-Attribute und Predictive Failure Analysis
• APC USV-Planung – Wie man die richtige USV-Kapazität berechnet
• DIN 66399 – Schutzklassen und Sicherheitsstufen – Übersicht zu Sicherheitsstufen für Datenträgervernichtung
• Thomas-Krenn Wiki – RAID Controller – Hardware-RAID-Controller erklärt, Vergleich Typen

Videos

YouTube