Backup bricht ab: "Progress of Table" - 201%

MyOOS [Dumper]ist ein Sicherungsprogramm für MySQL-Datenbanken. Damit können Sicherungskopien der Daten (Forum, Shop, Blog, usw.) erstellt und bei Bedarf auch wieder hergestellt werden. Besonders bei Web-Space ohne Shell-Zugang bietet sich MyOOS [Dumper] als sinnvolle Alternative an.
Antworten
gravima
Beiträge: 1
Registriert: 10.10.2019, 15:38

Backup bricht ab: "Progress of Table" - 201%

Beitrag von gravima »

Finde es super, dass ihr mySQLDumper weiter entwickelt. Leider bricht bei mir bei einer Datenbank der Backup ab bei "Progress of Table" bei 201%. Es kommt keine Fehlermeldung.

Auch im Log ist leider kein Hinweis zu finden:
"Log created."
"Start Dump 'xxx.sql.gz'"

Nutze PHP7.3. Es handelt sich hierbei um eine Datenbank mit~226MB von einem vBulletin System. Die Tabelle "cronlog" ist jedoch nicht sonderlich groß und auch ansonsten sehe ich auf Anhieb nichts auffälliges. Bin jedoch auch kein MySQL-Experte.

Habt ihr eine Idee woran das liegen könnte? Kann ich euch noch weitere Infos zusenden um diesem Problem auf den Grund zu gehen?
Dateianhänge
backup-breaks.jpg
backup-breaks.jpg (16.97 KiB) 3936 mal betrachtet
r23
Beiträge: 2625
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Re: Backup bricht ab: "Progress of Table" - 201%

Beitrag von r23 »

Hallo,

ich habe MySQLDumper jetzt auf 3 Systemen geprüft und keines erzeugt mehr als 100 Prozent.

Mit den zur Verfügung gestellten Informationen kann ich den Fehler leider nicht auf meinen Systemen abbilden.

Beste Grüße

Ralf
Jaydee
Beiträge: 7
Registriert: 06.12.2019, 11:29

Re: Backup bricht ab: "Progress of Table" - 201%

Beitrag von Jaydee »

Hallo,

ich sehe Deinen Thread gerade erst und kann vielleicht kurz darauf eingehen:
Diese seltsame "Prozentanzeige" kann eigentlich nur auf einen Fehler während der Ausführung zurück gehen, so etwas habe ich ebenfalls in den ca. 12 Jahren, in denen ich mit dem Dumper zu tun habe (auch aktiv im Support etc.) noch nicht ein einziges Mal gesehen.
Normalerweise wird beim PHP-Backup sowohl der Tabellen- als auch Gesamt-Fortschritt korrekt und bis 100% dargestellt.
Alles andere wäre ja allein auch schon mathematisch falsch, mehr als 100% kann logischerweise weder eine Tabelle noch Datenbank haben (wenn man nicht Überhänge fälschlicherweise separat rechnen möchte).

Diese falsche Anzeige ist aber nicht auf den Abbruch zurückzuführen bzw. auch nicht umgekehrt.
Dir wird schlicht das Script beim letzten Selbstaufruf ins Timeout gelaufen sein, also probiere bitte mal Folgendes:
Dem Screenshot nach hast Du die Konfiguration auf "Standard" gelassen, was die Ausführung betrifft (also 100 / 50000). Ich kenne jetzt die Leistungsfähigkeit und Konfiguration Deines Servers nicht,
Gerade der rechte Wert (also die Anzahl Datensätze, die maximal in einem Durchgang ausgelesen werden), ist besonders entscheidend für den Erfolg.
Setze den mal testweise auf 20.000 herunter (anschließend Konfiguration neu speichern) und starte ein neues Backup.

Falls erfolgreich -> setze ggf. den Wert in kleineren Schritten wieder höher, bis das Backup erneut abbricht, dann auf den letzten (erfolgreichen) Wert zurücksetzen.

Falls nicht erfolgreich -> setze den Wert noch niedriger, zum Beispiel auf 15.000 und teste erneut.

Den linken Wert kannst Du normalerweise auch höher setzen, z.B. auf 500 oder gar 1.000. Das schafft normalerweise selbst der schwächste Server locker.
Bei idealer Konfiguration ist das Backup ruckzuck durchgelaufen, 230 MB sind ja nun wirklich kein Ding.
ICh habe gestern noch testweise ein Backup auf einem schwächeren Shared-Server gezogen, die Datenbank hat ca. 1,5 GB und das lief in ca. 8,5 Minuten (was schon lange ist) via PHP durch.

Falls wirklich alles nicht hilft, kannst Du noch versuchen das Backup als "Multipart" auszuführen. Das beschleunigt zwar nicht den Durchlauf pro Aufruf, erzeugt aber mehrere kleinere Backup-Dateien (deren Größe Du vorher bestimmen kannst) und erleichtert ggf. das Handling eines Backups. Auch für mögliche FTP-Transfers usw.

Grundsätzlich: Der Dumper muss/sollte immer an die jeweilige Serverumgebung (vor allem PHP-Laufzeit/Timeout und gesamte Leistungsfähigkeit) angepasst werden. Die Vorgabe von 100 / 50.000 ist nur eine Empfehlung, die auf den meisten heutigen Servern klaglos funktioniert, aber trotzdem nicht auf allen. Vor allem Shared-Server mit kleineren Web-Tarifen schaffen die 50.000 auf gar keinen Fall, da muss ggf. drastisch reduziert werden. Ich betreue z.B.unter anderem einen, auf dem gerade 20.000 Datensätze klaglos in einem Rutsch durchgehen, 30.000 sind schon zu viel und führen ebenfalls bei größeren Tables zum Abbruch bei ca. 70 - 80%.

Viel Erfolg! :)
Antworten