GB in TiB umrechnen

Ein Gigabyte ist eine Milliarde Byte, im dezimalen Sinn, den Festplattenhersteller, Mobilfunktarife und Videogrößen verwenden.

Ein Tebibyte sind 1.024 Gibibyte. Der Abstand zum Terabyte wächst mit jeder Stufe: 2,4 % bei Kilo, 4,9 % bei Mega, 7,4 % bei Giga, 10 % bei Tera.

Der Faktor ist 0,000909, und den trägt praktisch niemand mit sich herum. Auf 0,00091 gerundet liegt er um 0,06 % daneben — bei kleinen Zahlen unsichtbar, bei etwa 10.000 GB 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 TiB sind 1.024 der Einheit darunter, ein TB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1099,5116 GB und 1000 GB — 10 % —, 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 TB 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.

Kubernetes verlangt bei einer Speicheranfrage explizit zwischen dem Suffix „G" (dezimales Gigabyte, 1.000.000.000 Byte) und „Gi" (Gibibyte, 1.073.741.824 Byte) zu unterscheiden, und in der Praxis eines deutschen Systemhauses, das Cluster für Kunden betreibt, wird in YAML-Manifesten fast ausschließlich das binäre „Gi" verwendet — es ist die von der Kubernetes-Dokumentation empfohlene Form. Das zugrundeliegende Storage-Array, etwa ein NetApp- oder Pure-Storage-System, weist seine Kapazität dagegen häufig dezimal in Terabyte aus, wie es auf dem Datenblatt des Herstellers steht.

Eine Anfrage über 500 „Gi" entspricht damit 536,87 dezimalen Gigabyte, nicht 500 — ein Unterschied von 7,4 Prozent, der sich bei der Kapazitätsplanung eines ganzen Clusters mit Dutzenden solcher Anfragen zu einer Größenordnung summiert, die auf keinem Datenblatt so vorgesehen war. Wer eine Kubernetes-Kapazitätsplanung gegen ein dezimal spezifiziertes Array abgleicht, muss deshalb konsequent in Bytes rechnen und erst am Ende in die jeweils passende Einheit zurückübersetzen.

Ein Cluster-Pool, der als 10 TiB dimensioniert wurde, nimmt in der Praxis mehr als 10.000 dezimale Gigabyte an Volumenanfragen auf — genauer 10.995 GB —, was in vielen Kapazitätsplanungstabellen deutscher IT-Abteilungen nicht ausgewiesen ist, weil dort die beiden Einheiten stillschweigend gleichgesetzt werden. Wer vierzig Volumenanfragen zu je 250 GB plant, kommt auf 10.000 GB, was 9,09 TiB entspricht — knapp unter dem zehn TiB großen Pool, aber mit weniger Puffer, als die runde Zahl auf den ersten Blick vermuten lässt.

Die Umkehrung ist der praktischere Merkwert für die tägliche Arbeit: Ein Gibibyte fasst 1.073,74 dezimale Megabyte, ein Tebibyte 1.099,51 dezimale Gigabyte. Wer diese beiden Zahlen im Kopf hat, kann eine Kapazitätsmeldung aus dem Monitoring-System — meist binär in TiB oder GiB — sofort gegen eine Bestellmenge auf einem Hardware-Angebot prüfen, das fast immer dezimal in TB oder GB kalkuliert ist.

Deutsche Behörden und Betreiber kritischer Infrastrukturen, die nach dem IT-Grundschutz-Kompendium des Bundesamts für Sicherheit in der Informationstechnik dokumentieren müssen, führen in ihren Kapazitätsnachweisen häufig sowohl die vom Hersteller angegebene Rohkapazität in dezimalen Terabyte als auch die vom Betriebssystem gemeldete, binär gezählte nutzbare Kapazität in Tebibyte — und ein Prüfer, der die beiden Zahlen nicht auseinanderhält, hält die Differenz schnell für einen ungeklärten Kapazitätsschwund statt für eine bloße Einheitenfrage.

Eine saubere Dokumentation weist deshalb beide Zahlen mit ihrer jeweiligen Einheit getrennt aus, statt eine einzelne „Kapazität"-Zeile zu führen, die stillschweigend zwischen den Systemen wechselt: die Herstellerangabe in TB als Ausgangspunkt, die betriebssystemseitige Meldung in TiB als tatsächlichen Nachweis, und die rund zehn Prozent Differenz zwischen beiden als eigene, benannte Zeile.

Der verbreitetste Rechenfehler beim Umrechnen von Gigabyte in Tebibyte ist die Division durch 1.024 statt durch 1.099,51 — eine Verwechslung mit dem Gigabyte-zu-Gibibyte-Schritt, der bei dieser Umrechnung nicht ausreicht, weil zwei Präfixstufen gleichzeitig übersprungen werden. Wer 1.000 GB durch 1.024 statt durch 1.099,51 teilt, erhält 0,977 statt der korrekten 0,909 TiB — ein Pool, der damit rechnerisch um 7,4 Prozent größer wirkt, als er tatsächlich ist.

Die zuverlässige Kontrollrechnung führt über Bytes: 1.000 GB sind exakt 1.000.000.000.000 Byte, geteilt durch 1.099.511.627.776 Byte je Tebibyte ergibt 0,9095 TiB. Wer diesen Umweg über die reine Bytezahl einmal nachvollzogen hat, erkennt den Divisionsfehler auf Anhieb, sobald er in einer fremden Kapazitätsplanung wieder auftaucht.

Ein deutsches Systemhaus, das eine Backup-Lösung für einen Kubernetes-Kunden dimensioniert, vereint in einer einzigen Rechnung fast zwangsläufig alle Fallstricke dieser Seite: Die geschützten Datenmengen kommen als „Gi"-Angaben aus den PersistentVolumeClaims, das Ziel-Repository ist in TB beim Cloud-Anbieter eingekauft, und die Deduplizierungsrate wird vom Softwarehersteller als Prozentsatz auf eine ungenannte Basiseinheit angegeben. Jede dieser drei Zahlen für sich ist plausibel, und trotzdem passt die Summe am Ende selten zusammen, wenn nicht vorher alles auf eine gemeinsame Bytezahl gebracht wurde.

Die Reihenfolge, die sich in der Praxis bewährt, ist deshalb immer dieselbe: zuerst alle Werte in Bytes umrechnen, dort die Retentionslogik und die Deduplizierung anwenden, und erst am Ende in die Einheit übersetzen, die auf der Rechnung des Cloud-Anbieters steht. Jeder Zwischenschritt in Gi oder TB spart zwar eine Umrechnung, kostet aber die Möglichkeit, das Ergebnis am Ende noch nachzuvollziehen.

Die offizielle Kubernetes-Dokumentation empfiehlt ausdrücklich, Speicheranfragen mit den binären Suffixen „Ki", „Mi" und „Gi" statt mit den dezimalen „K", „M" und „G" zu stellen, gerade weil viele zugrundeliegende Systeme intern ohnehin in Zweierpotenzen rechnen und eine dezimale Anfrage sonst krumm aufgerundet werden müsste. Für ein deutsches Systemhaus bedeutet das, dass die binäre Schreibweise im Cluster selbst die richtige Wahl ist — der Fehler entsteht nicht durch die Wahl von „Gi", sondern dadurch, dass diese Zahl später ungeprüft mit einer dezimalen Herstellerangabe verglichen wird.

Wer diese Empfehlung kennt, behandelt eine Diskrepanz zwischen Kubernetes-Anfrage und Hardware-Datenblatt nicht als Fehler in der Konfiguration, sondern als das, was sie tatsächlich ist: zwei unterschiedliche, aber jeweils für sich korrekte Konventionen, die erst durch eine bewusste Umrechnung zusammenpassen.