Integritäts-Workflow für eine selbst gehostete Fotobibliothek mit Originalen und abgeleiteten Dateien

Eine gesund aussehende Fototimeline ist kein Beweis dafür, dass die Originale, die Datenbank und die generierten Vorschauen vollständig intakt sind.

Eine selbst gehostete Galerie kann weiterhin zwischengespeicherte Vorschaubilder ausliefern, nachdem ein Original verschwunden ist, oder perfekte Originale behalten, während Worker keine neuen Ableitungen erzeugen. Trennen Sie erforderlichen Zustand von wiederherstellbarem Zustand, überprüfen Sie die Original-Bytes außerhalb der App, gleichen Sie Dateien mit Datenbankeinträgen ab und generieren Sie vor dem Testen einer isolierten Wiederherstellung nur ein einzelnes Canary neu. Stoppen Sie sofort, wenn sich Prüfsummen ändern, der Quellspeicher instabil wird oder ein Job in die Originale schreibt.

Erforderlichen und regenerierbaren Zustand definieren

Erfassen Sie Originale, hochgeladene Videos, Sidecar-Dateien, Datenbank, Konfiguration, Geheimnisse, Benutzerkonten, Alben, Bearbeitungen und Freigabeeinträge als erforderlichen Zustand. Führen Sie Vorschaubilder, transkodierte Videos, Gesichtseinbettungen und Suchindizes separat als Ableitungen auf, die nur dann regenerierbar sein können, wenn Originale und Anwendungszustand intakt bleiben.

Eine selbst gehostete Bereitstellung legt die Bibliothek häufig auf Speichermedien mit hoher Kapazität und die Datenbank oder den Arbeitspfad auf schnelleren Medien ab. Ein praktischer Immich-Speicherbericht beschreibt die Trennung von Bibliotheks- und Hot-Path-Speicher. Deshalb muss eine Integritätsprüfung jeden eingebundenen Pfad abdecken und nicht nur den Ordner, den Benutzer durchsuchen.

Notieren Sie die Anwendungsversion, das Container-Image, die Mount-Definitionen, den Status des Datenbankschemas, den freien Speicherplatz und den Status der Auftragswarteschlange. Stoppen Sie, wenn ein erforderlicher Pfad fehlt oder unerwartet schreibgeschützt ist; ein Regenerierungsjob sollte nicht beginnen, solange die maßgebliche Quelle unklar ist.

Original-Bytes unabhängig von der Galerie nachweisen

Erstellen Sie für die Originale ein vertrauenswürdiges Prüfsummenmanifest oder verwenden Sie ein vorhandenes und vergleichen Sie es im schreibgeschützten Modus mit dem aktuellen Verzeichnisbaum. Gleichen Sie die Dateianzahl, die Gesamtzahl der Bytes, nicht lesbare Dateien, unerwartete Objekte mit null Bytes und verwaiste Pfade ab. Öffnen Sie außerhalb der Galerie eine geschichtete Stichprobe mit JPEG, HEIC, RAW, Video, älteren Jahren und aktuellen Uploads.

Leiten Sie den Zustand der Originale nicht aus sichtbaren Vorschaubildern ab. Eine Galerie kann weiterhin zwischengespeicherte Ableitungen ausliefern, nachdem ein Original verloren gegangen ist, und ein intaktes Original kann verborgen bleiben, wenn die Vorschau-Pipeline ausfällt. Die Unterscheidung zwischen Originalen und regenerierbaren Ableitungen macht die direkte Dateiprüfung zum ersten Sicherheits-Gate.

Wenn sich Hashes ändern oder Lesevorgänge fehlschlagen, pausieren Sie Import, Bereinigung und die Regenerierung von Ableitungen. Stellen Sie den fehlerhaften Speicher wieder her oder erstellen Sie ein Abbild davon, bevor Sie Datenbankeinträge ändern. Die Phase ist bestanden, wenn die erforderlichen Originale lesbar sind und ungeklärte Unterschiede einen Verantwortlichen, einen Grund und eine Wiederherstellungsmaßnahme haben.

Einträge, Pfade und Ableitungsjobs abgleichen

Vergleichen Sie Datenbankeinträge von Assets in beide Richtungen mit den Dateisystempfaden: Einträge ohne Dateien und Dateien ohne Einträge. Prüfen Sie UID und GID, Bind-Mounts, Stammverzeichnisse externer Bibliotheken, die Groß-/Kleinschreibung und umbenannte Verzeichnisse, bevor Sie Assets als fehlend deklarieren. Bewahren Sie Listen verwaister Elemente auf, anstatt eine der beiden Seiten automatisch zu löschen.

Stichproben Sie anschließend Jobs für Vorschaubilder, Vorschauen, Transkodierung, Metadatenextraktion und maschinelles Lernen. Ein unabhängiger Fehlerbehebungsartikel zu intakten Originalen mit fehlgeschlagenen Ableitungen veranschaulicht, wie intakte Uploads neben grauen Kacheln bestehen können, wenn Speicher, Worker oder Ableitungspfade ausfallen.

Generieren Sie eine einzelne Canary-Ableitung erst neu, nachdem Original und Datenbankzeile übereinstimmen. Als bestanden gilt eine neue Vorschau mit dem erwarteten Besitzer, Pfad und der erwarteten Client-Antwort; ein Fehlschlag bleibt auf Worker-Logs, Decoder, Ausgabespeicher oder Warteschlangenstatus eingegrenzt. Starten Sie niemals eine vollständige Bibliotheksneuerstellung, bevor dieses Canary nach einem Neustart weiterhin korrekt ist.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Die vollständige Bibliothek in einem isolierten Ziel wiederherstellen

Stellen Sie Originale, Datenbank, Konfiguration, Geheimnisse und erforderliche Sidecar-Dateien in einer verworfenen Umgebung mit anderen Ports und Pfaden wieder her. Starten Sie die Abhängigkeiten in der richtigen Reihenfolge, überprüfen Sie Benutzer und Alben und erlauben Sie anschließend nur die für den Beispieldatensatz erforderlichen Ableitungsjobs. Verweisen Sie die Testinstanz nicht auf beschreibbaren Produktionsspeicher.

Testen Sie die Anmeldung, Timeline, Suche, Albumzugehörigkeit, den Download der Original-Bytes, eine Bearbeitung, eine Freigabe und die Wiedergabe eines Videos. Vergleichen Sie die Hashes heruntergeladener Dateien mit dem Manifest und prüfen Sie, dass ein zweiter Neustart keine Pfadzuordnungen verliert und den erforderlichen Zustand nicht unter dem falschen Besitzer neu erstellt.

Erklären Sie die Integrität erst dann als nachgewiesen, wenn die aktive Bibliothek und die isolierte Wiederherstellung beim erforderlichen Zustand übereinstimmen und die Canary-Ableitungen aus den Originalen neu erstellt werden. Eskalieren Sie Abweichungen zwischen Datenbank und Dateien, zunehmende Prüfsummenfehler oder Jobs, die Originale verändern; bewahren Sie Manifeste und Logs auf, damit die Reparatur nicht zu einem undokumentierten Reimport wird.