kB in GiB 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 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.

Der Faktor ist 0,000001, und den trägt praktisch niemand mit sich herum. Auf 0,000001 gerundet liegt er um 0,14 % daneben — bei kleinen Zahlen unsichtbar, bei etwa 1.000 kB 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 1073741,824 kB und 1000000 kB — 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.

Wer aus Datenschutzgründen einen eigenen Nextcloud-Server betreibt – auf einem Verein, einer kleinen Kanzlei oder einfach privat, weil die Daten nicht bei einem US-Anbieter liegen sollen –, sieht in der Administrationsoberfläche eine Speicherbelegung in Gibibyte, während die einzelne Datei, etwa ein E-Mail-Anhang oder ein synchronisiertes Vorschaubild, in Kilobyte gemessen wird. Diese beiden Systeme kommen aus unterschiedlichen Quellen: Die Dateigröße zählt Inhalt, das Betriebssystem darunter rechnet in Zweierpotenzen, weil die Hardware das tut.

Ein Gibibyte fasst 1.073.741,824 kB, nicht die runde Million. Für die Frage "wie viele Dateien passen noch auf den Server" ist das kein Rundungsfehler, sondern eine 7,4-Prozent-Differenz gegenüber einer naiv dezimal geschätzten Kapazität – bei einem 500-Gibibyte-Volume sind das rund 37 Gibibyte, die zwischen einer groben Schätzung und der tatsächlich verfügbaren Kapazität liegen.

Nextcloud-Instanzen füllen sich typischerweise mit sehr vielen kleinen Objekten: E-Mail-Anhänge zwischen 20 und 200 kB, Vorschaubilder im niedrigen zweistelligen Kilobyte-Bereich, synchronisierte Konfigurationsdateien im einstelligen Kilobyte-Bereich. Eine Vereinsverwaltung mit 5.000 archivierten E-Mails samt Anhängen bei durchschnittlich 80 kB kommt auf 400.000 kB, was 0,373 GiB entspricht – die Differenz zur naiven Rechnung mit einer Million ist bei dieser Größenordnung noch klein, wächst aber linear mit der Anzahl der Objekte.

Bei 200.000 Dateien, wie sie ein mehrjähriger Vereinsarchivbestand durchaus erreicht, macht dieselbe 7,4-Prozent-Differenz bereits mehrere Gibibyte aus – genug, um eine knapp kalkulierte Festplatte oder ein gemietetes Root-Server-Volume unerwartet früh an die Grenze zu bringen. Die Umrechnung lohnt sich also gerade bei der Kapazitätsplanung für einen selbstgehosteten Server, nicht erst bei einer einzelnen großen Datei.

Die Speicherbelegung, die ein Server oder ein Betriebssystem meldet, kommt nicht aus einer Zählung von Inhalt, sondern aus der Adressierung von Speicherblöcken, und die läuft binär: Ein Dateisystem organisiert Platz in Blöcken einer Zweierpotenz-Größe, üblicherweise 4 KiB, und jede Kapazitätsmeldung, die auf dieser Blockstruktur aufbaut, erbt die Zweierpotenz. Der einzelne Anhang oder das Log-Fragment dagegen wurde durch Zählen von Bytes gemessen und dezimal angegeben, weil Inhalt keine Blockstruktur hat.

Diese unterschiedliche Herkunft erklärt auch, warum eine Umrechnung von Kilobyte in Gibibyte nicht nur eine andere Zahl liefert, sondern zwei unterschiedliche Fragen beantwortet: Wie viel Inhalt liegt vor, und wie viel Platz belegt dieser Inhalt in einem System, das in Blöcken denkt. Für eine Kapazitätsplanung ist die zweite Frage die relevante, und sie beginnt erst mit dem Umrechnungsfaktor 1.073.741,824.

Neben der reinen Einheitendifferenz kommt bei sehr kleinen Dateien die Blockrundung hinzu: Ein 2-kB-Anhang, der als eigenständige Datei abgelegt wird, belegt auf einem Dateisystem mit 4-KiB-Blöcken volle 4 KiB, mehr als das Doppelte seiner tatsächlichen Größe. Eine Million solcher Anhänge enthalten damit real rund 1,86 GiB Content, belegen aber – weil jede Datei einen vollen Block bekommt – rund 3,81 GiB Speicher, mehr als das Doppelte des tatsächlichen Inhalts – ein Effekt, der bei der Kapazitätsplanung eines Nextcloud-Servers oft schwerer wiegt als die 7,4 Prozent zwischen kB und GiB.

Nextcloud selbst legt einen Teil dieser Kleinstdateien nicht einzeln im Dateisystem ab, sondern in einer Datenbank oder gebündelt, was diesen Effekt abmildert – wie stark, hängt von der konkreten Konfiguration ab und ist deshalb vor einer Kapazitätsplanung zu prüfen statt anzunehmen. Der verlässliche Weg bleibt derselbe: die reale Belegung am laufenden System messen, statt aus der Summe der Dateigrößen allein auf den benötigten Gibibyte-Wert zu schließen.

Wer den eigenen Nextcloud-Server über eine mobile Datenverbindung synchronisiert – etwa auf einem Bauwagen oder in einem Ferienhaus ohne Festnetzanschluss –, vergleicht dabei zwei Zahlen aus unterschiedlichen Systemen: Das gebuchte Datenvolumen bei Telekom, Vodafone oder O2 wird in dezimalen Gigabyte verkauft, während die Verbrauchsanzeige im Router oder im Betriebssystem des angeschlossenen Rechners in Zweierpotenzen rechnet und die belegten Kilobyte pro synchronisierter Datei entsprechend anders summiert.

Bei einem Datenvolumen von 20 GB, das über einen Monat durch viele einzelne kleine Synchronisationsvorgänge aufgebraucht wird, macht diese Differenz real 1,5 GB aus – der Unterschied zwischen den 7,4 Prozent, die zwischen dezimalem und binärem Gigabyte liegen. Wer die Verbrauchsanzeige des Routers als exakten Spiegel des Telekom-Kontingents liest, überschätzt damit systematisch, wie viel Volumen tatsächlich noch übrig ist, und läuft eher unerwartet in eine Drosselung als erwartet.

Für eine belastbare Planung hilft es, sich auf eine der beiden Zahlen festzulegen und konsequent dabei zu bleiben – am ehesten die Abrechnung des Mobilfunkanbieters, weil sie am Ende die einzige ist, die tatsächlich in Rechnung gestellt wird. Die Kilobyte-zu-Gibibyte-Umrechnung dient dann dazu, die Anzeige des eigenen Systems in dieselbe Sprache zu übersetzen, nicht umgekehrt.

Dieselbe Unschärfe betrifft, wer einen VPS oder Root-Server bei einem deutschen Hoster wie IONOS oder Hetzner für die eigene Nextcloud-Instanz mietet: Das gebuchte Speichervolumen wird in der Produktbeschreibung dezimal in Gigabyte beworben, während das im Server-Betriebssystem laufende Dateisystem intern in Gibibyte rechnet. Bei einem gebuchten 500-Gigabyte-Volume zeigt das System also weniger als 500 GiB an tatsächlich nutzbarem Platz, ohne dass etwas fehlt – die Differenz ist dieselbe 7,4-Prozent-Lücke, nur diesmal auf der Anbieterseite statt auf der Verbrauchsseite gemessen.

Für eine Kapazitätsplanung, die diese Lücke von vornherein berücksichtigt, lohnt es sich, mit dem gebuchten Gigabyte-Wert rückwärts zu rechnen: Ein 500-GB-Volume fasst rund 465,7 GiB, und diese Zahl – nicht die 500 vom Werbetext – ist die, gegen die eine in Gibibyte geschätzte Kapazitätsplanung für viele kleine Dateien tatsächlich geprüft werden sollte.