Solltest du Immich Live sichern oder den Dienst zuerst stoppen?

Stoppen Sie Immich zuerst, wenn Sie die einfachste und am leichtesten zu erklärende Konsistenzgrenze wünschen; verwenden Sie eine Live-Sicherung nur, wenn Sie einen datenbanknativen Dump erstellen und die Erfassung oder den Snapshot der Medien so koordinieren können, dass ihre Wiederherstellungsbeziehung bekannt ist.

Immich speichert Asset-Datensätze in PostgreSQL, während Originale und abgeleitete Dateien auf dem Speicher liegen. Daher kann eine gewöhnliche rekursive Live-Kopie unterschiedliche Zeitpunkte erfassen. Für einen kleinen Haushalt ist ein kurzes Wartungsfenster oft sicherer als eine komplexe Orchestrierung. Wenn kontinuierliche Uploads wichtig sind, lassen Sie den Dienst aktiv, verwenden Sie jedoch datenbankbewusste Werkzeuge, dokumentieren Sie die Erfassungsreihenfolge, schützen Sie neu eintreffende Assets und bewerten Sie die Sicherung anhand einer isolierten Wiederherstellung.

Definieren Sie jede Komponente, die bei der Wiederherstellung neu erstellt werden muss

Inventarisieren Sie die PostgreSQL-Datenbank, die Upload-Bibliothek, die gemäß Ihrer Richtlinie benötigten generierten Medien, Definitionen externer Bibliotheken, Compose- und Umgebungsdateien, Geheimnisse, Proxy-Einstellungen und Verschlüsselungsschlüssel. Ordnen Sie ein, welche Elemente Immich verwaltet und welche neu generiert werden können.

Ein praxisorientierter Artikel zur Datenbanksicherung erklärt, wie ein PostgreSQL-Dump verwendet wird, anstatt das aktive Datenbankverzeichnis wie gewöhnliche Dateien zu behandeln. Die datenbankbewusste Sicherungsmethode unterstützt den Live-Betrieb; bestätigen Sie Befehle und Versionen für Ihre Bereitstellung.

Ein Plan scheitert, wenn er zwar die Originale schützt, ihre Datensätze jedoch nicht wiederherstellen kann, oder wenn er die Datenbank schützt, aber Medien auslässt. Schreiben Sie die Wiederherstellungsreihenfolge neben die Sicherungsreihenfolge, bevor Sie entscheiden, ob Ausfallzeit akzeptabel ist.

Wählen Sie eine Sicherung bei gestopptem Dienst für die klarste Grenze

Pausieren Sie Uploads, stoppen Sie die Immich-Anwendung und die Worker ordnungsgemäß und erstellen Sie anschließend ein datenbanknatives Backup. Kopieren oder snapshotten Sie außerdem die Medien und Bereitstellungsdateien. Lassen Sie PostgreSQL nur so lange laufen, wie es für den Dump erforderlich ist, oder stoppen Sie es ordnungsgemäß vor einem Speichersnapshot, der für diesen Dienst vorgesehen ist.

Ein gestoppener Dienst behebt keine falschen Pfade oder einen unvollständigen Umfang. Prüfen Sie daher Mounts und Archivgrößen. Eine erfolgreiche Sicherung weist während der Erfassung keine aktiven Immich-Schreibvorgänge auf, umfasst ein erfolgreiches Datenbank-Backup, lesbare Medienbeispiele, Prüfsummen und eine dokumentierte Neustartzeit.

Der ZimaSpace-Leitfaden zum Überprüfen von Sicherungsschlüsseln und Wiederherstellungen unterstreicht, dass eine ruhige Kopie erst dann wiederherstellbar ist, wenn ihre Zugangsdaten und ihr Wiederherstellungspfad getestet wurden.

Verwenden Sie eine koordinierte Live-Sicherung, wenn die Verfügbarkeit entscheidend ist

Erstellen Sie für einen Live-Plan einen konsistenten datenbanknativen Dump und kombinieren Sie ihn mit einem Speichersnapshot oder einer Dateierfassung, deren Zeitpunkt und Schreibverhalten bekannt sind. Dokumentieren Sie Start- und Abschlusszeiten, behalten Sie neu eintreffende Uploads bis zur nächsten Sicherung bei und vermeiden Sie das Kopieren des aktiven Datenbankverzeichnisses.

Eine Community-Diskussion über die Sicherung von Immich aus einer laufenden Bereitstellung zeigt, warum Betreiber zwischen Datenbank und Upload-Dateien unterscheiden. Verwenden Sie diese Live-Sicherungsgrenze als praktischen Kontext, nicht als Ersatz für einen Wiederherstellungstest.

Ein Live-Entwurf ist nur dann erfolgreich, wenn das Datenbankwerkzeug fehlerfrei abgeschlossen wird, die Dateisystemerfassung atomar ist oder ihre Reihenfolge dokumentiert wurde und während des Zeitfensters erstellte Uploads berücksichtigt werden. Wählen Sie andernfalls den Weg mit gestopptem Dienst oder erhöhen Sie die Sicherungshäufigkeit, um das Wartungsfenster zu verkürzen.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Stellen Sie isoliert wieder her und treffen Sie die endgültige Entscheidung

Stellen Sie die ausgewählte Datenbank und die Medien auf einem isolierten Ziel mit den gespeicherten Bereitstellungsdateien wieder her. Prüfen Sie Benutzer, Asset-Anzahl, stichprobenartig ausgewählte Originale, Alben, Favoriten, Suchvorgänge, externe Bibliotheken und einen neuen Upload. Starten Sie das Ziel neu und wiederholen Sie die wichtigsten Prüfungen.

Wählen Sie Sicherungen bei gestopptem Dienst, wenn die Ausfallzeit für den Haushalt akzeptabel ist und die Einfachheit Fehler reduziert. Wählen Sie koordinierte Live-Sicherungen, wenn die Verfügbarkeit zusätzliche Werkzeuge rechtfertigt und wiederholte Wiederherstellungstests den Prozess bestätigen. Die Entscheidung kann sich ändern, wenn Bibliotheksgröße und Upload-Häufigkeit zunehmen.

Beenden Sie die Ausmusterung der Produktionsumgebung, wenn bei der Wiederherstellung Fehler wegen fehlender Dateien oder verwaister Datensätze auftreten. Bewahren Sie beide Sicherungskomponenten und die Protokolle auf und gleichen Sie anschließend Zeitstempel und Umfang ab. Eskalieren Sie mit Datenbankversion, Dump-Methode, Dateisystemmethode, Erfassungszeiten und Anzahl der Abweichungen. Löschen Sie niemals die letzte Sicherung bei gestopptem Dienst, bevor die Live-Methode nicht unabhängig erfolgreich getestet wurde.