Ein Kunde von mir wollte vor zwei Jahren sein gesamtes Archiv in die Cloud verschieben. Er hatte kalkuliert, dass seine Datenmenge exakt in den kleinsten Speicherplan passt. Er dachte, er wüsste Bescheid, doch am Ende des Monats kam die Rechnung und er zahlte das Dreifache des geplanten Preises. Sein Fehler war nicht mangelndes Budget, sondern ein Rechenfehler, den fast jeder macht, der glaubt, die Frage 1 Gb Ist Wieviel Mb sei mit einer einzigen Zahl aus dem Schulbuch beantwortet. Er rechnete mit glatten Tausendern, während sein Cloud-Anbieter mit Zweierpotenzen arbeitete. Dieser kleine Unterschied in der Definition von Gigabyte und Gibibyte sorgte dafür, dass seine automatische Skalierung ansprang und teure Zusatzpakete buchte, die er nie eingeplant hatte. In meiner Praxis sehe ich das ständig: Architekten, die Terabyte-Speicher für Datenbanken bestellen und sich wundern, warum das Betriebssystem plötzlich 7 % weniger Platz anzeigt als gekauft.
Die Falle der Zehnerpotenz bei 1 Gb Ist Wieviel Mb
Der erste große Patzer passiert bei der Unterscheidung zwischen dem, was Marketingabteilungen verkaufen, und dem, was Informatiker im Keller tatsächlich programmieren. Wenn Sie eine Festplatte im Laden kaufen, steht darauf oft eine Kapazität in Gigabyte (GB). Die Hersteller nutzen hier das Dezimalsystem. Für sie sind 1.000 Megabyte (MB) ein Gigabyte. Das sieht auf der Verpackung nach mehr aus und lässt sich leichter vermarkten. Sobald Sie dieses Laufwerk aber in Ihren Rechner stecken, rechnet Windows oder Ihr Server-Betriebssystem meistens im Binärsystem.
Hier fängt das Problem an. Im binären System wird mit der Basis 2 gerechnet. Ein Gigabyte, oder korrekterweise ein Gibibyte (GiB), besteht aus 1.024 Mebibyte (MiB). Das klingt nach einer vernachlässigbaren Differenz von 24 Einheiten. Doch wenn man das auf Skaleneffekte hochrechnet, bricht das Kartenhaus zusammen. Wer bei der Planung denkt, 1 Gb Ist Wieviel Mb lässt sich pauschal mit 1.000 beantworten, verliert bei einem Terabyte bereits rund 70 Gigabyte an Kapazität durch reine Umrechnungsfehler. Ich habe Admins gesehen, die kurz vor einer Migration Panik bekamen, weil ihr Zielmedium plötzlich "zu klein" war, obwohl die Zahlen auf dem Papier identisch aussahen.
Das Chaos der Bezeichnungen im Alltag
Die International Electrotechnical Commission (IEC) hat eigentlich schon vor langer Zeit versucht, dieses Chaos zu ordnen. Sie führten Begriffe wie Kibibyte, Mebibyte und Gibibyte ein. In der realen Arbeitswelt nutzt das kaum jemand im täglichen Gespräch. Wir sagen Gigabyte und meinen manchmal das eine, manchmal das andere. Das führt dazu, dass Softwareentwickler APIs schreiben, die Datenmengen in Bytes erwarten, während das Frontend die Werte für den Nutzer in "GB" aufrundet. Wenn die Rundungslogik nicht mit der Speicherlogik des Backends übereinstimmt, kommt es zu Pufferüberläufen oder abgebrochenen Uploads. Man muss sich vorher festlegen: Rechnen wir für Menschen oder für Maschinen?
Warum Provider beim Datentransfer schummeln
Ein weiterer Fehler, der richtig teuer wird, betrifft den Datentransfer. Cloud-Anbieter wie AWS, Azure oder Google Cloud berechnen Egress-Gebühren — also Kosten für Daten, die das Rechenzentrum verlassen. Hier wird oft mit harten Bandagen gekämpft. In den Preislisten steht ein Betrag pro Gigabyte. Wer hier nicht genau hinschaut, ob der Provider 1.000 MB oder 1.024 MB als Basis ansetzt, erlebt beim Monitoring eine böse Überraschung.
In meiner Zeit als Berater habe ich ein Unternehmen betreut, das Video-Streaming-Inhalte auslieferte. Sie hatten ihren Traffic auf Basis der Binärrechnung kalkuliert. Der Provider rechnete jedoch dezimal ab. Das bedeutet, der Provider sah "mehr" Gigabytes in den Logs als die interne Analyse der Firma. Am Ende des Quartals klaffte eine Lücke von mehreren tausend Euro in der Bilanz. Es ist völlig egal, was man im Studium gelernt hat; entscheidend ist allein die Definition in den Allgemeinen Geschäftsbedingungen des Dienstleisters. Wer dort nicht nachliest, wie die Messung erfolgt, unterschreibt einen Blankoscheck.
Der Fehler bei der Partitionierung von virtuellen Maschinen
Wenn man virtuelle Instanzen aufsetzt, vergeben viele Nutzer den Speicherplatz nach Gefühl. Sie denken sich: "Ich brauche 100 GB für das System." Dann partitionieren sie die virtuelle Disk exakt auf diesen Wert. Das Problem ist, dass das Dateisystem selbst Platz benötigt — für Inodes, Journaling und Metadaten. Wenn man dann noch die falsche Umrechnung im Kopf hat, bleibt am Ende nicht genug Platz für die eigentliche Anwendung.
Ein realistisches Szenario: Ein Entwickler möchte eine Datenbank mit 50 GB Daten migrieren. Er bucht einen Server mit genau 50 GB Speicherplatz. Er geht davon aus, dass 1 Gb Ist Wieviel Mb die Frage ist, die er mit 1.024 beantworten kann, und dass das reicht. Beim Import der SQL-Datei bricht der Prozess bei 92 % ab. Warum? Weil das Dateisystem (zum Beispiel ext4 unter Linux) standardmäßig 5 % des Platzes für den Root-Nutzer reserviert und die Dateisystem-Strukturen selbst mehrere hundert Megabyte fressen. Er hätte mindestens 60 GB buchen müssen, um sicher zu sein. Er verlor einen ganzen Arbeitstag mit dem Resizing der Partitionen, nur weil er die Netto-Kapazität mit der Brutto-Kapazität verwechselt hatte.
RAM-Management und die versteckten Kosten der Virtualisierung
Beim Arbeitsspeicher (RAM) ist die Welt scheinbar einfacher, da RAM fast immer in Zweierpotenzen adressiert wird. 1 GB RAM sind in der Welt der Hardware-Riegel immer 1.024 MB. Doch hier lauert die Falle in der Virtualisierungsschicht. Hypervisor wie VMware oder KVM benötigen selbst Ressourcen, um die virtuelle Maschine zu verwalten.
Ich habe erlebt, wie eine Agentur versuchte, 16 virtuelle Maschinen mit jeweils 1 GB RAM auf einem Host mit exakt 16 GB physischem RAM zu betreiben. Das Ergebnis war ein kompletter Systemabsturz. Der Host hatte keinen Platz mehr für seinen eigenen Kernel und die Verwaltung der Speicherseiten. In der Praxis muss man immer einen Puffer von mindestens 10 % bis 15 % einplanen. Wer Hardware am Limit kauft, weil er die Zahlen im Prospekt eins zu eins übernimmt, provoziert Instabilitäten. Es gibt keinen "perfekt gefüllten" Server. Es gibt nur Server, die laufen, und solche, die wegen Speichermangel swappen und damit die Performance in den Keller ziehen.
Vorher und Nachher: Eine Migration im direkten Vergleich
Schauen wir uns an, wie dieser Fehler in der Praxis abläuft. Ein mittelständischer Betrieb wollte seine On-Premise-Server in die Cloud schieben.
Der falsche Ansatz (Vorher): Der IT-Leiter schaute in seine Windows-Statistiken. Dort stand, dass seine Daten 800 GB groß sind. Er kaufte einen Cloud-Speicher-Slot von exakt 800 GB, da er dachte, Gigabyte sei Gigabyte. Er ignorierte, dass Windows GiB anzeigte, der Cloud-Anbieter aber in GB (Dezimal) verkaufte. Während des Kopiervorgangs meldete das Tool nach 745 GB "Speicher voll". Der IT-Leiter musste den Vorgang stoppen, das Abo hochstufen — was bei diesem Anbieter eine Mindestlaufzeit für das größere Paket nach sich zog — und den Upload von vorne starten. Die Ausfallzeit verlängerte sich um sechs Stunden, und die Kosten für den Speicher stiegen um 40 %, da er in den nächsthöheren Tarif gezwungen wurde, der weit über seinem Bedarf lag.
Der richtige Ansatz (Nachher):
Ein erfahrener Techniker hätte die 800 GB (laut Anzeige) sofort als binären Wert erkannt. Er hätte gewusst, dass das dezimal etwa 859 GB entspricht. Er hätte zusätzlich 10 % Puffer für das Dateisystem und 5 % für zukünftiges Wachstum eingerechnet. Er hätte also von vornherein 1 TB (1.000 GB dezimal) gebucht. Das klingt erst mal teurer, aber durch die Vermeidung von Fehlern, Redundanzen beim Upload und den Verzicht auf teure Notfall-Upgrades spart er dem Unternehmen am Ende Geld und Nerven. Er nutzt ein Tool wie rsync oder spezialisierte Cloud-Kopierer, die im Vorfeld eine exakte Byte-Prüfung machen, anstatt sich auf die Anzeige im Explorer zu verlassen.
Netzwerk-Durchsatz und die Verwechslung von Bits und Bytes
Das ist der Klassiker unter den Fehlern. Jemand sieht ein Angebot für eine Leitung mit "1 Gbit/s" und denkt, er kann eine Datei von 1 GB in einer Sekunde übertragen. Das ist der Moment, in dem ich meistens schmerzhaft schmunzeln muss. Ein Byte besteht aus acht Bit. Wer das vergisst, verrechnet sich um den Faktor acht. Aber es kommt noch schlimmer.
In der Netzwerktechnik gibt es den sogenannten Overhead. Protokolle wie TCP/IP packen zusätzliche Informationen um jedes Datenpaket. Wenn Sie also eine Leitung mit 1.000 Mbit/s haben, werden Sie in der Realität niemals 125 MB pro Sekunde übertragen. Rechnen Sie eher mit 110 MB/s, wenn es gut läuft. Wenn Sie ein Backup-Fenster von vier Stunden haben und Ihre Datenmenge strikt durch die theoretische Bandbreite teilen, wird Ihr Backup garantiert in den Arbeitsalltag hineinlaufen und das Netzwerk für alle anderen lahmlegen. In meiner Laufbahn habe ich Backup-Pläne scheitern sehen, weil jemand "Gigabit" und "Gigabyte" in einer Excel-Tabelle synonym verwendet hat. Das Ergebnis war eine Firma, die drei Tage lang nicht arbeiten konnte, weil die Datenrückspielung achtmal länger dauerte als vom Praktikanten berechnet.
Lokaler Cache und die unterschätzte Gefahr für SSDs
Heutige Anwendungen, besonders in der Webentwicklung oder beim Videoschnitt, lagern massiv Daten in temporäre Verzeichnisse aus. Wer eine Workstation plant und den Speicherplatz knapp bemisst, zerstört langfristig seine Hardware. SSDs (Solid State Drives) haben eine begrenzte Anzahl an Schreibzyklen. Wenn eine SSD fast voll ist, muss der Controller der Platte ständig Daten hin- und herschieben, um Platz für neue Schreibvorgänge zu finden (Wear Leveling).
Wenn Sie eine 500-GB-SSD haben und diese ständig bis auf 490 GB füllen, wird die Platte innerhalb kürzester Zeit extrem langsam und stirbt früher. Ich habe in einem Designstudio erlebt, wie reihenweise teure NVMe-Platten nach nur 12 Monaten den Geist aufgaben. Der Grund: Die Mitarbeiter arbeiteten mit riesigen Files und ließen der Platte keinen Raum zum "Atmen". Hier gilt die Faustregel: Lassen Sie immer 20 % einer SSD ungenutzt. Wer hier spart und die Frage, wie viel Platz er wirklich braucht, zu optimistisch beantwortet, zahlt später für den Datenrettungsdienst.
Tools zur Wahrheit
Verlassen Sie sich nie auf die Standardanzeige Ihres Betriebssystems, wenn es um kritische Infrastruktur geht. Nutzen Sie Tools, die Ihnen die Größe in Bytes anzeigen. Bytes lügen nicht.
- Unter Linux:
df -hzeigt menschlich lesbare Werte, aberdf -B1zeigt die exakten Bytes. - In der Cloud: Prüfen Sie die Metriken in den Dashboards der Anbieter, nicht die Logs Ihrer Anwendung.
- Bei Datenbanken: Schauen Sie auf die Größe der Datendateien auf der Festplatte, nicht nur auf die Summe der Datensätze im SQL-Dump. Ein Index kann die benötigte Menge schnell verdoppeln.
Realitätscheck
Erfolgreiches Arbeiten mit IT-Infrastruktur hat wenig mit mathematischer Perfektion aus dem Lehrbuch zu tun. Es geht um Pragmatismus. Wenn Sie wissen wollen, wie viel Kapazität Sie wirklich brauchen, dann nehmen Sie Ihren berechneten Wert und addieren Sie pauschal 25 %. Das deckt die Differenz zwischen Binär- und Dezimalsystem ab, lässt Raum für den Overhead des Dateisystems und gibt der Hardware genug Puffer für eine ordentliche Performance.
In der Theorie ist alles sauber getrennt, aber in der Praxis mischen Betriebssysteme, Hardwarehersteller und Cloud-Anbieter die Einheiten, wie es ihnen gerade passt. Wer versucht, auf das Megabyte genau zu planen, wird scheitern. Es gibt keine Abkürzung: Sie müssen die AGB Ihrer Dienstleister lesen und verstehen, nach welchem Standard diese abrechnen. Die harte Wahrheit ist: Speicher ist billig, aber die Arbeitszeit, die Sie verlieren, wenn der Speicher mitten in der Nacht vollläuft, ist unbezahlbar. Planen Sie großzügig oder planen Sie zu scheitern. So einfach ist das in diesem Bereich. Wer das nicht akzeptiert, wird weiterhin Lehrgeld in Form von Nachzahlungen und Systemabstürzen zahlen. Alles andere ist Wunschdenken von Leuten, die noch nie eine Migration unter Zeitdruck durchgeführt haben.
