Immich: Hardware, Speicher und Backup planen

Google Fotos ist ein sehr bequemer Kleiderschrank. Bei Immich baust du den Schrank selbst, samt Boden, und den Schlüssel zum Ersatzschrank verwahrst du in einem anderen Haus. Dieser Guide plant, bevor das erste Foto umzieht.

Kurz gesagt

Was braucht Immich zum Laufen? Die Dokumentation des Projekts nennt mindestens 2 CPU-Kerne und 6 GB RAM und empfiehlt 4 Kerne und 8 GB [1]. Mit 4 GB geht es nur mit abgeschaltetem Machine Learning, also der Bilderkennung [1]. Die Datenbank gehört auf eine lokale SSD, nie auf eine Netzfreigabe [1]. Plane den Speicher auf das 1,1- bis 1,2-Fache deiner Original-Bibliothek und über Server, lokales Backup und Offsite-Kopie auf etwa das Dreifache (unsere Ableitung, Details unten). Beim Backup zählt eine Regel: Immichs eigene Datenbank-Dumps enthalten nur Metadaten, die Foto-Ordner musst du selbst sichern, und das Projekt rät, erst die Datenbank und dann die Dateien zu sichern [6]. Unten steht, was das pro Jahr kostet, mit Datum und Quelle, und wo Selbsthosten kein Geld spart.

So funktioniert’s

1. Was tatsächlich läuft. Die Compose-Datei des Releases v3.3.5 startet vier Container: den Immich-Server (Web, API und Aufgaben, Port 2283), einen Machine-Learning-Container, eine Valkey-Instanz als Warteschlange und eine PostgreSQL-Datenbank mit der VectorChord-Erweiterung [3]. Machine Learning (ML, maschinelles Lernen) sind hier die Modelle, die deine Fotos lesen: Smart Search nach Inhalt (CLIP) und Gesichtserkennung [10][22]. Laut Doku läuft die CLIP-Suche auf Postgres, deshalb ist die Datenbank so wichtig [10].
2. Version festnageln. Das neueste Release, das wir am 25. Okt. 2026 gefunden haben, ist v3.3.5 vom 21. Okt. 2026 [4]. Die Beispiel-.env setzt IMMICH_VERSION=v3, einen Tag, der der aktuellen Hauptversion folgt [2][5]. Die Compose-Datei fällt auf release zurück, wenn die Variable leer ist [3]. Wir würden stattdessen eine volle Version wie v3.3.5 eintragen, denn Upgrades sollen deine Entscheidung sein. Das Projekt verspricht Breaking Changes nur in Hauptversionen, verlangt, dass der Server zur Hauptversion der App passt, rät, zuerst die mobilen Clients zu aktualisieren, und unterstützt keine Downgrades [5]. Wir haben die Images nicht selbst gezogen; das Tag-Format stammt aus der Projektdokumentation und der Release-Liste [2][4].
3. CPU, RAM und wo es läuft. Neben den Mindestwerten oben schreibt die Doku, dass Immich auf amd64 und arm64 läuft und der ML-Container auf amd64 die Befehlssatzstufe x86-64-v2 braucht, die die meisten CPUs seit etwa 2012 mitbringen [1]. Eine vollständige virtuelle Maschine ist in Ordnung. Docker in einem LXC-Container empfiehlt das Projekt nicht, und Nicht-Linux-Hosts rät es ab [1]. Begrenzt du Docker-Ressourcen, braucht die Datenbank mindestens 2 GB RAM [1].
4. Wie viel RAM der ML-Container frisst. Das hängt vom Modell ab. Das Standard-Suchmodell ist ViT-B-32__openai [12]. Im Benchmark des Projekts (7800X3D, direkt auf Linux, ohne Beschleunigung, volle Genauigkeit) liegt der Spitzenwert bei etwa 1.004 MiB RAM; größere Modelle brauchen grob 3.000 bis 6.600 MiB, etwa 3.854 MiB für ViT-SO400M-16-SigLIP2-384__webli [10]. Der Benchmark klammert Bilddecodierung und Webserver aus [10]. Für das Standard-Gesichtsmodell buffalo_l [12] haben wir keinen Speicherwert gefunden, deshalb gilt er als unbelegt. Die Standardwerte für parallele Aufgaben sind niedrig (Smart Search 2, Gesichtserkennung 2, Vorschaubilder 3, Videokonvertierung 1) [12], und die Doku warnt davor, sie über die Zahl der CPU-Kerne zu erhöhen [13].
5. Vier Wege für das Machine Learning. (a) Auf demselben Rechner per CPU. Das ist die einfachste Lösung. Die Doku nennt keine Durchsatzzahlen, deshalb behaupten wir keine Geschwindigkeit. Teste mit ein paar hundert Fotos, bevor du alles importierst. (b) ML ausschalten, wenn du nur 4 GB hast; dann fehlen dir Inhaltssuche und Gesichtsgruppen [1]. (c) Den ML-Container auf einen stärkeren Rechner auslagern. Du trägst seine URL in den Einstellungen ein, und wenn du sie hinzufügst statt die lokale zu ersetzen, weicht Immich auf den lokalen Container aus, falls der entfernte ausfällt. Die Doku warnt, dass Bildvorschauen zu diesem Container wandern und er keinerlei Sicherheitsmaßnahmen hat; halte ihn also in einem vertrauenswürdigen LAN [9]. (d) Eine GPU nutzen. Unterstützt sind CUDA (NVIDIA, Compute Capability 5.2 oder höher, Treiber 545 oder neuer), ROCm (AMD, mit einem 35-GiB-Image), OpenVINO (Intel-GPUs, bei integrierten mit mehr Problemen), ARM NN (Mali) und RKNN (Rockchip). Die Doku nennt die Funktion experimentell und nur für Linux (oder Windows über WSL2) [8].
6. Video ist die zweite Last. Videos werden standardmäßig in eine Kompatibilitätskopie umgewandelt; das Original bleibt erhalten [6]. Als Standard dokumentiert sind H.264 mit 720p, nur wo nötig [12]. Hardware-Transcoding (NVENC, Quick Sync, RKMPP, VAAPI) ist möglich, laut Doku liefert es aber deutlich größere Dateien bei meist geringerer Qualität, es ist experimentell, und der Raspberry Pi wird nicht unterstützt [11].
7. Wohin die Platten kommen. Der Datenbankordner (DB_DATA_LOCATION) umfasst typischerweise 1 bis 3 GB und gehört auf eine lokale SSD [1]. Für Datenbanken auf Festplatten gibt es in der Compose-Datei einen Schalter [3]. Der Medienordner (UPLOAD_LOCATION) will ein Unix-kompatibles Dateisystem mit Benutzer- und Gruppenrechten, etwa ext4 oder ZFS [1]. Unsere Lesart: Eine SMB-Freigabe ohne Unix-Rechte ist für diesen Ordner ein Risiko, also teste, bevor du dich festlegst. Auf Windows-Hosts akzeptiert Immich NTFS für die Datenbank nicht [1].
8. Speicherrechnung (unsere Ableitung). Vorschaubilder und umgewandelte Videos vergrößern die Bibliothek laut Doku um etwa 10 bis 20 Prozent [1]. Du kannst das senken, indem du die 1440p-Vorschaugröße verkleinerst [13]. Nenne deine Original-Fotos und -Videos L. Der Server braucht etwa das 1,1- bis 1,2-Fache von L plus 1 bis 3 GB für die Datenbank. Eine lokale Backup-Kopie braucht etwa L, weil sich Vorschaubilder und Transcodes neu erzeugen lassen [6][7]. Eine Offsite-Kopie braucht noch einmal L. Das ergibt grob das 3,1- bis 3,2-Fache von L, ohne versionierte Historie und Wachstum. Die erste Tabelle nach dieser Liste zeigt die Zahlen. Miss L an deinem Takeout-Download oder deinem Handy, statt zu raten. Beim Umzug brauchst du außerdem Platz für die Takeout-Archive. Das Community-Werkzeug immich-go, das die Immich-Doku für Google Takeout empfiehlt [14], liest ZIP-Dateien direkt [16]. Die eigene Planungs-Checkliste nennt als freien Platz etwa das 1,5-Fache der Quellgröße [15]. Das ist eine Faustregel aus Drittquelle.
9. Was ein Backup enthalten muss. Immich speichert Dateipfade und Metadaten in der Datenbank und durchsucht den Bibliotheksordner nicht, deshalb sind Datenbank-Backups unverzichtbar [6]. Die eingebaute Aufgabe schreibt Dumps nach UPLOAD_LOCATION/backups, standardmäßig täglich um 02:00 Uhr, die letzten 14 bleiben erhalten. Fotos oder Videos enthalten sie nicht [6]. Die kritischen Originale liegen in library, upload und profile. Vorschaubilder und kodierte Videos erzeugen Aufgaben nach einer Wiederherstellung neu [6]. Die Doku sagt klar, dass Immich das Dateisystem nicht für dich sichert [6], und die README des Projekts beginnt mit einer 3-2-1-Warnung [17].
10. Reihenfolge beim Backup. Die Dokumentation nennt zwei sichere Wege. Halte den Container immich-server an, solange du kopierst, dann ändert sich nichts. Oder, wenn das nicht geht, sichere zuerst die Datenbank und danach die Dateien. Dann sind im schlimmsten Fall Dateien da, die die Datenbank nicht kennt. In umgekehrter Reihenfolge kann die Datenbank Einträge enthalten, deren Dateien fehlen [6]. Das Vorlagen-Skript der Doku hält diese Reihenfolge ein: Es sichert die Datenbank in einen Ordner im Upload-Verzeichnis und archiviert erst dann alles mit Borg, ohne thumbs und encoded-video [7]. Das machen wir genauso, und der Dump ist Pflicht: Das Skript schreibt ihn nach /srv/immich/library/database-backup/immich-database.sql.gz, bevor Borg startet. So enthält jedes Archiv, lokal wie offsite, sowohl den Dump als auch die Dateien. Beide Doku-Seiten nutzen pg_dump, es gibt also keinen Unterschied, um den man herumarbeiten müsste [6][7]. Das Skript beginnt mit set -euo pipefail. Scheitert der Dump oder gzip, bricht das Skript ab, und es entsteht kein Archiv. Ohne pipefail könnte ein fehlgeschlagenes pg_dump durch die Pipe rutschen und eine kaputte Datei in einem scheinbar intakten Archiv hinterlassen. Das Setup der Vorlage nutzt --encryption=none [7]. Für eine Offsite-Kopie würden wir stattdessen ein verschlüsseltes Repository wählen und Schlüssel und Passphrase getrennt vom Backup aufbewahren; unser Guide zu restic und Borg unter „Passt dazu“ erklärt die Schlüssel. Probe die Wiederherstellung in jedem Fall.
11. Wiederherstellung. In der Weboberfläche unter Administration, Wartung kannst du einen aufgelisteten Dump zurückspielen; Immich legt vorher einen Wiederherstellungspunkt an und rollt zurück, wenn es scheitert [6]. Bei einer frischen Installation verlangt die Wiederherstellung per Kommandozeile eine Datenbank, die noch nie gelaufen ist: Lösche den Datenbankordner, falls der Server schon gestartet war. Die Doku erwähnt, dass sich der Ablauf mit v2.5.0 geändert hat [6]. Ein Dump aus einer anderen Immich-Version kann Migrationen brauchen [6].
12. Was es kostet (unsere Rechnung, Preise vom 25. Okt. 2026). Googles Listenpreise, zitiert auf einer Telekom-Shopseite, betragen 2,99 € pro Monat für 200 GB und 9,99 € pro Monat für 2 TB, die diese Seite als Google AI Plus verkauft [18]. Über fünf Jahre sind das 179,40 € und 599,40 €. Für die Offsite-Kopie führt Hetzner eine Storage Box mit 1 TB für 3,81 € pro Monat inklusive 19 Prozent MwSt. (228,60 € über fünf Jahre) [19] und eine mit 5 TB für 12,97 € pro Monat (778,20 €) [20]. Beide unterstützen Borg und restic [21]. Die Leistungen sind unsere Annahmen: Ein Server mit 10 W Dauerlast verbraucht 87,6 kWh im Jahr, einer mit 25 W 219 kWh. Bei 37,0 ct/kWh, dem Haushaltsdurchschnitt für das bisherige Jahr 2026 laut BDEW-Analyse vom August 2026 [23][24], sind das 32,41 € und 81,03 € im Jahr, über fünf Jahre 162,06 € und 405,15 €. Setze deinen eigenen Tarif ein. Hardware und Platten sind unbelegt, weil wir keine Modelle verglichen haben. Die zweite Tabelle nach dieser Liste fasst es zusammen. Mit diesen Zahlen spart Selbsthosten mit gemieteter Offsite-Kopie kein Geld. Eine günstigere Offsite-Kopie, etwa eine Platte bei Verwandten, würde das ändern, doch dafür haben wir keinen Preis. Googles Tarife decken außerdem Gmail und Drive ab, und Immich ersetzt beides nicht. Entscheide dich für Immich wegen Kontrolle, Privatsphäre und Eigentum, und plane den Aufwand mit ein. Willst du auch Dateien und nicht nur Fotos selbst in der Hand haben, vergleicht der Nextcloud-Guide unter „Passt dazu“ Selbsthosten mit Mieten.

Tabellen: Speicher und Fünf-Jahres-Kosten (unsere Ableitung)

Plattenplatz nach Bibliotheksgröße, aus den Faktoren in den Schritten 8 und 9:

Kosten über fünf Jahre ohne Hardware und Platten, aus den Preisen in Schritt 12 (Strompreis 37,0 ct/kWh, Haushaltsdurchschnitt laut BDEW für das bisherige Jahr 2026 [23][24]):

Ein Homelab-Beispiel

Das ist ein allgemeines Setup für deinen eigenen Server, kein Bericht über unseren. Zu Immich oder Foto-Hosting in unserem Bytearium-Homelab machen wir keine Aussage. Angenommen sind Linux mit Docker, eine kleine SSD unter /srv/immich/postgres, eine Datenplatte unter /srv/immich/library und eine Backup-Platte unter /mnt/backup.

Lade die beiden Dateien so herunter, wie die Doku es beschreibt [2]: wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml und wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env. Bearbeite dann die .env:

UPLOAD_LOCATION=/srv/immich/library
DB_DATA_LOCATION=/srv/immich/postgres
IMMICH_VERSION=v3.3.5
DB_PASSWORD=<zufällig, nur A-Za-z0-9>
TZ=Europe/Berlin

Starte mit docker compose up -d und registriere den ersten Benutzer, der zum Admin wird [2]. Um das Machine Learning vor dem großen Import zu testen, lade ein paar hundert Fotos hoch und öffne die Aufgabenseite.

Sichere beim Backup zuerst die Datenbank mit dem Befehl aus dem Restore-Abschnitt [6] und kopiere dann die Dateien:

#!/usr/bin/env bash
set -euo pipefail
mkdir -p /srv/immich/library/database-backup
docker exec immich_postgres pg_dump --clean --if-exists --dbname=immich --username=postgres | gzip > /srv/immich/library/database-backup/immich-database.sql.gz.tmp
mv /srv/immich/library/database-backup/immich-database.sql.gz.tmp /srv/immich/library/database-backup/immich-database.sql.gz
borg create --stats /mnt/backup/immich-borg::'{now}' /srv/immich/library --exclude /srv/immich/library/thumbs --exclude /srv/immich/library/encoded-video

Die borg create-Zeile folgt dem Ausschlussmuster aus der Vorlage der Doku [7]. Lege das Repository einmal mit einem verschlüsselten Modus an, etwa borg init --encryption=repokey-blake2 /mnt/backup/immich-borg, und bewahre Schlüssel und Passphrase getrennt vom Backup auf. Das Skript schreibt den Dump zuerst nach /srv/immich/library/database-backup/immich-database.sql.gz, sodass jedes Archiv Dump und Bibliothek zusammen enthält [7]. Die Offsite-Kopie wiederholt borg create gegen ein entferntes Repository, immer nachdem der Dump geschrieben wurde, damit auch das Offsite-Archiv den Dump enthält. Bei einer Hetzner Storage Box läuft SSH über Port 23, und mit --remote-path wählst du die Borg-Version, zum Beispiel borg-1.4 [21]. Wegen set -euo pipefail stoppt das Skript bei einem fehlgeschlagenen Dump oder gzip, bevor ein Archiv entsteht.

Probe die Wiederherstellung auf einem zweiten Rechner: Installiere Immich mit derselben Version in der .env, verschiebe die gesicherten Ordner in sein Upload-Verzeichnis und spiele den Dump mit dem Kommandozeilen-Ablauf aus dem Restore-Abschnitt zurück [6]. Die Web-Wiederherstellung akzeptiert .sql.gz-Dateien [6], ob sie einen mit unserem Befehl erzeugten Dump annimmt, haben wir aber nicht geprüft. Prüfe, dass sich Fotos öffnen lassen, nicht nur, dass die Liste da ist.

Prüfliste

• Miss die Größe deiner Bibliothek in GB am Takeout-Archiv oder am Handy und notiere L.
• Prüfe, ob der Host mindestens 6 GB RAM und 2 Kerne hat, oder entscheide dich für ML aus oder ausgelagertes ML.
• Trage für IMMICH_VERSION eine volle Version ein und lies vor jedem Upgrade die Release Notes.
• Lege die Datenbank auf eine lokale SSD und halte sie von jeder Netzfreigabe fern.
• Wähle das Modell bewusst und vergleiche seinen Speicherwert aus der Doku-Tabelle mit deinem freien RAM.
• Plane etwa das Dreifache von L an Platten für Server, lokales Backup und Offsite ein und rechne dein Wachstum dazu.
• Sichere erst die Datenbank und dann die Dateien, oder halte den Server-Container beim Kopieren an.
• Schließe thumbs und encoded-video nur aus, wenn du die Neuerzeugung nach einem Restore akzeptierst.
• Verschlüssele das Offsite-Repository und bewahre den Schlüssel getrennt vom Repository auf.
• Spiele die Wiederherstellung einmal auf einem zweiten Rechner zurück und notiere Datum und Ergebnis.
• Vergleiche Kosten mit deinem eigenen Strompreis und datierten Anbieterpreisen, nicht mit unseren.