PostgreSQL, Fotos, Docker-Daten und Offsite-Backups zuverlässig schützen

Eine selbst gehostete Fotoplattform gibt uns die Kontrolle über unsere eigenen Daten zurück.

Damit kommt allerdings auch eine neue Verantwortung:

Wir müssen selbst dafür sorgen, dass diese Daten nicht verloren gehen.

Bei einem kommerziellen Cloud-Dienst kümmert sich der Anbieter um redundante Speichersysteme, Datenbanken, Replikation und Wiederherstellung. Bei einer eigenen Immich-Installation übernehmen wir diese Aufgaben selbst.

Das ist gerade bei einer Fotosammlung besonders wichtig.

Viele Dateien sind nicht ersetzbar:

• Familienfotos
• Kinderbilder
• Hochzeiten
• Urlaubsaufnahmen
• historische Scans
• Smartphone-Videos
• Erinnerungen aus vielen Jahren

Ein Festplattenausfall darf deshalb nicht bedeuten, dass die komplette Sammlung verloren ist.

Immich selbst empfiehlt ausdrücklich eine 3-2-1-Backup-Strategie. Dabei sollten sowohl die hochgeladenen Fotos und Videos als auch die Immich-Datenbank gesichert werden.

In diesem zehnten Teil unserer Serie bauen wir deshalb eine vollständige Backup- und Wiederherstellungsstrategie für Immich auf.

Welche Daten müssen bei Immich gesichert werden?

Eine Immich-Installation besteht aus mehreren Komponenten.

Vereinfacht:

Immich
│
├── PostgreSQL
│
├── Originalfotos und Videos
├── generierte Dateien
├── Konfiguration
├── Docker Compose
├── .env
├── Machine-Learning-Cache
└── Redis

Nicht alle Daten haben dabei die gleiche Bedeutung.

Besonders wichtig sind:

1. Originalfotos und Videos
2. PostgreSQL-Datenbank
3. Konfiguration

Diese drei Bereiche bilden den Kern einer Wiederherstellungsstrategie.

Warum die PostgreSQL-Datenbank so wichtig ist

Immich verwendet PostgreSQL als persistenten Datenspeicher.

Darin befinden sich unter anderem Informationen über:

• Benutzer
• Benutzerrechte
• Assets
• Dateipfade
• Alben
• Freigaben
• Systemeinstellungen
• Beziehungen zwischen Medien
• Metadaten
• weitere Anwendungsinformationen

Immich scannt seinen normalen Bibliotheksordner nicht einfach neu und rekonstruiert daraus automatisch den kompletten vorherigen Zustand.

Genau deshalb ist ein Datenbank-Backup unverzichtbar.

Bilder allein reichen nicht

Angenommen, wir sichern lediglich:

/data/library

oder den über:

UPLOAD_LOCATION

definierten Speicherbereich.

Nach einem Totalausfall besitzen wir zwar möglicherweise noch die Originalbilder.

Es fehlen aber unter Umständen:

Benutzer
Alben
Freigaben
Zuordnungen
Datenbankinformationen
Immich-Metadaten

Die Dateien sind also vorhanden, der ursprüngliche Immich-Zustand jedoch nicht.

Die Datenbank allein reicht ebenfalls nicht

Das andere Extrem wäre:

PostgreSQL Backup vorhanden

aber:

Fotos verloren

Dann kennt Immich zwar beispielsweise:

IMG_1234.JPG

und weiß, zu welchem Benutzer oder Album das Bild gehörte.

Die eigentliche Datei existiert aber nicht mehr.

Das Backup muss deshalb immer aus mindestens zwei zentralen Teilen bestehen:

PostgreSQL
      +
Fotos und Videos
      =
wiederherstellbares Immich

UPLOAD_LOCATION verstehen

Bei einer klassischen Docker-Compose-Installation definiert:

UPLOAD_LOCATION

den Speicherbereich für die von Immich verwalteten Mediendaten.

Beispielsweise:

UPLOAD_LOCATION=/srv/immich/library

Dieser Speicherbereich sollte Bestandteil der Datensicherung sein.

Die offizielle Immich-Dokumentation weist ausdrücklich darauf hin, dass die automatischen Datenbank-Backups keine Fotos und Videos enthalten. Die Medien unter UPLOAD_LOCATION müssen daher separat gesichert werden.

Was liegt im Immich-Speicher?

Je nach Version und Konfiguration enthält der Speicherbereich unterschiedliche Daten.

Dazu gehören insbesondere:

• hochgeladene Originale
• Benutzerbibliotheken
• Vorschaubilder
• transkodierte Videos
• Backups
• generierte Dateien

Nicht alle davon sind gleich wertvoll.

Originalmedien sind unersetzbar.

Vorschaubilder und transkodierte Videos können dagegen grundsätzlich neu erzeugt werden.

Originale haben höchste Priorität

Ein Backup-System sollte deshalb zuerst sicherstellen, dass folgende Dateien geschützt sind:

Originalfotos
Originalvideos

Ein verlorenes Thumbnail ist ärgerlich.

Ein verlorenes Originalfoto ist möglicherweise endgültig verloren.

Diese Priorisierung ist besonders relevant, wenn Offsite-Speicher teuer ist.

PostgreSQL automatisch sichern

Immich besitzt inzwischen eine integrierte Datenbank-Backup-Funktion.

Standardmäßig werden Datenbank-Backups automatisch erzeugt und unter:

UPLOAD_LOCATION/backups

gespeichert.

Der Zeitplan und die Aufbewahrung können über:

Administration
→ Settings
→ Backup

konfiguriert werden.

Die aktuelle Dokumentation nennt als Standard:

Backup täglich um 02:00 Uhr
Aufbewahrung der letzten 14 Backups

Diese Werte können angepasst werden.

Datenbank-Backup manuell auslösen

Ein Backup kann außerdem direkt über die Immich-Weboberfläche gestartet werden.

Dazu:

Administration
      ↓
Job Queues
      ↓
Create job
      ↓
Create Database Dump

Das erzeugte Backup erscheint anschließend ebenfalls im Backup-Verzeichnis.

Das ist beispielsweise vor einem größeren Upgrade sinnvoll.

PostgreSQL zusätzlich mit pg_dump sichern

Neben der integrierten Backup-Funktion kann PostgreSQL auch klassisch mit:

pg_dump

gesichert werden.

Die aktuelle Immich-Dokumentation zeigt hierfür beispielsweise:

docker exec -t immich_postgres \
pg_dump --clean --if-exists \
--dbname=immich \
--username=postgres \
| gzip > /backup/immich-database.sql.gz

Dabei müssen Benutzername und Datenbankname natürlich an die eigene .env angepasst werden.

Das Ergebnis ist beispielsweise:

immich-database.sql.gz

Ein solcher logischer Datenbank-Dump ist besonders interessant, weil er unabhängig von einem simplen Kopieren der PostgreSQL-Dateien funktioniert.

Warum nicht einfach den laufenden PostgreSQL-Ordner kopieren?

Die PostgreSQL-Datenbank arbeitet permanent mit Dateien, Transaktionen und internen Zuständen.

Ein einfaches:

cp -r /srv/immich/postgres /backup/

während PostgreSQL läuft, ist deshalb keine empfehlenswerte logische Datenbanksicherung.

Besser sind:

• pg_dump
• Immich-Datenbank-Backup
• konsistente Storage-Snapshots
• professionelle PostgreSQL-Backup-Verfahren

DB_DATA_LOCATION sichern?

Bei einer Standardinstallation kann PostgreSQL beispielsweise über:

DB_DATA_LOCATION

einen eigenen persistenten Speicherbereich erhalten.

Dieser enthält die physische Datenbank.

Ein Snapshot dieses Bereichs kann Teil einer Gesamtstrategie sein.

Für eine portable Wiederherstellung ist ein SQL-Dump jedoch häufig einfacher zu handhaben.

Immich empfiehlt außerdem, den PostgreSQL-Datenspeicher auf lokalem SSD-Speicher zu betreiben und nicht auf Netzwerkfreigaben.

Datenbank auf SSD, Backup auf NAS

Eine sinnvolle Architektur kann daher so aussehen:

Immich-Server
│
├── NVMe
│   └── PostgreSQL
│
└── Backup
     │
     ▼
    NAS

Die produktive Datenbank profitiert von schneller lokaler Speicherung.

Das Backup kann anschließend auf einem größeren NAS abgelegt werden.

Bilder sichern

Die eigentlichen Medien können mit nahezu jedem vernünftigen Backup-Werkzeug gesichert werden.

Beispiele:

rsync
BorgBackup
Restic
Kopia
ZFS
Btrfs
Snapshots
NAS-Backupsoftware

Ein einfaches Beispiel mit rsync:

rsync -aHAX --delete \
/srv/immich/library/ \
/mnt/backup/immich/library/

Hier ist allerdings Vorsicht geboten:

--delete

löscht im Ziel Dateien, die an der Quelle nicht mehr existieren.

Das ist für einen echten Backup-Bestand ohne Versionierung nicht immer erwünscht.

Synchronisation ist kein Backup

Ein wichtiger Unterschied:

Quelle ─── Sync ───► Ziel

ist nicht automatisch ein Backup.

Wenn eine Datei versehentlich gelöscht wird und der Löschvorgang sofort synchronisiert wird, ist sie anschließend auf beiden Seiten weg.

Ein richtiges Backup sollte deshalb möglichst:

• Versionen aufbewahren
• Snapshots besitzen
• ältere Stände wiederherstellen können

BorgBackup als Beispiel

Immich stellt selbst ein Beispielskript bereit, das BorgBackup verwendet.

Darin werden lokale und entfernte Borg-Repositories genutzt.

Dabei können beispielsweise generierbare Verzeichnisse wie Thumbnails und transkodierte Videos ausgeschlossen werden, um Speicherplatz zu sparen.

Ein konzeptioneller Aufbau:

Immich
   │
   ▼
Borg Backup
   │
   ├── lokales Repository
   │
   └── Remote Repository

Borg bietet unter anderem:

• Deduplizierung
• Kompression
• Verschlüsselung
• Versionierung
• Retention
• Remote-Backups

Docker Volumes sichern

Bei Docker müssen wir unterscheiden zwischen:

Bind Mount

und:

Docker Volume

Ein Bind Mount zeigt beispielsweise:

volumes:
  - /srv/immich/library:/data

Dann befinden sich die eigentlichen Dateien direkt unter:

/srv/immich/library

Das ist für Backups vergleichsweise transparent.

Named Docker Volumes

Ein Docker-Volume könnte dagegen beispielsweise heißen:

immich_model-cache

oder:

pgdata

Solche Volumes werden von Docker verwaltet.

Sie sollten nicht einfach vergessen werden, nur weil sie nicht direkt im Immich-Verzeichnis sichtbar sind.

Mit:

docker volume ls

lassen sich vorhandene Volumes anzeigen.

Welche Docker-Daten müssen wirklich gesichert werden?

Nicht jeder Docker-Datensatz muss zwingend langfristig gesichert werden.

Eine sinnvolle Priorisierung lautet:

Kritisch

Originalmedien
PostgreSQL-Datenbank
.env
docker-compose.yml

Nützlich

Konfigurationsdateien
Reverse-Proxy-Konfiguration
Zertifikatskonfiguration
Backup-Skripte

Wiederherstellbar

Container Images
Machine-Learning-Modelle
Cache-Dateien
Thumbnails
teilweise transkodierte Dateien

Container selbst müssen üblicherweise nicht gesichert werden.

Sie können aus Images neu erzeugt werden.

Docker Compose sichern

Unbedingt ins Backup gehören:

docker-compose.yml

und:

.env

Die .env enthält wichtige Installationsparameter wie:

UPLOAD_LOCATION
DB_DATA_LOCATION
DB_USERNAME
DB_DATABASE_NAME
DB_PASSWORD

Damit lässt sich die ursprüngliche Installation wesentlich leichter rekonstruieren.

Vorsicht bei .env

Die .env kann Kennwörter und andere sensible Daten enthalten.

Sie sollte deshalb:

• verschlüsselt gesichert
• nicht öffentlich gespeichert
• nicht ungeschützt in Git veröffentlicht

werden.

Ein öffentliches GitHub-Repository ist kein geeigneter Speicherort für produktive Zugangsdaten.

Was ist mit Redis?

Immich verwendet Redis über BullMQ zur Verwaltung von Hintergrundjobs. Dazu gehören beispielsweise Verarbeitungsschritte, die weitere Jobs auslösen können. PostgreSQL ist dagegen der persistente Datenspeicher für Benutzer-, Asset-, Freigabe- und weitere Anwendungsinformationen.

Daraus ergibt sich eine wichtige Konsequenz:

Redis ist normalerweise nicht der zentrale Bestandteil eines langfristigen Immich-Backups.

Redis enthält hauptsächlich Queue-Zustände für Hintergrundaufgaben.

Bei einer vollständigen Infrastruktur-Sicherung kann Redis selbstverständlich mitgesichert werden.

Für Disaster Recovery haben aber normalerweise folgende Daten deutlich höhere Priorität:

1. Originalmedien
2. PostgreSQL
3. Konfiguration

Machine-Learning-Cache sichern?

Auch die Machine-Learning-Modelle beziehungsweise Model-Caches sind normalerweise nicht unersetzbar.

Immich kann entsprechende Modelle erneut herunterladen.

Ein Backup kann einen Restore beschleunigen, ist aber nicht zwingend vergleichbar mit der Sicherung der Originalbilder.

Konsistentes Backup

Ein kritischer Punkt ist die Reihenfolge des Backups.

Angenommen, während des Backups lädt ein Smartphone gleichzeitig neue Bilder hoch.

Dann könnte folgender Zustand entstehen:

Datenbank:
IMG_9999.JPG vorhanden

Dateibackup:
IMG_9999.JPG fehlt

Nach einer Wiederherstellung würde die Datenbank auf eine Datei zeigen, die im Backup nicht existiert.

Immich während des Backups stoppen

Die sauberste Variante ist deshalb:

Immich stoppen
      ↓
Datenbank sichern
      ↓
Dateien sichern
      ↓
Immich starten

Wenn währenddessen keine Änderungen stattfinden, bleiben Datenbank und Dateisystem konsistent.

Die Immich-Dokumentation nennt das Stoppen des immich-server-Containers als beste Möglichkeit, beide Teile synchron zu sichern.

Backup ohne Downtime

Nicht jeder möchte Immich für ein Backup stoppen.

Dann empfiehlt Immich folgende Reihenfolge:

1. Datenbank sichern
2. Dateisystem sichern

Warum?

Im schlimmsten Fall enthält das Dateisystem anschließend Dateien, die im älteren Datenbank-Backup noch nicht bekannt sind.

Diese Dateien lassen sich später erneut importieren.

Die umgekehrte Reihenfolge wäre problematischer:

1. Dateien
2. Datenbank

Dann könnte die neuere Datenbank Dateien referenzieren, die im älteren Dateibackup noch gar nicht enthalten sind.

Snapshot-Strategien

Dateisystem-Snapshots sind für Immich besonders interessant.

Geeignete Technologien sind beispielsweise:

ZFS
Btrfs
LVM
Storage-Snapshots
NAS-Snapshots
VM-Snapshots

Ein Snapshot erzeugt einen konsistenten Zustand zu einem bestimmten Zeitpunkt.

Beispielsweise:

10:00 Snapshot 1
12:00 Snapshot 2
18:00 Snapshot 3

Wird um 19:00 Uhr versehentlich ein Album gelöscht, kann gegebenenfalls auf einen früheren Zustand zurückgegriffen werden.

Snapshot ist nicht automatisch Backup

Ein Snapshot auf derselben Festplatte schützt allerdings nicht vor:

Festplattenausfall
Controllerdefekt
Diebstahl
Brand
Wasserschaden
Ransomware
Serververlust

Snapshots sind deshalb hervorragend als zusätzliche Ebene.

Sie ersetzen aber kein unabhängiges Backup.

Eine mögliche Snapshot-Strategie

Beispielsweise:

stündliche Snapshots     24 Stück
tägliche Snapshots        7 Stück
wöchentliche Snapshots    4 Stück
monatliche Snapshots     12 Stück

Damit kann sowohl auf sehr aktuelle als auch auf ältere Zustände zurückgegriffen werden.

3-2-1-Regel

Die klassische 3-2-1-Regel lautet:

3 Kopien der Daten

2 unterschiedliche Speichermedien

1 Kopie an einem anderen Standort

Für Immich könnte das so aussehen:

                Immich Server
                     │
                     │ Kopie 1
                     ▼
                Primärspeicher
                     │
             ┌───────┴────────┐
             │                │
             ▼                ▼
           NAS          Offsite Backup
         Kopie 2           Kopie 3

Immich empfiehlt ausdrücklich diese Strategie.

Offsite-Backup

Ein Backup im selben Gebäude schützt nicht gegen alle Risiken.

Angenommen:

Server im Keller
NAS im Keller

Bei einem Brand oder Wasserschaden können beide Systeme gleichzeitig verloren gehen.

Deshalb sollte mindestens eine Sicherung außerhalb des eigenen Standorts liegen.

Möglichkeiten für Offsite-Backups

Beispiele:

• zweites NAS bei Familienmitgliedern
• Backup-Server an einem anderen Standort
• verschlüsselter Cloud-Speicher
• S3-kompatibler Object Storage
• externe Festplatte außerhalb des Hauses
• Cold Storage

Die Immich-Dokumentation empfiehlt mindestens eine externe Kopie beziehungsweise Cold Storage außerhalb des eigenen Standorts.

Offsite unbedingt verschlüsseln

Fotosammlungen gehören zu den persönlichsten Daten überhaupt.

Ein externes Backup sollte daher möglichst verschlüsselt werden.

Werkzeuge wie:

Borg
Restic
Kopia

können verschlüsselte Backups erstellen.

Damit sieht der externe Speicheranbieter lediglich verschlüsselte Datenblöcke.

Beispielstrategie für zuhause

Ein realistischer Aufbau könnte so aussehen:

Immich-Server
│
├── 4 TB SSD/HDD
│
└── PostgreSQL auf NVMe
     │
     ▼
NAS
│
└── tägliches Backup
     │
     ▼
Remote NAS
│
└── verschlüsseltes Offsite-Backup

Zusätzlich:

Datenbankdump täglich
Snapshots stündlich
Offsite-Sync nachts

Damit existieren mehrere Schutzebenen.

Backup-Retention planen

Nicht jedes Backup muss dauerhaft gespeichert werden.

Eine typische Aufbewahrungsstrategie könnte sein:

7 tägliche Backups
4 wöchentliche Backups
12 monatliche Backups

oder:

14 täglich
8 wöchentlich
12 monatlich

Welche Strategie sinnvoll ist, hängt von:

• Speicherplatz
• Änderungsrate
• Bedeutung der Daten
• Recovery-Anforderungen

ab.

Das Backup regelmäßig testen

Das wichtigste Backup ist nicht das Backup, das erfolgreich erstellt wurde.

Es ist das Backup, das erfolgreich wiederhergestellt werden kann.

Deshalb sollten regelmäßig Restore-Tests durchgeführt werden.

Beispielsweise:

Quartalsweise
      ↓
Test-VM erstellen
      ↓
Immich installieren
      ↓
Backup einspielen
      ↓
Fotos prüfen
      ↓
Alben prüfen
      ↓
Benutzer prüfen

Erst dann wissen wir, ob das Backup wirklich funktioniert.

Datenbank über die Weboberfläche wiederherstellen

Immich bietet inzwischen eine direkte Wiederherstellung vorhandener Datenbank-Backups über die Weboberfläche.

Unter:

Administration
→ Maintenance

befindet sich der Bereich:

Restore database backup

Dort kann ein vorhandenes Backup ausgewählt und wiederhergestellt werden.

Dabei wird die aktuelle Datenbank ersetzt.

Vor der Wiederherstellung erzeugt Immich automatisch einen Restore Point, sodass bei einem Fehler ein Rückweg existiert.

Maintenance Mode

Für administrative Aufgaben wie Datenbank-Restores verfügt Immich über einen Maintenance Mode.

Dieser kann über die Administration aktiviert werden.

Währenddessen wird Immich in einen speziellen Wartungszustand versetzt.

Das ist besonders sinnvoll bei:

• Restore
• Reparaturen
• Wartung
• Migration

Manueller PostgreSQL-Restore

Auch eine manuelle Wiederherstellung ist möglich.

Die aktuelle Immich-Dokumentation beschreibt dafür einen Ablauf, bei dem zunächst die Container heruntergefahren, PostgreSQL gestartet und anschließend der Dump wieder eingespielt wird.

Vereinfacht:

Immich stoppen
      ↓
PostgreSQL zurücksetzen
      ↓
Datenbank starten
      ↓
SQL-Dump einspielen
      ↓
Medien zurückkopieren
      ↓
Immich starten

Bei einer echten Wiederherstellung sollte immer die Dokumentation der konkret eingesetzten Immich-Version verwendet werden.

Vorsicht bei Versionsunterschieden

Backup- und Restore-Verfahren können sich zwischen Immich-Versionen ändern.

Die offizielle Dokumentation weist ausdrücklich darauf hin, dass sich das Verfahren mit Immich v2.5.0 geändert hat.

Bei älteren Backups sollte daher die Dokumentationsversion ausgewählt werden, die zur Version des Backups passt.

Das ist für Disaster Recovery äußerst wichtig.

Restore der Mediendateien

Neben PostgreSQL müssen auch die eigentlichen Dateien wiederhergestellt werden.

Beispielsweise:

rsync -aHAX \
/mnt/backup/immich/library/ \
/srv/immich/library/

Danach sollten:

Besitzer
Gruppen
Berechtigungen
Pfad

zur ursprünglichen Installation passen.

Insbesondere:

UPLOAD_LOCATION

muss wieder korrekt gesetzt sein.

External Libraries separat betrachten

Wer externe Bibliotheken nutzt, muss auch diese in die Backup-Planung aufnehmen.

Beispielsweise:

NAS
└── /Fotos

Wenn dieses Archiv nur extern eingebunden wird, befindet es sich möglicherweise gar nicht im Immich-UPLOAD_LOCATION.

Dann benötigt es eine eigene Sicherungsstrategie.

Read-Only bedeutet nicht Backup

Auch eine schreibgeschützt eingebundene NAS-Bibliothek kann durch:

• Hardwaredefekt
• Dateisystemfehler
• NAS-Ausfall
• Brand

verloren gehen.

Read-Only schützt lediglich vor bestimmten unbeabsichtigten Änderungen durch den Immich-Container.

Es ersetzt keine Datensicherung.

Disaster-Recovery-Szenario

Nehmen wir einen Worst Case an:

Immich-Server komplett ausgefallen
SSD defekt
Betriebssystem verloren
Docker nicht mehr vorhanden

Vorhanden sind lediglich:

Docker Compose Backup
.env Backup
PostgreSQL Dump
Foto-Backup

Damit lässt sich die Installation grundsätzlich rekonstruieren.

Disaster Recovery Schritt für Schritt

Ein möglicher Ablauf:

Schritt 1 – Neues System installieren

Beispielsweise:

Debian 13

installieren.

Schritt 2 – Docker installieren

Docker Engine und das Docker Compose Plugin installieren.

Schritt 3 – Konfiguration wiederherstellen

Zurückkopieren:

docker-compose.yml
.env

Schritt 4 – Speicherpfade erstellen

Beispielsweise:

/srv/immich/library
/srv/immich/postgres

Schritt 5 – Mediendateien wiederherstellen

Foto- und Videobackup zurückspielen.

Schritt 6 – PostgreSQL wiederherstellen

Datenbankdump importieren.

Schritt 7 – Container starten

docker compose up -d

Schritt 8 – Installation prüfen

Kontrollieren:

• Anmeldung
• Benutzer
• Timeline
• Alben
• Freigaben
• Fotos
• Videos
• Suchfunktionen

Schritt 9 – Hintergrundjobs prüfen

Gegebenenfalls müssen:

• Thumbnails
• Smart Search
• Machine Learning
• Video-Transcoding

erneut verarbeitet werden.

Recovery Time Objective

Bei professionelleren Installationen sollte außerdem über das sogenannte:

RTO – Recovery Time Objective

nachgedacht werden.

Es beantwortet die Frage:

Wie lange darf Immich im Katastrophenfall ausfallen?

Für eine private Fotoplattform könnten beispielsweise:

24 Stunden

vertretbar sein.

Recovery Point Objective

Das:

RPO – Recovery Point Objective

beantwortet dagegen:

Wie viele Daten dürfen maximal verloren gehen?

Bei einem täglichen Backup:

maximal etwa 24 Stunden

Bei stündlichen Snapshots:

maximal etwa 1 Stunde

Diese Überlegungen helfen bei der Festlegung des Backup-Zeitplans.

Ein robustes Backup-Konzept

Für einen privaten Immich-Server könnte folgende Strategie sehr gut funktionieren:

PostgreSQL
│
├── automatisches Immich-Backup täglich
└── zusätzlicher pg_dump täglich

Originalmedien
│
└── Borg/Restic täglich

Dateisystem
│
└── Snapshots mehrmals täglich

Konfiguration
│
├── docker-compose.yml
└── .env

Backup-Ziele
│
├── lokales NAS
└── verschlüsseltes Offsite-Backup

Beispiel-Zeitplan

Eine mögliche Planung:

02:00  Immich Datenbank-Backup

02:30  Datei-Backup auf NAS

03:30  Offsite-Backup

stündlich
       Dateisystem-Snapshot

Sonntag
       längere Wochen-Retention

Monatsanfang
       Monatsbackup

Für sehr wichtige Sammlungen kann der Zeitplan natürlich deutlich enger gestaltet werden.

Vor einem Immich-Update

Vor größeren Updates sollte zusätzlich ein manuelles Backup durchgeführt werden.

Empfohlen:

1. Datenbank-Backup erzeugen
2. Medien-Backup prüfen
3. docker-compose.yml sichern
4. .env sichern
5. Immich aktualisieren

Damit existiert bei einem unerwarteten Problem ein definierter Rückweg.

Backup überwachen

Ein Backup-Skript, das jede Nacht läuft, ist nur dann hilfreich, wenn wir erfahren, wenn es plötzlich nicht mehr funktioniert.

Deshalb sollten Backups überwacht werden.

Interessant sind beispielsweise:

• Exit-Code
• Backup-Größe
• Laufzeit
• freier Speicherplatz
• letztes erfolgreiches Backup
• Fehlerprotokoll

Beispiel für eine einfache Kontrolle

Nach einem Backup könnte beispielsweise geprüft werden:

ls -lh /backup/immich/

oder automatisiert:

Backup erfolgreich:
2026-09-06 02:42

Ein Monitoring-System kann bei Fehlern zusätzlich eine E-Mail oder Push-Nachricht senden.

Backup gegen Ransomware schützen

Ein ständig beschreibbares NAS kann im schlimmsten Fall ebenfalls von Schadsoftware verschlüsselt werden.

Dagegen helfen beispielsweise:

immutable Snapshots
Read-Only Snapshots
Offline Backups
Object Lock
getrennte Zugangsdaten
Offsite-Sicherung

Eine zusätzliche externe Festplatte, die nur während des Backups angeschlossen wird, kann ebenfalls eine einfache Schutzebene darstellen.

Verschlüsselungsschlüssel sichern

Bei verschlüsselten Backups entsteht ein weiterer kritischer Punkt:

Backup vorhanden
+
Schlüssel verloren
=
Backup unbrauchbar

Der Wiederherstellungsschlüssel sollte deshalb separat und sicher dokumentiert werden.

Beispielsweise:

• Passwortmanager
• Offline-Kopie
• verschlüsselter Tresor
• physisch sicherer Ort

Dokumentation gehört zum Disaster Recovery

Im Ernstfall sollte niemand erst rekonstruieren müssen:

Wo liegt UPLOAD_LOCATION?
Welcher DB-Name wurde verwendet?
Welche Docker-Version?
Welche Domains?
Welcher Reverse Proxy?
Welche Mountpoints?
Wo ist das Offsite-Backup?

Eine kleine Disaster-Recovery-Dokumentation spart enorm viel Zeit.

Beispiel einer DR-Dokumentation

Immich Server:
photosrv01

URL:
https://fotos.example.de

UPLOAD_LOCATION:
/srv/immich/library

DB_DATA_LOCATION:
/srv/immich/postgres

Lokales Backup:
/mnt/backup/immich

Offsite:
Remote Backup Server

Backup:
täglich 02:00 Uhr

Retention:
14 täglich
8 wöchentlich
12 monatlich

Zugangsdaten sollten dabei selbstverständlich nicht unverschlüsselt in einem frei zugänglichen Dokument gespeichert werden.

Was sollte unbedingt getestet werden?

Ein vollständiger Restore-Test sollte mindestens kontrollieren:

Login funktioniert
Benutzer vorhanden
Fotos sichtbar
Videos abspielbar
Alben vorhanden
Freigaben vorhanden
EXIF-Daten vorhanden
Timeline korrekt
externe Bibliotheken erreichbar
Smart Search funktioniert
Gesichtserkennung vorhanden

Damit lässt sich wesentlich besser beurteilen, ob eine Wiederherstellung tatsächlich erfolgreich war.

Die ideale Reihenfolge

Zusammengefasst:

                IMMICH BACKUP
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
     PostgreSQL             Mediendaten
          │                     │
          └──────────┬──────────┘
                     │
                     ▼
                Konfiguration
                     │
                     ▼
              lokales Backup
                     │
                     ▼
              Offsite Backup
                     │
                     ▼
              Restore testen

Erst der letzte Schritt macht aus einer Backup-Datei eine belastbare Backup-Strategie.

Best Practices

Für eine sichere Immich-Installation empfehle ich folgende Grundregeln:

Originalmedien und PostgreSQL immer gemeinsam sichern.

Automatische Immich-Datenbank-Backups aktivieren.

Zusätzlich regelmäßig einen externen Backup-Lauf durchführen.

Docker-Konfiguration und .env sichern.

PostgreSQL nicht auf SMB oder NFS betreiben.

Snapshots als zusätzliche Schutzschicht einsetzen.

Mindestens eine Offsite-Kopie vorhalten.

Offsite-Backups verschlüsseln.

Alte Backup-Versionen aufbewahren.

Backup-Fehler überwachen.

Vor Updates zusätzliche Sicherung erzeugen.

Restore regelmäßig testen.

Bei Immich besteht ein vollständiges Backup nicht einfach aus einem kopierten Fotoordner.

Die eigentlichen Originalbilder und Videos sind zwar die wichtigsten Daten, doch ohne PostgreSQL fehlen zentrale Informationen über Benutzer, Alben, Freigaben, Assets und weitere Teile der Immich-Struktur.

Umgekehrt ist ein perfektes PostgreSQL-Backup nutzlos, wenn die darin referenzierten Originaldateien verloren gegangen sind.

Eine belastbare Immich-Sicherung besteht deshalb aus mindestens:

Originalmedien
+
PostgreSQL-Datenbank
+
Konfiguration

Snapshots ergänzen diese Strategie um schnelle Wiederherstellungspunkte, während ein zusätzliches Offsite-Backup vor Hardwaredefekten, Feuer, Diebstahl oder anderen Katastrophen schützt.

Mit einer konsequenten 3-2-1-Strategie lässt sich Immich damit genauso zuverlässig betreiben wie andere professionelle Datendienste.

Der entscheidende Punkt lautet jedoch:

Ein Backup ist erst dann ein echtes Backup, wenn die Wiederherstellung erfolgreich getestet wurde.

Wer seine Immich-Installation regelmäßig sichert, Backups außerhalb des Servers aufbewahrt und gelegentlich einen vollständigen Restore durchspielt, schützt damit nicht nur ein paar Dateien – sondern möglicherweise Jahrzehnte persönlicher Erinnerungen.

Im nächsten Teil unserer Serie beschäftigen wir uns mit der Performance von Immich. Wir zeigen, wie PostgreSQL, SSDs, RAM, CPU, GPU, Machine Learning, Netzwerk und Hintergrundjobs optimiert werden können, damit auch sehr große Fotoarchive flüssig bleiben.