Neuester Blog

Erhöhen Sie max_connections nicht als Erstes. Messen Sie die Immich-Sitzungen, summieren Sie den Bedarf aller Container, halten Sie Kapazitäten für die Administration frei und optimieren Sie nur den nachweislich bestehenden Engpass.

Trennen Sie wiederholte Aufträge von doppelten Assets. Verwenden Sie einen einzigen kanonischen Aufnahmeweg, kontrollieren Sie Wiederholungsversuche und Pfadänderungen und testen Sie anschließend den erneuten Einstieg mit einer kleinen Kohorte.

Löschen Sie niemals PostgreSQL-WAL-Dateien, um Speicherplatz freizugeben. Stoppen Sie Schreibvorgänge von Immich, bewahren Sie den Datenbankstatus, schaffen Sie sicheren zusätzlichen Speicherplatz, stellen Sie PostgreSQL wieder her und verhindern Sie anschließend, dass dies erneut passiert.

Immich sollte fehlende Quelloriginale nicht stillschweigend neu erstellen. Identifizieren Sie den Typ und Ersteller der regenerierten Datei und korrigieren Sie anschließend die Erstellungsidentität.

Identifizieren Sie zunächst, welcher Pfad geändert wurde: Verwaltete Medien-Stammverzeichnisse und Importpfade externer Bibliotheken unterscheiden sich hinsichtlich Migration und Verhalten bei veralteten Daten.

Lass den alten Immich-Host intakt, bis der wiederhergestellte Server seine Identität, Medien, Beziehungen, Schreibvorgänge und Neustarts sowie ein neues wiederherstellbares Backup unter realer Nutzung erfolgreich unter Beweis gestellt hat.

Ein geteiltes Immich-Layout funktioniert oft gut: SSD für die Datenbank und häufig benötigte generierte Daten, HDD für die Originale, wobei jeder Pfad ausreichend dimensioniert, gesichert und nach einem Neustart getestet wird.

Nach Abschluss der Uploads kann die Sicherung CPU-, ML-, Video-, Datenbank- und Festplattenaktivität auslösen. Stimmen Sie die Lüftergeschwindigkeit auf die aktive Warteschlange ab, bevor Sie Kühlung oder Parallelität ändern.