Warum kann eine Integritätsprüfung des Repositorys erfolgreich sein, obwohl eine Datei weiterhin nicht wiederhergestellt werden kann?

Eine Repository-Prüfung kann erfolgreich sein, während die Wiederherstellung einer einzelnen Datei fehlschlägt, wenn die Prüfung Metadaten oder Stichprobendaten validiert und nicht genau diesen Wiederherstellungspfad.

Die Backup-Verifizierung ist kein einheitlicher Vorgang. Einige Prüfungen bestätigen die Repository-Struktur, Indizes, Manifeste und referenzierten Chunks, ohne jedes gespeicherte Byte zu lesen. Andere prüfen nur Stichproben, überspringen Dateien, die nie erfasst wurden, oder sagen nichts über Namen, Berechtigungen, ACLs, Labels, freien Speicherplatz und Anwendungssperren des Zielfilesystems aus. Betrachten Sie die fehlgeschlagene Datei als Pfad von der Snapshot-Auswahl über die gespeicherten Objekte bis zur Erstellung am Zielort.

Ermitteln Sie genau, was die erfolgreiche Prüfung verifiziert hat

Speichern Sie den Prüfungsbefehl, die Optionen, die Version des Backup-Tools, das Repository-Backend, die Snapshot-ID und das abschließende Protokoll. Ermitteln Sie, ob die Prüfung die Repository-Struktur, Archivmetadaten, referenzierte Chunks, gespeicherte Daten oder eine tatsächliche Extraktion überprüft hat.

Borg weist darauf hin, dass die standardmäßige Archivprüfung standardmäßig Metadaten, aber keine Dateidaten liest, sofern die Datenverifizierung nicht ausdrücklich angefordert wird.

Ein grünes Ergebnis kann daher lediglich beweisen, dass die Referenzen intern konsistent sind, während einige Nutzdaten-Chunks ungelesen bleiben. Bezeichnen Sie das Repository erst dann als vollständig wiederherstellbar, wenn repräsentative Dateien extrahiert wurden.

Ermitteln Sie, ob die gespeicherten Daten der Datei tatsächlich gelesen wurden

Suchen Sie die Datei im vorgesehenen Snapshot und ermitteln Sie die Packs, Chunks oder Objekte, die zu ihrer Rekonstruktion erforderlich sind. Vergleichen Sie die fehlgeschlagene Wiederherstellung mit dem Umfang der Datenprüfung des Repositorys.

Restic dokumentiert Prüfungen mit „read-data“ und „read-data-subset“ und zeigt damit, dass sich eine routinemäßige Strukturprüfung und das vollständige Lesen der Nutzdaten auf unterschiedlichen Verifizierungsstufen befinden.

Wenn nur eine Teilmenge gelesen wurde, kann die fehlgeschlagene Datei von einem nicht geprüften Pack abhängen. Führen Sie eine unterstützte gezielte oder vollständige Datenprüfung durch, bevor Sie eine Reparatur versuchen.

Bestätigen Sie, dass die Datei in diesem Snapshot enthalten war

Listen Sie den exakten relativen Pfad im ausgewählten Snapshot auf. Prüfen Sie Filter, Ausschlüsse, Warnungen zu nicht lesbaren Quelldateien, Regeln für symbolische Links, Mount-Grenzen und ob die Wiederherstellungsoberfläche eine andere Version ausgewählt hat.

Kopia weist darauf hin, dass Ignorierregeln übereinstimmende Pfade ausschließen. Daher kann die Repository-Konsistenzprüfung erfolgreich sein, obwohl die gewünschte Datei nie erfasst wurde.

Ein Platzhalterpfad oder ein übergeordneter Verzeichniseintrag beweist nicht, dass die Nutzdaten der Datei vorhanden sind. Vergleichen Sie das Snapshot-Inventar, die Größe, den Hash und den Zeitstempel mit dem erwarteten Quelldatensatz.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prüfen Sie Einschränkungen für Dateinamen und Pfade am Zielort

Stellen Sie dieselbe Datei an einem kurzen, leeren lokalen Pfad mit einem einfachen Namen wieder her. Vergleichen Sie ungültige Zeichen, reservierte Namen, Konflikte durch Groß- und Kleinschreibung, nachgestellte Leerzeichen, die Pfadlänge und die Unicode-Normalisierung.

Die Hinweise von Microsoft zur Dateibenennung dokumentieren Beschränkungen für Windows-Dateinamen und -Pfade, durch die die Wiederherstellung eines einzelnen Pfads abgelehnt werden kann, während das Repository selbst intakt bleibt.

Wenn die Datei an einem temporären kurzen Pfad wiederhergestellt wird, sind die gespeicherten Inhalte verfügbar. Korrigieren Sie das Layout am Zielort oder die Umbenennungszuordnung, statt das Repository zu reparieren.

Überprüfen Sie die Wiederherstellung von ACLs, erweiterten Attributen und Eigentümern

Wiederholen Sie die Wiederherstellung mit deaktivierter Beibehaltung von Metadaten ausschließlich in einem entbehrlichen Ziel und vergleichen Sie sie mit der normalen metadatenbewussten Wiederherstellung. Protokollieren Sie, welches Attribut zuerst fehlschlägt.

GNU tar dokumentiert die getrennte Wiederherstellung von ACLs und erweiterten Attributen. Das verdeutlicht, warum Dateidaten lesbar sein können, während die Anwendung von Metadaten fehlschlägt.

Akzeptieren Sie eine Wiederherstellung ohne Metadaten nicht als produktive Lösung, wenn Anwendungen auf ACLs, Eigentümer, Sparse-Bereiche oder erweiterte Attribute angewiesen sind. Verwenden Sie sie nur, um die fehlschlagende Ebene zu ermitteln.

Prüfen Sie Sicherheitslabels und Richtlinien am Zielort

Überprüfen Sie SELinux-Labels, Virenschutz- oder Endpoint-Schutz, Ransomware-Schutzmechanismen, unveränderliche Flags, Freigabeberechtigungen und Anwendungssperren am Wiederherstellungsziel.

Red Hat dokumentiert die Wiederherstellung standardmäßiger Sicherheitskontexte, wenn Dateien mit fehlenden oder ungeeigneten Labels eintreffen.

Eine Datei, die extrahiert werden kann, sich aber nicht öffnen lässt, kann an einer Richtlinie am Zielort und nicht am Repository scheitern. Testen Sie mit demselben Benutzer und derselben Anwendung, die die wiederhergestellte Datei benötigt.

Führen Sie vor jeder Reparatur eine isolierte Wiederherstellung durch

Stellen Sie die fehlgeschlagene Datei, ihre übergeordneten Metadaten und mehrere benachbarte Dateien in einem leeren Dataset oder temporären Verzeichnis wieder her. Speichern Sie Hashes, Protokolle und den Repository-Zustand, bevor Sie Reparaturbefehle ausführen.

Der ZimaSpace-Leitfaden zur Verifizierung von Prüfsummen und Metadaten erläutert die damit verbundene Unterscheidung zwischen der Integrität gespeicherter Inhalte und einer nutzbaren Wiederherstellung für Anwendungen.

Das Problem ist gelöst, wenn die ausgewählte Datei aus dem vorgesehenen Snapshot wiederhergestellt wird, ihrem erwarteten Inhalt entspricht, die erforderlichen Metadaten erhält und über den produktiven Anwendungspfad geöffnet werden kann.

Häufig gestellte Fragen

Beweist eine erfolgreiche Repository-Prüfung, dass jede Datei wiederhergestellt werden kann?

Nein. Das hängt davon ab, ob die Prüfung alle gespeicherten Daten gelesen hat und ob der Zielort jeden Pfad einschließlich seiner Metadaten wiederherstellen kann.

Sollte ich nach einem einzigen Fehler bei der Wiederherstellung sofort eine Reparatur ausführen?

Nein. Testen Sie zuerst einen anderen Zielort, bestätigen Sie, dass die Datei im Snapshot vorhanden ist, und führen Sie eine unterstützte Datenprüfung durch. Eine Reparatur kann beschädigte Metadaten oder Objekte entfernen.

Ist eine erfolgreiche Testwiederherstellung aussagekräftiger als ein Verifizierungsbericht?

Ja, für den getesteten Wiederherstellungspfad. Sie bestätigt für dieses konkrete Beispiel die Auswahl, Entschlüsselung, das Lesen der Nutzdaten, die Erstellung am Zielort und die Verarbeitung der Metadaten.