Speicherbedarf und Datenmengen berechnen

Speicherbedarf und Datenmengen berechnen

https://bildung.social/@oerinformatik/

https://oer-informatik.de/speicherbedarf

Speicherbedarf, Datenmenge, Bit und Byte, Binärpräfixe, IEC 80000-13, Farbtiefe, Zeichencodierung, Datenrate, Kompression, Übertragungsdauer

tl/dr; (ca. 29 min Lesezeit): Wie viel Speicher brauchen Fotos, Scans, Videos, Messwerte und Datensätze, wie lange dauert ihre Übertragung und was kostet ihre Ablage? Der Artikel erklärt Bit, Byte, Dezimal- und Binärpräfixe (kB und KiB), ein festes Rechenschema mit Einheiten, die Formeln für Rastergrafiken, Zeichencodierungen, Datentypen, Audio und Video sowie den Umgang mit Kompression, Overhead (auch aus MTU und Headern), Deduplizierung, Clustergröße und Rundung. Dazu kommen die Planung von Speichersystemen über mehrere Jahre, Ringspeicher, Bandbreitenbudgets und die Wahl von Auflösung, Bildrate und Codec für Videoaufzeichnungen [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Als Grundlagen zum Speicherbedarf kann ich nach Durchlesen des Artikels…

• … Bit und Byte unterscheiden und Datenmengen zwischen Dezimalpräfixen (kB, MB, GB, TB) und Binärpräfixen (KiB, MiB, GiB, TiB) umrechnen.

• … erklären, warum eine Festplatte mit „4 TB“ im Betriebssystem kleiner erscheint, und die angezeigte Größe berechnen.

• … den Speicherbedarf einer unkomprimierten Rastergrafik aus Pixelzahl (auch aus Maßen und Auflösung in dpi) und Farbtiefe berechnen und die Zahl darstellbarer Farben angeben.

• … den Speicherbedarf von Texten und Datensätzen aus Zeichencodierung (ASCII, UTF-8, UTF-16, Hexadezimalziffern) und Datentypen berechnen.

• … Datenmengen aus einer Datenrate (z. B. Video in kbit/s) und einer Dauer berechnen und über Mengen und Zeiträume hochrechnen.

• … Kompression, Zuschläge (Overhead, Reserve) und Prozentangaben richtig einrechnen und die Deduplizierung erläutern.

• … die Übertragungsdauer einer Datenmenge bei gegebener (Netto-)Datenrate berechnen und in Minuten und Sekunden angeben.

• … Ergebnisse aufgabengerecht runden (auf, ab, auf Nachkommastellen) und Speicherkosten bei angefangenen Speicherblöcken berechnen.

• … den Speicherbedarf für mehrere Jahre aus Altbestand, Auslastung und jährlichem Zuwachs planen, die Reichweite eines Speichers in ganzen Jahren und die Dauer bis zum Überschreiben eines Ringspeichers berechnen.

• … erklären, warum eine Datei auf dem Datenträger mehr Platz belegt als ihre Dateigröße (Clustergröße).

Darüber hinaus kann ich als Expertenwissen…

• … die Datenrate unkomprimierter Audio- und Videodaten aus Abtastrate, Auflösung, Kanälen bzw. Bildgröße und Bildrate berechnen und damit den Nutzen von Kompression beziffern.

• … einschätzen, wann Deduplizierung und Kompression viel und wann sie kaum Speicher sparen.

• … den Protokoll-Overhead aus MTU und Headergrößen berechnen, ihn bei der Übertragungsdauer großer Datenmengen berücksichtigen und bestimmen, wie viele Geräte in einen Anteil der Bandbreite passen.

• … für eine Videoaufzeichnung Auflösung, Bildrate und Codec als Auswahlkriterien beurteilen, gängige Formate nennen und die Datenmenge unkomprimiert und komprimiert vergleichen.

Ob Drohnenfotos für eine KI-Auswertung, eingescannte Rechnungen für das Archiv, Videos einer Veranstaltung oder Messwerte von Sensoren: Bevor Daten gespeichert oder übertragen werden, muss jemand abschätzen, wie viel Platz sie brauchen. Davon hängen die Größe von Festplatten und RAID-Verbünden, die Kosten für Cloud-Speicher, die Dauer einer Datensicherung und die nötige Bandbreite ab. In IT-Aufgaben ist diese Rechnung ein Klassiker: Die Zahlen sind einfach, die Punkte gehen aber oft an Einheiten, Präfixen und Rundung verloren. Dieser Artikel zeigt ein Rechenschema, mit dem das nicht passiert.

Bit und Byte: die kleinsten Einheiten

Ein Bit (binary digit) ist die kleinste Informationseinheit und kann zwei Zustände annehmen: 0 oder 1. Acht Bit bilden ein Byte (Einheitenzeichen B), die kleinste Einheit, die ein Rechner üblicherweise adressiert. Eine Folge von vier Bit heißt Nibble oder Halbbyte; sie reicht genau für eine Hexadezimalziffer (0 bis F).

1\,\mathrm{Byte} = 8\,\mathrm{bit}

Mit n Bit lassen sich 2^n verschiedene Werte darstellen: mit 8 Bit also 2^8 = 256 Werte, mit 24 Bit 2^{24} = 16.777.216 Werte. Diese Beziehung brauchst Du, wenn nach der Zahl der darstellbaren Farben oder Zeichen gefragt ist.

Achte auf die Schreibweise: Speichergrößen stehen meist in Byte (großes B), Datenraten in Bit pro Sekunde (bit/s, englisch oft bps). „100 Mbit/s“ und „100 MB/s“ unterscheiden sich um den Faktor 8.

Kilo oder Kibi? Dezimal- und Binärpräfixe

Für große Datenmengen gibt es zwei Präfix-Familien, die leider ähnlich aussehen:

Die Binärpräfixe („kilo binary“ = kibi) sind in der Norm IEC 80000-13 festgelegt (aktuelle Ausgabe 2025). Die Dezimalpräfixe bedeuten wie überall im SI-Einheitensystem Zehnerpotenzen: Ein Kilometer hat 1.000 Meter, ein Kilobyte 1.000 Byte. In jeder Stufe steckt bei den Binärpräfixen ein weiterer Faktor 1.024:

1\,\mathrm{GiB} = 1.024\,\mathrm{MiB} = 1.024 \cdot 1.024\,\mathrm{KiB} = 1.024^3\,\mathrm{Byte}

Wer welche Präfixe verwendet:

• Hersteller von Festplatten, SSDs, USB-Sticks geben die Kapazität dezimal an (1 TB = 10^{12} Byte).

• Datenraten in Netzwerken sind immer dezimal: 1 Mbit/s = 1.000.000 bit/s. Ein „Kibit/s“ kommt praktisch nicht vor.

• Arbeitsspeicher wird binär gebaut: Ein Modul mit „16 GB“ hat in Wahrheit 16 GiB.

• Windows rechnet im Explorer binär, schreibt aber „GB“ und „TB“. Linux-Werkzeuge und macOS zeigen je nach Programm dezimale oder binäre Werte, viele schreiben dann korrekt „GiB“.

Daraus ergibt sich die bekannte Verwunderung über „fehlenden“ Speicher:

Geg.: Festplatte mit S = 4\,\mathrm{TB} = 4 \cdot 10^{12}\,\mathrm{Byte}

Ges.: angezeigte Größe in TiB

S = \frac{4 \cdot 10^{12}\,\mathrm{Byte}}{1.024^4\,\mathrm{Byte/TiB}} \approx \underline{\underline{3{,}638\,\mathrm{TiB}}}

Windows zeigt diese Platte als „3,63 TB“ an. Es fehlt nichts, es ist nur eine andere Einheit. Der Unterschied wächst mit jeder Präfixstufe: Binär umgerechnet erscheint ein dezimal angegebener Wert bei Kilo um 2,3 %, bei Giga um 6,9 % und bei Tera um 9,1 % kleiner.

In einer Aufgabe steht die gewünschte Einheit fast immer dabei („in GiB“, „in MB“). Steht nur „MB“ ohne weitere Angabe, rechne dezimal und schreib Deine Annahme dazu. Manche Aufgaben geben den Umrechnungsfaktor ausdrücklich vor (etwa „1 KiB = 1.024 Byte“); dann gilt dieser.

Das Rechenschema: Einheiten mitführen

Die meisten Fehler entstehen nicht beim Rechnen, sondern beim Umrechnen. Deshalb lohnt sich ein festes Vorgehen:

1. Geg./Ges. notieren: Alle Angaben mit Einheit aufschreiben, die gesuchte Größe mit der geforderten Einheit.

2. Kleinste sinnvolle Einheit wählen: Alles in Bit oder Byte und in Sekunden umrechnen. Megapixel in Pixel (1 MP = 1.000.000 Pixel, dezimal!), Stunden in Sekunden, kbit/s in bit/s.

3. Formel aufstellen und Werte mit Einheiten einsetzen. Einheiten kürzen sich wie Zahlen: \mathrm{Pixel} \cdot \mathrm{bit/Pixel} = \mathrm{bit}.

4. Erst am Ende in die geforderte Einheit umrechnen und erst am Ende runden.

5. Das Ergebnis auf Plausibilität prüfen: Ist ein Foto wirklich 137 MiB groß? (Unkomprimiert ja; als JPEG eher 5 bis 15 MiB.)

Weil Aufgaben oft den Rechenweg verlangen und Teilpunkte für einzelne Schritte vergeben (z. B. „Umrechnung Byte in Bit: 1 Punkt“), sollte jeder Umrechnungsschritt im Rechenweg sichtbar sein. Bei Folgefehlern gibt es dann trotzdem Punkte.

Rastergrafiken: Pixel mal Farbtiefe

Ein unkomprimiertes Rasterbild (Foto, Scan, Bildschirminhalt) besteht aus Breite mal Höhe Bildpunkten (Pixel). Jedes Pixel braucht so viele Bit, wie die Farbtiefe angibt. Bei RGB-Bildern setzt sich die Farbtiefe aus drei Farbkanälen (Rot, Grün, Blau) zusammen: 3 Kanäle mit je 8 Bit ergeben 24 Bit pro Pixel („True Color“), mit je 16 Bit 48 Bit pro Pixel.

S = B \cdot H \cdot F

mit S Speicherbedarf in Bit, B und H Breite und Höhe in Pixel, F Farbtiefe in bit/Pixel. Ist die Pixelzahl als Megapixel angegeben, ersetzt sie B \cdot H.

Geg.: Foto mit 12\,\mathrm{MP} = 12.000.000\,\mathrm{Pixel}, Farbtiefe F = 24\,\mathrm{bit/Pixel}, unkomprimiert

Ges.: Speicherbedarf S in MiB

S = 12.000.000\,\mathrm{Pixel} \cdot 24\,\mathrm{bit/Pixel} = 288.000.000\,\mathrm{bit}

S = \frac{288.000.000\,\mathrm{bit}}{8\,\mathrm{bit/Byte}} = 36.000.000\,\mathrm{Byte} = \frac{36.000.000\,\mathrm{Byte}}{1.024^2\,\mathrm{Byte/MiB}} \approx \underline{\underline{34{,}332\,\mathrm{MiB}}}

Die Zahl der darstellbaren Farben hängt nur von der Farbtiefe ab: bei 24 Bit 2^{24} = 16.777.216 Farben (rund 16,7 Millionen), bei 8 Bit (z. B. GIF mit Farbpalette) 2^8 = 256 Farben.

Bildgröße aus Maßen und Auflösung

Bei Scans und Druckvorlagen sind statt der Pixelzahl die Maße und die Auflösung in dpi (dots per inch) oder ppi (pixels per inch) gegeben. Ein Inch (Zoll) sind 2,54 cm. Die Pixelzahl einer Seite ist dann:

B = \frac{b}{2{,}54\,\mathrm{cm/inch}} \cdot A

mit b Breite in cm und A Auflösung in Pixel/inch, für die Höhe entsprechend. Pixel gibt es nur ganz; runde die Pixelzahl je Kante auf ganze Pixel (oder folge der Vorgabe der Aufgabe).

Geg.: Foto im Format 10\,\mathrm{cm} \times 15\,\mathrm{cm}, gescannt mit A = 300\,\mathrm{dpi} und F = 24\,\mathrm{bit}

Ges.: Speicherbedarf in MiB

B = \frac{10\,\mathrm{cm}}{2{,}54\,\mathrm{cm/inch}} \cdot 300\,\mathrm{Pixel/inch} \approx 1.181\,\mathrm{Pixel} \qquad H = \frac{15\,\mathrm{cm}}{2{,}54\,\mathrm{cm/inch}} \cdot 300\,\mathrm{Pixel/inch} \approx 1.772\,\mathrm{Pixel}

S = 1.181 \cdot 1.772\,\mathrm{Pixel} \cdot 3\,\mathrm{Byte/Pixel} = 6.278.196\,\mathrm{Byte} \approx \underline{\underline{5{,}987\,\mathrm{MiB}}}

Hier wurde die Farbtiefe gleich in Byte eingesetzt (24 bit = 3 Byte). Das spart einen Schritt, geht aber nur, wenn die Farbtiefe ein Vielfaches von 8 ist.

Text und Datensätze: Zeichen und Datentypen

Zeichencodierungen

Wie viel Platz ein Text braucht, hängt von der Zeichencodierung ab:

Speicherbedarf je Zeichen für verschiedene Codierungen

Codierung	Speicher je Zeichen	Bemerkung
ASCII	7 Bit, gespeichert in 1 Byte	nur 128 Zeichen, keine Umlaute
ISO 8859-1 (Latin-1), Windows-1252	1 Byte	westeuropäische Sonderzeichen, 256 Zeichen
UTF-8	1 bis 4 Byte	ASCII-Zeichen 1 Byte, Umlaute 2 Byte, Emojis 4 Byte; Standard im Web
UTF-16	2 oder 4 Byte	die meisten Zeichen 2 Byte; z. B. intern in Java und Windows
UTF-32	4 Byte	feste Länge
Hexadezimalziffer (0–F)	4 Bit	kompakt, z. B. für MAC-Adressen und Prüfsummen
BCD-Ziffer (0–9)	4 Bit	binär codierte Dezimalziffer

Das Wort „Größe“ belegt in Latin-1 5 Byte, in UTF-8 7 Byte (ö und ß je 2 Byte) und in UTF-16 10 Byte. Ein reiner ASCII-Text verdoppelt seinen Speicherbedarf also, wenn er in UTF-16 statt in einer 1-Byte-Codierung gespeichert wird.

Ob Daten als Text oder binär gespeichert werden, macht viel aus: Die MAC-Adresse 24:6F:28:40:09:01 braucht als Text 17 Zeichen (17 Byte in ASCII), als 12 Hexadezimalziffern zu je 4 Bit aber nur 6 Byte.

Datentypen und Datensätze

Für Datensätze in Datenbanken oder Dateien addierst Du den Speicherbedarf aller Felder eines Datensatzes und multiplizierst mit der Zahl der Datensätze. Typische Größen (in MariaDB/MySQL, ähnlich in Java oder C):

Speicherbedarf ausgewählter Datentypen

Datentyp	Speicherbedarf
BOOLEAN / TINYINT	1 Byte
SMALLINT	2 Byte
INT (Integer, 32 Bit)	4 Byte
BIGINT (64 Bit)	8 Byte
FLOAT (einfache Genauigkeit)	4 Byte
DOUBLE (doppelte Genauigkeit)	8 Byte
CHAR(n)	n Zeichen (bei 1-Byte-Zeichensatz n Byte, bei utf8mb4 bis 4n Byte)
VARCHAR(n)	tatsächliche Länge plus 1 bis 2 Byte Längenangabe

Mehr zu den SQL-Datentypen findest Du im Artikel SQL-DDL: Datentypen. Aufgaben geben die Größen meist vor („für jede Stelle wird 1 Byte benötigt“, „Messwerte als Float mit 32 Bit“) – nimm dann genau diese Werte.

Geg.: 30 Sensoren, je Minute ein Datensatz aus Sensor-ID (INT, 4 Byte), Zeitstempel (4 Byte) und Messwert (FLOAT, 4 Byte), Zeitraum 24 h

Ges.: Speicherbedarf je Tag in KiB

S = (4 + 4 + 4)\,\mathrm{Byte} \cdot 1.440\,\frac{1}{\mathrm{Tag}} \cdot 30 = 518.400\,\mathrm{Byte} = \frac{518.400\,\mathrm{Byte}}{1.024\,\mathrm{Byte/KiB}} = \underline{\underline{506{,}250\,\mathrm{KiB}}}

In der Praxis kommen noch Indizes, Verwaltungsdaten der Datenbank und Dateisystem-Blöcke hinzu. Aufgaben fassen das gern als pauschalen Zuschlag zusammen (siehe Zuschläge).

Audio und Video: Datenrate mal Dauer

Für fortlaufende Daten wie Video, Audio oder Sensorströme ist meist eine Datenrate (Bitrate) gegeben, z. B. „6.000 kbit/s“. Dann gilt:

S = r \cdot t

mit r Datenrate in bit/s und t Dauer in s. Wichtig: kbit/s und Mbit/s sind dezimal, also 6.000\,\mathrm{kbit/s} = 6.000.000\,\mathrm{bit/s}.

Geg.: Videoaufzeichnung mit r = 6\,\mathrm{Mbit/s}, Dauer t = 1\,\mathrm{h} = 3.600\,\mathrm{s}

Ges.: Speicherbedarf in GiB

S = 6.000.000\,\mathrm{bit/s} \cdot 3.600\,\mathrm{s} = 21.600.000.000\,\mathrm{bit} = 2.700.000.000\,\mathrm{Byte} = \frac{2{,}7 \cdot 10^9\,\mathrm{Byte}}{1.024^3\,\mathrm{Byte/GiB}} \approx \underline{\underline{2{,}515\,\mathrm{GiB}}}

Läuft eine Aufzeichnung nicht ständig (z. B. eine Überwachungskamera mit Bewegungserkennung, die an 40 % des Tages aufzeichnet), multiplizierst Du die Dauer mit diesem Anteil.

Unkomprimierte Audio- und Videodaten (Expertenwissen)

Fehlt die Datenrate, lässt sie sich für unkomprimierte Daten berechnen:

• Audio (PCM): Datenrate = Abtastrate · Auflösung · Kanäle. Bei Audio-CD-Qualität: 44.100\,\mathrm{Hz} \cdot 16\,\mathrm{bit} \cdot 2 = 1.411.200\,\mathrm{bit/s}, also rund 10,094 MiB pro Minute.

• Video: Datenrate = Pixel je Bild · Farbtiefe · Bildrate. Bei Full HD mit 24 Bit und 25 Bildern pro Sekunde: 1.920 \cdot 1.080 \cdot 24\,\mathrm{bit} \cdot 25\,\mathrm{s^{-1}} = 1.244.160.000\,\mathrm{bit/s}. Eine Stunde wären rund 521 GiB.

Der Vergleich mit den 6 Mbit/s oben zeigt, warum Videos fast immer komprimiert (z. B. mit H.264, H.265 oder AV1) gespeichert werden: Die Datenmenge schrumpft etwa auf ein Zweihundertstel.

Vertiefung: Videoaufzeichnung planen

Wer Kameras für Überwachung, Streaming oder Aufzeichnung auswählt, entscheidet über drei Größen, die die Datenmenge bestimmen:

• Auflösung (Pixel je Bild): z. B. HD 1.280 × 720, Full HD 1.920 × 1.080, 4K UHD 3.840 × 2.160. Mehr Pixel zeigen mehr Details (Kennzeichen, Gesichter in größerer Entfernung), vervielfachen aber die Datenmenge: 4K hat viermal so viele Pixel wie Full HD.

• Bildrate (Bilder je Sekunde, fps): 25 oder 30 fps wirken flüssig; für Überwachung reichen oft 10 bis 15 fps, für schnelle Bewegungen (Sport, Verkehr) sind 50 oder 60 fps sinnvoll. Die Datenmenge wächst ungefähr proportional zur Bildrate.

• Codec (Kompressionsverfahren): H.264 (AVC) ist fast überall abspielbar, H.265 (HEVC) und AV1 brauchen bei gleicher Qualität etwa die Hälfte, erfordern aber mehr Rechenleistung und passende Abspielgeräte. Der Container (Dateiformat) wie MP4, MKV oder WebM verpackt Video, Ton und Untertitel; für Streaming im Web sind MP4 mit H.264 und WebM mit VP9 oder AV1 verbreitet, ausgeliefert z. B. über HLS oder MPEG-DASH.

Dieselben Angaben stehen in Datenblättern von Bildschirmen: Die Auflösung gibt die Pixelzahl an, die Farbtiefe die Bit je Pixel (z. B. 8 oder 10 Bit je Farbkanal) und die Bildwiederholfrequenz in Hertz, wie oft das Bild pro Sekunde neu aufgebaut wird (z. B. 60 Hz oder 144 Hz).

Für die Speicherplanung rechnest Du mit der vom Hersteller oder Encoder angegebenen Datenrate je Kamera, nicht mit dem unkomprimierten Wert. Zeichnet eine Kamera nur bei Bewegung auf, multiplizierst Du mit dem Anteil der Aufnahmezeit, und bei mehreren Kameras mit deren Zahl.

Hochrechnen über Mengen und Zeiträume

Aufgaben fragen selten nach einem einzelnen Bild, sondern nach dem Bedarf pro Tag, Woche oder Jahr. Rechne zuerst die Einheit (ein Bild, ein Datensatz, eine Sekunde Video) und multipliziere dann mit allen Mengenangaben. Schreib dabei die Einheiten der Faktoren mit („Bilder/Woche“, „Wochen/Jahr“), dann siehst Du sofort, ob ein Faktor fehlt.

Geg.: Baustellenkamera, alle 10 Minuten ein Foto mit 12 MP und 24 Bit (36.000.000 Byte, siehe oben), Betrieb rund um die Uhr, 365 Tage

Ges.: Speicherbedarf pro Jahr in TiB

S = 36.000.000\,\frac{\mathrm{Byte}}{\mathrm{Bild}} \cdot 144\,\frac{\mathrm{Bilder}}{\mathrm{Tag}} \cdot 365\,\frac{\mathrm{Tage}}{\mathrm{Jahr}} = 1{,}89216 \cdot 10^{12}\,\mathrm{Byte} = \frac{1{,}89216 \cdot 10^{12}\,\mathrm{Byte}}{1.024^4\,\mathrm{Byte/TiB}} \approx \underline{\underline{1{,}721\,\mathrm{TiB}}}

Häufige Stolpersteine: „rund um die Uhr“ bedeutet 24 Stunden je Tag, ein Jahr hat in Aufgaben meist 52 Wochen oder 365 Tage (steht in der Aufgabe), und „je Kamera“ heißt, dass noch mit der Zahl der Kameras multipliziert werden muss.

Speicher für mehrere Jahre planen

Bei der Anschaffung eines Speichersystems (z. B. eines SAN oder NAS) wird der Bedarf über die geplante Laufzeit berechnet:

S_{gesamt} = S_{Bestand} + \text{Zuwachs pro Jahr} \cdot \text{Jahre}

Ist nur die Kapazität des alten Systems und seine Auslastung bekannt, ergibt sich der Bestand als Kapazität mal Auslastung.

Geg.: altes SAN mit 20\,\mathrm{TiB} Nettokapazität, zu 80\,\% belegt; Zuwachs 800\,\mathrm{GiB} pro Jahr; Laufzeit 4 Jahre

Ges.: benötigte Nettokapazität in TiB

S_{Bestand} = 20\,\mathrm{TiB} \cdot 0{,}8 \cdot 1.024\,\mathrm{GiB/TiB} = 16.384\,\mathrm{GiB}

S_{gesamt} = 16.384\,\mathrm{GiB} + 800\,\frac{\mathrm{GiB}}{\mathrm{Jahr}} \cdot 4\,\mathrm{Jahre} = 19.584\,\mathrm{GiB} = \frac{19.584\,\mathrm{GiB}}{1.024\,\mathrm{GiB/TiB}} = \underline{\underline{19{,}125\,\mathrm{TiB}}}

Wie viele Festplatten daraus werden, hängt vom RAID-Level ab (siehe Links). Umgekehrt fragen Aufgaben nach der Reichweite eines Speichers: Kapazität geteilt durch den jährlichen Bedarf, abgerundet auf ganze Jahre, denn im angefangenen Jahr ist der Speicher bereits voll. Beispiel: 10\,\mathrm{TiB} Archivspeicher, jährlich 2{,}4\,\mathrm{TiB} Dokumente, die um 40\,\% komprimiert werden: \frac{10}{2{,}4 \cdot 0{,}6} \approx 6{,}944, der Speicher reicht also 6 volle Jahre.

Ein Ringspeicher (Ringpuffer) überschreibt die ältesten Daten, sobald er voll ist, z. B. die Speicherkarte einer Kamera oder eines Fahrtenschreibers. Wie lange die Daten erhalten bleiben, ist die Kapazität geteilt durch die Datenmenge pro Tag, ebenfalls abgerundet: Eine Kamera mit 4\,\mathrm{Mbit/s}, die an 25\,\% des Tages aufzeichnet, erzeugt 4.000.000\,\mathrm{bit/s} \cdot 86.400\,\mathrm{s} \cdot 0{,}25 : 8 = 10{,}8\,\mathrm{GB} pro Tag; eine 32\,\mathrm{GB}-Karte hält damit \frac{32}{10{,}8} \approx 2{,}963, also 2 volle Tage vor.

Speicher sparen und Zuschläge einrechnen

Kompression

Bei der Kompression werden Daten so umcodiert, dass sie weniger Platz brauchen.

• Verlustfreie Kompression (z. B. ZIP, PNG, FLAC) stellt die Originaldaten exakt wieder her. Sie eignet sich für Texte, Programme, Rohdaten für eine KI-Auswertung und Archive.

• Verlustbehaftete Kompression (z. B. JPEG, MP3, H.264) lässt Details weg, die das Auge oder Ohr kaum bemerkt, und spart dadurch viel mehr Platz. Die Originaldaten lassen sich nicht wiederherstellen.

Aufgaben nennen den Effekt unterschiedlich – lies genau:

Deduplizierung

Bei der Deduplizierung speichert ein System gleiche Daten nur einmal und legt für jede weitere Kopie nur einen Verweis an. Das funktioniert auf Dateiebene (Single Instance Storage, z. B. bei einem E-Mail-Archiv, in dem derselbe Anhang in vielen Postfächern liegt) oder auf Blockebene (gleiche Datenblöcke in verschiedenen Dateien, z. B. bei vielen ähnlichen virtuellen Maschinen oder täglichen Vollsicherungen). Deduplizierung spart viel, wenn es viele Kopien gibt. Bei Daten, die nur einmal vorkommen oder bereits komprimiert bzw. verschlüsselt sind (Fotos, Videos), spart sie kaum etwas. Mehr zu Sicherungskonzepten findest Du in den Übungsaufgaben zu Backups.

Zuschläge: Overhead und Reserve

Zu den reinen Nutzdaten kommen in der Praxis weitere Daten hinzu:

• Protokoll-Overhead bei der Übertragung (Header von Ethernet, IP, TCP, VPN). Aufgaben geben ihn z. B. als „100 % Overhead“ (Datenmenge verdoppeln) oder als Nettodatenrate („70 % der Bandbreite stehen für Nutzdaten zur Verfügung“) an.

• Verwaltungsdaten im Speicher: Dateisystem, Index einer Datenbank, Metadaten (Datei-Header, Farbprofile). Oft heißt es in der Aufgabe ausdrücklich, dass der Header nicht berücksichtigt wird.

• Reserve für Wachstum (z. B. „zuzüglich 20 % Reserve“: mal 1,2).

Prozentualen Mehrbedarf berechnest Du immer bezogen auf den Ausgangswert:

p = \frac{S_{neu} - S_{alt}}{S_{alt}} \cdot 100\,\%

Beispiel: Ein Punkt mit drei 32-Bit-Koordinaten braucht 12 Byte. Kommt eine RGB-Farbe mit 3 Byte dazu, sind es 15 Byte, also \frac{3}{12} = 25\,\% mehr.

Dateigröße und belegter Speicher: die Clustergröße

Dateisysteme verwalten Speicher in Clustern (Zuordnungseinheiten), z. B. 4.096 Byte. Eine Datei belegt immer ganze Cluster: Eine Datei mit 10.000 Byte braucht \lceil 10.000 : 4.096 \rceil = 3 Cluster, belegt also 12.288 Byte. Deshalb zeigt der Explorer bei „Größe“ und „Größe auf Datenträger“ verschiedene Werte, und viele kleine Dateien (Logdateien, Miniaturbilder, Sensordatensätze) belegen deutlich mehr Platz, als ihre Summe vermuten lässt. Große Cluster beschleunigen das Lesen großer Dateien, verschwenden aber bei kleinen Dateien Platz.

Übertragungsdauer berechnen

Wie lange eine Datei zum Hochladen oder Sichern braucht, ergibt sich aus Datenmenge und Datenrate:

t = \frac{S}{r}

Die Datenmenge muss dazu in Bit vorliegen, die Datenrate in bit/s (dezimal!). Ist nur ein Teil der Bandbreite nutzbar, rechnest Du mit der Nettodatenrate.

Geg.: Datei mit S = 1\,\mathrm{GiB}, Upload-Datenrate r = 50\,\mathrm{Mbit/s}

Ges.: Übertragungsdauer t in Minuten und Sekunden

S = 1 \cdot 1.024^3\,\mathrm{Byte} \cdot 8\,\mathrm{bit/Byte} = 8.589.934.592\,\mathrm{bit}

t = \frac{8.589.934.592\,\mathrm{bit}}{50.000.000\,\mathrm{bit/s}} \approx 171{,}799\,\mathrm{s}

Aufgerundet auf volle Sekunden sind das 172 s, also \underline{\underline{2\,\mathrm{min}\ 52\,\mathrm{s}}}.

Typischer Fehler: Die Datenrate mit 1.024 umrechnen. „50 Mbit/s“ sind 50.000.000 bit/s, nicht 50 \cdot 1.024^2.

Overhead aus MTU und Headern

Auf der Leitung werden nicht nur Nutzdaten übertragen, sondern in jedem Paket auch Header. Bei Ethernet darf ein IP-Paket höchstens so groß sein wie die MTU (Maximum Transmission Unit), meist 1.500 Byte. Davon gehen IP-Header (20 Byte) und TCP-Header (20 Byte) ab, es bleiben 1.460 Byte Nutzdaten. Auf der Leitung kommen Ethernet-Header und Prüfsumme (18 Byte) hinzu, also 1.518 Byte je Frame. Nutzbar sind damit

\frac{1.460\,\mathrm{Byte}}{1.518\,\mathrm{Byte}} \approx 96{,}179\,\%

der Datenrate. Weitere Header (z. B. PPPoE bei DSL mit 8 Byte oder ein IPsec-VPN mit rund 40 Byte und mehr) verkleinern den Nutzanteil weiter. Die Übertragungsdauer berechnest Du dann mit der Nettodatenrate: 1 TiB über 1 Gbit/s braucht \frac{1.024^4 \cdot 8\,\mathrm{bit}}{10^9\,\mathrm{bit/s} \cdot 0{,}96179} \approx 9.146\,\mathrm{s}, also gut 2 h 32 min. Manche Aufgaben geben den Overhead pauschal an (z. B. „35 % Overhead“: Datenmenge mal 1,35) oder nennen den nutzbaren Anteil direkt („30 % der Datenrate stehen zur Verfügung“). Bei sehr kleinen Dateien kommt die Latenz (Laufzeit eines Pakets, z. B. 20 ms) hinzu; bei großen Datenmengen fällt sie kaum ins Gewicht.

Wie viele Geräte passen in die Bandbreite?

Darf ein Dienst nur einen Teil der Bandbreite nutzen, teilst Du das Budget durch die Datenrate je Gerät und rundest ab: Von einem Upload mit 40 Mbit/s dürfen 5 % (2 Mbit/s) für Überwachungsdaten genutzt werden; jedes Gerät sendet 16 kbit/s. Es passen \frac{2.000.000\,\mathrm{bit/s}}{16.000\,\mathrm{bit/s}} = 125 Geräte.

Runden und Kosten

Aufgaben schreiben die Rundung meist vor („auf zwei Nachkommastellen“, „auf volle MiB aufrunden“, „auf ganze GiB“). Rechne mit ungerundeten Zwischenwerten weiter und runde erst das Endergebnis. Ohne Vorgabe entscheidet der Sachzusammenhang:

• Aufrunden, wenn Platz reserviert, gekauft oder abgewartet werden muss: Speicherbedarf, Zahl benötigter Festplatten, angefangene Speicherblöcke, Übertragungsdauer.

• Abrunden, wenn gefragt ist, wie viel in einen vorhandenen Speicher passt: Ein Datenträger für 16,155 Sicherungen fasst nur 16 vollständige.

Viele Anbieter berechnen Speicher in Blöcken, z. B. „4,80 € je angefangene 50 GiB und Monat“. Dann bestimmst Du zuerst die Zahl der Blöcke durch Aufrunden und multiplizierst erst danach mit Preis und Laufzeit:

Geg.: Bedarf 115\,\mathrm{GiB}, Preis 4{,}80\,\text{€} je angefangene 50\,\mathrm{GiB} und Monat, Laufzeit 12 Monate

Ges.: Kosten pro Jahr

n = \left\lceil \frac{115\,\mathrm{GiB}}{50\,\mathrm{GiB}} \right\rceil = \lceil 2{,}3 \rceil = 3 \qquad K = 3 \cdot 4{,}80\,\text{€} \cdot 12 = \underline{\underline{172{,}800\,\text{€}}}

Typische Fehler im Überblick

Typische Fehler beim Berechnen von Datenmengen

Fehler	So geht es richtig
Bit und Byte verwechselt	Farbtiefe und Datenraten in Bit, Speicher in Byte: durch 8 teilen bzw. mal 8
Megapixel mit 2^{20} umgerechnet	1 MP = 1.000.000 Pixel
Datenrate mit 1.024 umgerechnet	kbit/s, Mbit/s, Gbit/s sind dezimal
MB und MiB vermischt	Präfix der Aufgabe beachten; nur für Binärpräfixe durch 1.024 teilen
Bei GiB nur einmal durch 1.024 geteilt	Byte → GiB: dreimal durch 1.024 (bzw. durch 1.024^3)
Zwischenergebnisse gerundet	ungerundet weiterrechnen, nur das Endergebnis runden
Faktor vergessen (Kameras, Kanäle, Tage)	Einheiten der Faktoren mitschreiben
„um 30 %“ und „auf 30 %“ verwechselt	um 30 % weniger: mal 0,7; auf 30 %: mal 0,3
angefangene Blöcke abgerundet	Blöcke, Platten und Wartezeiten aufrunden
Altbestand mit der ganzen Kapazität statt mit dem belegten Anteil gerechnet	Kapazität mal Auslastung
Reichweite oder Ringspeicher-Dauer aufgerundet	nur vollständige Jahre bzw. Tage zählen: abrunden
Overhead bei der Übertragung vergessen	Nutzanteil aus MTU und Headern oder Overhead-Angabe einrechnen

Leitfragen

1. Was ist der Unterschied zwischen 1 GB und 1 GiB, und welche Präfixe verwenden Festplattenhersteller, Netzwerkdatenraten und Arbeitsspeicher? Antwort

1 GB ist dezimal 10^9 Byte, 1 GiB binär 2^{30} = 1.073.741.824 Byte. Festplattenhersteller geben Kapazitäten dezimal an, Netzwerkdatenraten sind immer dezimal (1 Mbit/s = 1.000.000 bit/s), und Arbeitsspeicher wird binär gebaut (ein „16-GB“-Modul hat 16 GiB); siehe Abschnitt „Kilo oder Kibi? Dezimal- und Binärpräfixe“.

2. Warum zeigt Windows eine neue 2-TB-Festplatte mit weniger als 2 TB an, und wie viel ist es genau? Antwort

Der Hersteller rechnet dezimal (2 \cdot 10^{12} Byte), Windows rechnet binär, schreibt aber „TB“. Genau sind es 2 \cdot 10^{12}\,\mathrm{Byte} : 1.024^4 \approx 1{,}819\,\mathrm{TiB} – es fehlt also nichts, es ist nur eine andere Einheit; siehe Abschnitt „Kilo oder Kibi? Dezimal- und Binärpräfixe“.

3. Wie berechnest Du den Speicherbedarf eines unkomprimierten Fotos, wenn Pixelzahl oder Maße und Auflösung sowie die Farbtiefe gegeben sind, und wie viele Farben kann es darstellen? Antwort

Du rechnest S = B \cdot H \cdot F (Pixelzahl mal Farbtiefe in bit/Pixel, 1 MP = 1.000.000 Pixel), teilst durch 8 für Byte und erst am Ende durch die Präfixfaktoren. Bei Maßen und Auflösung ermittelst Du die Pixel je Kante mit B = \frac{b}{2{,}54\,\mathrm{cm/inch}} \cdot A. Die Zahl der darstellbaren Farben ist 2^F, bei 24 Bit also 16.777.216; siehe Abschnitt „Rastergrafiken: Pixel mal Farbtiefe“ und Abschnitt „Bildgröße aus Maßen und Auflösung“.

4. Wie viele Byte braucht ein Zeichen in ASCII, UTF-8 und UTF-16, und wie viel Platz braucht eine Hexadezimalziffer? Antwort

ASCII nutzt 7 Bit und wird in 1 Byte gespeichert, UTF-8 braucht 1 bis 4 Byte (ASCII-Zeichen 1, Umlaute 2, Emojis 4 Byte), UTF-16 2 oder 4 Byte (meist 2). Eine Hexadezimalziffer braucht nur 4 Bit, also ein halbes Byte; siehe Abschnitt „Zeichencodierungen“.

5. Wie berechnest Du den Speicherbedarf einer Videoaufzeichnung aus Datenrate und Dauer? Antwort

Du multiplizierst die Datenrate in bit/s (dezimal, z. B. 6 Mbit/s = 6.000.000 bit/s) mit der Dauer in Sekunden: S = r \cdot t. Danach teilst Du durch 8 für Byte und rechnest erst am Ende in die gewünschte Einheit um; eine Stunde mit 6 Mbit/s ergibt etwa 2,515 GiB. Läuft die Aufzeichnung nur zeitweise, multiplizierst Du mit dem Anteil; siehe Abschnitt „Audio und Video: Datenrate mal Dauer“.

6. Wie rechnest Du Kompression, Overhead und Reserve ein, und wann hilft Deduplizierung? Antwort

Lies die Formulierung genau: „um 30 % verringern“ heißt mal 0,7, „auf 30 %“ mal 0,3, „Faktor 10“ geteilt durch 10. Overhead und Reserve rechnest Du als Zuschlag auf den Ausgangswert ein (z. B. 20 % Reserve: mal 1,2; 100 % Overhead: verdoppeln). Deduplizierung hilft, wenn es viele gleiche Daten gibt (gleiche Anhänge, ähnliche VMs, tägliche Vollsicherungen), kaum dagegen bei einmaligen oder bereits komprimierten bzw. verschlüsselten Daten; siehe Abschnitt „Kompression“, Abschnitt „Deduplizierung“ und Abschnitt „Zuschläge: Overhead und Reserve“.

7. Wie lange dauert die Übertragung einer Datei, und warum muss die Datenmenge dafür in Bit vorliegen? Antwort

Die Dauer ergibt sich aus t = \frac{S}{r}. Weil Datenraten in bit/s angegeben sind, muss auch die Datenmenge in Bit vorliegen, sonst liegst Du um den Faktor 8 daneben; die Datenrate selbst rechnest Du dezimal, nicht mit 1.024. Beispiel: 1 GiB bei 50 Mbit/s dauert etwa 172 s, also 2 min 52 s; siehe Abschnitt „Übertragungsdauer berechnen“.

8. Wann rundest Du auf, wann ab, und wie berechnest Du Kosten für angefangene Speicherblöcke? Antwort

Aufgerundet wird, wenn Platz reserviert, gekauft oder abgewartet werden muss (Speicherbedarf, Plattenzahl, angefangene Blöcke, Übertragungsdauer), abgerundet, wenn gefragt ist, wie viel in einen vorhandenen Speicher passt. Bei Blockpreisen bestimmst Du zuerst die Zahl der Blöcke durch Aufrunden und multiplizierst dann mit Preis und Laufzeit, z. B. \lceil 115 : 50 \rceil = 3 Blöcke · 4,80 € · 12 Monate; siehe Abschnitt „Runden und Kosten“.

Links und weitere Informationen

• zum Üben: Übungsaufgaben zu Speicherbedarf und Datenmengen

• zum Weiterlesen: Übungsaufgaben zu RAID (Nettokapazität von Plattenverbünden) und Übungsaufgaben zu Backups

• zu Datentypen: SQL-DDL: Datentypen

• als Nachschlagewerk: Wikipedia: Binärpräfix und Wikipedia: Farbtiefe (Computergrafik)

• Norm: IEC 80000-13:2025 Quantities and units – Part 13: Information science and technology

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Speicherbedarf und Datenmengen berechnen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/speicherbedarf veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/it-systeme/hardware-speicher. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]