TiB in MiB 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 Mebibyte sind 1.024 Kibibyte, also 1.048.576 Byte. Linux-Werkzeuge und Speicherangaben meinen in aller Regel das, auch wenn „MB" dasteht.

In dieser Richtung wird multipliziert, und zwar mit einer ganzen Zahl: ein Tebibyte sind 1.048.576 Mebibyte, exakt. 1.048.576 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 1048576 MiB und 953674,3164 MiB — 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.

Ein Tebibyte geteilt durch ein Mebibyte ergibt 1.048.576, und bei einem Backup-Repository ist genau diese Stückzahl die eigentlich interessante Größe. Borgbackup und Restic zerlegen jede gesicherte Datei in Chunks und legen für jeden einzelnen einen Eintrag mit Hashwert im Index an — wie viele Chunks aus einem Tebibyte werden, entscheidet direkt darüber, wie groß dieser Index wird und wie viel Arbeitsspeicher ein Backup-Lauf braucht.

Die Rechnung selbst ist eine einzige Division: 1.099.511.627.776 Byte durch 1.048.576 ergeben genau 1.048.576 MiB je Tebibyte, ohne Rest, weil beide Größen Zweierpotenzen sind. Interessant wird sie erst, wenn man sie durch die tatsächliche Chunk-Größe teilt — und die wird bei Borgbackup und Restic nicht fest vorgegeben, sondern inhaltsabhängig gewählt.

Anders als ein Multipart-Upload mit fester Teilgröße zerlegen deduplizierende Backup-Werkzeuge Dateien an inhaltsabhängigen Grenzen mit einer angepeilten Durchschnittsgröße, oft rund einem Mebibyte. Der Grund ist die Deduplizierung selbst: Fügt jemand am Anfang einer Datei ein einzelnes Byte ein, verschieben sich bei fester Blockgröße alle folgenden Blöcke, und jeder davon gilt als neu. Bei inhaltsabhängigen Grenzen verschieben sich nur die Grenzen in der Nähe der Änderung, der Rest der Datei bleibt als bereits gespeicherter Chunk erkennbar.

Das ist auch der Grund, warum diese Werkzeuge bei einem inkrementellen Backup so wenig neu übertragen — eine gewachsene Log-Datei oder ein leicht verändertes Dokument teilt sich den größten Teil ihrer Chunks mit der vorherigen Version. Eine feste Blockgröße würde diesen Effekt zunichtemachen, weshalb sie hier bewusst nicht verwendet wird.

Bei einem Mebibyte Durchschnittsgröße erzeugt ein Tebibyte in der Größenordnung einer Million Chunks, und jeder braucht einen Indexeintrag mit Hashwert. Der Repository-Index kommt damit auf mehrere Dutzend bis mehrere hundert Mebibyte und muss während eines Backup-Laufs im Arbeitsspeicher gehalten werden — auf einem kleinen Root-Server oder einem NAS mit wenig RAM ist das der Punkt, an dem ein Backup-Job zuverlässig ins Swapping gerät, lange bevor die Speicherkapazität selbst knapp wird.

Eine größere durchschnittliche Chunk-Größe halbiert den Index, senkt aber auch die Deduplizierungsrate: Größere Chunks werden seltener exakt wiedergefunden, weil eine kleine Änderung einen größeren Block betrifft. Wird ein Repository spürbar langsam statt voll, ist dieser Tausch meist der Punkt, den es neu zu bewerten lohnt.

Ein Tebibyte-Repository auf einem Synology- oder QNAP-NAS, das täglich per Restic oder Borgbackup gesichert wird, wächst nicht linear mit der Anzahl der Sicherungsläufe, sondern nur um die tatsächlich veränderten Chunks. Genau das macht die Chunk-Rechnung praktisch relevant: Wer wissen will, wie lange ein Tebibyte an Repository-Kapazität bei einer bestimmten täglichen Änderungsrate reicht, muss von der Chunk-Zahl und nicht von der Rohgröße der gesicherten Dateien ausgehen.

Das gilt besonders für virtuelle Maschinen und Datenbank-Dumps, die bei jedem Lauf komplett neu geschrieben werden, aber inhaltlich zu großen Teilen identisch bleiben. Ein zehn Gigabyte großer Dump, der sich täglich nur in wenigen Prozent ändert, belegt im Repository nach der Deduplizierung einen Bruchteil davon — die Chunk-Grenzen sind der Mechanismus, der das leistet, nicht die Kompression allein.

Wird ein Tebibyte-Repository selbst wieder in einen S3-kompatiblen Objektspeicher wie Hetzner Object Storage geschoben — was Restic und Borgbackup beide unterstützen —, gilt für diesen einen großen Transfer erneut die Zehntausend-Teile-Grenze der zugrunde liegenden Schnittstelle, unabhängig von der internen Chunk-Größe des Backup-Tools. Beide Chunk-Systeme laufen parallel und unabhängig voneinander: eines bestimmt, was im Repository dedupliziert wird, das andere, wie das fertige Repository über die Leitung geht.

Die beiden Größen zu verwechseln führt zu keinem Fehler, nur zu einer falschen Erwartung — ein auf ein Mebibyte im Schnitt zerlegtes Repository lässt sich trotzdem in 128-MiB-Teilen hochladen, weil beide Ebenen unabhängig voneinander funktionieren. Wer die Rechnung einmal sauber trennt, muss sie danach nicht mehr neu führen.

Die Deduplizierungsrate, die ein Repository am Ende erreicht, ist selbst eine Messgröße, die sich aus dem Verhältnis von gespeicherten zu eindeutigen Chunks ablesen lässt — beide Werte geben sowohl Borgbackup als auch Restic auf Nachfrage aus. Ein Verhältnis nahe eins bedeutet, dass fast jeder Chunk neu ist, was bei stark verschlüsselten oder bereits komprimierten Quelldaten normal ist, weil sich dort inhaltlich nichts wiederholt, das die Chunk-Grenzen erkennen könnten. Ein Verhältnis von zehn oder mehr bedeutet, dass die meisten Chunks aus früheren Läufen wiederverwendet werden.

Dieser Wert ist der praktische Gradmesser dafür, ob sich eine größere Chunk-Größe überhaupt lohnt. Bei einem Repository mit hoher Deduplizierungsrate schadet eine Vergrößerung der Chunks wenig, weil ohnehin schon viel Wiederverwendung stattfindet; bei einem Repository nahe eins bringt eine kleinere Durchschnittsgröße oft mehr, weil dort jede zusätzliche Chance auf eine Übereinstimmung zählt. Die reine Umrechnung von Tebibyte in Mebibyte sagt nichts über diesen Wert aus — sie liefert nur die Stückzahl, gegen die er zu lesen ist.

Für ein Repository mit vielen kleinen, sich häufig ändernden Dateien — ein Mailspool, ein Quellcode-Verzeichnis — bleibt die Standard-Chunk-Größe die richtige Wahl, weil die Deduplizierungsrate hier den Ausschlag gibt. Für ein Repository, das vor allem aus wenigen großen, selten geänderten Objekten besteht — Videoarchive, VM-Images, die als Ganzes neu geschrieben werden —, ist ein größerer Durchschnitt oft die bessere Wahl, weil die Indexgröße dann die spürbarere Kostenstelle ist.

Die Umrechnung eines Tebibyte-Bestands in Chunks bei beiden Größen macht die Entscheidung sichtbar, statt sie zu erraten: bei einem Mebibyte im Schnitt rund eine Million Chunks, bei acht Mebibyte im Schnitt rund hundertdreißigtausend. Der Index schrumpft entsprechend, und ob das den Verlust an Deduplizierung wert ist, hängt vollständig davon ab, wie ähnlich sich die gesicherten Dateien von Lauf zu Lauf tatsächlich sind.