Was ist der Status von Immich, und welche Teile müssen dauerhaft gespeichert werden?

Der Immich-Zustand umfasst die zusammengehörigen Medien-, Datenbank-, Identitäts-, Konfigurations- und abgeleiteten Daten, die erforderlich sind, um das vorgesehene Verhalten der Bibliothek wiederherzustellen.

Die Originaldateien sind unverzichtbar, bilden jedoch nicht die gesamte Anwendung ab. Alben, Benutzer, Besitzverhältnisse, Gesichter, Suchrepräsentationen, Pfadzuordnungen und Geheimnisse bestimmen, wie diese Dateien angezeigt werden und wer sie nutzen kann; einige davon sind maßgeblich, während andere mit entsprechendem Aufwand neu erstellt werden können.

Originalmedien und Datenbankbeziehungen bilden den Kern

Originalfotos und -videos bewahren die unersetzlichen Inhalte. Die Datenbank speichert, wie Immich diese Inhalte versteht: Benutzer, Besitzverhältnisse, Alben, Asset-IDs, Metadaten und Verarbeitungsbeziehungen. Jede Seite allein ist unvollständig, wenn das Ziel darin besteht, denselben Haushaltsdienst wiederherzustellen, anstatt lediglich lose Dateien zurückzugewinnen.

Der Immich-Sicherungsleitfaden von ZimaSpace erklärt, dass ein umfassender Schutz hochgeladene Medien und die Datenbank einschließt. Diese Unterscheidung liefert eine nützliche Definition des Zustands: Medien beantworten die Frage, welche Bytes vorhanden sind, während Datenbankeinträge festlegen, wie die Anwendung diese Bytes zuordnet, darstellt und kontrolliert.

Ordne die Datenbank und jeden Speicherort der Originalmedien dauerhaften Pfaden auf dem Host oder im Speichersystem zu. Stelle sicher, dass externe Bibliotheken durch ihre eigene Richtlinie geschützt sind. Leite die Persistenz nicht aus einem internen Containerpfad ab; überprüfe stattdessen das tatsächlich wirksame Volume oder Bind-Mount, das die Löschung und Neuerstellung des Containers übersteht.

Konfiguration und Geheimnisse stellen die Dienstgrenzen wieder her

Compose-Definitionen, Umgebungsvariablen, Speichermappings, Proxy-Regeln und die Konfiguration des Identitätsanbieters bestimmen, wie Dienste Daten und einander finden. Auch Passwörter, Signaturmaterial und API-Zugangsdaten müssen sicher erhalten bleiben. Werden Dateien ohne diese Einstellungen wiederhergestellt, kann die Datenbank unter der falschen Identität oder über falsche Pfade erreichbar sein.

Eine Analyse zur Speicherplanung für Immich unterscheidet zwischen dem Speicherort der Datenbank und der Vorschaubilder sowie dem zentralen Speicher für Originale. Die architektonische Erkenntnis daraus lautet: Ein logisch zusammengehöriger Dienst kann sich über mehrere physische Speicherorte erstrecken. Daher muss das Verzeichnis der persistenten Daten jedem Mount und jeder Abhängigkeit folgen, nicht nur einem Projektverzeichnis.

Speichere Bereitstellungsdefinitionen nach dem Entfernen von Geheimnissen in der Versionsverwaltung. Bewahre Geheimnisse in einer verschlüsselten Sicherung oder einem Geheimnis-Manager mit dokumentiertem Wiederherstellungsweg auf. Dokumentiere Eigentümer und Berechtigungen für Bind-Mounts. Überprüfe bei einem Testlauf den Zugriff der Dienste auf die Datenbank und das Lesen der Medien, bevor du den Fernzugriff freigibst oder neue Uploads annimmst.

Abgeleitete Daten können neu erstellt werden, sind aber betrieblich bedeutsam

Vorschaubilder, kodierte Videos und einige Ausgaben des maschinellen Lernens können abhängig von der Version und den aufbewahrten Datensätzen aus maßgeblichen Eingaben neu erstellt werden. Werden sie aus den Sicherungen ausgeschlossen, kann dies deren Größe verringern. Der Nachteil besteht in Zeitaufwand, Rechenlast, Wärmeentwicklung und einer geringeren Reaktionsfähigkeit, während ein wiederhergestellter Server eine große Familienbibliothek neu aufbaut.

Ein unabhängiger Sicherungsleitfaden unterscheidet zwischen unverzichtbaren Upload-, Bibliotheks- und Profildaten sowie Vorschaubildern und kodierten Videos, die Immich neu erstellen kann. Dadurch werden abgeleitete Daten nicht bedeutungslos; vielmehr erhalten Betreiber die Wahl zwischen Sicherungsgröße und der Zeit, die benötigt wird, um wieder vollständig vorbereitete Ansichten und Wiedergabe zu ermöglichen.

Miss die Wiederaufbaugeschwindigkeit anhand eines repräsentativen Tests, bevor du abgeleitete Daten ausschließt. Hochrechne vorsichtig anhand der betroffenen Asset-Zusammensetzung und berücksichtige sowohl Schreibvorgänge auf dem Speicher als auch die Belastung durch konkurrierende Vordergrundprozesse. Wenn die daraus resultierende Verzögerung das Wiederherstellungsziel verfehlt, sichere ausgewählte Pfade mit abgeleiteten Daten oder halte für das Wiederaufbaufenster zusätzliche Rechenkapazität bereit.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Beweise die Persistenz mit einem Test zur Container-Zerstörung

Verwende eine wegwerfbare Kopie der Bereitstellung, niemals die Produktionsumgebung. Erfasse Prüfsummen für einige Beispieloriginale, ein Testalbum, zwei Konten mit unterschiedlichen Zugriffsrechten und eine bekannte Suche. Entferne nur die geklonten Container, während der deklarierte persistente Speicher erhalten bleibt, und erstelle den Stack anschließend anhand der gespeicherten Konfiguration und Geheimnisse neu.

Ein Bericht aus der Community zur Persistenz beschreibt, dass Immich nach Neustarts wieder zur Ersteinrichtung zurückkehrte, weil das vorgesehene Datenbankverzeichnis auf dem Host leer blieb. Dies ist ein warnendes Beispiel dafür, dass ein konfigurierter Pfad kein Beweis dafür ist, dass Schreibvorgänge ihn tatsächlich erreichen. Der beobachtbare Zustand muss die behauptete Lebenszyklusoperation überstehen.

Bestehe den Test nur dann, wenn beide Konten wieder vorhanden sind, die Albumzugehörigkeit übereinstimmt, die Prüfsummen der Originale identisch sind und sich die bekannte Suche erwartungsgemäß verhält oder in einen dokumentierten Wiederaufbauzustand übergeht. Jeder unerklärliche Reset weist auf fehlende Persistenz hin. Aktualisiere die Zustandsübersicht, bevor du dich auf eine Sicherungsautomatisierung verlässt, die auf denselben Annahmen beruht.