kB in TiB umrechnen

Ein Kilobyte sind 1.000 Byte, wenn ein Normungsgremium es definiert, und 1.024, wenn ein Betriebssystem es tut. Diese Seite rechnet mit 1.000; die Einheit für 1.024 heißt Kibibyte.

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.

In dieser Richtung wird geteilt, und zwar durch eine ganze Zahl: 1.099.511.628 davon passen restlos in ein Tebibyte. Unangenehm ist daran nur, dass die Ergebnisse als Brüche herauskommen — ein Drittel, ein Zwölftel — statt als die runden Zahlen, die die Gegenrichtung liefert.

Verloren geht dabei trotzdem nichts, denn die Division ist exakt. Wenn dein Ergebnis als Dezimalzahl nicht stillhalten will — 0,0833… und Verwandte —, dann ist das der Bruch, der durchscheint, und kein Fehler, der sich einschleicht.

Ein TiB sind 1.024 der Einheit darunter, ein TB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1099511627,776 kB und 1000000000 kB — 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.

Der BSI-IT-Grundschutz verlangt in mehreren Bausteinen eine Protokollierung sicherheitsrelevanter Ereignisse über einen definierten Zeitraum, oft sechs bis zwölf Monate. Bei einer mittelgroßen Behörde oder einem Konzern fallen dabei leicht hundert Millionen Log-Zeilen am Tag an, jede etwa 1 kB groß — macht 100 GB täglich, was ein Speichersystem als 93,1 GiB meldet. Über neunzig Tage sind das dieselben Bytes, einmal als 9 TB in der Planung, einmal als 8,19 TiB auf der Anzeige des Speichersystems — keine fehlende Datenmenge, sondern derselbe Wert in zwei verschiedenen Einheiten mit fast zehn Prozent Abstand in der Zahl.

Zum Problem wird das erst beim Einkauf: Wer aus der Planungszahl „9" eine Bestellung mit derselben Ziffer, aber der jeweils anderen Einheit macht, kauft zu wenig. Wer die Differenz von rund neun Prozent von Anfang an einrechnet, verhindert, dass genau in dem Moment Speicherplatz fehlt, in dem die Protokolle aus Compliance-Gründen am dringendsten gebraucht werden.

Bevor die neun Prozent zwischen Terabyte und Tebibyte überhaupt relevant werden, entscheidet die Kompression über den Faktor: Strukturierte Log- und Metrikdaten lassen sich meist auf ein Fünftel bis ein Zehntel ihrer Rohgröße komprimieren. Wer diesen Faktor ignoriert, überschätzt den Bedarf um ein Vielfaches — ein Fehler, der jede Einheiten-Diskussion in den Schatten stellt.

Danach kommt die Redundanz: Ein Cluster, das jede Zeile dreifach vorhält, verdreifacht die Speichermenge; ein System mit Erasure Coding legt üblicherweise das 1,2- bis 1,5-Fache drauf. Beide Faktoren werden nach der Kompression und vor der Einheitenumrechnung angewendet, und wer sie vergisst, macht einen Fehler, gegen den die neun Prozent zwischen Terabyte und Tebibyte klein wirken.

Die Grundschutz-Bausteine geben Mindestfristen vor, keine Obergrenzen, und viele Organisationen bewahren länger auf, als die Vorgabe verlangt, weil eine kürzere Frist nachträglich schwer zu begründen ist. Wird die Frist halbiert, halbiert sich der stationäre Speicherbedarf exakt — der Nutzen sinkt dabei selten im gleichen Maß, weil die meisten Auswertungen ohnehin nur wenige Tage oder Wochen zurückreichen.

Wo eine längere Frist wirklich nötig ist — etwa für revisionsrelevante Ereignisse — reicht es oft, nur diesen Teil der Protokolle länger vorzuhalten und den Rest nach der Mindestfrist zu löschen. Diese Trennung muss festgelegt werden, bevor die Daten geschrieben werden, nicht danach.

Die Kalkulation entsteht fast immer in dezimalen Einheiten, weil Ereignisrate und Zeilengröße dezimal sind und sich so leicht rechnen lassen. Der eingesetzte Speicherpool meldet seinen Füllstand dagegen in binären Einheiten, weil das Dateisystem darunter so zählt. Steht in der Planung „9 TB“ und im Speichersystem „8,19 TiB“, ist das dieselbe Datenmenge — steht in der Planung „9 TiB“ und wird ein Pool mit „9 TB“ Nennkapazität bestellt, fehlen am Ende real gut 800 GB.

Der zweite Fall ist der gefährlichere, weil ihn nichts anzeigt, bis der Speicher tatsächlich knapp wird. Wer die Anforderung als Byte-Zahl in die Bestellung schreibt statt als gerundetes Präfix, entzieht der Verwechslung die Grundlage — für den Preis einer zusätzlichen Ziffer.