Jo mein Problem war dass die PS den PubKey mit Pfadangabe nicht genommen hat.
Ja, passiert schnell mal wenn der Pfad z.b. Leerzeichen hat. Da kann aber das "Umklammern" mit Anführungszeichen des Pfads Abhilfe schaffen.
-
-
Eigentlich geht es ja hier darum, ob der MyOOS-Dumper eine Alternative zum früheren MySQL-Dumper ist.
-
Da ich ja früher zur MySQLDumper-Zeit auch zum dortigen Team gehörte und hier wiederholt die Frage aufkam, warum man überhaupt ein derartiges Tool benötigt, kann ich vielleicht auch etwas dazu sagen:
Diese Frage kam auch dort im Support-Forum manchmal auf und die Antwort ist (wie auch teils hier schon erwähnt wurde) ganz einfach:
Weil
- längst nicht alle Admins über eigene Server verfügen, sondern beispielsweise auf Shared ohne SSH-Berechtigung liegen
- dort meistens nur "Standard"-Tools wie das fehlerträchtige phpMyAdmin zur DB-Verwaltung angeboten werden, die aber zur Sicherung größerer Datenbanken via PHP ungeeignet sind (Timeout-Gefahr durch kurze Script-Laufzeiten)
- gerade der MySQLDumper/MyOOSDumper dieses Problem durch ständige (frei konfigurierbare) Selbstaufrufe im Browser umgeht und
- dazu etliche komfortable Funktionen zur DB-Verwaltung bietet,
- deutlich komfortabler mittels GUI zu bedienen ist als beispielsweise SSH via PuTTY-Client (damit muss man sich auskennen und das tun längst nicht alle Admins)
- nicht zuletzt damit bei Bedarf auch sehr einfach einzelne Tabellen wiederhergestellt werden können (z.B nur alle User-Tables)
- sich damit sehr einfach Cronjobs per PERL-Script einrichten lassen, z.B: zur täglichen Sicherung
Nichtsdestotrotz ist falls möglich natürlich SSH/Konsole vorzuziehen, keine Frage. Zumal damit eine Sicherung deutlich schneller läuft als über einen Browser.
Für komplette Backups/Restores reicht das allemal und lässt sich ja ebenfalls als Cron ausführen.
WENN aber der Dumper verwendet wird, empfehle ich dringend unbedingt sofort den Verzeichnis-Schutz via .htaccess/.htpasswd einzurichten! . Das geht direkt über das Tool bei der Einrichtung, aber auch später jederzeit.
Denn man darf nie vergessen, dass jeder diesen Pfad erraten kann und somit vollen Zugriff auf die DB hätte, wenn nicht geschützt!
Das war leider damals auch manchmal Thema bei uns im Support, da manche Admins das nicht für nötig halten (aber auch nicht wissen, was die damit riskieren). Ein .htaccess-Schutz ist hingegen praktisch nicht zu umgehen, da dazu Server-Zugriff (oder ein KeyLogger zum Passwort-Abgriff) nötig wäre und wenn ein Unbefugter diesen Zugriff hat, ist eh alles zu spät bzw. wurde dann etwas gründlich falsch gemacht....
-
sich damit sehr einfach Cronjobs per PERL-Script einrichten lassen, z.B: zur täglichen Sicherung
hast du zufällig ein fertiges Script ?
-
Das befindet sich als Perl-Script bereits innerhalb des Dumpers (sofern es nicht in aktuellen Versionen entfernt wurde, das entzieht sich gerade meiner Kenntnis) und muss nur passend eingerichtet werden.
Du hinterlegst Deinen absoluten Server-Pfad zur Installation und lässt anschließend den Perl-Test 1x durchlaufen. Meldet der "OK", kannst Du im Anschluss sofort ein manuelles Backup via Perl im Dumper anstoßen.
Läuft auch das ohne Abbruch, gibt Dein Server diese Möglichkeit her und es spricht nichts mehr gegen die Einrichtung eines Cronjobs. Was dazu im Einzelen an Einträgen nötig ist, hängt von Deinem Hoster ab und weicht ab, je nach Crontab und Admin-Panel.
Im damaligen MySQLDumper-Forum hatte ich vor vielen Jahren mal die Konfigurationen diverser Hoster samt Screenshots gepostet, aber das Forum hat Daniel ja leider platt gemacht, da es nach Einstellung der Weiter-Entwicklung nicht mehr benötigt wurde.
Nachtrag: Der absolute Pfad zur Config muss in die Datei crondump.pl eingetragen werden.
-
Ich habe mit dem MyOOS-Dumper die Datenbank gesichert und mit Filezilla den Webspace gesichert.
Wie kann ich prüfen, ob beides richtig abgespeichert wurde?
-
Backups testet man üblicherweise mittels Restore. Am besten auf einem anderen Server und auf jeden Fall mit einer anderen Datenbank.
-
Indem du es irgendwo wiederherstellst und schaust, ob Probleme (auch beim Aufruf von Bildern z.B.) auftreten oder die Systemüberprüfung Fehler meldet.
Einen einfachen Weg die Korrektheit des Backups zu prüfen gibt es nicht wirklich.
-
ich weiß nicht, ob Ihr das kennt?
könnte man das mit XAMPP testen?
-
Ja.
-
mit dem MyOOS-Dumper
Wie kann ich prüfen, ob beides richtig abgespeichert wurde?
Was die DB betrifft, ist das gerade im Dumper eigentlich sehr eindeutig: Sobald z.B. das Perl-Script erfolgreich durchgelaufen ist, meldet es am Ende automatisch sinngemäß das hier:
QuoteEverythings is done: closing script xx.11.2021 xx:25:09
total time used: xxx sec. (genaue Sekundenangabe, die das Script aktuell benötigt hat)
#EOS (End of script)
sowie kurz darüber das hier:
QuoteFinished backup of database `db1234567890`.
Beim Backup via PHP-Script ist der Wortlaut etwas anders, aber sinngemäß ebenso verbindlich und mit Zeitangabe.
Anderenfalls, wenn z.B. die DB inkonsistent bzw. fehlerhaft ist oder es zu Verbindungsabbrüchen durch Timeout (oder Server-Ausfall etc.) kommt, bekommst Du eine entsprechende Fehlermeldung und auf KEINEN FALL ein "EOS" am Ende.
Das ist soweit schon verlässlich, garantiert aber natürlich trotzdem nicht, dass die DB bzw. einzelne Tabellen in sich nicht defekt ist/sind (die aber nicht zu Script-Abbrüchen führen würden). Das Backup spiegelt natürlich immer nur 1:1 den aktuellen Zustand einer Datenbank wieder, ggf. auch mit allen "Fehlern".
Aber sowohl "Fehlermeldung" als auch "Erfolgsmeldung" sind durchaus verbindlich.
Um letztliche Gewissheit zu erlangen, hilft (wie die Kollegen oben schon erwähnten) natürlich nur ein Restore samt Überprüfung (ob alles wie gewünscht funktioniert).
Ansonsten kannst Du mit dem Dumper auch automatisiert (Cronjob) oder per manuellem Aufruf des Backups ältere Backups löschen lassen. Dazu lässt sich in der Konfiguration eine beliebige Anzahl Sicherungen vorgeben, die erhalten bleiben sollen (z.B. die der letzten 7 Tage, was normal völlig reicht). Die älteren würden dann bei jedem Aufruf automatisch gelöscht. Gibt es aktuell keine älteren außerhalb diese gewählten Zahl, wird auch das exakt gemeldet.
Diese diversen Meldungen kannst Du auch per Mail erhalten, falls gewünscht. Wahlweise direkt über den Dumper, oder halt über die Cronjobs Deines Hosters (geht also im Extremfall auch doppelt).
-
Ich markiere (Kreis) und dann leere ich (siehe Pfeil) die Datenbank bevor ich sie neu einspiele? Das ist korrekt oder?
-
Löschen, nicht leeren!
-
Löschen, nicht leeren!
ich dachte leeren, ok dann weiß ich Bescheid, Danke
-
Zum einen das (löschen), zum anderen kannst Du den Vorgang auch direkt im Dumper automatisieren:
Konfiguration -> Allgemein -> Wiederherstellung -> Datenbank vor Wiederherstellung löschen: dort das Häkchen setzen und neu speichern.
-
so würde ich es dann einstellen.....
-
Genau diese Option meine ich, ja.
Dein Screenshot hilft vielleicht auch anderen Usern, die sie suchen. Wobei der genannte Pfad glaube ich schon recht eindeutig war.
-
Eventuell erhält der MyOOS [Dumper] zukünftig auch ein automatisches Update-Skript, zumindest steht dies auf der Wunschliste.
So ein Script wäre mehr als angebracht, denn derzeit muss man den MyOOS [Dumper] bei jedem Update komplett (außer den Backups) deinstallieren und anschließend erneut installieren.
-
derzeit muss man den MyOOS [Dumper] bei jedem Update komplett (außer den Backups) deinstallieren und anschließend erneut installieren.
das wollte ich schon erfragen. Jetzt weiß ich Bescheid
-
Eventuell erhält der MyOOS [Dumper] zukünftig auch ein automatisches Update-Skript, zumindest steht dies auf der Wunschliste.
So ein Script wäre mehr als angebracht, denn derzeit muss man den MyOOS [Dumper] bei jedem Update komplett (außer den Backups) deinstallieren und anschließend erneut installieren.
Hallo Webmark
sorry für doppelpost
Wann Eventuell erhält der MyOOS [Dumper] zukünftig auch ein automatisches Update-Skript, wo kann ich das nachlesen?
hier? https://github.com/r23/MyOOS/releases ? mein englisch ist nicht so gut.
P.S
Hier habe ich etwas gefunden https://foren.myoos.de/viewforum.php?f=41
so wie es scheint, ist der Support ausgelastet
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!
