Montagmorgen, die Produktion läuft an, doch die Mitarbeitenden kommen nicht an ihre Zeichnungen, Aufträge oder Kundendaten. Der zentrale Server antwortet nicht, das Storage-System meldet Fehler und das Backup ist entweder unvollständig oder nie getestet worden. Während die IT nach einem freien Ersatzgerät sucht, warten Fertigung, Verwaltung und Geschäftsführung auf eine Lösung.
Solche Situationen entstehen selten durch einen einzigen spektakulären Defekt. Häufig wachsen Server und Storage über Jahre, einzelne Festplatten werden ersetzt, zusätzliche virtuelle Maschinen kommen hinzu und Backups laufen irgendwann nur noch nach bestem Wissen. Die Anschaffungskosten waren damals überschaubar. Die späteren Kosten für Ausfälle, Energie, Kühlung, Stellfläche und manuelle Administration bleiben dagegen unsichtbar.
Für deutsche Unternehmen ist das Thema inzwischen größer als eine interne IT-Frage. 2024 lag der Strombedarf von Rechenzentren und kleineren IT-Installationen in Deutschland bei rund 20 TWh, etwa 4 % des gesamten deutschen Stromverbrauchs. Für 2025 wird ein Anstieg auf 21,3 Mrd. kWh erwartet, wobei rund zwei Drittel auf Server, Speicher und Netzwerktechnik entfallen (Bundesministerium für Wirtschaft und Energie, Stand und Entwicklung des Rechenzentrumsstandorts Deutschland). Eine tragfähige Server- und Storage-Architektur muss deshalb nicht nur schnell sein. Sie muss über mehrere Jahre wirtschaftlich, ausfallsicher und dokumentierbar bleiben.
Inhaltsverzeichnis
- Wenn Server and Storage plötzlich zum Geschäftsrisiko werden
- Grundlagen der Server- und Storage-Architekturen
- On-Premises versus Cloud und Hybrid-Modelle
- Performance und Kapazitätsplanung im Energiezeitalter
- Backup und Disaster Recovery unter NIS2-Anforderungen
- Wann sich Managed Services für Server and Storage lohnen
- Checkliste für Beschaffung und Migration
Wenn Server and Storage plötzlich zum Geschäftsrisiko werden
Ein Fertigungsbetrieb mit 120 Mitarbeitenden erlebt den Ausfall nicht als technisches Ereignis, sondern als Stillstand. Der Fileserver, über Jahre durch neue Freigaben und Projekte gewachsen, startet am Montag nicht mehr. Das letzte vollständige Backup liegt länger zurück, die aktuelle Sicherung enthält wichtige Dateien nicht und niemand kann sicher sagen, welche Version für die Produktion freigegeben war.
Die ersten Minuten wirken noch beherrschbar. Dann häufen sich die Folgen. Konstruktion und Arbeitsvorbereitung können Dokumente nicht öffnen, der Einkauf erreicht Bestellinformationen nicht und der Vertrieb muss Kunden vertrösten. Eine Ausfallversicherung kann finanzielle Schäden begrenzen, aber sie stellt keine Daten wieder her und ersetzt keine fehlende Wiederanlaufplanung.
Der Schaden beginnt lange vor dem Totalausfall
In vielen KMU kündigt sich ein kritisches System vorher an. Speicherpools laufen voll, Festplatten werden ohne dokumentierte Konfiguration getauscht, Firmwarestände unterscheiden sich und Warnmeldungen landen in einem Postfach, das niemand regelmässig prüft. Ein einzelner Server bildet dann gleichzeitig Dateispeicher, Verzeichnisdienst, Datenbankplattform und Host für virtuelle Maschinen.
Praktische Regel: Ein Server, dessen Ausfall mehrere Geschäftsbereiche gleichzeitig blockiert, braucht eine dokumentierte Abhängigkeit, eine definierte Wiederherstellung und einen getesteten Ersatzweg.
Redundanz allein löst das Problem nicht. Zwei Systeme können dieselbe Fehlkonfiguration teilen, ein synchroner Spiegel kann versehentlich gelöschte oder verschlüsselte Daten übernehmen und ein Backup ohne regelmässigen Restore-Test bleibt eine Annahme. Entscheidend ist, dass Verantwortliche wissen, welche Daten kritisch sind, wie schnell sie zurückkommen müssen und wer die Wiederherstellung ausführt.
Dokumentation gehört zur Betriebssicherheit
Ein aktueller Infrastrukturplan sollte Server, Storage, virtuelle Maschinen, Abhängigkeiten, Backup-Jobs, Aufbewahrung und Zuständigkeiten abbilden. Für Unternehmen, die ihre Risiken systematisch ordnen wollen, bietet ein strukturiertes IT-Risikomanagement für Unternehmen einen geeigneten Ausgangspunkt.
Das gilt auch für Betriebe mit wechselnden Einsatzorten oder externen Teams. Wenn Monteure, Techniker oder Projektmitarbeitende auf Baustellen arbeiten, müssen Datenzugriff, Gerätebereitstellung und Kommunikationswege zur Betriebsrealität passen. Praktische Hinweise zur Organisation von Teams und Unterkünften finden sich etwa in den Tipps für Team-Logistik in Peine.
Der eigentliche Fehler liegt selten darin, dass ein Unternehmen nicht die teuerste Hardware gekauft hat. Problematisch wird es, wenn niemand die gesamte Lebensdauer betrachtet. Energieverbrauch, Kühlung, Rack-Fläche, Support, Wartung und Ausfallrisiko gehören genauso zur Entscheidung wie Prozessor, Festplattentyp und Speicherkapazität.
Grundlagen der Server- und Storage-Architekturen
Die passende Architektur hängt vom Zugriffsmuster ab, nicht vom Produktprospekt. Ein kleiner Dateibestand mit wenigen gleichzeitigen Zugriffen braucht eine andere Konstruktion als eine Datenbank, virtuelle Desktops oder eine Plattform mit hoher Änderungsrate.
Vier Modelle, vier Einsatzlogiken
Direct Attached Storage, DAS, ist direkt an einen Server gebunden. Das ähnelt einem privaten Aktenschrank neben dem eigenen Schreibtisch. Die Lösung ist einfach und kann für einen einzelnen Host oder eine klar abgegrenzte Anwendung sinnvoll sein. Sie skaliert jedoch schlecht, wenn mehrere Server auf denselben Datenbestand zugreifen müssen oder der Server selbst ausfällt.
Network Attached Storage, NAS, stellt Dateien über das Netzwerk bereit. Mehrere Mitarbeitende greifen auf gemeinsame Ordner zu, ähnlich wie auf einen zentralen Büroschrank. NAS passt zu klassischen Dateiablagen, zentralen Freigaben und bestimmten Backup-Szenarien. Wichtig sind Benutzerrechte, Snapshots, Ersatzteilversorgung und eine klare Trennung zwischen produktiven Daten und Sicherungskopien.
Storage Area Networks, SAN, liefern meist Block-Storage über ein eigenes oder logisch getrenntes Speichernetz. Das ist eher ein automatisiertes Hochregallager, in dem Server definierte Speicherblöcke beziehen. SAN-Systeme eignen sich für anspruchsvolle Datenbanken, Virtualisierung und Anwendungen mit planbaren Performance-Anforderungen. Sie bringen aber zusätzliche Komplexität bei Fabric, Multipathing, Monitoring und Administration.
Hyperkonvergente Infrastruktur, HCI, verbindet Rechenleistung, Storage und Netzwerk in einer softwaredefinierten Plattform. Das Modell erinnert an ein modulares Container-Rechenzentrum. Knoten lassen sich nach einem einheitlichen Betriebsmodell erweitern, allerdings muss die gesamte Plattform sauber dimensioniert und lizenziert werden. Wer nur mehr Speicher braucht, kauft unter Umständen auch zusätzliche Rechenleistung mit.
Eine einfache Entscheidungshilfe
| Typische Situation | Sinnvoller Ausgangspunkt | Worauf besonders achten |
|---|---|---|
| Einzelne Anwendung auf einem Host | DAS | Host-Ausfall, Ersatz und Backup |
| Gemeinsame Dateiablage | NAS | Rechte, Snapshots und Wiederherstellung |
| Datenbank oder grosse Virtualisierungsumgebung | SAN | Latenz, Pfade und Fachbetrieb |
| Standardisierte virtuelle Plattform | HCI | Skalierung, Lizenzierung und Herstellerbindung |
Cloud Storage kann diese Modelle ergänzen oder ersetzen, ist aber kein automatisch besseres NAS. Entscheidend sind Datenhoheit, Zugriffswege, Wiederherstellung, Vertragsbedingungen und die Frage, wie viel Betrieb das eigene Team dauerhaft leisten kann. Eine Architektur ist dann gut gewählt, wenn sie die benötigte Leistung liefert, ohne unnötige Abhängigkeiten und laufende Kosten aufzubauen.
On-Premises versus Cloud und Hybrid-Modelle
Die Entscheidung zwischen On-Premises, Public Cloud und Hybrid sollte nicht nach persönlicher Vorliebe fallen. Für ein KMU zählen konkrete Betriebsparameter: Wie schnell müssen Anwendungen auf Daten zugreifen, welche Daten dürfen wo liegen, wie stark schwankt die Auslastung und welche Kosten entstehen während des gesamten Betriebs?
On-Premises bietet direkte Kontrolle über Hardware, Datenpfade und lokale Latenz. ERP, CAD, Produktionsplanung oder grosse Dateioperationen können davon profitieren, wenn Arbeitsplätze und Server am selben Standort verbunden sind. Dafür trägt das Unternehmen Investition, Wartung, Erneuerung, Stromversorgung, Kühlung und Ausfallvorsorge selbst.
Die Public Cloud verschiebt einen Teil dieser Verantwortung zum Anbieter. Kapazitäten lassen sich flexibler anfordern, neue Dienste sind schnell verfügbar und mehrere Standorte können leichter angebunden werden. Die Kehrseite sind laufende Nutzungsgebühren, Abhängigkeiten von Netzwerkverbindungen sowie Kosten für Datenbewegungen und Rückholungen. Wer grosse Datenmengen regelmässig aus der Cloud heraus transportiert, muss diese Egress-Kosten ausdrücklich in die Kalkulation aufnehmen.
| Kriterium | On-Premises | Public Cloud | Hybrid |
|---|---|---|---|
| Latenz | Sehr gut bei lokalen Workloads | Abhängig von Verbindung und Region | Kritische Daten lokal, flexible Dienste extern |
| Datenhoheit | Direkte Kontrolle | Vertragliche und technische Prüfung nötig | Verteilung nach Schutzbedarf |
| Skalierbarkeit | Planung und Beschaffung erforderlich | Sehr flexibel | Skalierung je Workload |
| Betrieb | Eigenes Team oder Dienstleister | Providerbetrieb, eigene Konfiguration bleibt relevant | Geteilte Verantwortung |
| Kostenmodell | Investition plus laufender Betrieb | Nutzungs- und Servicegebühren | Mischmodell mit gesteuerter Platzierung |
| Datenrückholung | Keine externen Egress-Gebühren | Rückholung kann Kosten verursachen | Rückholwege vorab definieren |
Die Betrachtung über mehrere Jahre
Ein Vergleich über 36 bis 60 Monate ist sinnvoll, weil der Anschaffungspreis nur einen Teil der Rechnung bildet. Bei On-Premises gehören Energie, Kühlung, Supportverlängerung, Ersatzteile, Stellfläche und Arbeitszeit in die TCO. In der Cloud zählen neben der Grundnutzung auch Speicherklassen, Backup, Replikation, Datenabfluss, Monitoring und gegebenenfalls zusätzliche Sicherheitsdienste.
Ein Hybrid-Modell ist für viele KMU pragmatisch, wenn es bewusst gestaltet wird. Lokale Systeme können zeitkritische oder besonders datenintensive Anwendungen bedienen, während Cloud-Dienste für externe Backups, Kollaboration, Archivierung oder saisonale Kapazitäten eingesetzt werden. Das funktioniert nur mit klaren Datenflüssen. Eine unkontrollierte Mischung aus lokalen Freigaben, synchronisierten Cloud-Ordnern und mehreren Backup-Plattformen macht die Umgebung teurer und schwerer prüfbar.
Performance und Kapazitätsplanung im Energiezeitalter
Eine belastbare Kapazitätsplanung beginnt nicht bei der Zahl der Terabyte. Für Server und Storage zählen IOPS, Durchsatz, Latenz, Wachstum, Energieaufnahme und benötigte Rack-Fläche gemeinsam. Ein System kann ausreichend Bruttokapazität haben und trotzdem zu langsam sein. Ein überdimensioniertes Array verursacht dagegen dauerhaft Strom-, Kühlungs- und Wartungskosten, ohne zusätzlichen geschäftlichen Nutzen.
Der Energieverbrauch macht diese TCO-Frage sichtbar. Der jährliche Bedarf von Servern, Storage und Netzwerktechnik in deutschen Rechenzentren stieg von 5,8 Mrd. kWh im Jahr 2010 auf 10 Mrd. kWh im Jahr 2020. Bereits 2020 entfielen rund 42 % des Stromverbrauchs auf Server, Speicher lag bei den IT-Verbrauchern an zweiter Stelle (Wissenschaftliche Dienste des Deutschen Bundestages, Energieverbrauch von Rechenzentren).
Erst messen, dann ersetzen
Vor einer Beschaffung gehören Monitoring-Daten aus repräsentativen Betriebszeiträumen auf den Tisch. Ausgewertet werden nicht nur Spitzenwerte, sondern auch die Verteilung von Lese- und Schreibzugriffen, Antwortzeiten, Warteschlangen, VM-Auslastung und die Entwicklung des freien Speichers. Windows Performance Monitor, DiskSpd für kontrollierte Tests und Array-Analysen der Hersteller helfen, Annahmen durch Messwerte zu ersetzen.
Deduplizierung und Komprimierung können die nutzbare Kapazität erhöhen, ohne sofort weitere Laufwerke einzubauen. Wie viel dabei gewonnen wird, hängt vom Datenbestand ab. Verschlüsselte Dateien, bereits komprimierte Medien und individuelle Binärdateien bieten meist weniger Potenzial als virtuelle Maschinen, Dokumente oder wiederkehrende Datenblöcke.
| Kostenfaktor | HDD-Array, 48 TB brutto | All-Flash, 24 TB brutto, 2:1 Dedup |
|---|---|---|
| Anschaffung | Geringerer Einstieg möglich, Controller und Ersatzteile einrechnen | Höherer Einstieg möglich, Effizienz und Support bewerten |
| Energie | Laufwerke drehen dauerhaft, Last und Kühlung berücksichtigen | Weniger bewegliche Komponenten, tatsächliche Leistungsaufnahme messen |
| Performance | Geeignet für sequenzielle und wenig latenzkritische Zugriffe | Sinnvoll bei hoher Parallelität und kurzen Antwortzeiten |
| Stellfläche | Mehr Laufwerke für Leistung und Redundanz möglich | Hohe Dichte, aber Controller und Erweiterungen einplanen |
| Kapazitätsrisiko | Bruttokapazität nicht mit nutzbarem Platz verwechseln | Dedup-Ergebnis muss mit echten Daten geprüft werden |
| Betrieb über drei Jahre | Wartung, Laufwerkstausch und Kühlung berücksichtigen | Lizenzierung, Support und Verbrauchswerte einrechnen |
Automatisches Tiering legt häufig benötigte Daten auf schnelle Medien und verschiebt selten verwendete Bestände auf günstigere Kapazität. Das lohnt sich besonders, wenn Arbeitsdaten, Archiv und Backup getrennt bewertet werden. Jede ungenutzte Festplatte bleibt ein laufender Kostenfaktor, solange sie Strom, Kühlung, Platz und Wartung bindet.
Für KMU folgt aus der installierten Serverbasis in Deutschland keine Pflicht zur maximalen Verdichtung. Entscheidend ist, Leistung am tatsächlichen Bedarf auszurichten und Kapazität nicht dauerhaft ohne passendes Zugriffsmuster vorzuhalten. So werden Energie, Stellfläche und Betriebskosten über mehrere Jahre planbarer.
Backup und Disaster Recovery unter NIS2-Anforderungen
Ein Backup-Konzept schützt nicht automatisch vor Betriebsunterbrechung. Es braucht drei miteinander verbundene Ebenen: eine erreichbare lokale Sicherung, eine räumlich oder logisch getrennte Kopie und eine nachweislich funktionierende Wiederherstellung.
Die klassische 3-2-1-Regel bleibt ein nützlicher Rahmen, reicht allein aber nicht aus. Entscheidend ist, ob eine Sicherung gegen Manipulation geschützt ist, ob Zugangsdaten getrennt verwaltet werden und ob das Team die Wiederherstellung unter realistischen Bedingungen beherrscht. Eine zusätzliche unveränderliche Kopie, getrennte Administrationsrechte und dokumentierte Tests machen aus einer Kopienstrategie eine belastbare Resilienzstrategie.
Wiederanlaufziele müssen zum Geschäft passen
Für das ERP gelten andere Anforderungen als für ein Archiv. E-Mail kann unter Umständen nachrangig wiederhergestellt werden, während Produktionsdaten oder zentrale Auftragsinformationen unmittelbar benötigt werden. Deshalb sollten Verantwortliche je Anwendung ein Recovery Time Objective, RTO, und ein Recovery Point Objective, RPO, festlegen.
Das RTO beschreibt, wie lange die Anwendung ausfallen darf. Das RPO legt fest, welcher Datenverlust zeitlich akzeptabel ist. Continuous Data Protection, anwendungskonsistente Snapshots und externe Replikation können kürzere Ziele unterstützen, erhöhen aber die Anforderungen an Netzwerk, Speicher, Lizenzen und Tests. Ein Ziel ist erst belastbar, wenn die Infrastruktur es unter Last und bei einem realistischen Fehlerbild erreicht.
Für betroffene Unternehmen ist das NIS-2-Umsetzungsgesetz laut BSI am 06.12.2025 in Kraft getreten. Das BSI nennt unter anderem nachvollziehbar zu dokumentierende Risikomanagementmassnahmen, die Meldung öffentlicher IP-Adressbereiche sowie regelmässig zu überprüfende organisatorische und technische Massnahmen (BSI, FAQ zu NIS2).
Was ein prüfbares Konzept dokumentiert
- Sicherungsumfang: Welche Server, Datenbanken, Freigaben und Konfigurationen werden gesichert?
- Zeitplan und Aufbewahrung: Wann laufen Jobs, wie lange bleiben Versionen verfügbar und wer prüft Fehler?
- Schutz gegen Manipulation: Welche Kopien sind unveränderlich oder administrativ getrennt?
- Wiederherstellung: Wer startet den Restore, welche Reihenfolge gilt und wie wird die Vollständigkeit geprüft?
- Testnachweis: Datum, System, Ergebnis, Abweichung und Korrekturmassnahme gehören in ein Protokoll.
Cloud-Backup kann als externe Kopie wirtschaftlich sinnvoll sein, darf aber nicht zur einzigen Rettungsoption werden. Vorab sollten Datenstandort, Verschlüsselung, Wiederherstellungsbandbreite, Vertragsende und Exportmöglichkeiten geklärt werden. Unterstützung bei einer passenden Umsetzung bietet etwa Cloud Backup in Deutschland.
Ein kurzer Restore-Test sagt mehr als ein grünes Backup-Symbol. Dieses Video zeigt ergänzend, wie Datenresilienz und Wiederherstellung in der Praxis eingeordnet werden können.
Wann sich Managed Services für Server and Storage lohnen
Eigenbetrieb wirkt günstig, solange nur die Hardware-Rechnung betrachtet wird. In der Praxis bezahlen Unternehmen zusätzlich für Patch-Management, Firmwarepflege, Monitoring, Dokumentation, Garantieverlängerungen, Ersatzteilkoordination und die Zeit von Mitarbeitenden, die sich eigentlich um Anwendungen, Kunden oder Produktion kümmern sollten.
Ein Managed-Service-Modell passt besonders dann, wenn mehrere Server, virtuelle Maschinen, Storage-Systeme oder Standorte zusammenwirken. Auch wechselnde Anforderungen, fehlende Vertretung bei Krankheit und die Pflicht zu nachvollziehbaren Sicherheitsprozessen sprechen für einen strukturierten externen Betrieb. Eine feste monatliche Pauschale kann die Planung erleichtern, während Pay-per-Use-Modelle bei stark schwankender Nutzung flexibler sein können.
Nicht jede Aufgabe gehört nach aussen
Ein Dienstleister kann Infrastruktur überwachen, Updates koordinieren, Kapazitäten prognostizieren, Backup-Fehler verfolgen und Disaster-Recovery-Tests organisieren. Die fachliche Verantwortung für ERP-Prozesse, Produktionslogik oder individuelle Freigaberegeln sollte dagegen beim Unternehmen bleiben. Gute Verträge definieren Zuständigkeiten, Reaktionswege, Wartungsfenster, Eskalationen und die Herausgabe von Dokumentation.
Ein Managed Service ist kein Freibrief für fehlende Kontrolle. Unternehmen sollten sich Reports, Anlagenübersichten, Backup-Protokolle, Restore-Nachweise und Sicherheitsmassnahmen zeigen lassen. Für KMU, die Server und Storage nicht selbst rund um die Uhr betreiben können, beschreibt Managed IT für mehr Sicherheit und Effizienz im Mittelstand einen möglichen Leistungsrahmen.
Entscheidend ist nicht, ob ein Dienstleister die Systeme bedient. Entscheidend ist, ob das Unternehmen jederzeit nachvollziehen kann, was geschützt ist, wer handelt und wie ein Ausfall behoben wird.
Die GSL Groß GmbH betreut als regionales IT-Systemhaus unter anderem Microsoft-Server sowie virtuelle und physische Client- und Serversysteme. Damit kann ein KMU den Eigenbetrieb mit externer Überwachung, Administration und dokumentierten Abläufen kombinieren, statt jede Aufgabe vollständig auszulagern.
Checkliste für Beschaffung und Migration
Ein Server- und Storage-Projekt sollte mit belastbaren Ist-Daten beginnen. Die folgende Reihenfolge lässt sich direkt in ein Projektmanagement-Tool übernehmen.
Vor der Bestellung
- Ist-Analyse durchführen: Erfassen Sie Workloads, Datenbestände, Abhängigkeiten, Auslastung, Engpässe, Backup-Jobs und bekannte Fehlerbilder.
- Anforderungen festlegen: Definieren Sie Performance, Verfügbarkeit, RTO, RPO, Datenhoheit, Wachstum und Zuständigkeiten.
- Architektur auswählen: Vergleichen Sie NAS, SAN, HCI, On-Premises, Cloud und Hybrid anhand realer Zugriffsmuster, nicht anhand allgemeiner Produktversprechen.
- Angebote nach TCO bewerten: Fordern Sie Energieverbrauch, Stellfläche, Support-Level, Ersatzteilverfügbarkeit, Lizenzen, Migration und Betriebskosten für 60 Monate getrennt auf.
Während der Umsetzung
- Migration vorbereiten: Bereinigen Sie Daten, prüfen Sie Berechtigungen, sichern Sie Konfigurationen und dokumentieren Sie die Ausgangslage.
- Parallelbetrieb planen: Lassen Sie alte und neue Umgebung kontrolliert nebeneinander laufen, validieren Sie Anwendungen und halten Sie einen Rollback-Plan bereit.
- Cutover durchführen: Legen Sie ein Wartungsfenster fest, informieren Sie betroffene Teams und prüfen Sie Datenkonsistenz nach der Umschaltung.
- Betrieb abnehmen: Kontrollieren Sie Monitoring, Alarmierung, Backup, Restore, Performance und Dokumentation mit echten Anwendungstests.
Zum Abschluss gehören ein aktueller Netzwerk- und Systemplan, Lizenznachweise, Supportkontakte, Admin-Zuständigkeiten, Backup-Protokolle und Restore-Testberichte in die Betriebsdokumentation. Diese Unterlagen helfen nicht nur bei Audits oder Versicherungsfragen. Sie verkürzen auch die Fehlersuche, wenn eine Person ausfällt oder ein System unerwartet neu aufgebaut werden muss.
Wenn Sie Server und Storage im KMU planbar, energieeffizient und belastbar betreiben möchten, unterstützt die GSL Groß GmbH bei Analyse, Beschaffung, Migration, Administration, Backup und NIS2-orientierter Dokumentation. Besprechen Sie Ihre aktuelle Umgebung und die nächsten 3 bis 5 Jahre mit GSL Groß GmbH, bevor ein überlastetes oder ungeschütztes System zum Geschäftsrisiko wird.