Backup/Remote-FTP funktioniert nicht mehr

  • Hallo!


    Ich habe keine Ahnung, was ich angestellt habe oder was passiert ist:


    1. Bisher liefen meine Backups auf dem Server und FTP ohne Probleme: Über MyFritz wird auf den USB-Stick an meiner Fritz!Box zugegriffen und das Backup dort gespeichert.

    2. Nun habe ich vor kurzem den Stick geändert (Neben der höheren Speicherkapazität ist dieser nun ext4 formatiert und nicht FAT)

    3. Seit dem kommt es zu dem Effekt, dass auf dem Remote-Speicher keine Sicherungen mehr stattfinden:

    Unable to create the remote backup: Transport error: unable to check directory existence: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: QUIT Last FTP response: 221 Goodbye

    4. Ich habe mit FileZilla einen Zugang über die Fritzbox wie folgt eingerichtet:

    Server: <Buchstabensalat, den hier freilich keiner kennen soll ;-)>.myfritz.net

    Port: <5-stellig, auch nicht nennenswert>

    Protokoll: FTP – File Transfer Protocol

    Verschlüsselung: Wenn verfügbar, explizites FTP über TLS verwenden

    Verbindungsart: Normal

    Benutzer: tralala

    Passwort: Streng geheim


    So wird die Verbindung aufgebaut, ich kann Dateien erstellen und löschen.


    Die Einstellungen beim Plesk-Backupmanger für den Remote Speicher:

    Hostname oder IP des FTP-Servers *: <IP-Adresse>:<5-stellig, auch nicht nennenswert> (die gleiche wie bei FileZilla...)

    Verzeichnis zum Speichern von Backupdateien: <leer>

    FTP-Benutzername *: tralala (der geliche wie bei FileZilla...)

    FTP-Passwort: Streng geheim (das gleiche wie bei FileZilla – es wird allerdings überhaupt nichts angezeigt, auch keine Pünktchen)

    Häckchen bei "Passiv Modus verwenden"

    Häkchen bei "FTPS verwenden"


    Sodann auf OK geklickt, ca. 1,5 Minuten auf das dort erscheinende "Bitte warten" gestarrt und sodann erscheint:

    FTP(S) einsatzbereit

    Ich starte dann ein manuelles Backup, und erhalte nach paar Minuten obige Fehlermeldung per Mail.


    Ich habe auch im FileZilla mal die IP-Adresse angegeben und wurde einmal danach gefragt, ob ich dem Zertifikat trauen möchte, weil es ungültig sei. Mache ich freilich gerne...


    Auch habe ich probiert, im Remote-Speicher bei Plesk die URL anzugeben. keine Veränderung.


    Fritz-Box-Einstellungen müssen korrekt sein, sonst könnte ich ja nicht via FileZilla problemlos zugreifen.


    ZUDEM: Es scheint so zu sein, dass, wird beim Backup nicht nur auf dem Server selbst, sondern dazu auch auf dem FTP-Remote das Backup gespeichert und die Remote-Speicherung nicht fehlerlos durchgezogen werden kann, das Backup als nicht durchgeführt gilt. Was zu dem netten Effekt führt, dass eine Gesamtsicherung nach der anderen durchgeführt wird und keine inkrementelle Sicherung, wie ich es eingestellt habe (Vollsicherung nur wöchentlich). Ergebnis: Zugang gesperrt wegen Quata-Überschreitung. (Die Warnmeldung kam bei mir nicht an, weil ... egal, mein Fehler)


    Kann da jemand was dazu sagen? Weshalb funktioniert das über Plesk nicht, obwohl der Remote-Speicher als einsatzbereit gemeldet wird?


    Danke!!

    P.S: Meine test haben ergeben, das ext4/FTP wohl ohne belang sind – auch bei FTP erscheint obige Meldung...


    EDIT: Im Zuge meines Test habe ich ja via FileZilla eine Testdatei auf dem Remote-Speicher angelegt. Ebene entdecke ich dies meldung im Backup-Manager:

    Warnung: Einige Dateien im Speicher FTP werden nicht in der Liste angezeigt, da ihre Namen nicht der Namenskonvention für Backupdateien entsprechen. Wenn Sie sich sicher sind, dass die Dateien gültige Backups sind, benennen Sie sie nach dem folgenden Muster: "backup_hosting123267.a2fd0.netcup.net_.tar"

    Aha: Gelesen kann werden... die Verbindung steht also...

    Hat Webhosting 2000 SE de a1 und WordPress Multisite

  • Hast Du dafür eine Lösung gefunden? (Das Thema ist als Erledigt markiert und ich komme von hier: Plesk mag FTP der FritzBox nicht)

    Ich bekomme dieselbe Fehlermeldung vom netcup / plesk Backup Manager:

    Unable to create the remote backup: Transport error: unable to check directory existence: Curl error: (19) FTP: couldn't retrieve (RETR failed) the specified file: Last FTP request: QUIT Last FTP response: 221 Goodbye


    (der versucht vermutlich mit einem bestimmten FTP Befehl ein Verzeichnis Listing abzufragen was beim Fritz!Box FTP fehlschlägt)

    Die Warnung im Backup Manager wenn in dem Verzeichnis andere Dateien herumliegen, die nicht dem Schema entsprechen bekomme ich auch, nachdem ich zum Test ob mein Benutzer da überhaupt reinspeichern kann eine bier.txt übertrage.

    Warnung: Einige Dateien im Speicher FTP werden nicht in der Liste angezeigt, da ihre Namen nicht der Namenskonvention für Backupdateien entsprechen. Wenn Sie sich sicher sind, dass die Dateien gültige Backups sind, benennen Sie sie nach dem folgenden Muster: "backup_hosting123456.a2e5e.netcup.net_.tar"

    (vor dem .tar wird der Zeitstempel eingefügt also yymmddhhmm oder gerade eben backup_hosting123456.a2e5e.netcup.net_2204021824.tar)

    Ich habe bevor ich die TCP Dumps von der fritz.box ansehe einen ProFTPD auf meinem Raspberry Pi eingerichtet, eine Portweiterleitung an der Fritz!Box erstellt und dort hat das Ablegen des Backups auf Anhieb geklappt. Es wird z.B. durch den Backup-Manager zuerst ein check0 Ordner mit Datei test und zufälligem Inhalt auf dem FTP erstellt.


    Aktuelle Vermutung:
    Das Problem steckt vermutlich im netcup / plesk Onyx Backup-Manager und müsste beim netcup Support gemeldet werden. Die Suche nach der Meldung "Unable to create the remote backup: Transport error" ergibt zwar einen Treffer in einem Plesk Forum ... das ist aber ein IPv6 Thread und der Hinweis kommt wegen einer Domain die nur einen AAAA-Record hat: https://talk.plesk.com/threads…ackups.342070/post-903825

    WH8000 SE 🥚 20 | WH1000 SE OST22 | WH1000 SE OST23 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️

    4 Mal editiert, zuletzt von Copro () aus folgendem Grund: Themen ausbuddeln und dann nicht schauen, ob sie schon erledigt sind. Hinweise auf plesk Fehler ergänzt.

  • Nein Copro , eine wirkliche Lösung habe ich nicht gefunden, allerdings danach auch nicht weiter gesucht.


    Was damals wohl der Fall war ist, dass nach einem Fritz!Box-Update der FAT-Stick, auf dem gesichert wurde, deaktiviert war. (Man kann das in der USB-Übersicht sehen.) Das Verhalten konnte ich beim letzten Update nicht mehr beobachten.


    Was das Sichern auf einem ext4-Stick angeht, bin ich immer noch ratlos.Ich hab’s in letzter Zeit nicht wieder probiert, doch letzter Stand war, das Plesk das nicht schafft. Mein letztlich nur rudimentäres Wissen in solchen Dingen reicht da einfach nicht, um tiefer ins Problem zu schauen. Also verwende ich wieder den FAT-Stick und warte auf die gute Fee (w/d/m), die das Problem irgendwann löst... ;)

    Hat Webhosting 2000 SE de a1 und WordPress Multisite

  • Bestätigst Du mir bitte noch einmal kurz, dass ein Backup per FTP über den plesk Backup Manager auf Deiner Fritz!Box mit dem FAT Stick klappt.

    Bei mir und einem NTFS formatierten Stick habe ich ja dasselbe Problem wie Du mit dem ext4-Stick ... das würde eher auf ein Problem des in der Fritz!Box eingesetzten ftpd hinweisen.


    Wenn es Dir nichts ausmacht dokumentiere ich hier meine Analysen ... ich habe dem ProFTPD mit "bla" beigebracht alle FTP Befehle vom plesk mitzuprotokollieren.

    Das passiert wenn man ein Backup per FTP anstösst:

    LOG

    Mit dem WireShark Dump von der Fritz!Box sehe ich dass er tatsächlich all die Vorbereitungen erfolgreich abschliessen kann. Vielleicht passierte das so schnell, dass ich die Änderung am Verzeichnis selbst nicht mitbekommen habe. Es wird also Verzeichnis check0 mit Datei test angelegt und danach auch wieder gelöscht aber es kommt nie zum STOR.


    Wenn ich das WireShark Protokoll richtig lese fragt er aus irgendwelchen Gründen nach der SIZE der Backupdatei ohne die vorher hochgeladen zu haben und bekommt eine 550 Antwort vom ftpd der Fritz!Box. Und nachdem sich das Spielchen einige Male wiederholt, wird entnervt aufgegeben.

    Code
    > SIZE backup_hosting123456.a2e5e.netcup.net_2204021920.tar
    < 550 backup_hosting123456.a2e5e.netcup.net_2204021920.tar: not a plain file.


    Werde mir also nochmal den guten Ablauf ProFTPD neben den komischen vom AVM ftpd legen und genau schauen wo der abweicht.
    Aber ich denke nicht dass man so einfach an den plesk Source kommt oder eine Chance hat da nachzusehen ... das wird Support Mithilfe brauchen. Und einen Support Request bei plesk einreichen macht auch keinen Sinn weil Onyx seit dem 20.08.2021 EOL erreicht hat.

    WH8000 SE 🥚 20 | WH1000 SE OST22 | WH1000 SE OST23 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️

    4 Mal editiert, zuletzt von Copro () aus folgendem Grund: WireShark Log Auszüge ergänzt

  • Ja, Copro , ich habe eben noch mal in meiner Fritz!Box unter „Heimnetz | USB/Speicher“ nachgesehen: Das Backup erfolgt auf einem USB 2.0-Stick mit FAT-Dateisystem. Und das läuft ohne Probleme.


    Der Stick, auf dem ich nicht sichern konnte, ist wird mit „ext2“ als Dateisystem angezeigt.

    Hat Webhosting 2000 SE de a1 und WordPress Multisite

    Danke 1
  • Die erste Abweichung passiert vor dem STOR der Datei und während der ProFTPD beide Anfragen nach der Verzeichnisliste mit 226 beantwortet , kommt es beim AVM ftpd bei einem der Befehle zu einem 550. 226 gibt die erfolgreiche Verarbeitung des letzten Befehls und Schließen der Datenverbindung bekannt. 550 ist ein permanent negativer Fehler der das erneute Senden des auslösenden Befehls nicht empfiehlt.


    ProFTPD OK:
    > LIST

    < 226

    > NLST

    < 226


    AVM ftpd Nicht OK:
    > LIST

    < 150 Opening ASCII mode data connection for '/bin/ls -lgA'.

    < 226 Transfer complete.

    > NLST

    < 550 No files found.


    Das 550 hier schon beim NLST Befehl würde vielleicht den Teil der Fehlermeldung erklären: "unable to check directory existence"

    Es wird dann nochmals NLST und LIST probiert und dann trotzdem noch versucht die Größe der Datei auszugeben, die aber gar nicht hochgeladen wurde:

    > SIZE backup_hosting123456.a2e5e.netcup.net_2204021920.tar

    < 550 backup_hosting123456.a2e5e.netcup.net_2204021920.tar: not a plain file.

    Ganz zum Schluss nachdem auch das Vorhandensein der Datei mehrmals nicht bestätigt werden kann, wird aufgegeben.

    Ob sich das plesk Uploadscript wirklich verschluckt an der Antwort und diese Antwortcodes - speziell der 550 für den NLST auch in Ordnung sind kann ich nicht beurteilen.



    Was ich aber noch herausgefunden habe ist, dass es unter Umständen mit einige der aktuelleren FRITZ!OS Releases ein Rechteproblem bei den Ordnern gibt wenn diese per SMB und nicht mit per FTP erzeugt wurden. Also per SMB werden diese vom root User angelegt und vom FTP mit dem definierten FTP Benutzer. Evtl. spielt das Problem da mit rein nachdem der interne smbd gegen eine AVM eigene Implementierung ncqs getauscht wurde:

    [Problem] - FB 7490 mit ext4 SMB vs FTP Bug (Rechteproblem) - Sonst noch jemand? | IP Phone Forum (ip-phone-forum.de)
    Vielleicht hilft Dir da ja und Du kannst probieren den Ordner auf dem EXT4 Stick einfach auch komplett per FTP anzulegen.

    WH8000 SE 🥚 20 | WH1000 SE OST22 | WH1000 SE OST23 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️

  • Ich habe doch noch einen Workaround gefunden. Wenn man eine gültige Backup Datei im Verzeichnis ablegen kann, tritt der Fehler nicht mehr auf. =O

    Das sollte Dir auch helfen können Nikelaos - Du brauchst also nur eine der Backups vom FAT Stick auf den ext2 Stick ins Verzeichnis kopieren wo dann auf die Backups hinsollen.

    Wenn man betroffen ist und noch kein gültiges plesk Backup zuhause hat, kann man ja das erste Backup auf den Serverspeicher machen und ganz normal vom Webhost z.B. per FTP herunterladen. Dann warte ich mal, ob das auch noch bei jemand anderem das Problem löst.


    Falls der Support hier mitliest ... mit dem beschriebenen Workaround lässt sich das Problem lösen. Ich lasse aber gerne den Ausgangszustand für weitere Analysen auf meinem FTP bestehen.

    Weitere Überlegungen: (die aber nicht mehr sooo wichtig sind)

    Mit einer leeren Datei im richtigen Schema - z.B. von meinem Host a2e5e backup_hosting123456.a2e5e.netcup.net_2204032020.tar wird nur ein Fehler angezeigt weil er keine vernünftigen Archiv Metadaten findet. Evtl. könnte man so eine korrekte Minimalkonfiguration sogar basteln für jemand der es nicht schafft ein erstes Backup irgendwohin abzulegen. Das TAR enthält neben einer backup_info_datetimestamp.xml auch eine dump-header und dump-index ... ist also vermutlich nicht so trivial das auch noch zu überlisten. Aber wer schon ein gültiges Backup ziehen konnte ist vermutlich ja fein raus.

    WH8000 SE 🥚 20 | WH1000 SE OST22 | WH1000 SE OST23 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️

    Einmal editiert, zuletzt von Copro ()

    Gefällt mir 2
  • So, Copro , ich habe vor ein paar Tagen sämtliche Backup-Dateien vom FAT-USB auf den ext2-USB kopiert. Sodann in der FritzBox das Verzeichnis des Backup-Benutzers auf das Verzeichnis auf dem ext2-USB geändert.


    Und siehe: ES FUNKTIONIERT! Sowohl die inkrementellen wie die Vollbackups laufen jetzt ohne Probleme.


    Und JETZT ist das Thema erledigt (ich weiß nicht, wieso der Haken da erschienen ist...)


    Vielen Dank für die Unterstützung!

    Hat Webhosting 2000 SE de a1 und WordPress Multisite

    Ente gut, alles gut 1
  • Ich habe doch noch einen Workaround gefunden. Wenn man eine gültige Backup Datei im Verzeichnis ablegen kann, tritt der Fehler nicht mehr auf. =O

    Das sollte Dir auch helfen können Nikelaos - Du brauchst also nur eine der Backups vom FAT Stick auf den ext2 Stick ins Verzeichnis kopieren wo dann auf die Backups hinsollen.

    Vielen Dank für den genialen Einfall, der auch mein Backupproblem auf der Fritzbox gelöst hat. Vermutlich handelt es sich um ein Rechteproblem, welches die Fritzbox macht, wenn sie einen Ordner auf dem Datenträger via Webinterface anlegt.
    Was mir noch aufgefallen ist: Es muss gar keine gültige Backup-Datei sein, sondern es reicht theoretisch ein einfaches "touch" in der Bash - schon kann das Backup losgehen. Mal schauen, dass ich das noch an AVM nach Berlin melde.