Storage Area Network (SAN): Architektur, Protokolle & wann ein Mittelstand ein SAN wirklich braucht

Inhalt in Kürze

• Ein Storage Area Network (SAN) ist ein dediziertes Hochgeschwindigkeits-Netzwerk, das Server auf Blockebene mit zentralem Speicher verbindet — perfekt für Datenbanken, Virtualisierungs-Cluster und hohe IOPS-Workloads.
• SAN ≠ NAS: SAN liefert Block-Storage (wie lokale Festplatte), NAS liefert Dateien über SMB/NFS. Für Dokumente reicht NAS — für SQL, Exchange oder VMware-Farms braucht es SAN oder HCI.
• Der globale SAN-Markt wächst laut Futuremarketinsights 2026 mit 3,7 % CAGR von 23,9 Mrd. USD (2026) — aber die Architektur-Landschaft verschiebt sich rapide Richtung NVMe-oF und HCI.
• Für KMU in Hamburg und Norddeutschland ist ein klassisches Fibre-Channel-SAN in 9 von 10 Fällen übertrieben. Hyperconverged Infrastructure oder Cloud-Storage sind günstiger, einfacher und performant genug.
• Wenn SAN, dann richtig: Dual Controller, getrennte FC-Switches, redundante HBAs pro Server, Multipath-Software — und ein unabhängiges Backup. Ein SAN ohne sauberes Backup ist ein Single Point of Failure.

Sie haben einen neuen Fileserver gekauft, zwei virtuelle Maschinen ziehen Performance, die Datenbank ächzt um 9:00 Uhr, wenn alle Mitarbeiter gleichzeitig loslegen — und Ihr IT-Dienstleister schlägt ein SAN vor. Preisschild: 60.000 €. Bevor Sie unterschreiben: Lesen Sie diesen Artikel. Wir erklären, was ein SAN wirklich ist, wann es sich lohnt, und wann Sie mit einem Bruchteil des Budgets ein besseres Ergebnis bekommen.

Dieser Leitfaden richtet sich an Geschäftsführer und IT-Entscheider in Unternehmen zwischen 20 und 250 Mitarbeitern. Wir arbeiten seit über 20 Jahren mit SAN-Systemen in Hamburger Mittelstandsprojekten — und wir sagen Ihnen ehrlich, wann ein SAN die richtige Antwort ist und wann nicht.

Was ist ein Storage Area Network (SAN)? — Definition

Ein Storage Area Network (SAN) ist ein dediziertes Hochgeschwindigkeits-Netzwerk, das Server auf Blockebene mit einem oder mehreren zentralen Speichersystemen verbindet. Anders als bei einem klassischen Dateiserver sieht das Betriebssystem den SAN-Speicher als lokale Festplatte — Windows, Linux und VMware behandeln das Storage Array, als wäre es direkt im Server verbaut.

Technisch läuft das über Protokolle wie Fibre Channel, iSCSI, FCoE oder NVMe-over-Fabrics. Die Server sprechen das Protokoll über spezielle Netzwerkkarten (HBAs — Host Bus Adapter) und Switches, die ausschließlich für Storage-Traffic zuständig sind. Dieses „Fabric” genannte Netzwerk läuft strikt getrennt vom normalen LAN.

Drei Merkmale unterscheiden ein SAN von allem anderen:

1. Block-Level-Zugriff: Das SAN liefert keine Dateien, sondern Datenblöcke fester Größe (typisch 512 Byte oder 4 KB). Das Betriebssystem des Servers verwaltet das Dateisystem — nicht das SAN.
2. Dediziertes Netzwerk: Der Storage-Traffic läuft nicht über dasselbe Netzwerk wie E-Mails, Teams-Calls oder Drucker. Eigene Switches, eigene Kabel, eigene Managementebene.
3. Zentraler Pool, viele Server: Ein SAN kann Speicher für zehn oder hundert Server gleichzeitig bereitstellen. Diese Server greifen über LUNs (Logical Unit Numbers) auf „ihre” Datenblöcke zu.

Typische Einsatzfälle: SQL-Datenbanken mit hoher Transaktionslast, Microsoft Exchange in großen Umgebungen, SAP HANA, virtualisierte Server-Farmen mit VMware vSphere oder Hyper-V, Echtzeit-Analytics und CAD-Umgebungen mit riesigen Dateien.

SAN vs. NAS vs. DAS — der große Vergleich

Die drei Storage-Architekturen lösen unterschiedliche Probleme. Wer sie verwechselt, baut an der falschen Stelle. Laut dem Speicherguide-Marktreport 2026 ist die Vielfalt 2026 größer als je zuvor — NAS-Systeme sind leistungsfähiger geworden, SAN bleibt im Enterprise-Umfeld relevant, Cloud-Storage spielt eine wachsende Rolle.

DAS (Direct Attached Storage) sind Festplatten oder SSDs, die direkt im Server stecken oder über SAS an einen Server angeschlossen sind. Kein Netzwerk, keine Umwege — dafür aber auch keine Flexibilität. Wenn der Server ausfällt, ist auch der Speicher weg.

NAS (Network Attached Storage) ist ein eigenständiges Gerät mit eigenem Betriebssystem, das Dateien über SMB (Windows) oder NFS (Linux/VMware) ins LAN stellt. Synology, QNAP und NetApp sind typische Hersteller. Einfache Einrichtung, günstig, perfekt für Dokumenten-Shares und Backup-Ziele.

SAN (Storage Area Network) ist die Königsklasse: dedizierte Hardware, dediziertes Netzwerk, Block-Level-Zugriff. Komplex in der Planung, aber unschlagbar bei Performance-kritischen Workloads.

Eine ausführliche Entscheidungshilfe mit Kostenrechnung finden Sie auch in unserem Artikel NAS vs. SAN: Datenspeicherung für Unternehmen — dort steht die Kurzfassung: „NAS arbeitet auf Dateiebene (einfach), SAN auf Blockebene (schnell) — für KMU ist NAS meist die richtige Wahl.”

SAN-Architektur: Fabric, Switches, HBAs, LUNs

Ein SAN besteht aus fünf Kernkomponenten, die alle redundant ausgelegt sein sollten — sonst wird das SAN selbst zum Single Point of Failure.

1. Storage Array (das Herz): Dual-Controller-System mit SSDs oder Festplatten. Marktführer: Dell PowerStore/Unity XT, NetApp AFF/FAS, HPE Alletra/Primera, Pure Storage FlashArray, IBM FlashSystem. Alle bieten heute inline-Deduplikation, Kompression und Snapshots.
2. Fabric (das Netzwerk): Bei Fibre Channel sind das zwei getrennte FC-Switches (Brocade, Cisco MDS). Bei iSCSI zwei normale 25/100-GbE-Switches mit entsprechender QoS. Der Fabric-Begriff stammt aus der Fibre-Channel-Welt und beschreibt das gesamte Storage-Netzwerk.
3. HBAs (die Brücke): Host Bus Adapter in jedem Server — je ein FC-HBA pro Server-Port oder Ethernet-NICs mit iSCSI-Offload. Redundant: immer zwei HBAs pro Server, einer pro Fabric-Pfad.
4. Multipath-Software: Windows MPIO, VMware NMP oder Linux DM-Multipath. Sorgt dafür, dass der Server beide Pfade nutzt und bei Ausfall automatisch umschaltet — ohne Server-Reboot.
5. LUNs und Zoning: Jeder Server bekommt „seine" LUNs — logische Festplatten, die im Array definiert werden. Zoning auf dem Fabric regelt, welcher Server welche LUN überhaupt sehen darf (Sicherheitsebene). LUN-Masking im Array macht dasselbe auf Speicherseite.

Fabric-Topologien: Klassisch sind zwei physisch getrennte Fabrics (Fabric A und Fabric B), die niemals miteinander verbunden sind. Jeder Server, jedes Array und jeder Switch spricht mit beiden Fabrics. Fällt eine komplette Fabric aus — durch einen Switch-Crash, Firmware-Bug oder Kabelbruch — läuft alles über die andere weiter. Das ist der Grund, warum SAN-Projekte mindestens zwei Switches haben.

Ich sehe bei Neukunden regelmäßig SANs, die technisch top sind — und dann steht der einzige FC-Switch auf demselben Stromkreis wie das Array. Fällt eine Sicherung, ist alles weg. SAN-Planung heißt, bis zur Steckdose durchzudenken, nicht nur bis zur Firmware.

Jens HagelGeschäftsführer, hagel IT-Services GmbH

SAN-Protokolle: Fibre Channel, iSCSI, FCoE, NVMe-oF

Die Wahl des Protokolls entscheidet über Performance, Preis und welches Know-how im Team nötig ist. Pure Storage erklärt die Entwicklung hin zu NVMe-oF als eine der größten Veränderungen im Enterprise-Storage der letzten 20 Jahre.

Fibre Channel bleibt die Königsklasse. Wer eine bestehende FC-Infrastruktur hat und sie refresht, bleibt bei FC. Neuinstallationen im Enterprise wechseln meist zu NVMe-over-Fibre-Channel (FC-NVMe), das dieselben Switches nutzt, aber mit dem moderneren Protokoll deutlich höhere IOPS liefert.

iSCSI ist für viele Mittelstandsprojekte das Mittel der Wahl. Mit heutigen 25-GbE-Netzwerken und Offload-fähigen NICs (Intel, Marvell, NVIDIA Mellanox) erreicht iSCSI Performance-Zahlen, die vor zehn Jahren FC vorbehalten waren. Plus: Ihr Netzwerker versteht schon alles — keine FC-Schulung nötig.

NVMe-oF ist die Zukunft. Das ursprünglich für lokale SSDs entwickelte NVMe-Protokoll wurde für Netzwerke erweitert. Ergebnis: deutlich niedrigere Latenz (oft 30–50 % weniger als iSCSI) und massiv höhere Parallelität. Broadcom beschreibt NVMe-over-Fibre-Channel als das präferierte Protokoll für neue Enterprise-Installationen. Für 2026 gilt: Wer ein neues SAN plant, sollte NVMe-oF-fähige Hardware kaufen — auch wenn er erst später umstellt.

Wann ein KMU ein SAN braucht — und wann NICHT

Das ist die wichtigste Entscheidung im ganzen Projekt. Wir sehen bei Neukunden in Hamburg regelmäßig überdimensionierte SANs, die ein Bruchteil an HCI-Hardware erledigt hätte — und umgekehrt Unternehmen, die seit Jahren ein NAS als Datenbank-Storage missbrauchen und sich über Performance wundern.

SAN lohnt sich, wenn mehrere dieser Punkte zutreffen:

• Mehr als 50 virtualisierte Server in VMware, Hyper-V oder KVM — und die sollen live migrieren können (vMotion, Live Migration).
• Große SQL-, Oracle- oder SAP-Datenbanken mit hoher Transaktionslast (10.000+ IOPS dauerhaft).
• Geschäftskritische Anwendungen mit RTO unter 15 Minuten und RPO nahe null (z. B. Produktionssteuerung, Börse, Gesundheitswesen).
• Synchrone Replikation an einen zweiten Standort ist Pflicht — ein Ausfall darf maximal Sekunden kosten.
• Datenbestand jenseits 100 TB, der wachsen muss und nicht in die Cloud darf (Compliance, Datenresidenz).
• Ein IT-Team oder Dienstleister ist da, der SAN-Fabrics aufbauen und managen kann.

SAN lohnt sich NICHT, wenn:

• Sie weniger als 10 virtuelle Server betreiben — ein ordentliches NAS oder ein HCI-Cluster reicht völlig.
• Ihr Haupt-Workload Office-Dateien, Outlook und ein paar SQL-Instanzen sind — NAS + SSD-Cache löst das.
• Sie Latenzen von 2–5 ms verkraften — dann ist iSCSI-NAS oder Cloud-Storage oft ausreichend.
• Sie kein dediziertes IT-Team haben und der externe Dienstleister nicht wöchentlich ins Fabric reinschaut — SANs leben von aktivem Management.
• Ihr Budget unter 50.000 € liegt — dann bekommen Sie kein ernsthaft redundantes SAN, sondern eine halbe Lösung, die im Ernstfall versagt.

Typische SAN-Lösungen im Mittelstand

Der Markt für Mittelstands-SANs hat sich in den letzten fünf Jahren konsolidiert. Fünf Hersteller dominieren das Segment zwischen 20 und 200 TB. Alle bieten Dual-Controller-Systeme, Inline-Deduplikation und ein brauchbares Management-GUI — die Unterschiede liegen im Detail.

Realistische Preise für ein KMU-SAN (Stand 2026):

• Einstieg (20 TB All-Flash, Dual Controller, 2× FC-Switch 32 GFC, 4 HBAs, Lizenzen, Installation): 40.000 – 60.000 €
• Mittelklasse (50 TB All-Flash, iSCSI 25 GbE, synchrone Replikation): 70.000 – 120.000 €
• Enterprise (100 TB+ NVMe, zwei Standorte, Metro-Cluster): 150.000 – 400.000 €

Dazu kommen jährliche Support-Kosten von 15–25 % der Hardware und ein Strom-/Kühlungsbudget, das man nicht unterschätzen sollte. Ein All-Flash-Array zieht deutlich weniger Strom als ein altes Spinning-Disk-SAN — aber rechnen Sie mit 2–4 kW Dauerlast inkl. Kühlung.

Für die Auswahl nutzen wir bei unseren Kunden einen strukturierten Prozess — der IT-Einkaufsführer 2026 bildet das 1:1 ab. Er hilft, die richtigen Fragen zu stellen, bevor der Hersteller oder Reseller Zahlen nennt.

Alternativen 2026: Hyperconverged, Cloud-Storage, Software-Defined Storage

Das klassische SAN-Modell — separate Storage-Hardware, separates Fabric, separates Know-how — wird von drei modernen Ansätzen unter Druck gesetzt. Für die meisten KMU in Hamburg ist eine dieser Alternativen heute die bessere Wahl als ein neues SAN.

Hyperconverged Infrastructure (HCI)

HCI bedeutet: Statt Server + SAN + Fabric kaufen Sie identische Server-Nodes, die jeweils CPU, RAM und SSDs enthalten. Eine Software (Nutanix AOS, VMware vSAN, Microsoft Azure Stack HCI) verteilt die Daten redundant über den ganzen Cluster. Das Ergebnis: kein separates SAN mehr, stattdessen ein skalierbarer Verbund aus 3–16 Servern.

Vorteile:

• Ein Rack, eine Vendor-Linie, ein Support-Ansprechpartner
• Lineare Skalierung — ein Node dazukaufen bringt mehr Compute UND mehr Storage
• Einfacheres Management, weniger Spezial-Skills nötig
• Oft 30–40 % günstiger in der Anschaffung als vergleichbares SAN-Setup

Für wen: KMU mit 3–50 virtuellen Servern, die moderne Virtualisierung brauchen, aber kein eigenes Storage-Team haben. Für viele unserer Kunden in Hamburg ist HCI die erste Wahl bei Infrastruktur-Refresh.

Cloud-Storage (Azure Files, AWS FSx, Azure NetApp Files)

Für einen wachsenden Teil der Workloads muss Storage nicht mehr im eigenen Rechenzentrum stehen. Microsoft Azure Files, Azure NetApp Files und AWS FSx for NetApp ONTAP bieten Enterprise-Storage as a Service mit Performance-Garantien und integrierter Geo-Replikation. Der aktuelle Bitkom Cloud-Report zeigt, dass 80 % der deutschen Unternehmen inzwischen Cloud-Computing nutzen — Storage ist einer der größten Wachstumsbereiche.

Vorteile:

• Kein Kapital gebunden, rein betrieblicher Aufwand (OpEx statt CapEx)
• Geo-Replikation, Snapshots, Immutable Storage alles integriert
• Skalierung in Minuten, nicht Wochen
• Microsoft-365-Integration sofort verfügbar

Vorsicht bei: Sehr hohen IOPS-Anforderungen (Datenbanken), Latenz-sensiblen Anwendungen, Compliance-Vorgaben zur Datenresidenz (Schrems II). Unsere Cloud-Services-Beratung unterstützt Sie dabei, den passenden Mix zu finden.

Software-Defined Storage (SDS)

Ceph (Red Hat, SUSE), StorMagic, Microsoft Storage Spaces Direct und Starwind Virtual SAN verwandeln Commodity-Server mit lokalen Disks in einen verteilten Speicher. Die Intelligenz liegt komplett in der Software.

Vorteile:

• Sehr günstig in der Anschaffung (White-Box-Hardware)
• Hoher Grad an Individualisierung möglich
• Gut für Labs, DevOps-Umgebungen, Research

Nachteile: Braucht sehr gute IT-Skills. Wer Ceph operativ betreiben will, muss Ceph lieben — das ist kein „installieren-und-vergessen”-System. Für die meisten KMU im Mittelstand ist HCI die bessere Variante, weil sie den SDS-Aspekt mit Enterprise-Support verheiratet.

SAN + Backup: Best Practices

Ein SAN ersetzt kein Backup. Ein SAN ist genau eine zentrale Angriffsfläche — wer ins SAN kommt, kommt an alles. Wir haben bei hagel IT Ransomware-Fälle gesehen, in denen das gesamte SAN in 20 Minuten verschlüsselt war, inklusive der Snapshots auf demselben Array.

Konkrete Umsetzung:

1. Snapshots auf dem SAN: Für schnelle Wiederherstellung (Minuten) bei Anwenderfehlern oder versehentlichem Löschen. Mindestens 14 Tage Aufbewahrung, besser 30.
2. Backup auf separate Hardware: Veeam, Commvault, Rubrik oder Cohesity sichern die VMs/LUNs auf ein unabhängiges Backup-System — nicht auf das SAN selbst.
3. Offsite-Kopie: Mindestens eine Kopie muss physisch woanders sein. Typisch: ein zweites Backup-Repository in einem anderen Rechenzentrum oder ein Cloud-Backup (Wasabi, Backblaze, Azure Blob).
4. Immutable / Object-Lock: Mindestens eine Kopie muss unveränderlich sein. Verschlüsselungstrojaner kommen oft ins Backup-System und löschen dort zuerst.
5. Restore-Test: Einmal pro Quartal ein Restore üben — nicht nur auf dem Papier. Unsere Backup & Recovery-Lösungen beinhalten regelmäßige Restore-Tests als festen Vertragsbestandteil.

Häufige Fehler bei SAN-Planung

Die Fehler wiederholen sich in jedem zweiten Projekt. Wer sie kennt, vermeidet sie.

• Ein Switch, eine Stromleitung. Das SAN ist redundant, aber beide Controller hängen am selben USV-Kreis. Ein einziger Sicherungsautomat legt alles lahm.
• Keine dedizierte Management-Schnittstelle. SAN-Management läuft über dasselbe Netz wie die VMs — bei einem DDoS-Angriff auf die Firma ist auch das SAN-Interface weg.
• LUN-Masking vergessen. Alle Server sehen alle LUNs. Ein kompromittierter Server kann auf fremde Datenbanken zugreifen.
• Snapshot als Backup verkauft. Snapshots sind kein Backup. Punkt. Sie leben auf demselben Array.
• Keine Firmware-Strategie. Wer nach drei Jahren immer noch die GA-Firmware fährt, holt sich CVE-Probleme ins Haus. Firmware-Updates gehören ins Managed-IT-Standardprogramm.
• Kein Monitoring der Latenz. SANs werden nicht plötzlich langsam — sie werden langsam schleichend. Ohne IOPS- und Latenz-Monitoring merkt niemand etwas, bis die Datenbank crasht.
• Dokumentation nur im Kopf des Admins. Wenn der Senior-Admin krank wird, findet niemand das WWN-Zoning. Das verlängert jede Störung um Stunden.

In unserem Artikel Was ist eine Virtual Machine (VM)? erklären wir, wie VMs und SAN zusammenspielen — diese Zusammenhänge müssen beim SAN-Design von Anfang an mitgedacht werden.

Checkliste: Brauche ich ein SAN?

Beantworten Sie die folgenden Fragen mit Ja oder Nein. Ab 5 Ja-Antworten kommt ein SAN ernsthaft in Frage — unter 5 sollten Sie HCI, NAS oder Cloud in Betracht ziehen.

• Mehr als 20 virtuelle Server im Einsatz oder in Planung?
• SQL-Datenbank mit 50 GB+ und mehr als 50 gleichzeitigen Nutzern?
• RTO unter 1 Stunde für geschäftskritische Anwendungen gefordert?
• Datenbestand wächst jährlich um 20 %+ und soll mindestens 5 Jahre tragen?
• Synchrone oder asynchrone Replikation an einen zweiten Standort ist Pflicht?
• VMware vSphere, Hyper-V-Cluster oder Proxmox mit Live-Migration produktiv im Einsatz?
• Internes IT-Team oder externer Dienstleister mit SAN-Erfahrung verfügbar?
• Budget größer 50.000 € für Storage in den nächsten 12 Monaten?
• Compliance-Vorgaben erfordern Vor-Ort-Datenhaltung (Gesundheitswesen, Rüstung, kritische Infrastrukturen)?

0–3 Ja: Klassisches NAS oder Cloud-Storage. Sie brauchen kein SAN. 4–6 Ja: Hyperconverged Infrastructure (HCI) ist wahrscheinlich die beste Wahl. Prüfen Sie auch Hybrid-Cloud-Szenarien. 7–9 Ja: Ein SAN kommt ernsthaft in Frage. Holen Sie 2–3 Angebote ein — und lassen Sie das Design unabhängig prüfen.

Wir bieten für Hamburger Unternehmen ein kostenloses 15-Minuten-Erstgespräch an, in dem wir Ihre Situation einordnen. In den meisten Fällen zeigt sich nach 10 Minuten, welche Storage-Architektur zu Ihrem Unternehmen passt — ohne dass Sie einen Hersteller-Termin brauchen.

Was Sie heute tun können

Drei konkrete Schritte, die kein Budget erfordern, aber bessere Entscheidungen ermöglichen:

1. Datenbestand und IOPS messen. Kostenlose Tools wie Microsoft PerfMon, vSphere-Performance-Counter oder iostat (Linux) zeigen in 5 Minuten, ob Sie wirklich ein Performance-Problem haben — oder nur ein Kapazitätsproblem.
2. Backup-Konzept auf 3-2-1-1-0 prüfen. Unabhängig von Ihrer Storage-Entscheidung: Wenn dieses Konzept nicht steht, ist jede weitere Investition umsonst. Unsere Cybersicherheits-Checkliste enthält einen Backup-Schnelltest.
3. Zwei unabhängige Angebote einholen. Ihr bestehender IT-Partner wird eine bestimmte Richtung vorschlagen. Holen Sie ein Zweitangebot — und lassen Sie das Design unabhängig durch einen dritten prüfen. Bei Storage-Projekten jenseits 30.000 € ist das branchenübliche Praxis.

Fazit

Ein Storage Area Network ist ein mächtiges Werkzeug — aber kein Allheilmittel. Für Konzerne mit tausenden VMs, SAP-HANA-Landscapes und 24/7-Produktionsanforderungen bleibt SAN die richtige Antwort. Für den typischen Mittelstand zwischen 20 und 200 Mitarbeitern sind Hyperconverged Infrastructure, modernes NAS oder Cloud-Storage in neun von zehn Fällen die bessere Wahl: schneller bereitgestellt, einfacher zu betreiben, günstiger.

Wenn doch ein SAN, dann richtig: Dual Controller, zwei getrennte Fabrics, redundante HBAs pro Server, Multipath-Software, sauberes Zoning und LUN-Masking — und ein Backup, das nicht auf demselben Array liegt. Alles andere ist ein sehr teurer Single Point of Failure.