diff --git a/ROADMAP.md b/ROADMAP.md
index d9eafcc..cbd8a34 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1225,8 +1225,15 @@ Die Statusseite sagt weiterhin `sicherung ok an 3 Orten`. Das ist wörtlich
 richtig — sie zählt Ablageorte, nicht Platten und nicht Gebäude. Wer daraus
 liest „also ist es sicher", liest mehr hinein, als dasteht.
 
-**Offen und bewusst offen:** ein Ziel außerhalb dieser Maschine. Die Kandidaten
-stehen in `docs/ideen.md`.
+**Und wo der Rechner steht, gehört dazu:** ein Windows-Root-Server **im
+Rechenzentrum**, bedient von zu Hause über mRemoteNG. Das macht ein Ziel beim
+Betreiber daheim nicht zu einem halben Schritt, sondern zum richtigen — zwei
+Gebäude, zwei Netze, zwei Anbieter.
+
+Dazu steht auf der Serverseite schon alles bereit: `sshd` läuft (Automatic,
+`0.0.0.0:22`), die Firewall lässt ihn durch, das SFTP-Subsystem ist an. Es
+fehlt ein Konto, das nur lesen darf — und ein Skript auf dem Heimrechner, das
+**holt**. Kandidaten und Begründung in `docs/ideen.md`.
 
 ### ⬜ Als Nächstes
 
diff --git a/docs/ideen.md b/docs/ideen.md
index 8401c28..6e1bf9c 100644
--- a/docs/ideen.md
+++ b/docs/ideen.md
@@ -138,28 +138,55 @@ die Oberfläche sie nicht ein zweites Mal hinschreibt.
 Bei 910 GB frei ist das heute keine Grenze, sondern eine Zusicherung: der
 Papierkorb kann nicht mehr unbemerkt zur zweiten Ablage werden.
 
-### Ein Ziel AUSSERHALB dieser Maschine — offen
+### Ein Ziel AUSSERHALB dieser Maschine — offen, aber der Weg steht fest
 
 Nachgemessen am 12.08.2026: **es verlässt heute nichts diesen Rechner.** Auch
-die Nextcloud nicht — sie läuft hier, in denselben Docker-Volumes, auf
-derselben Platte 0 wie die Daten. Details in der ROADMAP.
+die Nextcloud nicht — sie läuft hier, in denselben Docker-Volumes, auf derselben
+Platte 0 wie die Daten. Details in der ROADMAP.
 
-Gegen einen Plattenausfall ist gesorgt (`D:` ist eine eigene NVMe). Gegen
-Feuer, Diebstahl oder eine verschlüsselte Maschine ist es nicht.
-
-Kandidaten, mit dem, was sie wirklich können:
+**Wo dieser Rechner steht, ist dabei der entscheidende Punkt**, und er ist mir
+zuerst durchgerutscht: es ist ein Windows-Root-Server **im Rechenzentrum**. Der
+Betreiber sitzt zu Hause und ist per mRemoteNG verbunden. Das dreht die
+Bewertung um — eine Platte zu Hause ist nicht „dasselbe Haus", sondern zwei
+Gebäude, zwei Netze, zwei Stromkreise, zwei Anbieter. Besser wird ein
+Sicherungsziel kaum.
 
 | Weg | deckt ab | Haken |
 |---|---|---|
-| **Private PC holt ab** (`robocopy`/`rsync` vom PC aus) | Rechner tot, Server kompromittiert | PC muss laufen, wenn geholt wird |
-| **5-TB-Platte am Router** | Rechner tot | gleiches Haus; der Server darf schreiben, also erreicht Ransomware sie auch |
-| **5-TB-Platte am Server** | Plattenausfall | dritte Platte im selben Gehäuse, kein Gewinn gegen Feuer |
-| **Discord-Kanal** (nur der Bot, 993 KB/Tag) | Haus tot | 9 MB je Datei — für d4rk_media mit 336 MB unbrauchbar |
+| **Rechner zu Hause holt ab** | Platte, Rechner, Rechenzentrum, übernommener Server | muss laufen, wenn geholt wird |
+| **5-TB-Platte am Router**, vom Heimrechner beschrieben | dasselbe | Router-USB ist langsam; für 337 MB je Nacht reicht es |
+| **Discord-Kanal** (nur der Bot) | dasselbe | 9 MB je Datei — für d4rk_media mit 336 MB unbrauchbar |
+| 5-TB-Platte **am Server** | nur Plattenausfall | dritte Platte im selben Gehäuse — `D:` kann das schon |
 
-**Die Eigenschaft, auf die es ankommt, ist HOLEN statt SCHICKEN.** Ein Ziel, in
-das der Server selbst schreiben darf, ist auch ein Ziel, das ein übernommener
-Server löschen kann. Wer die Sicherung vom anderen Ende abholt, hält keine
-Zugangsdaten auf der Maschine, die geschützt werden soll.
+### Warum HOLEN und nicht SCHICKEN
+
+Ein Ziel, in das der Server selbst schreiben darf, ist auch eines, das ein
+übernommener Server löschen kann. Wer vom anderen Ende abholt, hält **keine
+Zugangsdaten auf der Maschine, die geschützt werden soll**. Das ist der eine
+Unterschied, der im Ernstfall zählt.
+
+### Was dafür schon dasteht
+
+```
+sshd            Running, Automatic, lauscht auf 0.0.0.0:22 und [::]:22
+Firewall        "OpenSSH SSH Server (sshd)" -> Allow
+sshd_config     Subsystem sftp sftp-server.exe
+                AllowGroups administrators "openssh users" sshusers
+                AuthorizedKeysFile .ssh/authorized_keys
+je Nacht        d4rk_media 335,9 MB + d4rkbot 0,9 MB = 336,9 MB
+```
+
+**Auf der Serverseite fehlt also nichts** außer einem Konto, das nur lesen darf.
+Der Rest ist ein Skript auf dem Heimrechner, das per SFTP zieht und N Stände
+behält.
+
+### Ein Fund am Rande, der dazugehört
+
+In `sshd_config` steht **kein** `PasswordAuthentication no`. Der Standard von
+OpenSSH ist `yes` — auf Port 22, offen ins Internet, auf einem Server, dessen
+`AllowGroups` die **Administratoren** einschließt. Wer ohnehin ein
+Sicherungskonto mit Schlüssel anlegt, sollte bei der Gelegenheit auf
+Schlüssel-only umstellen.
 
 ---