Das ist ein klassisches Missverständnis – die Hersteller lügen nicht, verwenden aber eine andere Einheit:

Dezimal vs. Binär:

Dezimal (Hersteller)	Binär (Betriebssystem)
1 KB = 1.000 Bytes	1 KiB = 1.024 Bytes
1 MB = 1.000.000 Bytes	1 MiB = 1.048.576 Bytes
1 GB = 10⁹ Bytes	1 GiB = 2³⁰ Bytes
1 TB = 10¹² Bytes	1 TiB = 2⁴⁰ Bytes

Die Differenz:

• 1 TB dezimal = 1.000.000.000.000 Bytes
• 1 TiB binär = 1.099.511.627.776 Bytes
• Verhältnis: 10¹² ÷ 2⁴⁰ = 0,9095
• Ergebnis: Eine "1 TB"-Festplatte zeigt in Windows nur 931 GiB

Die kuriose Geschichte:

Ursprünglich wurden Kilobyte, Megabyte etc. informell für beide Systeme verwendet. 1998 führte die IEC (International Electrotechnical Commission) die binären Präfixe KiB, MiB, GiB ein. Apple verwendet sie konsequent, Windows und viele Linux-Distributionen nutzen weiterhin "KB, MB, GB" – aber mit binärer Bedeutung.

Faustregel: Herstellerangaben sind immer dezimal – 10% kleiner als im Betriebssystem angezeigt.

Die Wahl hängt von den Prioritäten ab: Performance, Redundanz, Kapazität oder Kosten:

RAID	Min. Disks	Nutzbar	Ausfälle	Empfohlen für
0	2	100%	0	Nur Temp-Daten
1	2	50%	1	OS, kleine DBs
5	3	(n-1)/n	1	Fileserver
6	4	(n-2)/n	2	Backup, Archive
10	4	50%	1 pro Mirror	Datenbanken
50	6	(n-2)/n	1 pro Gruppe	Große Datenmengen
60	8	(n-4)/n	2 pro Gruppe	Hohe Redundanz

Empfehlungen:

• RAID 0: NUR für temporäre, reproduzierbare Daten (z.B. Render-Farm)
• RAID 1: Boot-Laufwerk, kleine Datenbanken, VM-Speicher
• RAID 5: Fileserver mit Read-heavy-Workloads, aber Vorsicht bei großen Disks
• RAID 6: Backup-Storage, Archive, wenn Rebuild-Zeiten kritisch sind
• RAID 10: Datenbanken, Virtualisierung, alles mit viel Write-I/O

RAID 5 – gefährlich bei großen Disks:

Bei Disks > 4 TB dauert der Rebuild oft 24-72 Stunden. Während dieser Zeit ist keine Redundanz vorhanden. Fällt eine zweite Platte aus, sind alle Daten verloren. Deshalb: Für große Disks RAID 6 oder RAID 10 bevorzugen.

Die Begriffe werden oft verwechselt, haben aber unterschiedliche Zwecke:

Aspekt	Backup	Archiv
Zweck	Wiederherstellung	Aufbewahrung
Zeitraum	Tage bis Wochen	Jahre bis Jahrzehnte
Zugriff	Häufig, schnell	Selten, langsam OK
Speichermedium	Disk, Cloud	Tape, Cloud-Archive
Kosten	Höher pro GB	Niedriger pro GB
Änderung	Regelmäßig überschrieben	Unveränderlich (WORM)

Backup:

• Ziel: Nach Datenverlust schnell wiederherstellen
• Rotation: Ältere Backups werden durch neuere ersetzt
• Zugriff: Muss in Minuten bis Stunden möglich sein
• Beispiel: Tägliches Backup der Produktionsdatenbank

Archiv:

• Ziel: Langfristige Aufbewahrung (z.B. für Compliance)
• Unveränderlich: Daten dürfen nicht mehr geändert werden
• Zugriff: Stunden bis Tage OK, dafür günstiger
• Beispiel: Rechnungen 10 Jahre aufbewahren (gesetzlich)

Compliance-Anforderungen:

• DSGVO: Unterschiedlich je nach Datenart
• HGB: Handelsbücher 10 Jahre
• AO: Steuerrelevante Unterlagen 10 Jahre
• Medizin: Teilweise 30 Jahre

Best Practice: Backup UND Archiv – sie sind komplementär, nicht ersetzend.

Thin Provisioning (Dünnbesetzung) ist eine Storage-Technik, bei der Speicher nur bei tatsächlicher Nutzung zugewiesen wird:

Das Problem mit traditionellem Storage:

• Thick Provisioning: Bei Erstellung wird der komplette Speicher reserviert
• Beispiel: 10 VMs mit je 1 TB = 10 TB reserviert
• Verschwendung: VMs nutzen oft nur 20-30% ihrer Kapazität
• Ergebnis: 7 TB liegen brach, können nicht genutzt werden

Die Thin-Provisioning-Lösung:

• Zuweisung: Nur tatsächlich genutzter Speicher wird verbraucht
• Beispiel: 10 VMs mit je 1 TB = 2-3 TB tatsächlich belegt
• Überprovisionierung: Man kann mehr zuweisen als physisch vorhanden
• Nutzung: 70-80% Einsparung typisch

Vorteile:

• Kosteneinsparung: Weniger Hardware nötig
• Flexibilität: Mehr VMs auf gleicher Hardware
• Snapshots: Effizienter durch Copy-on-Write

Nachteile & Risiken:

• Überprovisionierung: Wenn alle VMs plötzlich wachsen → Storage voll!
• Performance: Initial etwas langsamer durch Metadaten
• Monitoring: Genaueres Monitoring nötig
• Komplexität: Nicht alle Backup-Tools unterstützen es

Best Practice: Überwachung auf 80% Nutzung, Reserve für Wachstum, klare Alarmierung. Nicht über 200% überprovisionieren.

Die Lebensdauer von SSDs wird oft falsch eingeschätzt – meistens sind sie langlebiger als HDDs:

Die drei Faktoren:

• TBW: Total Bytes Written – Schreibmenge bis Garantie-Ende
• Alter: Elektronik und Controller können altern
• Nutzung: Temperatur, Schreibmuster, Workload

Typische TBW-Werte:

SSD-Typ	TBW pro 1 TB	Jahre bei 50 GB/Tag
Consumer (QLC)	~200-400 TB	11-22 Jahre
Consumer (TLC)	~600 TB	~33 Jahre
Prosumer (TLC)	~1.200 TB	~65 Jahre
Enterprise (MLC)	~10.000 TB	~550 Jahre
Enterprise (SLC)	~30.000 TB	~1.600 Jahre

Realität vs. Theorie:

• Studien zeigen: Die meisten SSDs halten länger als TBW
• Ausfälle: Meist durch Controller-Fehler oder Firmware-Bugs
• Garantie: 5 Jahre ODER TBW – was zuerst eintritt
• HDDs: Fallen statistisch häufiger aus als SSDs

Wichtige Kennzahlen für Admins:

• DWPD: Drive Writes Per Day – bei Enterprise-SSDs
• 1 DWPD: Die SSD kann täglich mit ihrer eigenen Kapazität beschrieben werden
• 3 DWPD: Dreifache Kapazität pro Tag – für intensive Workloads
• SMART-Werte: Wear-Leveling, Program/Erase Count, Media Wearout Indicator

Fazit: Consumer-SSDs halten bei normaler Nutzung 10+ Jahre. Enterprise-SSDs in Rechenzentren werden meist ausgetauscht, bevor TBW erreicht ist.

Die drei Storage-Architekturen haben unterschiedliche Anwendungsfälle:

Typ	Protokoll	Zugriff	Kosten
DAS	SATA/SAS	Block	Niedrig
NAS	NFS/SMB	File	Mittel
SAN	iSCSI/FC	Block	Hoch

DAS (Direct Attached Storage):

• Direkt am Server angeschlossen
• Beispiel: Interne Festplatten, externe USB-Laufwerke
• Vorteil: Günstig, einfach, schnell
• Nachteil: Nicht teilbar, begrenzt skalierbar
• Einsatz: Einzelne Server, kleine Umgebungen

NAS (Network Attached Storage):

• Eigenes Gerät im Netzwerk mit eigenem Dateisystem
• Beispiel: Synology, QNAP, TrueNAS
• Protokoll: NFS, SMB/CIFS
• Vorteil: Einfaches Filesharing, Zugriff von überall
• Nachteil: Höhere Latenz als DAS, SMB-Overhead
• Einsatz: Fileserver, Backup-Target, Home-Office

SAN (Storage Area Network):

• Eigenes Storage-Netzwerk, oft mit Fibre Channel
• Beispiel: Dell EMC PowerStore, NetApp, Pure Storage
• Protokoll: iSCSI, Fibre Channel, FCoE, NVMe-oF
• Vorteil: Höchste Performance, HA, Snapshots, Replikation
• Nachteil: Sehr teuer, komplex, Fachwissen nötig
• Einsatz: Enterprise-Datenbanken, Virtualisierung

Entscheidungshilfe:

• Ein Server, viel Speicher: DAS
• Mehrere Server, Filesharing: NAS
• Enterprise-Virtualisierung, Datenbanken: SAN
• Cloud-Alternative: Objekt-Storage (S3-kompatibel)

Die Speicherplanung für Virtualisierung (VMware, Hyper-V, Proxmox) hat besondere Anforderungen:

Die 5 Speicherkategorien:

• VM-Disks: Betriebssystem + Anwendungen der VMs
• VM-Snapshots: Sicherungspunkte (temporär, aber oft groß!)
• VM-Memory: Bei Memory Overcommit oder Suspend
• ISOs/Templates: Installationsmedien und Vorlagen
• Logs/Swap: VM-Logs, Swap-Files, Dumps

Daumenregeln pro VM:

VM-Typ	Disk	RAM	Snapshots
Small (Linux)	20-40 GB	2-4 GB	1-2x Disk
Medium (Windows Server)	60-100 GB	8-16 GB	1-2x Disk
Large (DB-Server)	200-1000 GB	32-128 GB	2-3x Disk
XL (SAP, Exchange)	1-10 TB	128-512 GB	2-3x Disk

Speicher-Overhead einplanen:

• VMFS-Datastore: +10-20% Metadaten
• Snapshots: +20-50% (bei kurzen Aufbewahrungszeiten)
• Replikation: +100% bei aktiver Replikation
• Thin Provisioning: Überwachung auf max. 80% Nutzung
• Reserve: 20-30% für Wachstum

Beispielrechnung: 50 VMs, durchschn. 100 GB Disk, 8 GB RAM

• VM-Disks: 50 × 100 GB = 5 TB
• Snapshots (1,5x): +7,5 TB
• Memory Dumps (1x): +400 GB
• Templates/ISOs: +500 GB
• Subtotal: ~13,4 TB
• Mit Reserve (+30%): ~17,5 TB

Best Practices:

• Separate Datastores: VMs, Snapshots, Logs, ISOs
• Monitoring: Datastore-Nutzung überwachen (85% = Alarm)
• Automatische Snapshot-Löschung: Nicht vergessen!
• Storage I/O Control: Bei Überlast aktivieren

Die Cloud vs. On-Premises Frage ist komplex – hier die wichtigsten Zahlen:

Cloud-Storage-Anbieter (Beispiele):

Anbieter	Preis/GB/Monat	Egress
AWS S3 Standard	~0,023 $	0,09 $/GB
AWS S3 Glacier	~0,004 $	teuer
Azure Blob Hot	~0,018 $	0,087 $/GB
Google Cloud Standard	~0,020 $	0,12 $/GB
Backblaze B2	~0,005 $	0,01 $/GB
Wasabi	~0,006 $	kostenlos

Kosten-Beispiel: 100 TB Storage, 10 TB Egress/Monat

• AWS S3 Standard: 100.000 GB × 0,023 = 2.300 $ + 10.000 GB × 0,09 = 900 $ = 3.200 $/Monat
• Backblaze B2: 100.000 GB × 0,005 = 500 $ + 10.000 GB × 0,01 = 100 $ = 600 $/Monat
• Wasabi: 100.000 GB × 0,006 = 600 $ + 0 $ = 600 $/Monat

On-Premises (Beispiel: 100 TB NAS):

• Hardware: ~15.000 € einmalig (3 Jahre Abschreibung)
• Strom: ~200 W × 24 × 365 = 1.750 kWh × 0,30 € = ~525 €/Jahr
• Wartung/Support: ~1.500 €/Jahr
• Personal: Anteilig, oft übersehen!
• Gesamt: ~500 €/Monat + Personal

Wann Cloud, wann lokal?

• Cloud lohnt: Variabler Bedarf, unregelmäßiger Zugriff, Archivierung, weltweite Verfügbarkeit
• Lokal lohnt: Konstanter Bedarf, hoher Durchsatz, Datenschutz-Anforderungen, niedrige Latenz
• Hybrid: Oft die beste Wahl – heiße Daten lokal, kalte Daten in der Cloud

Vorsicht bei Egress-Kosten: Daten aus der Cloud zu holen ist oft teuer. Allein der Ausstieg kann fünfstellige Beträge kosten. "Vendor Lock-in" ist real!