Deep Dive
Google Fotos ablösen mit Immich
15.237 Fotos und Videos, sechs ZIP-Dateien und ein Wochenende: wie meine Bilder von Google nach Hause umgezogen sind, und warum der neue Speicher am Sonntagmorgen voll war.
Freitagabend, kurz vor halb zwölf. In meinem Bilder-Ordner liegen fünf frisch heruntergeladene ZIP-Dateien, vier davon knapp elf Gigabyte groß. Die sechste kommt erst am Samstagmorgen. Zusammen sind es 56 GB, und darin steckt alles, was bei Google Fotos lag. Die ältesten Bilder sind von 2002.
Wer schon einmal das Handy gewechselt hat, kennt die bange Frage danach: Sind wirklich alle Fotos mitgekommen? Hier ist sie eine Nummer größer, denn die Bilder sollen Google ganz verlassen und zu mir nach Hause ziehen. Am Samstag um 17:19 Uhr waren 15.237 Fotos und Videos umgezogen. Am Sonntag um 05:13 Uhr war der Speicher voll. Was dazwischen und danach passiert ist, erzählt dieser Artikel.
Er ist eine Vertiefung zur Serie über mein Homelab, also die kleine Rechnerlandschaft, die ich zu Hause selbst betreibe. Auf der Serienkarte sind wir in der Schicht „Dienste“, bei den Programmen, die ich tatsächlich benutze.
Warum überhaupt?
Google Fotos macht vieles richtig. Das Handy lädt jedes Bild hoch, die Suche findet Gesichter und Motive, Alben lassen sich mit zwei Klicks teilen.
Immich ist eine Foto-App, die man selbst betreibt. Sie kann erstaunlich viel von dem, was Google kann: Es gibt eine Web-Oberfläche und Apps für Android und iOS, und Immich erkennt Gesichter und Bildinhalte mit eigener Rechenkraft, ohne dass ein Bild das Haus verlässt.
Für mein Homelab gab das den Ausschlag. In Teil 1 habe ich mir vier Ziele gesetzt, zwei davon lauten „nichts aus dem Internet erreichbar“ und „alles wiederherstellbar“. Fotos gehören zu den persönlichsten Daten, die es gibt, also sollen sie genau dort liegen, wo diese Ziele gelten.
Im Gegenzug sind Plattenplatz, Arbeitsspeicher und Sicherungen jetzt meine Sache. Wie schnell man das merkt, zeigt dieses Wochenende ziemlich gut.
Wo Immich wohnt
Bevor die erste Datei hochgeladen werden kann, braucht Immich ein Zuhause. Bei mir bekommt jeder Dienst eine eigene virtuelle Maschine, kurz VM. Das ist ein Computer, den mein Server nur simuliert: Er hat eigene Festplatten, eigenen Arbeitsspeicher und ein eigenes Betriebssystem, teilt sich aber die echte Hardware mit den anderen VMs, ungefähr wie Wohnungen in einem Mehrfamilienhaus. Die VM für Immich heißt bei mir immich-01.
Von außen ist diese VM nicht zu erreichen. Meine Geräte sprechen über NetBird mit ihr, ein privates Netz, das über das normale Internet läuft, in das aber nur meine eigenen Geräte hineinkommen. Jede Verbindung darin läuft durch einen verschlüsselten Tunnel. Wie das genau funktioniert, erklärt Teil 2.
immich-01 hat zwei virtuelle Festplatten: 25 GB für das Betriebssystem und eine eigene Datenplatte für die Bilder. Die Datenplatte hatte anfangs 50 GB, und das war, wie sich zeigen sollte, für Google viel zu wenig. Zum Glück steht die Größe als Zahl in der Textdatei, aus der die VM gebaut wird (Teil 4). Am Samstag vor dem Import habe ich die Zahl von 50 auf 120 geändert, und die Platte wuchs im laufenden Betrieb mit.
Zoomen wir in die VM hinein. Immich ist kein einzelnes Programm, es besteht aus vier Teilen, die jeweils in einem eigenen Container laufen. Ein Container ist eine Art Umzugskarton für ein Programm: Darin steckt das Programm mit allem, was es braucht, und er lässt sich mit einem Befehl starten, stoppen oder gegen eine neuere Version tauschen. Das Werkzeug dafür heißt Docker. Die Tabelle zeigt die vier Container und was sie speichern:
| Container | Aufgabe | Daten |
|---|---|---|
| Server | Web-Oberfläche, nimmt Uploads von App und Import an | die Fotos und Videos |
| Machine Learning | erkennt Gesichter und beschreibt Bildinhalte für die Suche | die heruntergeladenen Erkennungsmodelle |
| Datenbank | merkt sich Alben, Personen, Aufnahmedaten und Suchinformationen | die Datenbank selbst |
| Warteschlange | verteilt die Arbeit an die Hintergrundjobs | keine |
Alle Daten der Container landen auf der Datenplatte. Die Fotos sind dabei der dicke Brocken, die Datenbank ist im Vergleich winzig. Diese Größenverhältnisse spielen am Sonntagmorgen noch eine Rolle.
Was in so einem Export steckt
Zurück zu den sechs ZIP-Dateien. Google nennt seinen Export Takeout. Wer ihn entpackt, findet Ordner wie „Fotos von 2014“, einen Ordner pro Album und neben fast jedem Bild eine zweite, kleine Datei mit einem Namen wie IMG_20200610_111724.jpg.supplemental-metadata.json.
Diese Begleitdateien sind so etwas wie ein Beipackzettel zu jedem Foto. Sie sind im JSON-Format geschrieben, einem einfachen Textformat für Daten, und darin stehen der Aufnahmezeitpunkt, der Titel und weitere Angaben wie der Ort. Ein Screenshot zum Beispiel trägt selbst kein Aufnahmedatum in sich und wüsste ohne seinen Beipackzettel nur noch, wann er exportiert wurde. Die Zeitleiste in Immich wäre dann ein einziger Tag im September 2026.
Es kommt noch besser. Foto und Beipackzettel liegen nicht einmal zuverlässig im selben ZIP: Bei einem Screenshot steckte das Bild in Archiv 2 und sein Beipackzettel in Archiv 1. Wer die Archive einzeln entpackt und hochlädt, verliert solche Paare.
Samstag, 17:02 Uhr
Deshalb habe ich gar nichts entpackt. Das kostenlose Werkzeug immich-go liest alle sechs ZIP-Dateien zugleich, sucht zu jedem Bild den passenden Beipackzettel, auch bei bearbeiteten Fassungen mit verändertem Namen, und lädt alles zu Immich hoch. Der Aufruf sah gekürzt so aus:
immich-go upload from-google-photos \
--server "$IMMICH_URL" --api-key "$IMMICH_API_KEY" \
--sync-albums --pause-immich-jobs \
takeout-*.zip
Die beiden Schalter in der dritten Zeile sind die interessanten. --sync-albums baut die Google-Alben in Immich nach. --pause-immich-jobs hält Immichs Hintergrundjobs an, solange der Import läuft. Das sind die Arbeiten, die Immich nach jedem neuen Bild erledigt, etwa Vorschaubilder rechnen und Gesichter suchen. So muss die VM nicht gleichzeitig 50 GB annehmen und rechnen, sondern arbeitet den Stapel danach in Ruhe ab.
Das Bild zeigt den Weg vom Export bis in die VM:
immich-go lief auf meinem Arbeitsplatzrechner und sprach über NetBird direkt mit immich-01. Um 17:19 Uhr, nach gut 17 Minuten, stand am Ende des Protokolls diese Bilanz:
| Ergebnis | Anzahl |
|---|---|
| gefunden: 14.420 Bilder und 817 Videos | 15.237 (50,3 GB) |
| neu hochgeladen | 14.100 |
| lag schon in Immich (fast alle von 2026) | 833 |
| doppelt im Export | 245 |
| aus dem Google-Papierkorb, verworfen | 13 |
| Fehler | 0 |
Die Videos sind übrigens nur gut fünf Prozent der Dateien, belegen aber 34 der 50 GB. Die 245 Doppelten sind Albumbilder, die im Export zweimal stehen, im Album- und im Jahresordner; immich-go lädt sie einmal hoch und hängt sie ins Album. Liegen blieben 766 Dateien, die immich-go als nutzlos einstufte, fast alle .MP-Dateien von Pixel-Handys. Was genau darin steckt, habe ich mir ehrlich gesagt noch nicht angesehen.
Null Fehler, Alben da, Zeitleiste stimmt. Ich war zufrieden und habe Feierabend gemacht.
Sonntag, 05:13 Uhr
Um zu verstehen, was in der Nacht passiert ist, muss man wissen, wie ich Immich sichere. Dafür gibt es bei mir zwei Arten von Sicherung, die Teil 6 ausführlich beschreibt.
Die VM-Sicherung läuft jede Nacht um 01:00 Uhr und sichert die ganze VM mit allen Platten auf einen Backup-Server, den ich bei Hetzner gemietet habe, also außer Haus. Das ist wie ein Foto der ganzen Wohnung. Die Dienst-Sicherung läuft um 03:30 Uhr und packt nur die Daten der Container in Archive. Sie legt die Archive zuerst auf der VM selbst ab und kopiert sie dann verschlüsselt in einen Cloud-Speicher, den man nach Gigabyte mietet. Damals packte sie alle Daten von Immich, auch die Fotos.
In der Nacht nach dem Import tat sie also genau das. Um 03:35 Uhr packte sie die frisch gefüllte Bibliothek, 58 GB, und schrieb das Archiv auf dieselbe Datenplatte, auf der die Fotos lagen. Danach war die 120-GB-Platte fast voll.
Um 05:13 Uhr kam das wöchentliche Update, das sonntags neue Versionen der Container holt. Es sichert vorher noch einmal, kam damit 4,7 GB weit und brach mit „No space left on device“ ab, kein Platz mehr auf dem Gerät. Die Datenbank konnte nichts mehr schreiben und stürzte ab, und Immich zeigte nur noch eine Fehlerseite. Auf meinem Handy landeten zwei Push-Nachrichten, eine für das gescheiterte Update und eine, weil Immich nicht mehr antwortete.
Zwei Archive löschen, Datenbank und Server neu starten, und Immich lief wieder. Interessanter war die Frage, warum die Fotos überhaupt zweimal auf derselben Platte lagen.
Fotos sind groß und ändern sich kaum, und für so etwas ist die VM-Sicherung ohnehin besser geeignet. Sie merkt sich, welche Teile der Platte sich seit der letzten Nacht geändert haben, und liest normalerweise nur diese. Seit jenem Sonntag sichert die Dienst-Sicherung deshalb nur noch die Datenbank, rund 250 MB. Die Fotos kommen mit der VM-Sicherung außer Haus, und die Erkennungsmodelle lädt Immich bei Bedarf einfach neu herunter.
Das Bild fasst zusammen, wie die VM heute aufgebaut ist und welche Daten auf welchem Weg gesichert werden:
Das Handy und die Anmeldung
Damit war der Altbestand sicher. Bleiben die Fotos, die jeden Tag neu dazukommen, und die kommen vom Handy.
Auf dem Handy läuft die Immich-App und daneben die NetBird-App, die das Handy in mein privates Netz holt. In der Immich-App steht als Serveradresse https://immich.home.example. Diese Adresse führt nicht direkt zur VM, sondern zu meinem Reverse Proxy. Das ist eine Art Pförtner: Er nimmt alle Anfragen an meine Dienste entgegen, kümmert sich um die Verschlüsselung zum Browser und reicht jede Anfrage an die richtige VM weiter, in diesem Fall an immich-01.
Bevor die App etwas hochladen darf, muss ich mich anmelden. Dafür nutze ich eine zentrale Anmeldung namens Authentik statt eines Passworts pro Dienst. Das funktioniert wie die Rezeption im Hotel: Ich weise mich einmal dort aus, und Immich vertraut dem, was Authentik bestätigt. Auf der Login-Seite von Immich erscheint dafür ein Knopf „Mit Authentik anmelden“.
Die Anmeldung öffnet kurz den Browser, und über eine besondere Rücksprungadresse findet das Handy danach zurück in die App. Das Bild zeigt beide Wege, erst die Anmeldung, dann den Upload:
So reist jedes neue Foto verschlüsselt durch mein privates Netz, und am Router zu Hause ist trotzdem kein einziger Zugang nach außen offen. Die Kehrseite: Ist NetBird auf dem Handy aus, findet die App den Server nicht.
Zehn Tage später
Fotos kosten nicht nur Platz. Mitte September wurde der Arbeitsspeicher meines Servers knapp. Ich habe deshalb bei fast allen VMs Ballooning eingeschaltet: Der Server darf einer VM Arbeitsspeicher wieder wegnehmen, wenn sie ihn gerade nicht braucht, aber nur bis zu einer Untergrenze. Bei immich-01 lag diese Untergrenze bei 2,5 von 4 GB.
Eine Woche später war Immich nicht erreichbar. Anmelden konnte ich mich an der VM auch nicht mehr. Nur ein kleiner Helfer in der VM, der unabhängig vom Netzwerk antwortet, meldete noch 118 MB freien Speicher. Im Systemprotokoll stand der Rest. Wenn der Arbeitsspeicher ganz ausgeht, beendet Linux kurzerhand Programme. Am späten Vorabend hatte es eine Viertelstunde lang alle ein bis drei Minuten das Erkennungsprogramm beendet, um 00:01 Uhr dann den Immich-Server selbst.
Ein direkter Befehl an den Server gab der VM sofort wieder Speicher. Danach bekam sie 6 GB höchstens und 5 GB mindestens, einen Neustart mit 40 Sekunden Ausfall, und die Last fiel von über 24 auf 1,9. Eine Aufgabe ist noch offen: Ich habe die Werte von Hand am Server geändert, sie müssen also noch in die Textdatei, aus der die VM gebaut wird. Sonst stellt der nächste Lauf die alten Werte wieder her.
Was bleibt
Die sechs ZIP-Dateien liegen übrigens bis heute in meinem Bilder-Ordner. Gelöscht habe ich sie noch nicht, obwohl die Bilder längst in Immich liegen und jede Nacht außer Haus gesichert werden. Mitgenommen habe ich vor allem zwei Dinge. Ein Google-Export ist mehr als ein Haufen Fotos, die Zeitleiste steckt in den Beipackzetteln. Und bei großen Datenmengen rechne ich jetzt doppelt, weil Fotos, Sicherungen und etwas Luft gleichzeitig auf die Platte passen müssen.
Immich ist nur einer der Dienste in dieser Schicht. Wie dort ein Brief aus dem Briefkasten in ein durchsuchbares Archiv kommt, mit Aufkleber, Scanner und einem lokalen Sprachmodell, erzählt Teil 3.