docs: Wiederherstellung ohne Postgres und Update geprobt, nicht behauptet

Beides auf einer eigens aufgesetzten Instanz durchgespielt:

* **Update einer laufenden Instanz**: Schema 19 -> 23 mit Daten in der
  Datenbank. Konten, Ordner, Dateien und Etikettenzuordnungen unveraendert,
  kein dirty-Zustand, /health 200. Ein Neuaufbau bringt nichts, was das
  Update nicht auch bringt.

* **Grosser Wiederherstellungsfall**: Container und Datenbank weggeworfen,
  nur die Dateien aus der Sicherung zurueck. Funktioniert -- aber nur, wenn
  die Konten vorher mit *demselben* Benutzernamen wieder angelegt werden.
  Der Ordnername auf der Platte ist die Zuordnung. Ohne diesen Schritt
  bleibt der Abgleich stehen und sagt es je Datei ("Konto ... gibt es
  nicht"); er raet nicht.

  Danach standen Ordnerkette, Unterordner, Umlaute, Groessen, Pruefsummen
  und Dateitypen wieder da, der Download lieferte den urspruenglichen
  Inhalt, .trash und .versions blieben aussen vor.

Dazu aufgeschrieben, was aus einer reinen Dateisicherung **nicht**
zurueckkommt: Etiketten, Absender, Belegdatum, Freigabelinks, fruehere
Fassungen, Kalender und Termine.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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)