Sollten Sie Immich-Metadaten auf einer SSD und Massendaten auf einer HDD speichern?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Ja, eine Immich-Bereitstellung profitiert häufig davon, die Datenbank und latenzempfindliche generierte Daten auf einer SSD zu speichern, während große originale Foto- und Videodateien auf einer HDD liegen – insbesondere, wenn die Mediathek deutlich größer ist als der App-Status. Die Aufteilung ist jedoch nur dann sinnvoll, wenn Pfade, freie Speicherreserven, Backups und Wiederherstellungsschritte klar bleiben.

Die Entscheidung lautet nicht „Metadaten schnell, Medien langsam“. Immich greift auf verschiedene Speicherbereiche unterschiedlich zu: PostgreSQL verarbeitet viele kleine Statusoperationen; Miniaturansichten und Vorschauen werden beim Durchsuchen häufig gelesen; kodierte Videos können groß sein; Originale benötigen vor allem Kapazität und Haltbarkeit. Ermittle die Eigenschaften dieser Bereiche getrennt, bevor du etwas verschiebst.

Trenne häufig genutzte kleine I/O-Daten vom kapazitätsorientierten Medienbestand

Erfasse die PostgreSQL-Daten, Miniaturansichten, Vorschauen, kodierten Videos, den Modell-Cache, hochgeladene Originale, externen Bibliotheken und Sicherungskopien. Notiere die aktuelle Größe, das Wachstum, die Lese-/Schreibfrequenz, den Wiederaufbauaufwand und ob der jeweilige Bereich eine Wiederherstellung überstehen muss. So verhinderst du, dass die allgemeine Bezeichnung „Metadatenordner“ mehrere völlig unterschiedliche Arbeitslasten verbirgt.

Das ZimaSpace-Speicherframework zum Platzieren von Medienmetadaten und aktivem Cache macht die nützliche Unterscheidung deutlich: Datenbanken und Indizes profitieren von Speicher mit niedriger Latenz, während umfangreiche Quelldateien auf Kapazitätsspeicher verbleiben können, wenn ihr Zugriffsmuster nicht dieselben IOPS erfordert. Wenn deine aktuelle HDD bei Suchvorgängen, der Zeitleistennavigation und Hintergrundaufgaben eine niedrige Latenz aufweist, bringt es möglicherweise nur wenig sichtbaren Nutzen, jedes abgeleitete Element auf die SSD zu verschieben. Behalte das aktuelle Layout bei, bis ein kontrollierter Vergleich zeigt, dass tatsächlich auf den aktiven Speicherpfad gewartet wird.

Lege PostgreSQL und häufig gelesene abgeleitete Dateien auf die SSD, wenn sie den Engpass darstellen

PostgreSQL und das Durchsuchen vieler Miniaturansichten erzeugen zahlreiche kleine Lese- und Schreibvorgänge, die auf einer ausgelasteten mechanischen Festplatte langsam wirken können, insbesondere wenn Importe oder Backups dasselbe Gerät nutzen.

Bei aktuellen Immich-Layouts solltest du die Datenbank auf lokalem Speicher mit niedriger Latenz belassen und unterstützte Pfade für generierte Daten gezielt verschieben, anstatt beliebige verschachtelte Mounts zu erfinden.

Der zugrunde liegende Speichermechanismus ist außerhalb von Immich gut bekannt: Die Speicheroptimierung von PostgreSQL profitiert von deutlich günstigeren Zufallszugriffen als auf rotierenden Festplatten. Das garantiert zwar keinen sichtbaren Geschwindigkeitsgewinn in Immich, erklärt aber, warum Datenbank- und Indexoperationen gute SSD-Kandidaten sind, wenn die gemessene Wartezeit durch die Gerätelatenz entsteht.

Miss die Verbesserung anhand desselben Album-, Such- und Importbeispiels vor und nach der Änderung. Wenn die Datenbanklatenz sinkt, die für den Benutzer sichtbare Anfrage aber weiterhin auf Netzwerkübertragung, Bilddekodierung oder maschinelles Lernen wartet, solltest du die verbleibende Verzögerung nicht länger der HDD zuschreiben.

Bewahre Originale auf der HDD auf, wenn Kapazität und Schutz wichtiger sind als zufällige I/O-Zugriffe

Originalfotos und -videos bilden normalerweise die größte Speicherklasse und werden häufig als vollständige Dateien statt als winzige zufällige Datenbankseiten gelesen. Große HDD-Pools können daher ein sinnvoller Speicherort für Originale sein, wenn sie die erforderliche Zuverlässigkeit, den nötigen Durchsatz und ausreichende Backup-Kapazität bieten. Auch die HDD-Ebene benötigt ausreichend freien Speicherplatz und eine stabile Latenz bei gleichzeitigen Import- und Suchvorgängen.

Eine lang laufende Immich-Diskussion zur Trennung von Miniaturansichten und Medien spiegelt denselben betrieblichen Wunsch wider: Generierte Dateien für die Navigation und umfangreiche Originale haben unterschiedliche Zugriffsprioritäten. Sie beweist jedoch nicht, dass jede Installation zwei physische Geräte benötigt; der Nutzen hängt davon ab, wo Anfragen derzeit warten.

Lege unersetzliche Originale nicht einfach deshalb auf eine HDD, weil sie günstiger ist, und betrachte RAID anschließend als Backup. Bewahre eine zweite Kopie sowie je nach gewünschtem Schutz für den Haushalt eine Kopie außerhalb des Hosts oder offline auf. Die Speicherklassifizierung verändert Leistung und Kosten, verringert aber nicht die Folgen, wenn die einzige Kopie der Familienmediathek verloren geht.

-15% OFF

Verschiebe jeweils nur eine Speicherrolle und teste die Mounts nach einem Neustart

Erstelle vor dem Verschieben eines Pfads ein konsistentes Datenbank-Backup und dokumentiere die aktuelle Zuordnung der Host- zu den Container-Mounts. Verschiebe jeweils nur eine Rolle, starte den Stack, überprüfe alte und neue Dateien, führe eine Suche durch, spiele ein Video ab, lade eine entbehrliche Datei hoch und bestätige, dass die neuen Schreibvorgänge auf dem vorgesehenen Gerät landen. Verschiebe Datenbank, Miniaturansichten, Originale und Backup-Ziele nicht in einer einzigen Änderung.

Starte den Host neu, statt nur die Container neu zu erstellen. Bei einer funktionierenden Aufteilung werden die Mounts von SSD und HDD verfügbar gemacht, bevor Immich schreibt; Benutzer und Beziehungen bleiben erhalten, ausgewählte Originale lassen sich lesen und die Überwachung des freien Speicherplatzes bleibt auf beiden Ebenen aktiv. Ein leeres Ersatzverzeichnis an einem erwarteten Mount-Punkt ist ein Abbruchkriterium. Behalte die Aufteilung bei, wenn sich der gemessene Engpass verbessert und die Wiederherstellungsübersicht verständlich bleibt. Führe ein Rollback durch, wenn das Layout veraltete Pfade, fehlende Dateien, abweichende Berechtigungen oder einen Backup-Prozess verursacht, der nur eine Ebene schützt. Das beste Speicherkonzept ist das schnellste, das du weiterhin korrekt wiederherstellen kannst.

Support & Tipps

Mehr zum Lesen

So verhindern Sie doppelte Jobs oder Importe in Immich
Sep 08, 2026

So verhindern Sie doppelte Jobs oder Importe in Immich

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...

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.