diff --git a/README.md b/README.md
index 7bfef85..29cea0a 100644
--- a/README.md
+++ b/README.md
@@ -545,6 +545,48 @@ Für den umgekehrten Fall – ein Eintrag, dessen Datei aus der Sicherung
 *nicht* zurückkam – zeigt derselbe Lauf die verwaisten Einträge und räumt sie
 auf Wunsch weg.
 
+### Der große Fall: alles zurück, ohne Postgres
+
+Einzelne Dateien zurückzuholen ist das eine. Der Ernstfall ist der andere:
+Der Server ist fort, aus der Sicherung kommen nur die **Dateien** zurück, die
+Datenbank ist leer.
+
+Das geht – aber nur in dieser Reihenfolge, und der zweite Schritt ist der,
+den man vergisst:
+
+1. **Dateien zurücklegen** nach `DATA_PATH`, mit der Struktur aus der
+   Sicherung (`users/<konto>/home/…`). Aether starten.
+2. **Konten neu anlegen – mit exakt denselben Benutzernamen.** Der Ordnername
+   auf der Platte *ist* die Zuordnung; ein Konto `mueller` findet nichts, was
+   unter `users/Mueller/` liegt. Passwörter dürfen neu sein, Namen nicht.
+3. **Admin → Audit → Rescan storage**, erst *Check*, dann *Apply*.
+
+Ohne Schritt 2 bleibt der Abgleich stehen und sagt es je Datei:
+`Konto "altnutzer" gibt es nicht`. Er rät nicht und legt nichts an – ein
+falsch zugeordnetes Dokument wäre schlimmer als ein unsichtbares.
+
+**Einmal geprobt, nicht behauptet** (10.09.2026): Auf einer eigens
+aufgesetzten Instanz Dateien gesichert, Container *und* Datenbank
+weggeworfen, nur die Dateien zurückgeholt. Nach den drei Schritten standen
+Ordnerkette, Unterordner, Umlaute im Dateinamen, Größen, Prüfsummen und
+Dateitypen wieder da, und der Download lieferte den ursprünglichen Inhalt.
+`.trash/` und `.versions/` blieben zu Recht außen vor. Ein dritter Abgleich
+meldete nichts Offenes mehr.
+
+**Was dabei nicht zurückkommt**, weil es nur in der Datenbank steht:
+Etiketten, Absender, Belegdatum, Freigabelinks, frühere Fassungen, der
+erkannte Text der Volltextsuche (er wird neu erzeugt), Kalender und Termine.
+Wem das wehtut, der sichert Postgres mit – die Dateien allein sind die
+Rückfallebene, nicht der volle Umfang.
+
+### Aktualisieren einer laufenden Instanz
+
+Neues Abbild ziehen und neu starten, mehr nicht: Die Migrationen laufen beim
+Start selbst. Geprobt am 10.09.2026 von Schema 19 auf 23 mit Daten in der
+Datenbank – Konten, Ordner, Dateien und Etikettenzuordnungen standen danach
+unverändert da, kein `dirty`-Zustand. **Ein Neuaufbau ist dafür nicht nötig
+und bringt nichts**, was das Update nicht auch bringt.
+
 ---
 
 ## Kalender (CalDAV)