Hallo,
mysqldump ist ein Tool des MySQL-Servers, der ein deutlich tieferen Einblick in die Datenbanken bekommt und auch nutzen kann, als es MySQL-Dumper jemals könnte, da dieser als "Client" sich mit dem Server verbindet.
Das ist inkorrekt. mysqldump agiert genau so als Client wie MySQLDumper es tut. Ein direkter Zugriff auf den Tablespace erfolgt nicht. Beide Tools haben bei identischem Nutzer den Zugriff auf die gleichen Informationen.
Man muss sich nicht überlegen, ob man nun UTF-8 oder doch ein ISO-8859-1 Datenbank hat, oder ob man gar UTF-16 oder 32, genau so wenig muss man sich gedanken machen, dass das Programm sich aufhängen könnte, weil die Backup-Datei zugroß ist.
Also ich habe soweit ich mich erinnere den gewünschten Zeichensatz fest angegeben (sowohl beim Sichern als auch beim Wiederherstellen).
QuoteIch find es toll, dass du dich da mit SSH und den Standardwerkzeugen beschäftigt hast, und wirklich so schwer ist es ja nun wirklich nicht.
Nein, echt einfacher und schneller als mit Dumper und Web-FTP.
Der Forenordner (8 MB) und die Datenbank (3 MB) sind ja in einer Sekunde gesichert und auch wieder eingespielt.
Das nenne ich mal schnell. 
@Teralios: Was bedeutet der PHP-Code in Deinem Beitrag? Habe null Ahnung davon. 
Das ist inkorrekt. mysqldump agiert genau so als Client wie MySQLDumper es tut.
Mhm? Dann hab ich da was falsch in der Erinnerung gehabt.
Ändert aber an den weiteren Punkten nicht viel.
Was bedeutet der PHP-Code in Deinem Beitrag? Habe null Ahnung davon.
Ach, da geht es darum, wie die Passwörter gesichert werden, mit denen der Zugriff auf MySQL-Dumper gesichert werde soll. Stark vereinfacht: sehr unsicher.
Also ich habe soweit ich mich erinnere den gewünschten Zeichensatz fest angegeben (sowohl beim Sichern als auch beim Wiederherstellen).
Die Funktion haben sie dann auch hinzugefügt später. Ändert aber nichts daran, dass man bei MySQL-Dumper da aufpassen musste früher und anscheinend auch Heute noch, womit das "einfacher" einfach nicht stimmt.
Die Funktion haben sie dann auch hinzugefügt später. Ändert aber nichts daran, dass man bei MySQL-Dumper da aufpassen musste früher und anscheinend auch Heute noch, womit das "einfacher" einfach nicht stimmt.
Also ich glaube ich sichere seit jeher mit dem Zeichensatz UTF-8. Dass Smileys andere Zeichensätze erfordern, lese ich zum ersten Mal, das sind doch nur Bilder... 
Also ich glaube ich sichere seit jeher mit dem Zeichensatz UTF-8. Dass Smileys andere Zeichensätze erfordern, lese ich zum ersten Mal, das sind doch nur Bilder...
... 😀👈🏻 kein 📷, sondern ein Zeichen. Gehören zu Unicode und sind theoretisch UTF-8, aber:
Und deswegen kann es zu Problemen kommen und MySQL-Dumper scheint diese nicht abzufangen.
Ah. Wenn man die nur ein für alle mal sperren könnte. Muss ich etwas beachten, wenn ich per mysqldump einen Dump mit dem Zeichensatz UTF-8 erzeuge, also kein UTF8-Irgendwas? Habe da bislang noch keine Probleme festgestellt. 
Nur ist MySQL-Dumper selbst zu doof zu erkennen, dass die Daten nach utf8_mb4 gespeichert werden müssen - Emoji-Unterstützung z. B. - sondern nutzt vermutlich utf8_ci
Ich habe mich diesbezüglich an den Support von MyOOS gewandt.
Ergebnis: Ab der kommenden für den 21.07.21 geplanten Version wird utf8mb4 als Standard gesetzt. Siehe: https://github.com/r23/MyOOS/c…1114fa11ee13cefa3e5a73340.
Man kann sich aber auch bereits jetzt behelfen, indem man folgende Änderung vornimmt.
In
~/mod/inc/mysqli.php
Zeile 265
function mod_mysqli_connect($encoding='utf8', $keycheck_off=false, $actual_table='')nach
function mod_mysqli_connect($encoding='utf8mb4', $keycheck_off=false, $actual_table='')ändern.
Zudem habe ich meinen Webhoster gefragt, weshalb kein Zugang über SSH ermöglicht wird.
Gekürzte Antwort
QuoteWir bieten aus Sicherheitsgründen keinen SSH Zugang mehr an, weil ein SSH Zugang fast gleichzusetzen ist mit dem Zugang den ein Server-Administrator hat. Wir haben festgestellt, dass da Kunden Befehle eingetippt haben, die freundlich ausgedrückt das Gemeinwohl auf dem Server gefährdet haben.
Diese Aussage scheint mir durchaus plausibel zu sein, denn welche sonstigen Gründe sollte es geben, dass ein Webhoster die vormals implementierte Funktion wieder entfernt hat?
@Teralios Besten Dank für deine Argumente, doch wie du siehst gibt es eben auch Webhoster die einen Zugang über SSH ganz bewusst nicht anbieten.
Klar könnte ich den Webhoster bei dem ich seit dem Start meines Forums (2008) bin wechseln, doch ich fühle mich dort über all die Jahre hinweg sehr gut betreut und selbst bei größeren Problemen wurde mir stets umgehend geholfen.
Diese Aussage scheint mir durchaus plausibel zu sein, denn welche sonstigen Gründe sollte es geben, dass ein Webhoster die vormals implementierte Funktion wieder entfernt hat?
Wenn man den Server richtig konfiguriert haette (chroot, nur bestimmte Befehle zulassen) haette es gar nicht so weit kommen muessen.
Aber natuerlich kann das schon stimmen.
Häufig ist auch SSH erst ab einer bestimmten Paketgröße drin. Hier ein Beispiel: https://www.hetzner.com/de/webhosting
Der Dumper war war damals eine prima Sache. Denn es kam ja nicht auf die Sicherung allein an, sondern auch und gerade um die automatische Verwaltung der Sicherungen. Die Anzahl der Sicherungen konnte festgelegt werden und auch alle anderen Datenbanksicherungen konnten verwaltet werden.
Schon seit längerem produziert der Dumper Fehler, die man erst siehst, wenn es zu spät ist. Man kann ihm leider nicht mehr trauen.
Das Sichern über die Shell hilft nur dann zufriedenstellend, wenn man die Sicherungen auch automatisiert Verwalten kann. Man sich zwar Skripte für einen cronjob zäusammenfrickeln, aber wurden hier nicht genannt.
Das Thema bleibt also spannend.
Schon seit längerem produziert der Dumper Fehler, die man erst siehst, wenn es zu spät ist. Man kann ihm leider nicht mehr trauen.
Demnach testest du also jede Version explizit auf eventuell vorhandene Fehler?
Ja, immer mal wieder. Beim letzen Probieren habe ich zum Beispiel nur durch Zufall entdeckt, das ein Mitglied nicht mitgenommen wurde.
Bezüglich des MyOOS Dumper habe ich die in Beitrag 68 erwähnte Änderung im Script vorgenommen und Backup/Wiederherstellung erfolgreich getestet, d. h. sowohl das Backup, als auch die Wiederhergestellten Tabellen, hatten den korrekten Zeichensatz utf8mb4.
Wichtig ist, dass im Dumper in beiden Fällen utf8mb4 steht
Wie erwähnt wird dies bei der nächsten Version als Standard eingerichtet.
Diese Aussage scheint mir durchaus plausibel zu sein, denn welche sonstigen Gründe sollte es geben, dass ein Webhoster die vormals implementierte Funktion wieder entfernt hat?
Plausibel im ersten Moment.
Besten Dank für deine Argumente, doch wie du siehst gibt es eben auch Webhoster die einen Zugang über SSH ganz bewusst nicht anbieten.
Was in dem Fall aber nicht für den Hoster spricht und, wenn man nun böse sein will, sogar eher dafür spricht, dass diesem Hoster allgemein nicht wirklich zu vertrauen ist, weil sie entweder faul sind oder nicht das nötige Fachwissen besitzen einen Server richtig zu konfigurieren.
Es gibt heute genug Shells/Bashes, die es ermöglichen, dass man Nutzern bestimmte Befehle nicht ermöglicht und andere Befehle so absichert, dass sie nur ihr eigenes Verzeichnis sabotieren, wenn sie es denn wollen. Und das beste ist: Man muss diese Einstellung eigentlich nur ein einziges mal vornehmen und testen und kann sie danach auf jeden Server mitnehmen für das Webhosting.
Wer natürlich ohne Kenntnisse einfach den Usern einen SSH-Zugang gibt und das nicht einstellt, der hat natürlich ein Sicherheitsproblem.
Es bleibt halt dabei: Sofern man die Möglichkeit hat per SSH/Cronjob ein Backup zu erstellen, sollte lieber diese Wege nutzen, da diese zuverlässiger sind. Wer diese Möglichkeit nicht hat, sollte schauen, ob ein Backup-Tool des Hosters existiert. Wer all diese Möglichkeiten nicht hat, kann/muss dann zu Hilfsmitteln wie MySQLDumper greifen.
Allgemein gilt aber, dass man immer wieder mal ein Backup stichprobenartig auf Funktionalität testet, sonst steht man irgendwann echt mal ohne da.
Das Sichern über die Shell hilft nur dann zufriedenstellend, wenn man die Sicherungen auch automatisiert Verwalten kann. Man sich zwar Skripte für einen cronjob zäusammenfrickeln, aber wurden hier nicht genannt.
Wobei der SSH-Zugang auch hier im ersten Moment nur notwendig ist um ggf. ein Cronjob zu testen und dann per Cronjob ausführen zu lassen. Aber selbst da gibt es so einige Tutorials, die einem dabei helfen, wenn man denn sucht.
Das einzige, was dem im Wege steht, ist es, wenn der Hoster gewisse Zugänge erst in kostenintensiveren Paketen anbietet, ohne dasss man diese braucht.
Heute wurde MyOOS 5.09 veröffentlicht und utf8mb4 ist nun Standard.
Don’t have an account yet? Register yourself now and be a part of our community!
