fix: die Sicherung laedt wieder hoch -- ueber localhost statt ueber Cloudflare

Der naechtliche Lauf scheiterte mit HTTP 413. Nachgemessen mit drei Groessen,
statt geraten:

    1 KB -> 201 | 60 MB -> 201 | 340 MB -> 413, "Server: cloudflare"

cdn.d4rkst3r.de laeuft ueber Cloudflare, und das deckelt Uploads im Gratistarif
bei 100 MB. Das Archiv ist 336 MB. Weder der Proxy (client_max_body_size 0) noch
die Nextcloud (16 GB) waren es.

Bestellt war ein eigener Name ohne Cloudflare. Vorher aber geprueft, ob es den
ueberhaupt braucht -- und er braucht es nicht: die Nextcloud laeuft auf
DERSELBEN Maschine. Ueber http://localhost:11000 verlaesst der Verkehr die
Rueckschleife nicht, und "localhost" steht schon in trusted_domains. Kein DNS,
kein Zertifikat, kein Proxy, und nebenbei fuenfzehnmal schneller:

    ueber 192.168.100.1:11000   340 MB in 59 s
    ueber localhost:11000       340 MB in  4 s

Kein TLS dabei, und das ist in Ordnung: die Verbindung geht nicht hinaus.

Ganzer Lauf zur Gegenprobe: 4630 Eintraege, 335,9 MB, zweite Platte identisch,
hochgeladen 201, zurueckgeholt und verglichen identisch. Statusseite sagt
wieder "sicherung ok an 3 Orten".

WICHTIG, DAMIT NIEMAND ES FALSCH LIEST -- und das steht auch im Skript: diese
Kopie ist KEINE Auswaertskopie. Die Nextcloud liegt auf derselben Platte wie
die Daten. Sie ist die dritte Kopie, nicht der Weg aus dem Haus. Der fehlt
weiterhin.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-13 09:32:44 +02:00
co-authored by Claude Opus 5
parent f138df44a7
commit 6e654e0ef8
+23
View File
@@ -37,6 +37,29 @@
# 5. Alte Archive fliegen raus, an ALLEN drei Orten, sobald mehr als
# -Behalten da sind.
#
# WARUM localhost UND NICHT DER OEFFENTLICHE NAME. Am 13.08.2026 scheiterte der
# naechtliche Upload mit HTTP 413. Nachgemessen mit drei Groessen:
#
# 1 KB -> 201 | 60 MB -> 201 | 340 MB -> 413, "Server: cloudflare"
#
# cdn.d4rkst3r.de laeuft ueber Cloudflare, und das deckelt Uploads im
# Gratistarif bei 100 MB. Das Archiv ist 336 MB.
#
# Der Umweg war ohnehin unnoetig: die Nextcloud laeuft auf DERSELBEN Maschine.
# Ueber http://localhost:11000 geht der Verkehr gar nicht erst hinaus -- kein
# Cloudflare, kein Proxy, kein Zertifikat, und nebenbei fuenfzehnmal schneller:
#
# ueber 192.168.100.1:11000 340 MB in 59 s
# ueber localhost:11000 340 MB in 4 s
#
# Dass dabei kein TLS im Spiel ist, ist in Ordnung: die Verbindung verlaesst die
# Rueckschleife nicht. "localhost" steht bereits in Nextclouds trusted_domains.
#
# WICHTIG, DAMIT NIEMAND ES FALSCH LIEST: diese Kopie ist KEINE Auswaertskopie.
# Die Nextcloud liegt im selben Docker-Volume-Bereich auf derselben Platte wie
# die Daten. Sie ist die dritte Kopie, nicht der Weg aus dem Haus -- der fehlt
# weiterhin.
#
# WARUM CURL UND NICHT RCLONE. Nextcloud spricht WebDAV, curl spricht WebDAV,
# und curl ist ohnehin da. rclone waere ein weiteres Programm, das installiert,
# konfiguriert und aktuell gehalten werden will — fuer PUT, PROPFIND und DELETE