Backup-Probleme nach Update auf Version 24.0
Re: Backup-Probleme nach Update auf Version 24.0
Guten Morgen zusammen,
auch bei mir gab es erneut einen Fehler. Da mein bisheriger Anbieter für Backup nur diese Übertragung anbietet und mir keine weitere Wahl lässt, werde ich die Zusammenarbeit dort beenden und mir morgen eine KeyDisc zulegen. Für mich ist es keine Option, an einem Produktivsystem herumzubasteln.
auch bei mir gab es erneut einen Fehler. Da mein bisheriger Anbieter für Backup nur diese Übertragung anbietet und mir keine weitere Wahl lässt, werde ich die Zusammenarbeit dort beenden und mir morgen eine KeyDisc zulegen. Für mich ist es keine Option, an einem Produktivsystem herumzubasteln.
Freundliche Grüße von Henning
Re: Backup-Probleme nach Update auf Version 24.0
Weil der Backupserver nur via FTP(S) erreichbar ist. Als alternative könnte ein Zugang via CIFS oder NFS erfolgen, aber mit dem kenne ich mich nicht aus und SFTP steht leider nicht zu Verfügung.
Re: Backup-Probleme nach Update auf Version 24.0
Auf die Funktionsweise von Restic und Rclone habe ich leider keinen Einfluss. In der Regel gibt es regelmäßige Updates von Restic/Rclone. Die können in der Regel auch außerhalb von KeyHelp Updates eingespielt werden.
(restic self-update & rclone selfupdate)
Aktuell gibt es zum Beispiel ein Update für Restic auf Version 0.16.4. KeyHelp 24.0 kommt mit Restic 0.16.3. Laut Changelog sollte es allerdings keine Auswirkungen auf die Funktionalität innerhalb KeyHelp haben. Zumal ich die Ursache auch nicht bei Restic, sondern eher bei Rclone (für Datenübertragung zuständig) suchen würde.
Ich habe in der Vergangenheit immer mal wieder Fehlerberichte bei Rclone eingereicht, die dann daraufhin gefixt wurden. Hierbei war immer FTP in Kombination mit TLS das Problem. Damals konnte ich das Ganze mit speziellen Test-Fällen noch reproduzieren.
Als ich gestern versuchte, den hier gemeldeten Fehler zu reproduzieren, gelang es mir jedoch nicht (Getestet von einem Debian 12 auf ein Ubuntu 22 System mit FTP Server-Version "proftpd 1.3.7c") Was mich zum nächsten Punkt bringt.
Was auch eine eine Ursache für den FTP Fehler sein könnte: Alte FTP-Server Versionen auf den Zielsystemen. Solche Fälle gab es in der Vergangenheit auch schon. Das ist natürlich etwas, das nur der Hostinganbieter beantworten/beurteilen/beheben kann.
Z.B. den Fehler den Blickgerecht auf Seite 1 gepostet hat lässt darauf schließen, das der FTP Server ein Feature nicht beherrscht.
Mit freundlichen Grüßen / Best regards
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Re: Backup-Probleme nach Update auf Version 24.0
Danke für die Ausführliche Antwort. Das mit "alten FTP Server" könnte durchaus zutreffen. Ich werde mich mal beim Anbieter erkundigen.
-
- Posts: 72
- Joined: Tue 28. Nov 2023, 17:52
Re: Backup-Probleme nach Update auf Version 24.0
Wie versprochen, noch einmal Feedback nach einigen Tagen von uns: Seit der Umstellung auf SFTP läuft das bei uns auch einwandfrei durch.
Grüße
Roland
Roland
Re: Backup-Probleme nach Update auf Version 24.0
Auch ich habe bei nahezu allen meinen Server den selben Fehler, dass das Backup durchläuft und dann beim Bereinigen abbricht. Auf allen Servern läuft Keyhelp in der aktuellsten Version auf Debian 12.
Bei Debian 12 läuft ProFTPD in Version 1.3.8
Das Problem tritt nur mit FTPS-Verbindungen auf.
Ich habe auf dem FTP-Server folgende Fehler entdeckt, die mit der Thematik zu tun haben:
im Log /var/log/proftpd/proftpd.log findet sich folgende Meldung:
Das spiegelt sich auch im tls-log wider: (/var/log/proftpd/tls.log)
Auf Seiten Keyhelps, das auf dem zu sichernden Server läuft gibt es dann die Fehlermeldung:
Ich habe ProFTPD so konfiguriert, dass er nur TLS 1.3 akzeptiert.
Wenn ich die Meldungen so lese, vermute ich dass es an ProFTPD liegt. Besser gesagt am Modul mod_tls von ProFTPD
Demnach dürften FTP-Verbindungen das Problem nicht haben. Ich will das aber jetzt nicht ausprobieren, meine Daten unverschlüsselt durch Netz zu jagen....
Könnte es sein, dass es an TLS 1.3 liegt? oder am Cipher?
Ich habe das auch mit TLS 1.2 getestet: Gleicher Fehler...
Liegt es am Zusammenspiel von ProFTPD und openSSL?
Hat jemand eine Idee, wie man den OpenSSL-Fehler beheben kann?
Bei Debian 12 läuft ProFTPD in Version 1.3.8
Das Problem tritt nur mit FTPS-Verbindungen auf.
Ich habe auf dem FTP-Server folgende Fehler entdeckt, die mit der Thematik zu tun haben:
im Log /var/log/proftpd/proftpd.log findet sich folgende Meldung:
Code: Select all
mod_tls/2.9.2: unexpected OpenSSL error, disconnecting
Code: Select all
2024-04-19 16:10:42,193 mod_tls/2.9.2[155667]: TLS/TLS-C requested, starting TLS handshake
2024-04-19 16:10:42,220 mod_tls/2.9.2[155667]: TLSv1.3 connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits)
2024-04-19 16:10:42,344 mod_tls/2.9.2[155665]: Protection set to Private
2024-04-19 16:10:42,358 mod_tls/2.9.2[155665]: TLSv1.3 data connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits, resumed session)
2024-04-19 16:10:42,898 mod_tls/2.9.2[155419]: panic: SSL_ERROR_SYSCALL, line 11104: system error: Datenübergabe unterbrochen (broken pipe)
2024-04-19 16:10:42,898 mod_tls/2.9.2[155419]: unexpected OpenSSL error, disconnecting
Code: Select all
Failed to prune repository: Remove(<lock/fda1fe071c>) returned error, retrying after 1.004040118s: blob not removed, server response: 500 Internal Server Error (500)
rclone: 2024/04/19 16:00:43 ERROR : locks/
Wenn ich die Meldungen so lese, vermute ich dass es an ProFTPD liegt. Besser gesagt am Modul mod_tls von ProFTPD
Demnach dürften FTP-Verbindungen das Problem nicht haben. Ich will das aber jetzt nicht ausprobieren, meine Daten unverschlüsselt durch Netz zu jagen....
Könnte es sein, dass es an TLS 1.3 liegt? oder am Cipher?
Ich habe das auch mit TLS 1.2 getestet: Gleicher Fehler...
Code: Select all
2024-04-19 17:18:19,178 mod_tls/2.9.2[167555]: TLSv1.2 data connection accepted, using cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)
2024-04-19 17:18:22,180 mod_tls/2.9.2[167552]: panic: SSL_ERROR_SYSCALL, line 11104: system error: Datenübergabe unterbrochen (broken pipe)
2024-04-19 17:18:22,180 mod_tls/2.9.2[167552]: unexpected OpenSSL error, disconnecting
Hat jemand eine Idee, wie man den OpenSSL-Fehler beheben kann?
Re: Backup-Probleme nach Update auf Version 24.0
FTP war Schrott und ist Schrott auch mit angeschraubter Verschlüsselung (FTPS). SFTP läuft ohne Probleme.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Backup-Probleme nach Update auf Version 24.0
Du kannst problemlos auf unverschlüsseltens FTP umstellen, da das Backup selbst schon verschlüsselt ist.
Gruß,
Tobi
-----------------------------
wewoco.de
Das Forum für Reseller, Digital-Agenturen, Bildschirmarbeiter und Mäuseschubser
Tobi
-----------------------------
wewoco.de
Das Forum für Reseller, Digital-Agenturen, Bildschirmarbeiter und Mäuseschubser
Re: Backup-Probleme nach Update auf Version 24.0
Da gebe ich dir recht. Ich vermeide FTPS eigentlich so gut ich kann...FTP war Schrott und ist Schrott auch mit angeschraubter Verschlüsselung (FTPS). SFTP läuft ohne Probleme.
Ich wollte nur, dass jeder Server beim Backup nur sein Verzeichnis auf dem Backup-Server sehen kann und nicht die Ordner der anderen Server. Bei SFTP hat der User in KeyHelp ja Zugriff auf den ganzen Server... (Außer in KeyHelp Pro mit chroot)
Danke für den Hinweis. Dann teste ich das doch mal mit FTP only...Du kannst problemlos auf unverschlüsseltens FTP umstellen, da das Backup selbst schon verschlüsselt ist.
Re: Backup-Probleme nach Update auf Version 24.0
Ach, das Target ist auch KeyHelp?JensE wrote: ↑Fri 19. Apr 2024, 18:34 Da gebe ich dir recht. Ich vermeide FTPS eigentlich so gut ich kann...
Ich wollte nur, dass jeder Server beim Backup nur sein Verzeichnis auf dem Backup-Server sehen kann und nicht die Ordner der anderen Server. Bei SFTP hat der User in KeyHelp ja Zugriff auf den ganzen Server... (Außer in KeyHelp Pro mit chroot)
ProFTPd kann auch SFTP, aber ich weiß nicht, ob man das unterKeyHelp anflanschen kann. Nutze kein FTP.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Backup-Probleme nach Update auf Version 24.0
Ja, beide Systeme laufen mit KeyHelp. Der zu sichernde Server und der Backup-Server...
Ich habe das jetzt mit FTP only getestet, und da lief alles problemlos durch. Das ist aber nicht was ich will.
Aber ich habe jetzt eine Lösung mit SFTP gefunden, die mir besser gefällt.
Ziel:
Jeder zu sichernde Server soll auf dem Backup-Server nichts von den anderen Servern sehen können und das soll über SFTP mit SSH-Keys laufen (nicht mit Passwort).
Vorgehensweise:
Dazu benötigt man auf dem Backup-Server für die zu sichernden Server eine SSH-Umbebung mit chroot.
Für jeden zu sichernden Server wird dazu auf dem Backup-Server in KeyHelp ein eigener Kunde angelegt.
Dieser Kunde hat nur folgende Berechtigungen:
Speicherplatz und Traffic unbegrenzt, Zugriff auf SSH, Datei-Manager und Control-Panel
Ab jetzt geht es in der Konsole des Backup-Servers weiter und wir müssen uns dort als root anmelden.
Um den Kunden-Account des zu sichernden Servers in einer chroot-Umgebung einzusperren, genügt es diesen Account der Gruppe keyhelp_chroot hinzuzufügen:
Zur Info: Um den Kunden-Account wieder aus dieser Gruppe zu entfernen, kann man folgenden Befehl verwenden...
Damit haben wir für den zu sichernden Server schon mal die SSH-chroot-Umgebung, aus der er nicht ausbrechen kann. Dieser Account hat keinen Zugriff auf die Konsole, aber man kann den Zugang verwenden um das Backup über SFTP auf dem Backup-Server zu speichern.
Nun bereiten wir alles vor, um den öffentlichen Schlüssel, den wir auf dem zu sichernden Server erstellen werden auf dem Backup-Server zu hinterlegen. Dazu brauchen wir die Datei ~/.ssh/authorized_keys mit dem richtigen Besitzer und Rechten...
Datei anlegen:
Den Besitzer korrigieren, da diese Datei aktuell root gehört:
und nun noch die richtigen Rechte: (nur der Kunde selbst darf Zugriff auf diese Datei haben...)
Wir legen noch ein Verzeichnis an, in dem wir das Backup speichern wollen z.B. im Home-Ordner/files/ des Kundenaccounts mit dem richtigen Besitzer:
Jetzt müssen wir nur noch den öffentlichen Schlüssel auf dem zu sichernden Server generieren und im Backup-Server hinterlegen:
Dazu melden wir uns beim zu sichernden Server in KeyHelp an und legen ein neues Repository für das Backup an.
Dort wählen wir SFTP aus und als Authentifizierungsmethode "Öffentlicher / Privater Schlüssel", den wir dort mit einem Klick generieren und kopieren können.
Das Repository aber noch nicht speichern. Wir müssen den öffentlichen Schlüssel erst auf dem Backup-Server hinterlegen.
Dazu gehen wir wieder in die Konsole des Backup-Servers und öffnen die vorher angelegte Datei authorized_keys und kopieren dort den öffentlichen Schlüssel hinein:
Jetzt können wir auf dem zu sichernden Server das Repository speichern und wenn alles geklappt hat, sollte das Repository angelegt worden sein.
Nun legen wir noch einen regelmäßigen Backup-Plan an und das Backup läuft...
Das war jetzt eine Menge Text, aber wem dieses Vorgehen gefällt, kann das übernehmen.
LG Jens
Ich habe das jetzt mit FTP only getestet, und da lief alles problemlos durch. Das ist aber nicht was ich will.
Aber ich habe jetzt eine Lösung mit SFTP gefunden, die mir besser gefällt.
Ziel:
Jeder zu sichernde Server soll auf dem Backup-Server nichts von den anderen Servern sehen können und das soll über SFTP mit SSH-Keys laufen (nicht mit Passwort).
Vorgehensweise:
Dazu benötigt man auf dem Backup-Server für die zu sichernden Server eine SSH-Umbebung mit chroot.
Für jeden zu sichernden Server wird dazu auf dem Backup-Server in KeyHelp ein eigener Kunde angelegt.
Dieser Kunde hat nur folgende Berechtigungen:
Speicherplatz und Traffic unbegrenzt, Zugriff auf SSH, Datei-Manager und Control-Panel
Ab jetzt geht es in der Konsole des Backup-Servers weiter und wir müssen uns dort als root anmelden.
Um den Kunden-Account des zu sichernden Servers in einer chroot-Umgebung einzusperren, genügt es diesen Account der Gruppe keyhelp_chroot hinzuzufügen:
Code: Select all
usermod -aG keyhelp_chroot USERNAME
Code: Select all
gpasswd -d USERNAME keyhelp_chroot
Nun bereiten wir alles vor, um den öffentlichen Schlüssel, den wir auf dem zu sichernden Server erstellen werden auf dem Backup-Server zu hinterlegen. Dazu brauchen wir die Datei ~/.ssh/authorized_keys mit dem richtigen Besitzer und Rechten...
Datei anlegen:
Code: Select all
> /home/users/USERNAME/.ssh/authorized_keys
Code: Select all
chown USERNAME:USERNAME /home/users/USERNAME/.ssh/authorized_keys
Code: Select all
chmod 700 /home/users/USERNAME/.ssh/authorized_keys
Code: Select all
mkdir /home/users/USERNAME/files/backup
chown USERNAME:USERNAME /home/users/USERNAME/files/backup
Dazu melden wir uns beim zu sichernden Server in KeyHelp an und legen ein neues Repository für das Backup an.
Dort wählen wir SFTP aus und als Authentifizierungsmethode "Öffentlicher / Privater Schlüssel", den wir dort mit einem Klick generieren und kopieren können.
Das Repository aber noch nicht speichern. Wir müssen den öffentlichen Schlüssel erst auf dem Backup-Server hinterlegen.
Dazu gehen wir wieder in die Konsole des Backup-Servers und öffnen die vorher angelegte Datei authorized_keys und kopieren dort den öffentlichen Schlüssel hinein:
Code: Select all
vim /home/users/USERNAME/.ssh/authorized_keys
Nun legen wir noch einen regelmäßigen Backup-Plan an und das Backup läuft...
Das war jetzt eine Menge Text, aber wem dieses Vorgehen gefällt, kann das übernehmen.
LG Jens
Re: Backup-Probleme nach Update auf Version 24.0
Top! Gefällt mir, gut beschrieben.
Yes Es gibt auch noch Lösungen ohne nano
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.