KeyHelp Community

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
vermutlich ...

Server-Betriebssystem + Version
Debian 12.11 (64-bit) - 6.1.0-37-arm64

Eingesetzte Server-Virtualisierung-Technologie
KVM

KeyHelp-Version + Build-Nummer
KH: 25.1 (Build 3433)

Problembeschreibung / Fehlermeldungen
Vor 2 Tagen ist mir bei den KH SQL full backups aufgefallen das dass mysql.sql nicht vorhanden war wie bei den anderen dumps .. Start bei mysql.sql.1.
Ich habe dann ein cp -p mysql.sql.1 mysql.sql ausgeführt. Fehlermeldungen (siehe unten) die Größe (nur bei den mysql.sql.* Files bleibt immer gleich.
Da ist beim rename etwas schiefgelaufen, möglich wäre die Pause ist zu kurz (Überlappung) Zeile 348 01_maintenance.php zeigt ein Problem, ist aber ioncubed und nicht lesbar für mich.
Hier wurde ein mysql full dump als roundcube.sql.2 erstellt.

Erwartetes Ergebnis
möglicherweise zu kurze Pause vorm dem rename von tmp dump. also tmp dump sollte passend zum Namen sein

Tatsächliches Ergebnis

Code: Select all

[code]
[06-Jul-2025 00:00:02 Europe/Berlin] PHP Warning:  chmod(): No such file or directory in /home/keyhelp/www/keyhelp/functions/functions.main.php on line 2516
[06-Jul-2025 00:00:02 Europe/Berlin] PHP Warning:  rename(/home/keyhelp/keyhelp.backup/dumps/tmp.sql,/home/keyhelp/keyhelp.backup/dumps/roundcube.sql): No such file or directory in /home/keyhelp/www/keyhelp/cronjob/master/01_maintenance.php on line 348
[27-Jul-2025 00:00:02 Europe/Berlin] PHP Warning:  chmod(): No such file or directory in /home/keyhelp/www/keyhelp/functions/functions.main.php on line 2516
[27-Jul-2025 00:00:02 Europe/Berlin] PHP Warning:  rename(/home/keyhelp/keyhelp.backup/dumps/tmp.sql,/home/keyhelp/keyhelp.backup/dumps/mysql.sql): No such file or directory in /home/keyhelp/www/keyhelp/cronjob/master/01_maintenance.php on line 348

[/code]

Schritte zur Reproduktion

Zusätzliche Informationen

Hallo,

Das Problem muss beim mysqldump Befehl liegen (Bug?!). An Ensprechender Stelle führe ich mit

Code: Select all

mysqldump --routines --databases [...] '<DATENBANKNAME> > <PFAD>

Einen dump durch. Anschließend schaue ich mir den Exit-Code des Befehls an. Ist dieser 0 (== alles okay) wird normal weiter verfahren.

Das Problem in deinem Fall kann nur entstehen, wenn der Befehl eine 0 zurück gibt, es aber tatsächlich zu einem Problem gekommen ist und entweder kein Dump oder die Datei nicht erstellt werden konnte. Andernfalls werden die Zeilen, die im Fehlerprotokoll aufgeführt sind gar nicht ausgeführt.

Ich hab nun verschiedene Dinge probiert um dem Befehl eine 0 zu entlocken, wenn irgendetwas schief läuft. Das ist mir nicht gelungen und er hat jedesmal korrekt den Exit-Code zurückgegeben, wie man es bei korrekter Funktionsweise erwarten würde.

Ich würde das jetzt erstmal nicht überbewerten, ggf. kannst du zum fraglichen Zeitpunkt nochmal ins journalctl schauen, ob mariadb dort irgendwelche Probleme geloggt hat. Ansonsten bin ich natürlich darauf angewiesen, das Befehle korrekte Rückgabewerte liefern um deren Erfolg oder Fehlschlag zu bewerten.

Zumindest bist du nicht der Einzige, bei dem mysqldump mal einen falschen Rückgabewert liefert. Siehe letzter Beitrag: https://serverfault.com/questions/24985 ... n-a-status

Alexander wrote: ↑Tue 29. Jul 2025, 10:03 Ich würde das jetzt erstmal nicht überbewerten, ggf. kannst du zum fraglichen Zeitpunkt nochmal ins journalctl schauen, ob mariadb dort irgendwelche Probleme geloggt hat. Ansonsten bin ich natürlich darauf angewiesen, das Befehle korrekte Rückgabewerte liefern um deren Erfolg oder Fehlschlag zu bewerten.

Sieht für mich auch nach einem temp. Problem aus ... aber das rename danach ist irgendwo aus der Reihe mysql.sql1 - mysql.sql7 scheinen alle gleich.

Kann ich alles unter dem Ordner /home/keyhelp/keyhelp.backup/dumps/* löschen, oder werden die Dumps irgendwo aufgezeichnet bzgl. Reihenfolge?
Falls es möglich ist, wäre es vieleicht besser die Dumps direkt mit dem jeweiligen Namen zu erstellen anstatt > tmp.sql ...

Eventuell magst du den Dump um den Parameter „—quick“ ergänzen? Damit habe ich gute Erfahrungen gemacht.

Ebenso ist es mitunter erforderlich vor dem Dump die Datenbank zu reparieren damit der Dump ordnungsgemäß funktioniert.

@Ralph
Guggst du hier für eigene Backups:
viewtopic.php?t=11905

Eigene Backups sind ohnehin die Besten

Tobi wrote: ↑Tue 29. Jul 2025, 10:35 Eventuell magst du den Dump um den Parameter „—quick“ ergänzen? Damit habe ich gute Erfahrungen gemacht.

Danke, aber dieses Problem bezieht sich auf die täglichen KH internen SQL Dumps unter /home/keyhelp/keyhelp.backup/dumps.
Ich denke am besten wäre es wohl den Folder /home/keyhelp/keyhelp.backup/dumps zu leeren und dann morgen nochmal überprüfen ...

Ralph wrote: ↑Tue 29. Jul 2025, 10:33 Sieht für mich auch nach einem temp. Problem aus ... aber das rename danach ist irgendwo aus der Reihe mysql.sql1 - mysql.sql7 scheinen alle gleich.

Die ist bei mir i.d.R. auch immer gleich, wenn nicht gerade ein neuer DB-User angelegt wird. Kannst auch selbst mal ein Dump erstellen und schauen, wie groß es ist:

Code: Select all

mysqldump --routines --databases mysql > /tmp/mysql.sql

Ralph wrote: ↑Tue 29. Jul 2025, 10:33 Kann ich alles unter dem Ordner /home/keyhelp/keyhelp.backup/dumps/* löschen, oder werden die Dumps irgendwo aufgezeichnet bzgl. Reihenfolge?

Kannst du einfach löschen.

Ralph wrote: ↑Tue 29. Jul 2025, 10:33 Falls es möglich ist, wäre es vieleicht besser die Dumps direkt mit dem jeweiligen Namen zu erstellen anstatt > tmp.sql ...

Ich nenne die temporäre Datei nun wie die zu sichernde Datenbank, also mysql.tmp.sql, bevor ich dann rotiere und sie in z.B. mysql.sql umbenannt wird. Das verhindert zwar nicht, das mysqldump einen falschen Rückgabewert zurückgibt, aber das sollte das Phänomen verhindern, das im fall eines falschen Rückgabewertes die tmp.sql ggf. falsch bezeichnet wird.

Ralph wrote: ↑Tue 29. Jul 2025, 10:47
Tobi wrote: ↑Tue 29. Jul 2025, 10:35 Eventuell magst du den Dump um den Parameter „—quick“ ergänzen? Damit habe ich gute Erfahrungen gemacht.
Danke, aber dieses Problem bezieht sich auf die täglichen KH internen SQL Dumps unter /home/keyhelp/keyhelp.backup/dumps.
Ich denke am besten wäre es wohl den Folder /home/keyhelp/keyhelp.backup/dumps zu leeren und dann morgen nochmal überprüfen ...

Eigentlich war Alex gemeint…

Tobi wrote: ↑Tue 29. Jul 2025, 10:35 Eventuell magst du den Dump um den Parameter „—quick“ ergänzen? Damit habe ich gute Erfahrungen gemacht.

Das dürfte by Default bereits aktiviert sein. Zumindest skippe ich es nicht. Manpage:

Code: Select all

 --opt

           This option is shorthand. It is the same as specifying --add-drop-table --add-locks --create-options --disable-keys --extended-insert
           --lock-tables --quick --set-charset. It should give you a fast dump operation and produce a dump file that can be reloaded into a
           MariaDB server quickly.

           The --opt option is enabled by default. Use --skip-opt to disable it.  See the discussion at the beginning of this section for
           information about selectively enabling or disabling a subset of the options affected by --opt.

Tobi wrote: ↑Tue 29. Jul 2025, 12:08 Eigentlich war Alex gemeint…

Oh sorry Tobi

... quick sollte normalerweise bei dumps bereits greifen lt. mysqldump.cnf
Ok, ich hab jetzt mal ein backup von dumps gemacht und den Folder geleert, mal schauen wie es morgen aussieht.
Vieleicht ist irgendwo eine Verzögerung (Störung) aufgetreten während dem rename task und mysql.sql wurde zu roundcube.sql ... ist jetzt bei mir kein akutes Problem, aber bei einem restore könnte es eventl. Probl. machen.

Alexander wrote: ↑Tue 29. Jul 2025, 12:26
Tobi wrote: ↑Tue 29. Jul 2025, 10:35 Eventuell magst du den Dump um den Parameter „—quick“ ergänzen? Damit habe ich gute Erfahrungen gemacht.
Das dürfte by Default bereits aktiviert sein. Zumindest skippe ich es nicht. Manpage:
Code: Select all
 --opt

           This option is shorthand. It is the same as specifying --add-drop-table --add-locks --create-options --disable-keys --extended-insert
           --lock-tables --quick --set-charset. It should give you a fast dump operation and produce a dump file that can be reloaded into a
           MariaDB server quickly.

           The --opt option is enabled by default. Use --skip-opt to disable it.  See the discussion at the beginning of this section for
           information about selectively enabling or disabling a subset of the options affected by --opt.

RTFM…
Danke Alex!

Bisher alles ok ... ich war nur irritiert wg. der Größe von mysql.sql weil ich von einen kompletten full Dump ausging, enhält also nur DB Verweise und die MySQL User. Bei den geplanten Backups ist es dann vermutlich auch so, aber eine Frage dazu ...

Wenn ich jetzt NUR die Datenbanken (files & emails sichern nicht angehakt) via KH Backup task sichere (mysql und die user DBs) und dann einen restore durchführe, bleiben vorhandene Webs und Emails dann unberührt, oder wird durch einen Restore task ohne Files alles vom Backup abgeglichen (incl. delete email und web folder)?

Ich sichere alle Files via rsync, ist für mich besser zu managen z.b. restore einzelner Dateien geht schnell und Malware checks auf dem Backup system können sich Zeit lassen etc.

Wenn ich jetzt NUR die Datenbanken (files & emails sichern nicht angehakt) via KH Backup task sichere (mysql und die user DBs) und dann einen restore durchführe, bleiben vorhandene Webs und Emails dann unberührt, oder wird durch einen Restore task ohne Files alles vom Backup abgeglichen (incl. delete email und web folder)?

Es wird nichts gelöscht durch das Zurückspielen eines Backups.

KeyHelp Community

KH MySQL dump rename Fehler

KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler [GELÖST]

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler

Re: KH MySQL dump rename Fehler