Wer sichert einen Immich-Server, und wie bekommst du alles zurück?

Am 19. Oktober 2026 haben wir alles auf einem Immich-Testserver gelöscht, einschließlich des lokalen Borg-Repositorys. Übrig blieben nur das externe Borg-Repository und sein exportierter Schlüssel. Aus diesen beiden hat eine Neuinstallation die gesamte Bibliothek zurückgeholt.

Auf einem VPS von DreamHost bist du selbst für diese Backups zuständig. Der Support von DreamHost ist rund um die Uhr für Hardware, Netzwerk und Konnektivität erreichbar, während du Betriebssystem, Software und Konfiguration verwaltest. Laut dem Help Center von DreamHost kann DreamHost auf deine Daten auf einem VPS nicht zugreifen und sie weder sichern noch wiederherstellen, weil du den VPS vollständig selbst kontrollierst. Immich erstellt jede Nacht um 2:00 Uhr einen eigenen Datenbank-Dump. Diese Dumps enthalten aber nur Metadaten, niemals Fotos oder Videos. Auf einem Immich-Server von DreamHost erstellt das Hilfsprogramm immich-backup einen Dump der Datenbank und weist darauf hin, dass du das Bibliotheksverzeichnis separat vom Server kopieren musst. Wenn du noch dabei bist, von Google Photos umzuziehen, behalte die Takeout-Dateien, bis das erste Backup unten gelaufen ist. Falls du dich noch nicht für eine Foto-App entschieden hast, lies zuerst, wie sich Immich im Vergleich zu PhotoPrism, Ente und Nextcloud schlägt.

Was das Backup enthalten muss

Laut der Dokumentation von Immich speichert Immich Dateipfade und Nutzer-Metadaten in der Datenbank und durchsucht den Bibliotheksordner nicht. Ein Backup braucht deshalb beides aus derselben Nacht. Alben, Freigaben und Bearbeitungen stecken in diesen Metadaten. Stellst du die Fotos ohne die Datenbank wieder her, bekommst du lose Dateien ohne Alben. Stellst du die Datenbank ohne die Fotos wieder her, verweist Immich auf Dateien, die nicht da sind. Die Größen unten stammen aus dem zweiten Backup unserer Testbibliothek.

Ohne die beiden neu erstellbaren Ordner haben wir 214 MB von einem 1,39 GB großen Ordner gespart. Der Preis dafür war ein Neuaufbau der Miniaturansichten nach der Wiederherstellung. Deine .env und docker-compose.yml liegen außerhalb des Upload-Ordners, kopiere sie also einmal vom Server. Wir haben ohne unsere wiederhergestellt, mit frischen Kopien und einem neuen Datenbankpasswort. Mit deinen eigenen musst du Pfade und Version aber nicht erst nachschlagen.

So haben wir einen gelöschten Server wiederhergestellt

Der Testserver (kein Server von DreamHost) hatte zwei Konten, einen Admin und ein Familienmitglied. Zusammen hatten sie 401 Fotos und 4 Videos mit 1,06 GB, dazu 5 weitere Fotos im Papierkorb. Wir haben ihn mit den Dingen eingerichtet, die eine Familie vermissen würde, wenn sie verschwänden. Einige Fotos waren Favoriten mit Beschreibungen und Sternebewertungen, einige waren archiviert, und bei einigen waren Datum und Ort bearbeitet. Ein Album war für das zweite Konto freigegeben. Ein Freigabelink hatte ein Passwort und ein Ablaufdatum.

Jedes Backup folgte dem Borg-Skript von Immich mit Borg 1.4.0. Es erstellte einen Dump der Datenbank im Upload-Ordner und kopierte diesen Ordner dann in ein verschlüsseltes Repository außerhalb der VM, ohne Miniaturansichten und transkodierte Videos. Nach dem Löschen haben wir den Server in dieser Reihenfolge neu aufgebaut.

1. Immich aus den offiziellen Dateien neu installieren

   Lade frische Kopien von docker-compose.yml und example.env aus dem Schnellstart von Immich herunter. Setze IMMICH_VERSION in .env auf die Version, die du verwendet hast, denn der Standardwert v3 holt das neueste v3-Release. Du findest sie im Namen jedes automatischen Dumps. Wir haben außerdem ein anderes Datenbankpasswort als auf dem alten Server gesetzt, und docker compose pull dauerte über unsere Verbindung 16,4 Sekunden.

2. Das neueste Archiv aus dem externen Repository entpacken

   Führe borg extract für das neueste Archiv aus und verschiebe die Ordner an den neuen Upload-Speicherort. Unser Archiv mit 1,15 GB war in 4,8 Sekunden entpackt. Wenn du thumbs/ und encoded-video/ beim Backup ausgelassen hast, solltest du laut der Integritätsseite von Immich in jedem dieser Ordner eine leere Datei .immich anlegen, weil Immich beim Start danach sucht.

3. Die Datenbank wiederherstellen, bevor Immich zum ersten Mal startet

   Die Wiederherstellung über die Kommandozeile von Immich setzt eine Neuinstallation voraus, bei der der Immich-Server seit dem Erstellen seiner Container noch nie gelaufen ist. Starte also nur Postgres. Das sind die Befehle von Immich, mit dem Standard-Datenbanknamen und -Benutzer aus example.env. Ersetze gunzip --stdout durch cat, wenn der Dump reines SQL ist, wie ihn das Skript von Immich erstellt.

   bashKopieren

   docker compose create
   docker start immich_postgres
   sleep 10
   gunzip --stdout "/path/to/backup/dump.sql.gz" \
   | sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \
   | docker exec -i immich_postgres psql --dbname=immich --username=postgres --single-transaction --set ON_ERROR_STOP=on

   Dieser Schritt dauerte einschließlich der 10-sekündigen Wartezeit 19,9 Sekunden.

4. Immich starten

   Führe docker compose up -d aus. Unser Server antwortete nach 3,9 Sekunden, und das alte Admin-Passwort funktionierte. Rechnet man eine halbe Sekunde für das Anlegen des Ordners und das Verschieben der Dateien dazu, kamen die Wiederherstellungsschritte zusammen auf 46 Sekunden.

5. Thumbnails mit der Option „All“ neu erstellen

   Die Zeitleiste zeigte keine Miniaturansichten, weil sie nicht im Backup waren. Die Integritätsseite von Immich empfiehlt, den Miniaturansichten-Job für fehlende Elemente auszuführen, und wir haben erwartet, dass das funktioniert. Auf unserem wiederhergestellten Server hat diese Option aber nichts in die Warteschlange gestellt, da die Datenbank noch jeden Miniaturansichten-Pfad enthielt. Öffne stattdessen unter Administration die Job-Warteschlangen und führe den Miniaturansichten-Job mit All aus. Er hat 810 Miniaturansichten und Vorschauen in 100 Sekunden neu erstellt, etwa 8 Dateien pro Sekunde auf unserer VM mit 2 vCPUs. Echte Handyfotos sind größer, rechne bei einer Familienbibliothek also mit einem langsameren Tempo.

Auf einem echten Server läuft das Entpacken mit der Geschwindigkeit der Verbindung zu deinem externen Repository, eine große Bibliothek dauert also deutlich länger als unsere. Wir haben den wiederhergestellten Server mit einem Snapshot von vor dem Löschen verglichen.

Die Web-Wiederherstellung von Immich

In Immich v3 kannst du auch über den Willkommensbildschirm eines frischen Servers wiederherstellen, und Immich empfiehlt den Weg über das Web für die meisten Nutzer. Wir haben es auf einer zweiten gelöschten Installation ausprobiert, nachdem wir den gesamten Upload-Ordner zurückkopiert hatten, einschließlich Miniaturansichten und backups/, insgesamt 1,39 GB.

Der Willkommensbildschirm bietet Getting Started oder Restore From Backup. Klickst du auf Letzteres, startet Immich im Wartungsmodus neu. Unser Headless-Testbrowser blieb 2 Minuten bei Server is restarting hängen, also haben wir uns über den Wartungs-Login-Link angemeldet, den der Server in sein Log schreibt und den docker logs immich_server anzeigt. Ein normaler Browser aktualisiert sich womöglich von selbst, das haben wir aber nicht getestet. Immich prüfte dann, ob jeder Ordner lesbar und beschreibbar war, und listete die in backups/ gefundenen Dumps mit Datum, Version und Größe auf.

Wir haben den neuesten gewählt, einen Dump, den der wiederhergestellte Server um 2:00 Uhr selbst erstellt hatte. Immich speicherte zuerst einen 9,5 MB großen Wiederherstellungspunkt der aktuellen Datenbank. Die Login-Seite war 20 Sekunden nach unserer Bestätigung wieder da, und jede Prüfung aus der Tabelle oben war erneut erfolgreich. Diesmal erschienen die Miniaturansichten ohne Neuaufbau, weil die Ordnerkopie sie enthielt.

Wo die drei Kopien liegen

Die README von Immich rät dir, für deine Fotos und Videos immer einem 3-2-1-Backup-Plan zu folgen.

Bei einem gemieteten Server ist der Server selbst die erste Kopie (er steht ja schon nicht bei dir zu Hause). Kopie zwei kommt auf eine Festplatte oder ein NAS zu Hause. Kopie drei geht in ein externes Borg-Repository. Ein Repository auf der Festplatte des Servers zählt nicht, weil es Speicherplatz deines Tarifs belegt und mit dem Server verschwindet. Ein zweiter VPS von DreamHost liegt zwar außerhalb des Servers, aber laut dem Help Center von DreamHost wird jeder VPS im Rechenzentrum US East in Ashburn, Virginia, gehostet. Er zählt also nicht als externe Kopie.

BorgBase, das auf der Skript-Seite von Immich für externe Backups genannt wird, hostet Borg-Repositorys. Als wir uns die Tarife am 19. Oktober angesehen haben, gab es 10 GB kostenlos, 250 GB für 30 US-Dollar pro Jahr oder 1 TB für 110 US-Dollar pro Jahr, ohne Transfergebühren. Fotos lassen sich kaum komprimieren, du brauchst also ein Repository etwa in der Größe deiner Originale. Unser zweites Archiv schrumpfte von 1.150 MB auf 1.130 MB.

Borg speichert nur, was sich geändert hat. Unser erster Durchlauf fügte dem externen Repository 852 MB hinzu. Nachdem wir 110 Fotos ergänzt hatten, fügte der zweite Durchlauf 304,7 MB hinzu (die neuen Fotos plus den geänderten Datenbank-Dump). Das gesamte Skript lief 8,8 Sekunden. Ein einfacher Kopierjob würde alles erneut übertragen. Auch eine Synchronisierung ist kein Backup, denn ein auf dem Server gelöschtes Foto verschwindet auch aus der synchronisierten Kopie, während Borg ältere Archive behält.

Die erste Kopie vom Server ist die langsame. Nimm eine 165-GB-Bibliothek, etwa das Maximum, das unser Google-Photos-Leitfaden für Stack 16 vorsieht. Das sind 1.320 Gigabit (165 × 8), also etwa 44 Minuten bei einer Beispielrate von 500 Mbit/s. Die Kopie zu Hause lädt mit der Download-Geschwindigkeit deines Heimanschlusses herunter. Falls du jemals aus dieser Kopie zu Hause wiederherstellst, wird sie mit der Upload-Geschwindigkeit deines Heimanschlusses wieder hochgeladen, und bei 20 Mbit/s Upload sind das etwa 18 Stunden. Bei Immich VPS Hosting bekommst du unbegrenzte Bandbreite ohne Gebühren für Mehrverbrauch (es gilt Fair Use).

Das nächtliche Backup einrichten

Du brauchst einen SSH-Zugang zum Server und ein leeres Repository bei deinem externen Dienst.

1. Borg installieren

   Unter Debian 13 installiert sudo apt install borgbackup laut der Paketliste von Debian Borg 1.4.0, die von uns getestete Version. Der Schnellstart von Borg erklärt die folgenden Befehle ausführlicher.

2. Den Server ohne Passwortabfrage am Repository anmelden lassen

   Cron kann kein Passwort eingeben. Füge deshalb den öffentlichen SSH-Schlüssel des Servers bei deinem externen Dienst hinzu und speichere die Passphrase des Repositorys in einer Datei, die nur root lesen kann.

   bashKopieren

   sudo sh -c 'umask 077; printf "%s" "YOUR-PASSPHRASE" > /root/.borg-passphrase'

3. Das Repository mit Verschlüsselung erstellen

   Das Skript von Immich erstellt seine Repositorys mit --encryption=none. Wir haben für die externe Kopie die Verschlüsselung aktiviert. Borg fragt nach der Passphrase.

   bashKopieren

   borg init --encryption=repokey-blake2 ssh://USER@HOST/./immich-borg

4. Den Schlüssel exportieren und außerhalb des Servers aufbewahren

   Bewahre Schlüssel und Passphrase auf deinem eigenen Computer oder in deinem Passwort-Manager auf, denn ohne sie kannst du das Repository nicht öffnen. In unserem Test waren der exportierte Schlüssel und das Repository das Einzige, was den Server überlebt hat.

   bashKopieren

   borg key export ssh://USER@HOST/./immich-borg immich-borg-key.txt

5. Das Backup-Skript speichern

   Das ist das Skript von Immich mit Verschlüsselung, einem Repository, sieben aufbewahrten täglichen Archiven und ohne das -t im Dump-Befehl. Mit -t enthielt unser Dump 242.266 Wagenrückläufe. Der Dump ließ sich trotzdem fehlerfrei wiederherstellen, aber ein Cron-Job hat kein Terminal, mit dem er kommunizieren könnte, also haben wir das Flag entfernt. Das Skript von Immich behält nur wöchentliche und monatliche Archive. Ein Foto, das in derselben Woche hinzugefügt und gelöscht wird, kann so aus allen Archiven fallen, deshalb haben wir --keep-daily=7 ergänzt. Lege den Ordner database-backup vor dem ersten Durchlauf einmal im Upload-Ordner an.

   bashKopieren

   #!/bin/sh
   set -eu
   UPLOAD_LOCATION="/path/to/immich/upload"   # UPLOAD_LOCATION from Immich's .env
   REPO="ssh://USER@HOST/./immich-borg"
   export BORG_PASSCOMMAND="cat /root/.borg-passphrase"
   
   # Database first
   docker exec immich_postgres pg_dump --clean --if-exists --dbname=immich --username=postgres \
     > "$UPLOAD_LOCATION/database-backup/immich-database.sql"
   
   # Then the files, without the rebuildable folders
   borg create "$REPO::{now}" "$UPLOAD_LOCATION" \
     --exclude "$UPLOAD_LOCATION/thumbs/" --exclude "$UPLOAD_LOCATION/encoded-video/"
   
   # Keep 7 daily, 4 weekly and 3 monthly archives
   borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=3 "$REPO"
   borg compact "$REPO"

   Führe auf einem Immich-Server von DreamHost immich-backup anstelle der Zeile docker exec aus und nimm den erzeugten Dump in die Zeile borg create auf. Wir haben das Hilfsprogramm in unserem Test nicht ausgeführt. Prüfe also in seiner Ausgabe, wo Dump und Bibliotheksordner liegen, und richte UPLOAD_LOCATION darauf aus.

6. Die Kopie zu Hause hinzufügen

   Wiederhole die Zeilen create, prune und compact für ein zweites Repository auf einem Rechner zu Hause, so wie das Skript von Immich seine lokalen und entfernten Kopien handhabt. Der Server muss diesen Rechner per SSH erreichen, entweder über eine Portweiterleitung an deinem Router oder über einen privaten Netzwerktunnel zwischen beiden. Wir halten den Tunnel für die einfachere Variante, da er keine feste Adresse für deinen Anschluss zu Hause braucht.

7. Einmal ausführen, dann mit cron planen

   Führe das Skript von Hand aus und lies seine Ausgabe. Führe dann sudo crontab -e aus und füge eine Zeile hinzu, die es jede Nacht ausführt, hier um 4 Uhr, nach dem nächtlichen Dump von Immich.

   bashKopieren

   0 4 * * * /usr/local/bin/immich-borg.sh >> /var/log/immich-borg.log 2>&1

8. Benachrichtigung erhalten, wenn ein nächtliches Backup fehlschlägt

   Füge am Ende des Skripts eine Zeile hinzu, die eine Check-in-URL aufruft, damit du erfährst, wenn ein nächtliches Backup nicht fertig geworden ist. Laut der Seite von DreamHost zu Uptime Kuma können sich deine eigenen Skripte per Cron Job über Push-Monitore melden. Nach den ersten beiden Nächten sollte borg list für jede Nacht ein neues Archiv anzeigen. Das erste ist etwa so groß wie deine Bibliothek, die folgenden sind deutlich kleiner.

Ein einzelnes Foto aus einem älteren Archiv zurückholen

Wenn du die Speichervorlage von Immich nicht aktiviert hast (standardmäßig aus), liegen deine Fotos in upload/ unter zufälligen Namen, die Immich erzeugt hat. Um ein bestimmtes Foto zu finden, extrahierst du den reinen SQL-Dump aus demselben Archiv und durchsuchst ihn nach dem ursprünglichen Dateinamen des Fotos. Der gespeicherte Pfad steht in derselben Zeile. Dann holst du genau diese eine Datei heraus.

borg extract "$REPO::ARCHIVE-NAME" path/inside/the/archive/photo.jpg

Das Extrahieren eines Originals aus dem Archiv unserer ersten Nacht dauerte 0,5 Sekunden. Sein SHA-256-Hash stimmte mit dem der Datei von vor dem Backup überein. Lade es über die Immich-App oder die Weboberfläche erneut hoch. Wir haben nicht getestet, was ein erneut hochgeladenes Foto behält. Plane also ein, es selbst wieder zu seinen Alben hinzuzufügen.

Vor jedem Immich-Update sichern

Immich unterstützt kein Downgrade, nicht einmal innerhalb einer Minor-Version. Das Backup, das du vor einem Update anlegst, ist daher dein einziger Weg zurück. Die Immich-Seite von DreamHost empfiehlt, vor dem Update immich-backup für die Datenbank auszuführen. Notiere dir außerdem die Version, die du nutzt. Immich schreibt sie in den Namen jedes automatischen Dumps, direkt vor die Postgres-Version, und eine Wiederherstellung auf eine andere Version versucht automatisch, die Datenbankmigrationen auszuführen.

Führe alle paar Monate eine Test-Wiederherstellung durch. borg check lief bei unserem Repository in 1,8 Sekunden fehlerfrei durch, aber nur eine echte Wiederherstellung zeigt, dass Immich daraus wieder hochkommt. Der Test, der zählt, ist die oben beschriebene Wiederherstellung auf einem Testserver, gefolgt von den Integritätsprüfungen von Immich, die v3 jede Nacht um 3 Uhr ausführt. Fehlende Thumbnails für alles im Papierkorb sind dabei normal. Öffne danach ein geteiltes Album und ein paar bearbeitete Fotos und prüfe, ob sie so aussehen, wie du sie hinterlassen hast.

So haben wir gemessen

DreamHost hat den Test am 19. und 20. Oktober 2026 mit Immich v3.3.3 durchgeführt. Die Test-VM lief mit Ubuntu 24.04.4 auf arm64 mit 2 vCPU und 7.922 MB Arbeitsspeicher, unter Colima auf einem Mac mit Apple Silicon. Das ist kein DreamHost-Server, und sie hat nur halb so viele Kerne wie Stack 16. Immich lief mit seiner eigenen Compose-Datei und example.env, angepasst nur bei Pfaden, Zeitzone, festgelegter Version und Datenbankpasswort. Borg 1.4.0 lief in einem Debian-13-Container. Die Bibliothek bestand aus synthetischen JPEGs mit Datum und GPS-Daten in den EXIF-Informationen sowie vier kurzen 1080p-Videoclips, verteilt auf Wegwerf-Konten. Jeder Schritt lief einmal.

Nicht abgedeckt sind das Immich-Image von DreamHost und sein Hilfsprogramm immich-backup, eine Übertragung über ein echtes Netzwerk (das externe Repository war ein Ordner auf demselben Mac), eine Bibliothek mit Hunderten Gigabyte und ein Backup einer älteren Immich-Version, das auf einer neueren wiederhergestellt wird. Immich v3.3.4 erschien am 20. Oktober. Die Versionshinweise nennen schnellere Personenabfragen und eine fehlende Übersetzung, aber nichts zu Backup oder Wiederherstellung. Wir haben den Test mit dieser Version noch nicht durchgeführt.

FAQ zum Sichern von Immich