Reicht ein 2-TB-Ziel? Backup-Kapazität mit TB, TiB, Änderungsrate und Aufbewahrung planen

Ein mit 2 TB beschriftetes Ziel ist nicht so groß wie 2 TiB. Der Unterschied fällt leicht unter den Tisch, wenn Betriebssystem, Backup-Software, Cloud-Abrechnung und Datenträgerbeschreibung nicht dieselben Einheiten verwenden. Eine zweite Fehlerquelle ist die Planung allein mit dem heutigen Datenbestand: Änderungen, die während der Aufbewahrungszeit in Wiederherstellungspunkten verbleiben, benötigen ebenfalls Platz.

Dieser Leitfaden prüft ein hypothetisches Szenario. Die Quelle belegt derzeit 1,6 TiB, pro Tag bleiben 25 GiB eindeutiger Änderungen erhalten, die Aufbewahrungszeit beträgt 14 Tage und für die Planung wird bewusst ein Puffer von 15% gewählt. Das Modell soll keine bestimmte Backup-Engine nachbilden. Es liefert eine nachvollziehbare erste Kapazitätsprüfung, bevor konkrete Produkte oder Tarife verglichen werden.

Alle Eingaben in ein Einheitensystem überführen

Dezimale SI-Präfixe beruhen auf Potenzen von 1.000, binäre IEC-Präfixe auf Potenzen von 1.024. NIST definiert 1 GB als 1.000.000.000 Byte und 1 GiB als 1.073.741.824 Byte. Die aktuelle Norm IEC 80000-13:2025 beschreibt Namen, Symbole, Definitionen und Umrechnungsfaktoren für die Informationstechnik einschließlich binärer Präfixe. Belegt ist dies in der NIST-Übersicht zu binären Präfixen und in der Übersicht zu IEC 80000-13:2025.

Die Symbole sind nicht austauschbar. Ein TiB entspricht ungefähr 1,0995 TB, ein TB ungefähr 0,9095 TiB. Für die Rechnung sollte eine gemeinsame Arbeitseinheit wie GiB oder Byte festgelegt und an jeder Eingabe notiert werden. Der Calquio-Datenspeicher-Konverter behandelt GB, TB, GiB und TiB als getrennte Einheiten. So gelangt kein mehrdeutiger Wert wie „Gigabyte“ unbemerkt in die Rechnung.

Annahmen vor der Schätzung festhalten

Die maximale Größe des Quelldatenträgers reicht als Eingabe nicht aus. Für eine erste Schätzung werden mindestens folgende Angaben benötigt:

• Tatsächlich belegte Quelldaten, nicht nur die maximale Datenträgergröße.
• Pro Tag aufbewahrte Änderungsdaten, also der eindeutige zusätzliche Umfang unter Berücksichtigung bekannter Produkteigenschaften.
• Aufbewahrungszeit, während der diese Änderungen in Wiederherstellungspunkten vertreten bleiben.
• Planungspuffer, der für Messunsicherheit und absehbares Wachstum bewusst gewählt und dokumentiert wird.
• Einheit und nutzbare Kapazität des Ziels, denn die Beschriftung muss nicht dem für Backups verfügbaren Platz entsprechen.

Auch reale Backup-Kalkulatoren arbeiten mit solchen Größen. Microsoft verlangt für eine Azure-Backup-Schätzung unter anderem belegten Speicher, erwartete Datenänderungsrate und Aufbewahrungsrichtlinie und unterscheidet verschiedene Sicherungsarten. Die Quelle begründet damit die Auswahl der Eingaben, nicht die genaue vereinfachte Formel dieses Artikels. Siehe die deutschsprachige Microsoft-Learn-Dokumentation, zuletzt aktualisiert am 19. September 2025.

Im Beispiel bedeuten „25 GiB pro Tag“, dass 25 GiB geänderter Daten während des gesamten 14-Tage-Fensters zusätzlichen Backup-Speicher belegen. Gemeint sind weder sämtliche Schreibvorgänge noch der Netzwerkverkehr oder eine allgemeingültige Änderungsrate. Auch die 15% sind keine Branchenregel, sondern eine ausdrücklich gewählte Annahme.

Das 14-Tage-Beispiel nachrechnen

Als gemeinsame Einheit dient GiB.

1. Aktuelle Belegung umrechnen: 1,6 TiB × 1024 = 1638,4 GiB.
2. Aufbewahrte Änderungen schätzen: 25 GiB/Tag × 14 Tage = 350 GiB.
3. Bestand und Änderungen addieren: 1638,4 + 350 = 1988,4 GiB.
4. Gewählten Puffer berechnen: 1988,4 × 15% = 298,26 GiB.
5. Puffer hinzufügen: 1988,4 + 298,26 = 2286,66 GiB.

Die transparente Formel lautet:

benötigte Kapazität = (belegte Quelldaten + tägliche aufbewahrte Änderung × Aufbewahrungstage) × (1 + Puffer)

Mit den gewählten Werten ergibt sich:

(1638,4 GiB + 25 GiB × 14) × 1,15 = 2286,66 GiB

Umgerechnet sind das 2,2331 TiB oder 2,4553 TB. Die Zwischenschritte zeigen, wo eine andere Aufbewahrungszeit, eine gemessene Änderungsrate oder ein anderer Puffer eingesetzt werden muss. Zugleich verhindern sie den unzulässigen Direktvergleich von 2,2331 TiB mit einer dezimalen 2-TB-Angabe.

2 TB und 3 TB auf derselben Basis prüfen

Die nominalen dezimalen Zielgrößen werden zuerst in GiB umgerechnet und dann mit den erforderlichen 2286,66 GiB verglichen.

Das 2-TB-Ziel scheitert schon bevor Dateisystem, Backup-Kataloge, Metadaten, reservierter Speicher oder temporärer Arbeitsbereich berücksichtigt werden. Ein nominales 3-TB-Ziel erfüllt die vereinfachte Anforderung. Das ist jedoch keine Kaufgarantie: Nach Formatierung und Reserven müssen noch mindestens die erforderlichen Byte tatsächlich nutzbar sein.

Bei Cloud-Diensten ist außerdem zu klären, was bei Abrechnung und Kontingenten als „gespeicherte Daten“ zählt. Je nach System können logische Daten, komprimierte Daten, geänderte Blöcke, Snapshots, Replikate oder Kombinationen davon maßgeblich sein. Die Einheitenumrechnung ist exakt; das Speichermodell eines Produkts lässt sich nicht verallgemeinern.

Den entscheidenden Parameter mit einer Sensitivitätsprüfung finden

Bleiben Ausgangsbestand, 14 Tage Aufbewahrung und 15% Puffer gleich, zeigt sich der Einfluss der täglichen Änderungen:

Diese Zeilen sind eine Sensitivitätsanalyse, keine drei Prognosen. Statt den Wert zu wählen, der zum gewünschten Ziel passt, sollte die Änderungsmenge an normalen Tagen und bekannten Spitzen gemessen werden. Wird das ursprüngliche Szenario mit 25 GiB pro Tag von 14 auf 30 Tage verlängert, steigt die vereinfachte Anforderung auf 2746,66 GiB beziehungsweise rund 2,9492 TB – noch vor produktspezifischem Aufwand. Allein die längere Aufbewahrung kann den scheinbaren Freiraum aufbrauchen.

Grenzen der Rechnung vor der Entscheidung prüfen

Das Modell behandelt jede tägliche Änderung von 25 GiB so, als belege sie bis zum Ende der Aufbewahrung zusätzlichen Platz. Es kann ein System mit wirksamer Deduplizierung oder Komprimierung überschätzen. Es kann ein System unterschätzen, das regelmäßig Vollkopien erzeugt, Metadaten und Arbeitsbereich benötigt, Replikate hält oder abgelaufene Wiederherstellungspunkte verzögert bereinigt. Verschlüsselte oder bereits komprimierte Dateien können ebenfalls anders reagieren als gewöhnliche Dokumente.

Vor der Festlegung auf ein Ziel sind deshalb fünf Schritte sinnvoll:

1. Definitionen des Produkts für Voll-, inkrementelle und differentielle Sicherungen, Snapshots und aufbewahrten Speicher lesen.
2. Tatsächlich belegte Quelldaten und Änderungen mit eindeutig benannten Einheiten messen.
3. Mit dem erforderlichen Wiederherstellungsfenster und einem dokumentierten Puffer neu rechnen.
4. Das Ergebnis mit nutzbarer Kapazität statt nur mit der Produktbeschriftung vergleichen.
5. Eine repräsentative Sicherung und Wiederherstellung testen und den beobachteten Verbrauch mit der Schätzung abgleichen.

Die Kapazitätsrechnung beantwortet, ob ein Ziel voraussichtlich groß genug ist. Sie beweist nicht, dass ein Backup vollständig, getrennt, wiederherstellbar oder sicher ist. Dafür bleiben Konfigurationsprüfung und Wiederherstellungstest im gewählten System erforderlich.

Quellen

• NIST — Präfixe für binäre Vielfache (Einheitendefinitionen; abgerufen am 3. August 2026)
• IEC — IEC 80000-13:2025, Größen und Einheiten: Informationswissenschaft und -technik (veröffentlicht am 11. Februar 2025; abgerufen am 3. August 2026)
• Microsoft Learn — Schätzen und Verstehen der Azure-Backup-Preise (aktualisiert am 19. September 2025; abgerufen am 3. August 2026)