Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Wiens Newsgroups: de.sci.electronics Subject: Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Date: Wed, 09 Sep 2026 16:48:05 +0200 Organization: none Lines: 72 Message-ID: <87wlsu1nzu.fsf@s-bot.de> References: <117pev1$60lu$1@solani.org> <117prg6$5oli$1@news1.tnib.de> <117qrcu$6vp1$1@solani.org> <117rf8s$8ivn$1@news1.tnib.de> <117rq31$7igm$1@solani.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: individual.net 4B7jXxZmMlXHdaaJ/YS1/AtCrit5FyOX8Ycijm5eHh4prnugk= Cancel-Lock: sha1:cwWOGFhkGm/EmdpdbpACJD1Iqsw= sha1:xaXKzJ0Ux9wAdOhrwxXJD6sSuS8= sha256:TNnJkImxly8PHPweo6opJ0JUE0nfiamdky4NNLLxZTQ= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Xref: csiph.com de.sci.electronics:369189 Helmut Schellong writes: > Marc Haber wrote on 09.09.2026 13:17: >> Helmut Schellong wrote: >>> Marc Haber wrote on 08.09.2026 22:34: >>>> Helmut Schellong wrote: >>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>>>> >>>>> Meine dritte Stufe - Backup ins Internet - hatte ich im Juli erfolgreich in Betrieb genommen. >>>>> Vier große (je 3..7 GB) verschlüsselte tar-Archive sind hochgeladen. >>>>> Geplant ist, daß das BAK dort einfach liegt und auf einen Bedarfsfall wartet. >>>>> Ungefähr alle drei Monate könnte das BAK (teilweise) aktualisiert werden. >>>>> >>>>> Zu aktueller Zeit (Sept) wollte ich mal teilweise neu hochladen. >>>>> Das funktionierte jedoch _diesmal_ nachhaltig nicht !!! >>>>> >>>>> Ich analysierte zwei Tage lang gründlich und fand heraus, daß beim Hochladen nach jeweils >>>>> 20 bis 30 Minuten die Verbindungen absichtlich >>>> >>>> ... von wem ...? >>>> >>>>> aus zeitlichen Gründen >>>> >>>> ... mit welcher Methode ...? >>> >>> Ich verwendete unter FreeBSD die Kommandos 'sftp' und 'scp' (scp -pC). >>> Mit scp kam ich jeweils etwas weiter als mit sftp, wegen Komprimierung. >>> Meine Kommandos meldeten stets, daß die Übertragung durch den remote host >>> abgebrochen wurde - broken pipe. >>> 'scp -pC -i /home/.ssh/id_ecdsa \!:1 u1234567@home7654321.1and1-data.host:\!:2' >>> >>> Ich versuchte an den beiden Testtagen mindestens 6 Uploads, die alle abgebrochen wurden. >>> Die Geschwindigkeit betrug 2..3 MB/s. >>> Tage später lag 5,1 MB/s vor, und der Upload von >7 GB gelang ohne Abbruch in etwa 13 Minuten. >>> Meine Testergebnisse sind halt eindeutig. >> Logs or it didnt happen. > > Ich habe auf der Wurzel meines Webspace ein Verzeichnis /log. > Daraus veröffentliche ich - nach Aufarbeitung - aber nichts. > >>>>> gekappt wurden! >>>>> Gekappt wurde nach 47..86% der vollen Datenmenge. >>>>> Diese jeweils zerbrochene Pipe hatte die Dateien am Zielort zerstört. >>>> >>>> Logs or it didn't happen. >>> >>> Im Zielverzeichnis liegen die Zieldateien nun mit zu geringer Abbruch-Size. >>> Sie werden zu Beginn des Uploads truncated... >> Ich möchte sehen was die Applikation auf der Konsole gesagt hat, was >> sie in ihre Logs geschrieben hat, und was gleichzeitig auf dem Netz >> los war. >> Du hast ja nichtmal gesagt, wo das Ziel der Kopieraktion ist, ob >> Firewall, Middlebox oder Zwangstrennung im Spiel ist, etc. >> So debuggen Zehnjährige. > > Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein > reichen mir meistens voll aus. > > Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, > und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, > so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. > Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! > > Ich bin ein Profi mit großer Erfahrung. > Genau deshalb komme ich ohne Zusatzarbeit aus. [...] Als Aechter Profi verzichtest du sicherlich auf screen(1)? -- Stefan