Warum belegt eine virtuelle Sparse-Festplatte nach der Wiederherstellung eines Backups ihre vollständige Größe?

Eine virtuelle Festplatte mit dynamischer Speicherzuweisung wird vollständig belegt, wenn die Wiederherstellung Bereiche mit Nullen als echte Blöcke schreibt oder das Image in einem Format mit fester Größe neu erstellt.

Sparse-VHD-, VHDX-, Raw- und QCOW2-Images können eine große logische Kapazität melden, während sie nur für zugewiesene Bereiche Speicherplatz verbrauchen. Eine Sicherung kann Dateiinhalte perfekt bewahren und dennoch die Zuordnung von Lücken, nicht zugewiesenen Clustern, dem Verwerfungsstatus oder Metadaten für Thin Provisioning verlieren. Das wiederhergestellte Gastsystem kann normal booten, obwohl die Hostdatei nun ihre gesamte virtuelle Größe belegt. Prüfen Sie Format und Speicherzuweisung, bevor Sie die einzige wiederhergestellte Kopie komprimieren oder konvertieren.

Logische Größe mit tatsächlich zugewiesener Größe vergleichen

Notieren Sie das Image-Format, die virtuelle Größe, die scheinbare Dateigröße, die auf dem Host zugewiesenen Blöcke, das Zieldateisystem und ob das wiederhergestellte Image als Sparse-Image oder vorab zugewiesen markiert ist.

Microsoft erklärt, dass Sparse-Dateien für nicht zugewiesene Bereiche Nullen zurückgeben und dabei eine größere nominelle Dateigröße beibehalten. Daher müssen virtuelle Größe und physischer Speicherverbrauch getrennt gemessen werden.

Verwenden Sie ein Tool, das die Speicherzuweisung berücksichtigt, anstatt sich ausschließlich auf einen Dateibrowser zu verlassen. Wenn virtuelle und zugewiesene Größe nun übereinstimmen, wurden die Lücken bei der Wiederherstellung wahrscheinlich materialisiert oder es wurde ein Format mit fester Größe ausgewählt.

Feststellen, ob die Sicherung Sparse-Lücken bewahrt hat

Prüfen Sie die Optionen des Sicherungsauftrags für Datei- und Blockkopien, Archive, Komprimierung und Sparse-Dateien. Ermitteln Sie, ob nur zugewiesene Extents gespeichert wurden oder ob die gesamte logische Festplatte als zusammenhängender Bytestrom gelesen wurde.

GNU Coreutils dokumentiert, dass Kopierwerkzeuge Sparse-Lücken am Ziel neu erstellen müssen. Andernfalls können lange Folgen von Nullen als gewöhnliche zugewiesene Blöcke geschrieben werden.

Eine inhaltlich gültige Wiederherstellung beweist nicht, dass Metadaten zur Speicherzuweisung erhalten geblieben sind. Vergleichen Sie ein kleines Test-Image mit bekannten Lücken, das denselben Sicherungs- und Wiederherstellungspfad durchläuft.

Prüfen, ob die Image-Konvertierung die Sparse-Zuweisung deaktiviert hat

Untersuchen Sie jeden Konvertierungsschritt zwischen Sicherungsobjekt und wiederhergestelltem Image. Notieren Sie Eingabe- und Ausgabeformat, Option für die Vorabzuweisung, Sparse-Schwellenwert und ob eine Kopierauslagerung verwendet wurde.

QEMU erklärt, dass qemu-img Nullsektoren erkennen und auslassen kann, während ein Sparse-Schwellenwert von null oder ein nicht unterstützter Pfad für die Kopierauslagerung zu einem vollständig zugewiesenen Ziel führen kann.

Konvertieren Sie ein Image niemals erneut, während die virtuelle Maschine läuft. Arbeiten Sie mit einer geprüften Kopie und vergleichen Sie den Inhalt der virtuellen Festplatte, bevor Sie das wiederhergestellte Image ersetzen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Überprüfen, ob das Zieldateisystem Sparse-Dateien unterstützt

Prüfen Sie die Unterstützung für Sparse-Dateien auf dem NAS-Zieldateisystem und auf jedem dazwischengeschalteten Bereitstellungsdatenträger. Wenn eine Wiederherstellung zunächst auf ein inkompatibles Dateisystem geschrieben wird, können Lücken verloren gehen, bevor das Image den endgültigen Speicher erreicht.

Thin Provisioning hängt sowohl von den Bereitstellungseigenschaften des Speicherobjekts als auch von seiner logischen Größe ab. Ein Ziel kann große Dateien unterstützen und das Image dennoch als vollständig zugewiesenes Objekt wiederherstellen, wenn die Sicherungsanwendung die Lücken nicht neu erstellt.

Wenn das Bereitstellungs- oder Zieldateisystem keine Lücken bewahren kann, ist die Datei möglicherweise bereits vollständig zugewiesen, bevor sie den endgültigen VM-Datenspeicher erreicht. Testen Sie die Sparse-Unterstützung zunächst mit einem entbehrlichen Image.

Format mit fester Speicherzuweisung von freiem Speicher im Gast trennen

Ermitteln Sie, ob der wiederhergestellte Datenträger als vorab zugewiesener Raw-Datenträger, als Sparse-Raw-Datenträger, als fest zugewiesenes VHD, als dynamisches VHDX oder als QCOW2 vorliegt. Freier Speicher im Gast wird nicht automatisch zu einer Lücke auf dem Host.

Red Hat unterscheidet zwischen vorab zugewiesenen und Sparse-virtuellen Datenträgern: Vorab zugewiesene Datenträger reservieren sofort die vollständige Größe, während Sparse-Datenträger Speicherplatz zuweisen, sobald Daten geschrieben werden.

Wenn das Wiederherstellungsziel absichtlich eine feste Speicherzuweisung verwendet, ist die vollständige Belegung erwartungsgemäß und kein Hinweis auf eine Beschädigung. Entscheiden Sie, ob der Kompromiss zwischen Leistung und Kapazität eine Rückkonvertierung in ein Thin-Format rechtfertigt.

Mit einer unterstützten Offline-Methode durch Nullen belegten Speicherplatz freigeben

Fahren Sie die virtuelle Maschine herunter, bestätigen Sie das Vorhandensein einer separaten Sicherung und ermitteln Sie, ob gelöschte Blöcke im Gast mit Nullen überschrieben oder verworfen wurden. Freier Speicher im Gastdateisystem kann weiterhin alte Daten ungleich null enthalten.

Der virt-sparsify-Workflow von Red Hat wandelt erkannten freien Speicher in Sparse-Bereiche auf dem Host um und warnt davor, auf aktiven Festplatten-Images zu arbeiten.

Führen Sie die Komprimierung nur auf einem duplizierten Image durch, überprüfen Sie anschließend das Gastsystem und behalten Sie das ursprüngliche wiederhergestellte Image, bis die Tests auf Anwendungsebene erfolgreich abgeschlossen sind.

Verhalten bei Vorabzuweisung und dem Freigeben von Lücken prüfen

Prüfen Sie, ob die Wiederherstellungsanwendung das Ziel aus Gründen der Zuverlässigkeit oder Leistung vorab zugewiesen hat und ob das Ziel das spätere Freigeben von Bereichen unterstützt.

Die Linux-fallocate-Schnittstelle unterscheidet zwischen der Zuweisung echter Blöcke und dem Freigeben von Lücken. Das zeigt, warum das Schreiben von Nullen und das Freigeben von Speicherplatz nicht derselbe Vorgang sind.

Geben Sie nicht direkt Lücken in einem unbekannten Format für virtuelle Festplatten frei. Verwenden Sie den Hypervisor oder das Image-Dienstprogramm, das dessen Metadaten und Clusteraufteilung versteht.

Wiederhergestellten Datenträger vor dem Ersetzen überprüfen

Starten Sie die komprimierte Kopie isoliert, überprüfen Sie Dateisysteme, Anwendungen, Snapshots und den freien Speicher im Gast. Vergleichen Sie anschließend repräsentative Dateihashes und die gemeldete Struktur der virtuellen Festplatte.

Die Wiederherstellungs-Checkliste für Heimserver von ZimaSpace enthält die ergänzende Anforderung, die Wiederherstellung von Speicher und Anwendungen nachzuweisen, bevor die vorherige Kopie entfernt wird.

Das Problem ist behoben, wenn der wiederhergestellte Datenträger sein vorgesehenes Thin-Format beibehält, der auf dem Host belegte Speicherplatz den tatsächlichen Gastdaten entspricht und die virtuelle Maschine Boot-, Arbeitslast-, Sicherungs- und Wiederherstellungsprüfungen besteht. Behalten Sie das vollständig zugewiesene Image, wenn die Konvertierung Fehler erzeugt oder die Plattform eine feste Speicherzuweisung erfordert.