GiB in TB umrechnen

Ein Gibibyte sind 1.073.741.824 Byte, rund 7 % mehr als ein Gigabyte. Windows misst in Gibibyte, schreibt aber „GB" daran — darin besteht das ganze Rätsel des verschwundenen Speicherplatzes.

Ein Terabyte ist eine Billion Byte. Eine als 1 TB verkaufte Platte hat genau das — der scheinbar fehlende Platz ist eine Meinungsverschiedenheit über Einheiten, kein Mangel.

Der Faktor ist 0,001074, und den trägt praktisch niemand mit sich herum. Auf 0,00107 gerundet liegt er um 0,35 % daneben — bei kleinen Zahlen unsichtbar, bei etwa 1.000 GiB wird daraus eine ganze Einheit.

Genau das ist die Zahl, die man vor dem Runden wissen will: nicht der Fehler selbst, sondern ab wann er aufhört, egal zu sein. Darunter ist der kurze Faktor der vernünftige; darüber nimm das Feld oben, das erst beim Ausgeben rundet.

Ein GiB sind 1.024 der Einheit darunter, ein GB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 0,0011 TB und 0,001 TB — 7,4 % —, und der Abstand wächst mit jeder Stufe. Bei einem Foto ist er ein Rundungsfehler, bei einer Festplatte ein sichtbares Stück.

Darin besteht das Rätsel um den fehlenden Speicherplatz vollständig. Eine Platte, die als GB verkauft wird, enthält exakt das, was draufsteht; Windows teilt anschließend durch 1.024 statt durch 1.000, behält den dezimalen Namen bei und zeigt deshalb eine kleinere Zahl an. macOS rechnet seit Version 10.6 in den dezimalen Einheiten und zeigt die Zahl von der Verpackung — dieselbe Platte, zwei Rechner, zwei Größen, und verloren geht dabei nichts.

Die Zahl am Anfang dieser Umrechnung kommt fast immer aus einer Software. Ein Hypervisor, ein Storage-Dashboard oder der Alert eines Monitoring-Systems meldet Auslastung in Gibibyte, weil Volume-Manager und Dateisysteme in Zweierpotenzen rechnen. Die Zahl am Ende steht in einem Bestellformular, und jeder Anbieter – ob deutsches Systemhaus oder Hyperscaler mit deutschem Rechenzentrum – quotiert dezimal in TB.

Damit ist es eine Grenzumrechnung und kein Kopfrechnen. Genau an dieser Grenze geht die Einheit am ehesten verloren: Die Anforderung wandert vom Admin zur Beschaffung als nackte Zahl, wird dort als dezimal gelesen, weil das Formular dezimal ist, und am Ende wird eine um sieben Prozent zu kleine Kapazität bestellt.

Die meisten Umrechnungen sind in beide Richtungen gleich verzeihend. Diese nicht. Eine Kapazität, die unter dem Bedarf landet, lässt sich nicht per Konfiguration nachbessern – sie braucht eine zweite Bestellung, eine zweite Freigabe und im Zweifel ein neues Wartungsfenster im laufenden Betrieb.

Die Regel lautet deshalb: immer aufrunden, und die Reserve erst danach draufrechnen. 4.000 GiB sind 4,295 TB, eine 4-TB-Platte reicht also nicht ganz. 8.000 GiB sind 8,59 TB, 20.000 GiB sind 21,47 TB – die Anforderung landet fast immer knapp hinter einer Katalogstufe, weil Katalogstufen runde Dezimalzahlen sind und Anforderungen runde Binärzahlen.

Eine kurze Tabelle deckt die meisten Fälle ab: 500 GiB sind 0,537 TB, 1.000 GiB sind 1,074 TB, 1.024 GiB – ein Tebibyte – sind 1,0995 TB, 2.000 GiB sind 2,147 TB, 5.000 GiB sind 5,369 TB, 10.000 GiB sind 10,737 TB. Der Merksatz: 7,4 Prozent aufschlagen, drei Nachkommastellen nach links verschieben.

Die 1.024-Zeile ist die, an der die Intuition kippt. Ein Tebibyte ist eben kein Terabyte, sondern 1,0995 davon – wer eine Anforderung als "ein Terabyte" formuliert, weil das eigene Tool binär anzeigt, braucht eine 1,1-TB-Bestellung, und die gibt es als Produkt nicht.

Die Reihenfolge entscheidet, ob am Ende eine überprüfbare Zahl steht. Zuerst die Nutzkapazität in GiB, weil das die Zahl ist, die tatsächlich gebraucht wird. Dann die Umrechnung in TB. Erst danach der Aufschlag für die Redundanz, der ein Faktor auf die Bestellung ist und keiner auf den Bedarf: Spiegelung verdoppelt, einfache Parität über acht Platten addiert ein Achtel, doppelte Parität ein Viertel.

Andersherum entsteht eine Zahl, die niemand mehr nachvollziehen kann. Wer den Einheitenwechsel erst nach der Paritätsrechnung anwendet, mischt eine 7,37-Prozent-Korrektur in eine 25-Prozent-Korrektur, und wenn das gelieferte Array kleiner ausfällt als erwartet, kann niemand mehr sagen, an welcher Stelle es passiert ist.

Bei deutschen Cloud-Anbietern ist das Problem besonders sichtbar, weil beide Einheiten auf derselben Rechnungsseite auftauchen. Ein Block-Volume wird in Gibibyte angelegt, das Nutzungsdiagramm zeigt Gibibyte, und die Preisliste nennt einen Satz pro Gigabyte-Monat. Jede der drei Angaben ist für sich korrekt, die Kombination ist es nicht intuitiv.

Praktisch schlägt das auf der Rechnung durch, nicht auf der Kapazität: Ein mit 1.000 GiB angelegtes Volume sind 1.074 GB abrechenbarer Speicher, die Rechnung liegt also 7,4 Prozent über einer naiv aus der Bereitstellungszahl geschätzten. Das ist ein kleiner Prozentsatz einer großen, wiederkehrenden Summe – also genau die Sorte Kostenabweichung, die erst ein Quartal später auffällt.

Es ist verlockend, die 7,4 Prozent als Puffer zu behandeln – zum umgerechneten Wert zu bestellen und die Differenz als Reserve zu verbuchen. Sie ist keine Reserve, sondern derselbe Bedarf, nur korrekt geschrieben; wer sie verplant, hat am Ende keinerlei Spielraum mehr. Wachstum, Snapshots, Dateisystem-Reserven und die Performance-Grenze, die Speicher meist vor der letzten Prozent Füllung erreicht, sind eigene Zuschläge und verdienen eigene Zeilen.

Bewährt hat sich eine Kette, die sich später nachvollziehen lässt: Nutzbedarf in GiB, derselbe Wert in TB, der Faktor aus der Redundanz, der Wachstumszuschlag für den Beschaffungszyklus, die gewählte Kataloggröße. Fünf Zeilen, jede für sich begründbar, statt einer Summe, die niemand mehr auseinanderrechnen kann.

Ein redundantes Array nutzt von jeder Platte nur so viel, wie die kleinste im Verbund liefert. Ein Satz aus Platten gleicher Nennkapazität kann daher schon an wenigen Gigabyte Herstellerunterschied Kapazität verlieren – ein alter Effekt, seit Platten in runden Dezimalzahlen verkauft werden, und der Grund, warum Storage-Controller jedes Mitglied vor dem Aufbau des Verbunds auf eine gemeinsame Grenze herunterrechnen.

Für die Beschaffung heißt das: Die Zielzahl darf keine bloße Gesamtsumme sein. Ein Bedarf von 40.000 GiB, umgerechnet in 42,95 TB und mit elf 4-TB-Platten gedeckt, ist eine andere Konfiguration als dieselbe Summe aus sechs 8-TB-Platten – unterschiedliche Rebuild-Zeiten, unterschiedliches Ausfallrisiko, unterschiedliche Nutzkapazität nach Parität. Erst umrechnen, dann die Plattengröße wählen, dann prüfen, ob die Rechnung mit dem gewählten RAID-Level wirklich noch aufgeht.