Server-Ersatzteile – Verfügbarkeit 2026: Diese Modelle sollten IT-Verantwortliche jetzt prüfen

Unser Praxisleitfaden für IT-Verantwortliche und Entscheider: welche Server-Generationen 2026 ins Risiko laufen, welche Teile zuerst knapp werden und wie Sie Ihren Bestand systematisch absichern

1. Warum die Ersatzteilversorgung 2026 zum Thema wird

In vielen Serverräumen stehen Maschinen, die technisch noch arbeiten, beim Hersteller aber längst aus dem Support gefallen sind. 2026 spitzt sich das für eine Menge Teams zu. Das Problem entsteht aus mehreren Ursachen gleichzeitig: Ersatzteile werden knapp, Firmware- und Security-Updates fallen weg, Reaktionszeiten im Fehlerfall steigen, Lieferketten schwanken, und die Aufsicht schaut genauer hin.

Die wichtigste Frage: Bekommen Sie an einem Freitagnachmittag noch ein passendes Mainboard, ein redundantes Netzteil, einen RAID-Controller mit intaktem Cache-Modul oder eine SSD mit dem richtigen Firmware-Stand?

Viele Unternehmen haben ihre Austauschzyklen gestreckt. Server, die früher nach drei bis fünf Jahren außer Betrieb genommen wurden, laufen heute sieben, acht oder neun Jahre. Gleichzeitig sind die Sicherheitsvorgaben strenger geworden. Die NIS-2-Richtlinie und DORA für den Finanzsektor verlangen ein aktives Risikomanagement. Hardware ohne Sicherheitsupdates ist unter diesen Vorgaben auch ein rechtliches und finanzielles Thema. Das technische Risiko kommt obendrauf.

„Never touch a running system“ funktioniert deshalb nicht immer. Stellt der Hersteller die Lieferung von Ersatzteilen ein, sind Sie auf den Sekundärmarkt angewiesen. Dort fehlt oft die passende Komponente mit dem benötigten Firmware-Stand, die ein hochverfügbarer Cluster braucht. Fällt dann etwas aus, reden wir über Ausfälle in Tagen oder Wochen statt in Stunden. Eine modellgenaue Prüfung der Ersatzteillage gehört 2026 ganz oben auf die To-do-Liste.

Eine Lösung für das Problem fehlender Ersatzteile sind spezialisierte Anbieter wie Hardwarewartung.com. Unser flexibler Ersatzteilservice ermöglicht es unseren Kunden, das Ausfallrisiko ihrer Hardware auf ein Minimum zu reduzieren.

2. Was „problematisch“ konkret heißt

Das EOL-Datum allein sagt wenig. Hersteller unterscheiden mehrere Phasen, und erst später kann es heikel werden. Cisco benennt zum Beispiel End-of-Life Announcement, End-of-Sale, End of SW Maintenance und als Schlusspunkt das Last Date of Support. Dell trennt End of Sales Life, End of Standard Support, End of Security Support und am Ende End of Service Life (EOSL). In der Praxis schlagen bei EOL / EOSL für Server vier Faktoren durch.

Erstens fällt der Hersteller-Support weg. Ist das EOSL erreicht, gibt es keine Wartung, keine Fixes, keine Ursachenanalyse mehr. Verträge lassen sich oft gar nicht mehr verlängern, oder nur zu Preisen, die Sie zum Neukauf drängen sollen. Bei einem Absturz stehen Sie dann allein da.

Zweitens verschiebt sich die Teilebeschaffung auf Broker: Komponenten kommen als refurbished, als Pulls (aus alten Servern ausgebaut) oder als New Old Stock (neu, aber gealtert). Die Historie bleibt unklar: Lief das Board jahrelang in einem zu warmen Raum? Hat der Transport feine Risse in der Platine hinterlassen? Das sehen Sie dem Teil nicht an.

Drittens versiegen Firmware- und Security-Updates, und das wiegt schwerer als die reine Hardware. Moderne Server sind kleine Rechner-Netzwerke. Der Management-Controller (Dells iDRAC, HPEs iLO, Lenovos XCC, Ciscos IMC) fährt ein eigenes Betriebssystem und hängt am Netz. Ransomware-Gruppen suchen gezielt nach Lücken in genau diesen Out-of-Band-Schnittstellen. Ein ungepatchtes System in einem kritischen Segment wird damit zum offenen Tor.

Viertens werden proprietäre Teile knapp. Standard-RAM (DDR4) oder gängige Intel-CPUs bekommen Sie meist noch jahrelang. Eng wird es bei herstellerspezifischen Bauteilen: RAID-Controller mit Cache-Modul und passendem Akku, proprietäre Backplanes, formfaktorgebundene Netzteile, firmware-gebundene OEM-SSDs. Fällt so ein Teil aus und ist nicht zu bekommen, steht der ganze Server, selbst wenn CPU und RAM völlig in Ordnung sind.

Abbildung: EOL / EOSL bei Servern: kritische Risikofaktoren

Am Ende hängt alles an den Liefer- und Wiederanlaufzeiten. Ein zugesagtes „Next Business Day“ oder gar „4 Stunden vor Ort“ hält für Legacy-Hardware 2026 oft nicht mehr, wenn das Teil erst international über Broker gesucht wird. Aus Stunden werden Tage, aus Tagen Wochen. Ohne Redundanz steht so lange der Betrieb.3. Die Server-Generationen im Risikobereich 2026

Ein genauer Blick auf die vier großen Serverhersteller lohnt sich, weil jeder seine Lifecycle-Daten anders kommuniziert. Wer gemischte Umgebungen betreut, merkt das schnell. Dell, HPE, Lenovo und Cisco haben jeweils eigene Fallstricke.

3.1 Dell PowerEdge

Bei Dell ist der genaue Status oft erstaunlich schwer zu fassen. Anders als andere Hersteller veröffentlicht Dell für PowerEdge keine globale, für alle gültige EOL-/EOSL-Tabelle. Ein Moderator im Dell-Forum hat das bestätigt: Stattdessen zählt das individuelle Versanddatum jedes einzelnen Servers, grob fünf bis sieben Jahre ab Werk.

Im Blick haben sollten Sie vor 2026 die 13. Generation (R630, R730, R730xd). Diese läuft heute größtenteils schon außerhalb des regulären Supports. Wer sie produktiv nutzt, lebt vom Sekundärmarkt oder von einem TPM-Vertrag.

Heikler ist die 14. Generation mit den sehr verbreiteten R640, R740, R740xd und R840. Viele davon gingen 2017 bis 2019 in großen Stückzahlen raus. Rechnet man Dells Fünf-bis-sieben-Jahre-Fenster dazu, rutschen genau diese Systeme rund um 2026 in die kritische Phase. Auch ältere hyperkonvergente Aufbauten wie MX-Chassis oder VxRail auf älteren PowerEdge-Knoten sind anfällig, weil Hardware- und Software-Support hier eng aneinanderhängen.

Exportieren Sie die Service Tags aller Dell-Systeme und fragen Sie jeden Eintrag im Dell Support-Portal einzeln ab. Unter „Service Events“ schalten Sie den Filter „Only show active events“ aus, sonst sehen Sie das individuell berechnete EOSL-Datum nicht.

Abbildung: Dell Support-Portal

Ein zweiter Stolperstein bei älteren Dells betrifft die Firmware-Updates über den iDRAC Lifecycle Controller. Bei iDRAC8 und frühen iDRAC9-Ständen häufen sich Fälle, in denen der Controller keine Verbindung mehr zu downloads.dell.com aufbaut, mit der Meldung „Invalid share name or repository location“. Ursache sind oft serverseitige Umstellungen oder veraltete TLS-Zertifikate im alten iDRAC, die moderne Server ablehnen. Das Paradoxe daran: Selbst wenn es noch ein letztes wichtiges Update gäbe, kann der Server es über den eingebauten Automatismus nicht mehr ziehen. Dann bleibt der Umweg über ein bootfähiges ISO.

3.2 HPE ProLiant

HPE macht es etwas transparenter und definiert Regeln pro Generation. Faustregel: Das Mindest-EOSL liegt etwa fünf Jahre nach dem Verkauf des letzten Geräts einer Generation. Den Status können Sie über das HPE Support Center anhand der Seriennummer und der Produkt-ID prüfen.

Heikel ist die ProLiant Gen9-Familie, allen voran DL360 Gen9 und DL380 Gen9. Das Ende der Vermarktung lag schon Mitte 2020, das EOSL beim DL380 Gen9 fiel auf Mitte 2025. Diese Server 2026 weiterzubetreiben ist riskant, denn auch grundlegende iLO-Lücken werden nicht mehr gestopft.

Bei Gen10 (DL360 Gen10, DL380 Gen10) liegt das End of Life für Neubestellungen im Mai bzw. Oktober 2024. Weil HPE danach mindestens fünf Jahre Support gewährt, sind diese Racks theoretisch bis 2029 grundversorgt. Trotzdem wird es schon 2026 zu Änderungen kommen: Basis-Support ja, aber einzelne Komponenten älterer Gen10-Ausbauten werden auf dem Sekundärmarkt schon knapp. Sonderfall Blade: Für den ProLiant BL460c Gen10 nennen Support-Datenbanken teils schon den 15. November 2026 als EOSL. Auch ältere Apollo- und Synergy-Teile laufen nach eigenen, oft kürzeren Zyklen.

In der Praxis zählt bei HPE die Peripherie und nicht die CPU. Kritisch sind Smart Array Controller, spezielle SFF/LFF-Laufwerke, Lüftermodule, proprietäre Netzteile und Backplanes. Ein Dauerbrenner bei Gen9 ist die Smart Storage Battery, die den Schreibcache des RAID-Controllers bei Stromausfall stützt. Verliert sie Kapazität, schaltet der Controller den Cache ab, und die Performance bricht ein.

Es gibt bekannte Firmware-Bugs (etwa POST Error 313), bei denen der Server beim Start hängen bleibt, wenn die Batterie schwächelt und gleichzeitig veraltete iLO-4-Stände (z. B. 2.40 oder 2.42) mit altem System-ROM laufen. Hier hilft nur, rechtzeitig Ersatzbatterien zu bevorraten und die Firmware des ganzen Servers sauber durchzupatchen, solange der Support noch greift.

3.3 Lenovo ThinkSystem / System x

Lenovo bringt eine Eigenheit mit, die aus der Übernahme der x86-Sparte von IBM stammt: Support-Enddaten hängen stark an der Region (Geo Code) und am vierstelligen Machine Type. Derselbe Marketingname kann je nach Region und Konfiguration ein anderes Enddatum haben.

Auf dem Schirm haben sollten Sie die System-x-Reihe, etwa x3650 M5 und x3550 M5, noch aus der IBM-Lenovo-Übergangszeit. Das EOSL für das x3650 M5 lag bereits Ende 2021. Wer dieses System 2026 noch fährt, hat kein Netz mehr unter sich. Auch bei frühen ThinkSystem-Modellen (SR530, SR630, SR650) ist Vorsicht angebracht. Der SR630 (Machine Type 7X02) ist aus der Vermarktung raus. Lenovo unterstützt nach dem Marktrückzug üblicherweise noch mindestens fünf Jahre, womit diese frühen ThinkSystems in die Endphase rücken. Ältere ThinkAgile-Appliances und storage-nahe Plattformen gehören ebenfalls auf den Prüfstand.

Nutzen Sie die End-of-Service-Abfrage von Lenovo und geben Sie Geo Code (z. B. EMEA), den vierstelligen Machine Type (z. B. 7X02) und das genaue CTO-Modell ein. Der Unterschied ist real: Ein baugleicher Server kann in Nordamerika ein anderes EOSL haben als in Europa. Erfassen Sie den Machine Type vom Typenschild oder über Lenovo Vantage/XCC sauber in der CMDB.

Abbildung: Lenovo End of Service Date Lookup

3.4 Cisco UCS

Cisco liegt beim Thema Transparenz vorn. Das Unternehmen veröffentlicht gestaffelte Meilensteine, von der EOL-Ankündigung über den letzten Versandtag und das Ende der Software-Wartung bis zum Last Date of Support (LDoS).

Im Fokus stehen die UCS C-Series Rack- und B-Series Blade-Server der M4-Generation (C220 M4, C240 M4, B200 M4). Ihr Last Date of Support war schon am 29. Februar 2024.

Bei M5 kommt es auf das Modell an. Das auf Machine Learning ausgelegte UCS C480 ML M5 hat ein hartes Last Date of Support zum 31. Dezember 2026. Die Standard-Racks und -Blades der M5-Reihe (C220 M5, C240 M5, B200 M5) haben mit dem LDoS am 31. Oktober 2028 mehr Luft. Aber: End-of-Sale war bereits Oktober 2023, und das Ende der Software-Wartung fällt auf Oktober 2026. Bei HyperFlex auf M5-Basis erreichte die HXDP-Software ihr End of SW Maintenance schon im September 2025.

Cisco ist der komplexeste Fall. Die gesamte UCS-Architektur hängt an den Fabric Interconnects und am UCS Manager. Jeder Tausch und jedes Firmware-Update muss gegen die UCS Hardware and Software Compatibility Matrix laufen. Wer 2026 alte B200 M4 gegen M7-Blades tauscht, muss prüfen, ob die vorhandenen Fabric Interconnects (6200er/6300er Serie) die neuen Blades und die nötigen UCS-Manager-Bundles überhaupt tragen. Oft zieht der Servertausch den Tausch der Netzwerk-Kerninfrastruktur nach sich und sprengt damit Budget und Zeitplan.

4. Welche Ersatzteile zuerst knapp werden

4.1 Laufwerke und SSDs

HDDs und vor allem SSDs gehören zu den häufigsten Ausfallkandidaten. Generische SATA-Platten sind selten das Problem, diese bekommen Sie überall. Eng wird es bei OEM-zertifizierten SAS- und NVMe-SSDs, bei Self-Encrypting Drives (etwa an Dells Data Protection gekoppelt) und bei Laufwerken, die fest an Carrier und Firmware-Signaturen gebunden sind.

Wie ernst Probleme mit der Laufwerks-Firmware sein können, zeigt der berüchtigte 32.768-Stunden-Bug. Mehrere SAS-SSD-Modelle von HPE, Dell, Cisco und Lenovo trugen denselben Firmware-Defekt eines Zulieferers: Ein Speicherüberlauf ließ die SSD nach exakt 32.768 Betriebsstunden ausfallen, also nach 3 Jahren, 270 Tagen und 8 Stunden. Weder Laufwerk noch Daten waren danach zu retten. Kurz darauf kam eine fast identische Warnung für einen Fehler bei 40.000 Stunden.

Im Cluster ist das brandgefährlich. Server werden meist im Batch gekauft und gleichzeitig in Betrieb genommen. Also erreichen alle Laufwerke eines RAID-Arrays oder vSAN-Clusters die Stundenzahl fast zeitgleich. Die vermeintliche Redundanz ist dann wertlos, weil alle Platten zusammen sterben.

Wer 2026 Ersatz-SSDs über Broker kauft, muss nachweisbar sicherstellen, dass die gepatchte Firmware (bei HPE z. B. HPD8) schon drauf ist. Sonst tickt die Uhr aufs Neue. Und manche RAID-Software verweigert das Firmware-Flashen im laufenden Betrieb bei inkompatiblen Arrays, sodass sich selbst vorhandene Teile nicht sauber einsetzen lassen.

4.2 RAID-Controller und HBAs

RAID-Controller und HBAs sind oft der kritischste Single Point of Failure im Gehäuse. Heikel sind High-End-Modelle mit großem Cache und Batterie (BBU) oder Supercap. Diese Energiespeicher altern chemisch. Fällt die Batterie aus, schaltet der Controller den Write-Back-Cache ab und I/O-lastige Datenbanken brechen auf einen Bruchteil ihrer Leistung ein. Ersatz für diese Module muss vor dem Ausfall bereitliegen.

Auf dem Sekundärmarkt kursieren Batterien, die jahrelang tiefentladen im Regal lagen und keine Kapazität mehr aufbauen. Fällt der ganze Controller aus, brauchen Sie ein exakt baugleiches Modell mit gleicher oder neuerer Firmware. Sonst lassen sich die Metadaten auf den Platten nicht korrekt importieren und die Foreign Configuration wird zum Datenverlust.

4.3 Mainboards und Backplanes

Ein durchgeschmortes Mainboard verlangt bei Marken-Servern fast immer dasselbe Modell mit identischer Hardwarerevision. Mainboards auf Lager zu legen, ist teuer und braucht antistatischen, temperierten Platz.

Noch unterschätzter sind Backplanes, also die Platinen hinter den Laufwerkseinschüben. Sie sind streng ans Chassis gebunden (8-Bay SFF, 24-Bay NVMe usw.) und im Störungsfall schwer kurzfristig zu bekommen. Geht eine Backplane kaputt (defekter SAS-Expander, beschädigte Anschlüsse), fällt sofort ein ganzer Strang Laufwerke aus. Das hebelt selbst ein RAID 6 aus und bringt den Server zum Stehen.

4.4 Netzteile, Lüfter und Riser Cards

Netzteile und Lüfter gelten als banal, bei Legacy-Systemen sind sie aber eine häufige Ausfallursache. Das Server-Management überwacht Temperaturzonen und Drehzahlen genau. Fällt in einem 1U-Server ein Lüfter aus, drosselt das System die CPUs per Thermal Throttling oder schaltet zum Schutz sofort ab. Passende Lüftermodule für sieben Jahre alte Server gibt es oft nur gebraucht, mit bereits verschlissenen Lagern. Auch Riser Cards für PCIe-Karten sind formfaktorgebunden. Geht hier etwas kaputt und hängen die 10G/25G-NICs an so einer Karte, ist die schnelle Netzwerkanbindung weg.

4.5 GPUs und Beschleunigerkarten

Für KI, Machine Learning, VDI oder 3D-Rendering werden ältere NVIDIA- (z. B. Tesla P100) oder AMD-GPUs in Legacy-Servern schnell zum Problem. Mehreres kommt zusammen: Support für die Karte selbst, Treiber-Kompatibilität mit aktuellen Betriebssystemen (VMware ESXi, moderne Linux-Kernel), die passende Luftführung für passive Karten und die proprietäre Stromversorgung übers Mainboard. Eine defekte Pascal- oder Volta-GPU in einem ausgedienten Server zu ersetzen, ist teuer, zumal Security-Patches für ältere vGPU-Software ebenfalls auslaufen.

5. Risikomatrix: Welche Server 2026 zuerst auf den Prüfstand gehören

Damit Sie mit knappen Ressourcen priorisieren können, ordnet die folgende Matrix gängige Generationen nach Risikostufe. Grundlage ist die Schnittmenge aus erreichtem oder überschrittenem EOSL und der Praxis bei der Teilebeschaffung.

6. Modellliste: Kandidaten, die 2026 besonders zu beobachten sind

Nutzen Sie die folgende Liste, um die EOSL-Risiken Ihres Serverparks zu bewerten..

Hinweis: Diese Liste ersetzt keine rechtsverbindliche EOL-Tabelle des Herstellers für einen konkreten Wartungsvertrag. Sie dient der Priorisierung für die interne Risikoanalyse und zeigt beispielhaft, wo 2026 der dringendste Handlungsbedarf liegt.

7. So prüfen Sie Ihren Bestand

Um die Betriebsrisiken Ihres Serverparks durch EOSL bewerten zu können, müssen Sie Ihren eigenen Bestand kennen. Verlassen Sie sich dabei nicht auf eine möglicherweise lückenhafte Excel-Liste aus dem Einkauf. Hier sind sieben Schritte für ein sauberes Audit:

1. Quellen zusammenführen. Gleichen Sie CMDB, Monitoring (PRTG, Nagios, Zabbix), Virtualisierung (vCenter) und Management-Konsolen (iDRAC, iLO, UCS Manager) mit den kaufmännischen Bestandslisten ab. So finden Sie „Geisterserver“, die abgeschrieben sind, aber noch Legacy-Anwendungen tragen.
2. Identmerkmale exakt erfassen. Die Modellnummer reicht nicht. Lesen Sie Dell Service Tags, Lenovo Machine Types samt Geo Code sowie Seriennummern und PIDs bei HPE und Cisco per Skript aus und katalogisieren Sie sie.
3. Pro Seriennummer prüfen. Fragen Sie das tagesgenaue LDoS bzw. EOSL über die Hersteller-Tools und -APIs für jede einzelne Seriennummer ab, statt sich auf aggregierte EOL-Listen aus dem Netz zu verlassen.
4. Kritische Komponenten je Modell katalogisieren. Welche RAID-Controller stecken drin? Laufen genau die SAS-SSDs mit potenziell kritischer Firmware (32.768-Stunden-Bug)? Wenn ja: Ist das HPD8-Update nachweislich aufgespielt?
5. Ersatzteilhistorie auswerten. Sehen Sie sich die IT-Tickets der letzten 24 bis 36 Monate an. Welche Teile (Lüfter, Smart Storage Battery, RAM) mussten bei welchen Modellen gehäuft getauscht werden? Das ist ein harter Indikator (Badewannenkurve der Ausfallraten).
6. Den Ernstfall simulieren. Fragen Sie beim Systemhaus, Distributor oder TPM-Anbieter, wie lange die Beschaffung eines Ersatz-Mainboards für einen R730xd oder ein UCS C240 M4 heute dauert.

Nach Business-Kritikalität priorisieren. Ein Gen9 als isolierter Print-Server verlangt eine andere Bewertung als derselbe Gen9 unter der ERP-Datenbank.

Abbildung: EOSL-Risiken im Serverpark bewerten: 7 Schritte für ein Audit

8. Entscheidung: Weiterbetreiben, absichern oder ersetzen?

Liegen die Audit-Daten vor, brauchen Sie pro System eine tragfähige Strategie. Fünf Optionen, grob nach Aufwand sortiert:

Option A – Weiterbetrieb mit Hersteller-Support (OEM). Anwendbar, solange die Seriennummer noch ein aktives SLA hat, der Hersteller Teile garantiert und Firmware-Patches (vor allem gegen kritische CVEs) liefert. Dann reicht das übliche Lifecycle-Monitoring.

Option B – Third-Party-Maintenance (TPM). Sinnvoll, wenn das OEM-EOSL erreicht ist oder die Verlängerung zu teuer wird, das System aber stabil läuft und keine neuen Hardware-Features braucht. Die Hersteller sind laut Ökodesign-Richtlinie verpflichtet, kritische Patches kostenlos zur Verfügung zu stellen. Allerdings halten sich nicht alle Hersteller daran. Für betroffene Nutzer kann es dann schwierig werden, sich ihr Recht zu erkämpfen, vor allem dann, wenn ein Serverproblem vorliegt und Zeitdruck herrscht. Spezialisierte TPM-Anbieter wie Hardwarewartung.com können hier aufgrund ihrer Erfahrung helfen und zusätzlich Workarounds bieten, mit denen die Systeme bis zur Verfügbarkeit des Patches am Laufen gehalten werden können. Storage-Hardware ist in diesem Kontext kritischer zu bewerten als Server. Hier zahlt sich ein Audit durch den TPM-Anbieter aus, der prüft, ob die Systeme wartbar sind und welches Restrisiko besteht. Feature-Updates können im Gegensatz zu Bugfixes kostenpflichtig sein. Hier kann der TPM-Anbieter ein Update über den OEM oder Channel Partner organisieren.

Option C – Eigene Ersatzteilbevorratung (Spares). Für kritische Systeme in einer laufenden, sich aber ins Jahr 2026 verzögernden Migration. Sie kaufen gezielt baugleiche Gebrauchtserver als Spender für Mainboards, Controller, Laufwerke und Riser. Das bindet Kapital und Lagerplatz, drückt die Reaktionszeit im Fehlerfall aber von Tagen auf Minuten. In diesem Zusammenhang ist ein Ersatzteilservice wie der von Hardwarewartung.com zu empfehlen. Das ist in vielen Fällen deutlich günstiger als das Vorhalten eines eigenen Vor-Ort-Lagers.

Option D – Hardware-Refresh (Ablösung). Pflicht, wenn das Risiko zu groß wird. Auslöser sind etwa Compliance-Lücken (Firmware ohne Security-Patches im NIS-2-Scope), Performance-Engpässe, das absehbare Ende der Software-Wartung für zentrale Infrastruktur. So schließt VMware vSphere ältere CPU-Generationen schrittweise aus. Ebenfalls sinnvoll bei hoher Business-Kritikalität. Wird TPM für sehr exotische Altsysteme unverhältnismäßig teuer, rechnet sich über die Gesamtkosten (TCO) oft der Neukauf.

Option E – Workload-Migration. Der Lifecycle-Wechsel ist ein guter Anlass, die Architektur zu hinterfragen. Statt alte Hardware 1:1 zu ersetzen, lässt sich der Workload verlagern: Bare-Metal in VMs, Dienste in Container (Kubernetes, OpenShift), Wechsel in die Public Cloud (IaaS/PaaS) oder Konsolidierung auf moderne HCI-Appliances.

9. Ersatzteilservice bei Hardwarewartung.com

Der Ersatzteilservice von Hardwarewartung.com bietet Unternehmen eine kosteneffiziente und flexible Lösung, um die Lebensdauer älterer Server- und Storage-Systeme von HPE, Dell EMC, NetApp, Cisco, IBM und weiteren sicher zu verlängern, ohne sich an teure und langfristige Wartungsverträge binden zu müssen.

Kunden profitieren von einem stark minimierten Ausfallrisiko für ihre geschäftskritischen Daten. Zu einem festen monatlichen Preis garantiert unser Service den Austausch defekter Komponenten oder ganzer Systeme am nächsten Werktag („Next Business Day“).

Um mögliche Ausfallzeiten auf ein absolutes Minimum zu reduzieren, können wir kritische Ersatzteile wie Festplatten sogar vorab direkt vor Ort beim Kunden lagern, so dass sie auf Wunsch von einem bereitgestellten Vor-Ort-Techniker installiert werden können.

Dank der flexiblen Vertragslaufzeiten ab bereits einem Monat gewinnen IT-Verantwortliche somit die maximale Planungsfreiheit und finanzielle Entlastung für ihre Infrastruktur-Projekte.

10. Typische Fehler in der Ersatzteilplanung

Ein paar Muster tauchen immer wieder auf und kosten im Ernstfall Tage. Diese sollten Sie vermeiden:

Nur die Kernkomponenten betrachten. Viele Teams schauen auf CPU, RAM und die Hauptlaufwerke und vergessen RAID-Controller, SAS-Expander-Backplanes, Mezzanine-NICs (etwa Ciscos VICs) und externe Fabric Interconnects. Fällt eine proprietäre Backplane aus, ist der ganze Laufwerksstrang tot, auch mit brandneuen Platten.

Pauschal aufs Modell vertrauen. „Der R740 wird doch noch unterstützt“ ist trügerisch. Weil die Support-Zyklen am Verkaufsdatum hängen, kann R740 „A“ (2017 gekauft) schon EOL sein, während R740 „B“ (zwei Jahre später) noch unter Wartung steht. Prüfen Sie pro Service Tag oder Machine Type.

Sich auf Cluster-Redundanz verlassen. „Fällt ein Node aus, übernimmt der andere“ stimmt bei Zufallsausfällen. Stammen alle Nodes aus derselben Charge und liefen gleich lange, altern sie synchron (gleiche MTBF). Der 32.768- bzw. 40.000-Stunden-Bug zeigt das drastisch: Innerhalb von Minuten können die Laufwerke aller Nodes zusammen ausfallen. Redundanz schützt vor Zufall, gegen synchrone Alterung hilft sie nicht.

Erst im Störungsfall reagieren. Wer Teile für ein EOSL-System erst sucht, wenn das Rack schon rot blinkt, fängt sich lange Ausfallzeiten ein. Refurbished-Händler haben nicht jede Mainboard-Revision sofort versandbereit.

Firmware- und Security-Support ignorieren. Ein mechanisch intakter Server ist wertlos, wenn ihn die Security-Abteilung wegen ungepatchter iLO-/iDRAC-Lücken aus dem Netz nehmen muss. Hardware- und Firmware-Lebenszyklus gehören zusammen.

TPM zu spät evaluieren. TPM-Verträge brauchen Vorlauf: Audits, Inventur vor Ort, Konfigurationsprüfung, Bestückung der Ersatzteillager. Wer den Anbieter erst am Tag des OEM-Support-Endes anruft, riskiert eine monatelange Deckungslücke.

11. Ihre Ersatzteil-Checkliste für Server 2026

Bevor Sie ins Detail gehen, prüfen Sie jedes kritische System mit diesen Leitfragen:

• Business Impact dokumentiert? Verarbeitet das System unternehmenskritische Prozesse (ERP, Logistik, CRM), bei denen ein Ausfall von mehr als vier Stunden direkt Geld, Vertragsstrafen oder Reputation kostet?
• Aktiver OEM-Support pro Seriennummer? Gibt es für den konkreten Service Tag bzw. Machine Type noch garantierten Support, tagesaktuell über das Hersteller-Portal validiert und in der CMDB hinterlegt?
• Kritische Teile kurzfristig lieferbar? Sind Mainboard, redundantes Netzteil, der exakte RAID-Controller (mit Cache und Batterie) und die spezifischen Backplanes im SLA-Zeitrahmen verfügbar, und ist die Lieferkette verifiziert?
• Firmware-Stand aktuell? Gibt es noch Security- und Firmware-Updates, und zwar nicht nur fürs Betriebssystem, sondern für Management-Controller (iLO, iDRAC), System-BIOS, NICs und SSD-Firmware (Betriebsstunden-Bugs)?
• Disaster-Recovery-Plan getestet? Existiert ein dokumentierter und kürzlich erfolgreich getesteter Restore- oder Migrationsplan, falls die Hardware irreparabel ausfällt?
• Architektur-Risiko geprüft? Ist das System Teil eines HA-Clusters, in dem alle Nodes aus derselben Charge stammen und denselben Alterungsprozess durchlaufen (Laufwerks-Betriebsstunden, Flash-Wear)?
• Wartungs-Alternative verhandelt? Gibt es bereits einen Rahmenvertrag mit einem TPM-Anbieter, der die Architektur versteht, die Teile vorrätig hat und im Ernstfall nahtlos übernimmt?

12. FAQs

Verlängert sich das End of Service Life (EOSL), wenn ich eine erweiterte Garantie kaufe?

Nein. Das EOSL legt der Hersteller fest. Care Packs oder Service-Verlängerungen lassen sich nur bis zu diesem Datum buchen. Ist es erreicht, lehnen Hersteller neue Verträge ab, weil sie die Ersatzteil-Lieferkette dann weltweit abbauen.

Können wir ausgefallene Platten durch beliebige SSDs vom Markt ersetzen?

Bei Enterprise-Servern mit Hardware-RAID-Controller meistens nicht ohne Probleme. Controller erkennen fremde SSDs oft nicht als gültig an, drosseln die Performance, verweigern die Aufnahme ins Array oder drehen die Lüfter dauerhaft auf 100 Prozent, weil sich die Temperatursensoren der Fremdplatten nicht über die OEM-Protokolle auslesen lassen. Dazu kommen inkompatible Firmware-Stände, die Cluster-Technologien wie VMware vSAN aus dem Tritt bringen. Bei Legacy-Systemen führen OEM-zertifizierte Laufwerke mit validierter Firmware zum stabileren Ergebnis.

Was ist Third-Party-Maintenance (TPM), und löst das alle Probleme?

TPM-Anbieter übernehmen den physischen Hardware-Support, nachdem der OEM-Vertrag abgelaufen oder zu teuer geworden ist. Sie bevorraten weltweit Teile in Lägern und bieten SLAs bis hin zum 4-Stunden-Austausch vor Ort. Das logistische Problem lösen sie gut und kosteneffizient. Das Firmware- und Software-Problem bleibt: Ohne Zugriff auf den proprietären Quellcode können sie keine neuen BIOS-, BMC- oder Security-Patches entwickeln, wenn nach dem End of Security Support eine neue Lücke auftaucht. TPM überbrückt also die Logistik. Ausnahme sind spezialisierte Anbieter wie Hardwarewartung.com: Wir können entsprechende Prüfungen vornehmen. Für die Firmware-Sicherheit nach dem Support-Ende sorgt es nicht.

Wie prüfe ich Updates, wenn der Dell Lifecycle Controller keine Verbindung zum Dell-Repository mehr aufbaut?

Das passiert bei älteren Dells (iDRAC8, frühe iDRAC9) häufig. Ursache sind veraltete SSL/TLS-Protokolle im alten iDRAC oder geänderte Serverpfade bei Dell, erkennbar an Meldungen wie „Invalid share name or repository location“. Dann aktualisiert sich der Server nicht mehr selbst. Nutzen Sie den Dell Repository Manager (DRM) auf einem separaten Arbeitsplatzrechner, bauen Sie einen lokalen Katalog (Server Update Utility), exportieren Sie ihn als bootfähiges ISO und patchen Sie lokal über virtuelles Medium per iDRAC-Konsole. Den Garantiestatus prüfen Sie separat über das Dell-Portal anhand des Service Tags, weil er im iDRAC nicht steht.