TiB in kB umrechnen

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.

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.

In dieser Richtung wird multipliziert, und zwar mit einer ganzen Zahl: ein Tebibyte sind 1.099.511.628 Kilobyte, exakt. 1.099.511.628 ist die Definition und keine Messung, die knapp danebenlag.

Damit ist es eine der wenigen Umrechnungen, die sich im Kopf lohnen, und das Ergebnis lässt sich prüfen: rechne zurück, und du musst exakt auf der Ausgangszahl landen, ohne Rest, den man wegerklären müsste.

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.

Betreiber kritischer Infrastrukturen müssen sicherheitsrelevante Ereignisse protokollieren und über einen festgelegten Zeitraum nachvollziehbar vorhalten, und eine einzelne Protokollzeile — Zeitstempel, Quelle, Ereignistyp, Nutzdaten — liegt typischerweise im Bereich eines Kilobyte. Ein Tebibyte fasst 1.099.511.627,78 kB (der Rechner oben rundet auf zwölf signifikante Stellen), also für praktische Zwecke rund 1,1 Milliarden Zeilen dieser Größe, bevor irgendein Overhead eingerechnet ist.

Bei zwei Kilobyte je Zeile werden daraus 549,8 Millionen, bei fünf Kilobyte 219,9 Millionen, bei einem halben Kilobyte 2,2 Milliarden. Die Spanne zwischen diesen drei Werten ist ein Faktor zehn, allein durch die Zeilengröße getrieben, während die Einheitenfrage — Kilobyte oder Kibibyte — das Ergebnis nur um zehn Prozent verschiebt. Diese Reihenfolge ist die wichtigste Erkenntnis: Die Zeilengröße richtig zu schätzen wiegt mehr als die genaue Präfix-Wahl.

Ein System, das tausend Ereignisse pro Sekunde bei je einem Kilobyte protokolliert, erzeugt ein Megabyte pro Sekunde, also 86,4 GB pro Tag. Ein Tebibyte unkomprimierte Kapazität deckt damit 12,7 Tage ab. Verdoppelt sich die Ereignisrate, halbiert sich die Dauer; verdoppelt sich die Zeilengröße, halbiert sie sich erneut; kommt eine zweite protokollierende Komponente mit derselben Rate hinzu, halbiert sie sich ein drittes Mal. Die Rechnung ist trivial, die Eingangsgrößen sind der eigentliche Arbeitsaufwand.

Eine geforderte Vorhaltezeit steht meist fest, bevor die tatsächliche Rate bekannt ist, was die Rechnung umkehrt: die geforderte Kapazität durch die Anzahl der Tage teilen ergibt das Tagesbudget, innerhalb dessen das System bleiben muss. Neunzig Tage bei 86,4 GB am Tag sind 7,78 TB, also 7,08 TiB — die Zahl, die gegen den vorhandenen Pool geprüft werden sollte, bevor irgendjemand eine Vorhaltefrist unterschreibt, die der Speicher nicht einhalten kann.

Strukturierter Protokolltext komprimiert gut, weil er sich wiederholt: Zeitstempel im festen Format, wiederkehrende Feldnamen, ein begrenztes Vokabular an Meldungsvorlagen. Verhältnisse von fünf zu eins und besser sind bei Protokolldaten üblich, und die genaue Zahl hängt vom Inhalt und vom Algorithmus ab, nicht von etwas, das sich aus einer Größenangabe ableiten ließe. Dieser einzelne Faktor verändert eine Vorhalteschätzung stärker als jede andere Eingangsgröße zusammen.

Er muss dabei an der richtigen Stelle angewendet werden. Kompression greift auf der gespeicherten Seite, die Ereigniszahl und die Erfassungsrate liegen also in unkomprimierten Kilobyte, während die Kapazität komprimiert vorliegt. Eine unkomprimierte Rate ohne das Kompressionsverhältnis dazwischen direkt gegen eine komprimierte Kapazität zu teilen ergibt einen Fehler in der Größenordnung des gesamten Kompressionsfaktors — deutlich mehr als die zehn Prozent, um die es bei der Einheit auf dieser Seite geht.

Ein gespeichertes Ereignis besteht selten nur aus seiner Nutzlast. Indizierungssysteme legen einen invertierten Index an, der die Größe der Dokumente, die er beschreibt, erreichen kann; Replikation vervielfacht das Ganze um den Replikationsfaktor; ein Write-Ahead-Log hält kürzliche Änderungen doppelt. Nichts davon erscheint in einer Kilobyte-Angabe, die jemand an einem einzelnen Beispiel gemessen hat.

Der verlässliche Weg ist, nicht die Bestandteile zu schätzen, sondern das System zu messen. Eine bekannte Anzahl Ereignisse in eine repräsentative Instanz laden, die belegte Größe ablesen, teilen. Das Ergebnis ist eine Byte-pro-Ereignis-Zahl, die jeden vom System selbst hinzugefügten Overhead bereits enthält, und lässt sich mit deutlich mehr Vertrauen auf jede Größenordnung hochrechnen als eine Summe geschätzter Einzelposten.

Den exakten Faktor zu verwenden — 1024⁴ durch 1000, also 1.099.511.627,776 kB je Tebibyte, angezeigt als 1.099.511.627,78 — kostet nichts und verhindert, dass sich die zehn Prozent unbemerkt einschleichen. Das Ergebnis danach sollte grob gerundet werden. Eine Vorhalteschätzung, die auf einer durchschnittlichen Ereignisgröße, einer durchschnittlichen Rate und einem angenommenen Kompressionsverhältnis beruht, trägt keine vier signifikanten Stellen, und eine solche Genauigkeit vorzutäuschen verleitet die nächste Person dazu, gegen eine Zahl zu planen, die nie so fest stand.

Die ehrliche Form der Antwort ist eine Spanne mit ihren Annahmen: rund zwei Wochen unkomprimiert, rund drei Monate bei einem Verhältnis von acht zu eins, angenommen ein Kilobyte pro Zeile und tausend Zeilen pro Sekunde. Jede dieser Annahmen lässt sich später prüfen und korrigieren, was eine einzelne Zahl von 12,7 Tagen nicht erlaubt.

Die Vorhalterechnung geht davon aus, dass abgelaufene Protokolldaten sofort Platz freigeben, und die meisten Speichersysteme arbeiten nicht so. Log-Segmente werden als Ganzes entfernt statt zeilenweise, ein Index-Rebuild läuft nur periodisch, und ein Copy-on-Write-Dateisystem hält alte Blöcke am Leben, solange ein Snapshot sie referenziert. Der tatsächliche Belegungsstand liegt deshalb meist etwas über dem, was die reine Vorhaltefenster-Rechnung erwarten lässt.

Wie groß dieser Überhang ausfällt, hängt davon ab, wie oft die Bereinigung läuft. Räumt ein System täglich auf, entspricht der Überschuss ungefähr einem Tag Zuwachs — bei 86,4 GB täglich sind das 0,08 TiB und bei einem größeren Pool vernachlässigbar. Läuft die Bereinigung wöchentlich oder erst bei Erreichen einer Schwelle, kann der Überhang einen spürbaren Anteil des Vorhaltefensters ausmachen und gehört von vornherein in die Kapazitätsplanung, statt erst aufzufallen, wenn der Pool unerwartet früh voll ist.

Ein Terabyte sind exakt 1.000.000.000 kB — eine glatte Milliarde, ohne jeden Bruchteil. Ein Tebibyte sind 1.099.511.627,776, angezeigt als 1.099.511.627,78. Dieser Unterschied in der Glattheit ist ein verlässliches Erkennungszeichen beim Lesen einer fremden Kalkulationstabelle: Eine Kapazitätszeile mit einer runden Milliarde Kilobyte wurde aus einem dezimalen Terabyte hergeleitet, unabhängig davon, was die Spaltenüberschrift behauptet, und eine Zeile mit 1,0995 Milliarden stammt aus einem Poolbericht.

Diese Prüfung lohnt sich bei jedem Dokument, das durch mehr als eine Hand gegangen ist. Gemischte Konventionen in einer einzigen Tabelle sind üblich, weil die Kapazität meist aus einem System und die Rate aus einem anderen stammt, und die entstehenden zehn Prozent werden dann eher auf Overhead geschoben als auf die Rechnung selbst.