Warum sehen deduplizierte Backups kleiner aus als ihr Wiederherstellungsumfang?
Deduplizierte Backups wirken kleiner, weil wiederholte Blöcke nur einmal gespeichert werden, während eine Wiederherstellung jede logische Datei und jede unabhängige Kopie rekonstruiert.
Zehn Images virtueller Maschinen können in einem Backup-Repository mehrere Gigabyte identischer Betriebssystemblöcke gemeinsam nutzen. Bei der Wiederherstellung auf einem gewöhnlichen Dateisystem werden zehn Adressräume neu erstellt, sofern das Ziel nicht ebenfalls kompatible gemeinsame Blocknutzung, Sparse-Dateien oder Komprimierung unterstützt. Repository-Größe und Wiederherstellungskapazität beschreiben daher unterschiedliche Darstellungen mit unterschiedlichen Belegungsregeln und unterschiedlichen Zusatzkosten auf dem ausgewählten Zieldateisystem.
Deduplizierung speichert eine Identität einmal und referenziert sie mehrfach
Backup-Software teilt Daten in Blöcke auf, erstellt Fingerabdrücke und speichert nur Blöcke, die noch nicht vorhanden sind. Manifeste halten fest, welche Blöcke zu jeder Datei und jedem Wiederherstellungspunkt gehören. Das Repository kann viele logische Kopien mit einer physischen Nutzlast und mehreren Referenzen darstellen.
Eine Übersicht über die Backup-Deduplizierung erklärt, wie redundante Kopien aus dem Backup-Speicher entfernt werden. Die Einsparung hängt von wiederholten Inhalten ab, nicht einfach von der Anzahl der Dateien.
Die Wiederherstellung kehrt diese Zuordnung um. Jede Datei erhält ihre geordneten Bytes am gewünschten Ziel. Wenn das Ziel keine gemeinsame Blocknutzung unterstützt, belegen wiederholte Blöcke erneut separate Extents. Die Datenreduzierung war eine Eigenschaft des Repositorys und keine Garantie dafür, dass jedes Wiederherstellungsziel gleichermaßen kompakt bleibt.
Komprimierung, Sparse-Dateien und Metadaten vergrößern den Unterschied
Komprimierung reduziert die gespeicherten Bytes abhängig von der Entropie des Inhalts. Sparse-Dateien lassen lange Bereiche aus Nullen weg, doch eine Wiederherstellungsoption kann diese Lücken materialisieren. Belegungseinheiten, Prüfsummen, erweiterte Attribute und Dateisystemmetadaten verursachen zusätzlichen Aufwand am Ziel, den Repository-Zusammenfassungen möglicherweise nicht berücksichtigen.
Eine Erläuterung des Speichers unterscheidet Sparse-Dateien von der belegten Größe: Eine Datei kann eine große logische Länge melden und dennoch weniger physische Blöcke belegen. Wiederherstellungstools müssen Lücken ausdrücklich beibehalten, um diese Einsparung zu erhalten.
Das Gegenteil ist ebenfalls möglich. Ein komprimiertes Ziel oder ein Copy-on-Write-Klon kann wiederhergestellte Daten kleiner als ihre logische Größe halten. Es gibt keinen universellen Multiplikator für die Umrechnung von Repository-Bytes in wiederhergestellte Bytes, da Darstellung, Aufbewahrungsumfang und Zieldateisystem allesamt eine Rolle spielen.
Wo Deduplizierung nicht die Hauptursache ist
Die Erklärung greift nicht, wenn eine einzelne nicht duplizierte Datei unerwartet größer wird. Verschlüsselung, bereits komprimierte Medien, Datenbankexportformate oder eine Änderung der Thin-Provisioning-Konfiguration können stattdessen ausschlaggebend sein. Ein Backup-Katalog zeigt möglicherweise auch nur eindeutige Daten für einen Bereich an, während die Wiederherstellung mehrere ausgewählte Snapshots umfasst.
Eine technische Diskussion über das Deduplizierungsverhältnis betont, dass logische und physische Größen bei der Angabe von Deduplizierungsverhältnissen unterschieden werden müssen. Verhältnisse ohne Angabe des Geltungsbereichs können die Kapazitätsplanung irreführen.
Der Mechanismus greift ebenfalls nicht mehr, wenn sich die Hashes oder die Anzahl der wiederhergestellten Dateien von der ausgewählten Sicherung unterscheiden. Dann liegt das Problem bei der Auswahl oder Integrität und nicht bei einer erwarteten Vergrößerung. Kleinere Backup-Bytes rechtfertigen keine zu knapp bemessene temporäre Speicherkapazität vor der Überprüfung.
Messen Sie eine Wiederherstellung, statt dem Verhältnis zu vertrauen
Wählen Sie einen repräsentativen Wiederherstellungssatz aus und erfassen Sie die logischen Quellbytes, die eindeutigen Repository-Bytes, die komprimierten Bytes, Sparse-Extents, die Dateianzahl und die Belegungseinheit des Ziels. Stellen Sie die Daten in einem isolierten Ziel mit aktivierter und deaktivierter Beibehaltung von Sparse-Dateien wieder her, überprüfen Sie anschließend die Hashes und den belegten Speicherplatz.
Verwenden Sie einen Speicherplan für gemeinsam genutzten Modellspeicher, damit das Testziel aktive Dienste nicht beeinträchtigen kann. Halten Sie die Aufbewahrungseinstellungen des Repositorys und die Komprimierungseinstellungen des Ziels bei den Vergleichen konstant.
Bemessen Sie die Wiederherstellung anhand des größeren Werts aus der gemessenen belegten Ausgabe und der logischen Dataset-Größe zuzüglich angemessener Arbeitsreserve, nicht anhand der deduplizierten Repository-Zahl. Wenn die Beibehaltung von Sparse-Dateien das Ergebnis verändert, dokumentieren Sie diese Abhängigkeit. Wenn sich Dateiidentität oder Dateianzahl ändert, halten Sie inne und beheben Sie zunächst die Korrektheit der Wiederherstellung, bevor Sie die Kapazität optimieren.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Warum fühlt sich die Wärme lokaler KI in einem offenen Regal anders an als in einem geschlossenen Schrank?
Verfolgen Sie die Wärmeentwicklung, den Luftaustausch und die Rückführung der Luft bei offenen und geschlossenen Aufstellungen und messen Sie anschließend die Variablen, die sie...
Warum wirkt ein Heimserver nachts selbst bei gleicher Lüftergeschwindigkeit leiser?
Verstehen Sie, warum eine unveränderte Lüftergeschwindigkeit keine unveränderte wahrgenommene Lautstärke garantiert und wie sich Maskierung, Raumbedingungen und tatsächliche akustische Veränderungen voneinander unterscheiden lassen.
Warum sieht die Speicherplatznutzung in der NAS-Benutzeroberfläche anders aus als im Dateisystem?
Erfahren Sie, was jede Speicherangabe misst, warum die gültigen Gesamtsummen voneinander abweichen und wie Sie die Kapazität abgleichen, ohne Daten aufgrund der falschen Anzeige...
