phpBB.de

Dann sorry....

Mein Provider stellt ein php-Script für Backup zur Verfügung. Es wird über den Browser aufgerufen und es hat funktioniert. Danach habe ich den Link auf cronjobservice.net in meinem Cronjob eingetragen. Auch da hat es geklappt. Die Bestätigungsmail wurde mir auch zugesandt. Nur ein FTP-Übertrag und eine Löschung der lokal gesicherten Backupdatei gibt es (noch) nicht. Mein Provider bietet das nicht an und meinte, dass müsse separat programmiert werden.

Evtl. eine Serverfrage / Hosting .... :

Hi, wir reden über Linux (!?) oder den Apachen und über welche Konstellationen bzgl. MySQL mit oder ohne Zusatz = PHP-Erweiterung: mysqli?

*MSD-Ursprung (Version 1.24.4) benötigt PHP-5.6. (in meinem Falle steht auch diese PHP-Version auf dem Server noch zur Verfügung), um einen Aufruf über einen relativen Pfad via cgi-bin meines Wissens zu ermöglichen.

MySQLDumper-Version: 1.24.4
Betriebssystem: Linux
MySQL-Version: 5.7.25
PHP-Version: 5.6.40

MySQL-Version = Mit PHP-Erweiterung: mysqli

Weshalb die Entickler der neueren Generation dieses Konzept nicht verwirklichen oder anhand der Betriebssysteme (Server) nicht berücksichten könn(t)en, einbinden oder Hoster derartige Konfigurationen (Möglichkeiten) nicht berücksichtigen, ist aus meiner Sicht ein tatsächliches Rätsel.
Ich kann gar nicht glauben, dass es heutzutage Hoster gibt, die kein cgi-bin anbieten, so dass ein relativer Pfad für den Cron-Job verwendet werden kann.

Datenbankspezialistin bin ich allerdings nicht in allen Systemem - und/oder Konfigurationen ggf. via ...

.htaccess
==>
==> Einträge per AddHandler .... etc.
Zum Beispiel:
==> MSD-Ursprung (Version 1.24.4) in Zeile 1: AddHandler x-httpd-php56 .php .html

Der *) MSD funktioniert in meinem Falle für 21 Datenbanken derzeit noch immer.

BTW: *) Bei mir läuft sowohl sftp und webftp derzeit noch problemlos ...

Auch wenn ich ich mich hier in meiner Annahme vertue, erlaube ich mir diese Hinweise auf Server / SQL Konstellationen und den relativen Pfad. Falls es nicht grundsätzlich passt, entschuldige ich mich gerne um kein Durcheinander zu verursachen.

Grübelnde Grüße

@LuMaReMa, du sprichst in Sachen ALL-Inkl.com, ist das richtig? Gefunden habe ich lediglich ein Thema aus dem Jahr 2016 / 2019. Ob das noch immer in deinem Falle hilfreich ist, sein kann?

Sicherungen vor den Tests der Änderungem der DB etc. bitte nicht vergessen.

Falls noch nicht bekannt und sich signifikante Änderungen bis zum aktuellen Stand keine Konflikte ergeben, sei es zumindest am Rande erwähnt:

https://foren.myoos.de/viewtopic.php?p=4221#p4221

Grüße

@talk19zehn:

.htaccess
==>
==> Einträge per AddHandler .... etc.
Zum Beispiel:
==> MSD-Ursprung (Version 1.24.4) in Zeile 1: AddHandler x-httpd-php56 .php .html

Welche htaccess meinst du?

Danke für den Hinweis auf den Beitrag in myoos. Da in meinem Al-Incl-Paket keine Cronjobs enthalten sind benutze ich externe über cronjonservice.net.
Der Aufruf funktioniert ja auch einwandfrei: das Backup startet, bleibt aber immer an der gleichen Stelle nach 30sec ab.

Hallöchen, in meinem Falle existiert in oberster HTML-Ebene ein *)cgi-bin (Ordner). Darin liegen:
crondump.pl, perltest.pl, simpletest.pl

Im Ordner HTML -> „MySQLDumper“ liegen die Ordner und Dateien => MySQLDumper-Version: 1.24.4 und darin **)die .htaccess in der die Zeile 1 ergänzt / hinzugefügt

AddHandler x-httpd-php56 .php .html

ist. Somit startet der „MySQLDumper-1.24.4“ noch immer:
Den Cronjob kann ich nun per *)relativen Pfad ansprechen und somit die Sicherungen wie gewohnt ausführen. Das funktioniert nur, solang PHP V-5.6 noch auf dem Server zur Verfügung steht. Des Weiteren kann ich den „MySQLDumper-1.24.4“ wie gewohnt aufrufen und ggf. darin arbeiten: Einzelne Sicherungen anschubsen oder Datenbanken aufrufen etc.

Meine „Umwege“ sind darin begründet, da ich noch alte phpBB-Versionen auf dem Server liegen habe, denen jeweils eine entsprechende PHP-Version in der .htaccess zugewiesen worden ist (PHP V-5.6. – PHP V-7.4).

**) Der Aufruf etc. kann von Hoster zu Hoster natürlich völlig unterschiedlich geregelt sein.

Da nach meinen Informationen ein Multi-Dump beim MyOOSDumper der neueren Generation noch nicht möglich war, bin ich zunächst diese Wege im Jahr 2021 in Sachen „MySQLDumper-1.24.4“ gegangen. Die Datenbanken werden ohne Abbruch weiterhin gesichert.


Ich dachte zudem, dass der Hinweis auf den o.g. Beitrag auf foren.myoos.de ggf. für dich hilfreich sein könnte.

…(…)… „Der Dumper macht an der Stelle eigentlich nichts anderes, als den (relativen oder absoluten, je nach Aufruf) Server-Pfad auszulesen und anzuzeigen“.

Aufruf im Browser oder für externen Cronjob …
…(…)…

Ich habe mir schon den Kopf zerbrochen, warum in deinem Falle ein Abbruch nach 30 Sekunden erfolgt. Da der Dumper in der Regel das Limit „umgeht“. Eventuell ist es möglich, dass sich ein Spezialist deine MSD-Konfigurationen / Erfordernisse usw. ggf. per Teamviewer mal anschaut.

Ob das kostenpflichtig ist, vermag ich nicht zu beurteilen.

Viele Grüße

LuMaReMa hat geschrieben: 31.05.2022 22:52 Ich habe ein Problem mit dem MySQLDumper / MyOOSDUmper.

Wenn ich PHP-Backup ausführe (was nur manuell im Programm geht), werden alle Tabelle gesichert, die gepackte Datei per FTP übertragen und eine Fertigmail versendet.

Das ist auch völlig korrekt so, weil, wenn Du das Backup per PHP anstößt ist der Browser geöffnet und das PHP Timeout wird mittels rekursiver Selbstaufrufe mit Hilfe von Javascript umgangen

LuMaReMa hat geschrieben: 31.05.2022 22:52 Wenn das Perl-Script ausgeführt wird startet das Backup zwar, bricht aber nach 30 sec immer an der gleichen Tabelle ab.

Ich habe keine Idee, wo ich die Suche beginnen soll und woran es liegen könnte. Vielleicht gibt es ja ein "PerlProfi", der mir da helfen kann.

Dass das Backup nach 30 Sekunden abbricht, liegt an der (eingestellten) Laufzeit von PERL!
Hier funktioniert das Austricksen des Timeouts mittels Javascript-Selbstaufrufen eben nicht. Und wenn das Timeout erreicht ist (weil die Datenbank einfach zu groß ist und nicht innerhalb der 30 Sekunden gebackupt werden kann), ist halt Schluss.

Diese Art des Backups (PERL-Backup) funktioniert also nur solange, wie der Perl-Timeout des Servers nicht erreicht wird.
Bei All-Inkl zum Beispiel sind das meist zwischen 6 und 12 Sekunden.
Für kleinere Datenbanken, die komprimiert nur 4-5 MB ergeben, reicht das aus.
Wenn in der Datenbank allerdings so viele Datensätze stehen, dass zum Sichern mehr Zeit benötigt wird, als der Server zur Verfügung stellt, dann bricht das Script einfach ab.
Das Backup ist dann unvollständig! Man muss also darauf achten, dass am Ende der Log-Meldungen irgendwann mal ein #EOS (End of script) steht. Nur dann kann man sicher sein, dass dieses Backup im Notfall auch alle Datensätze enthält, die in der Datenbank gespeichert sind.

Grüße: Mahony

Hallo

LuMaReMa hat geschrieben: 01.06.2022 11:55

Heißt aber leider übersetzt: Diese Programme sind - bei größeren Datenbanken - unbrauchbar geworden. Schade!

Nein, das kann man soo nicht sagen, denn wenn man die Möglichkeit hat die Laufzeit von PERL zu erhöhen, dann funktioniert auch das automatisierte Backup mittels Cronjob (und mittels PHP funktioniert es ja eh, da dort das Timeout per Javascript-Selbstaufrufen umgangen wird).
UND das war auch noch nie anders!

Grüße: Mahony

Hallo

HaioPaio hat geschrieben: 01.06.2022 11:12 Es existiert noch keine Funktion um die php-Datensicherungsroutine als CRON Job laufen zu lassen.

DAS wird NIE passieren, weil es technisch nicht möglich ist das PERL-Timeout zu umgehen.
Hier hilft tatsächlich nur die Anhebung der PERL-Laufzeit.

siehe dazu auch die Erklärung hier >>> http://phpbb3-support.square7.ch/viewto ... 4682#p4682

Edit DSB:
Da immer wieder danach gefragt wird -> es gibt keine zuverlässige PHP-Alternative für das Automatisieren des Backups durch Aufruf einer PHP-Datei (Timeout-Problematik). Einige wollen besonders "clever" sein und rufen trotz unserer Erklärungen per Cronjob die Datei dump.php auf. Ein Cronjob ist kein Browser und so werden die Selbstaufrufe, welche durch Javascript realisiert sind, nicht ausgeführt, da dies normalerweise im Browser passiert. Das geht natürlich in die Hose und liefert keinesfalls ein vollständiges Backup!
Klipp und klar: kein Perl = keine Automatisierung des Backup-Vorgangs durch einen Cronjob!

Grüße: Mahony

Ich habe das auf AllIncl gefunden:
https://all-inkl.com/wichtig/anleitunge ... n_304.html

Kann man da was mit zaubern?

Und das hier:

Beachten Sie bitte, dass größere Datenbanken u.U. nicht per phpMyAdmin gesichert werden können, da das Script ggf. an Serverrestriktionen stößt!

Für diesen Fall empfehlen wir das Sichern der Daten mit einem externen Tool wie beispielsweise HeidiSQL.