Hallo,
ich bin gezwungen mit dem Forum auf eine neuen Server umzuiehen.
Nach dem Import der DB wurde mir der Rescue-Mode auf dem neuen Server angeboten und ich habe die neue Domain eingetragen.
Nach zwei tagen nochmals die DB vom altem Forum importiert, diesmal wurde mir kein Rescue Mode angeboten.
Also habe ich mit phpmyadmin die Tabelle application geändert.
Nur das Dashboard verwaist immer noch auf die alte Domain.
Wo kann man das ändern?
Wenn du händisch in der DB rumfuschst musst du mindestens den Cache leeren über das ACP.
Das ACP sollte unabhängig davon aufrufbar sein.
Habe ich gemacht.
Ich sehe aber nun es fehlen auch reichlich Sätze in der DB.
Ich werde sie nochmal importieren oder eine andere Sicherung nehmen.
Andere Sicherung, die von gestern war viel kleiner. 
Andere Sicherung, die von gestern war viel kleiner.
Dann war sie nicht komplett (Timeout Error) und Du hast sie vermutlich über phpMyAdmin erstellt. 
Was man spätestens bei größeren Datenbanken tunlichst vermeiden sollte.
Ok, gute Wahl und dann ist die Sicherung natürlich auch komplett.
Die Größenabweichung mag dann durch dadurch kommen, dass sich (relativ kleine) Unterschiede aus dem Umstand ergeben, ob man via PHP (und damit Selbstaufrufen im Browser) oder aber Perl (ggf. auch via Cronjob) sichert.
Dieses Verhalten ist dann völlig normal und hat nichts zu bedeuten, die Sicherung ist trotzdem komplett und lässt sich beispielsweise auch leicht dadurch prüfen, dass am Ende des Scripts der Erfolg (bei Perl z.B. "EOS") gemeldet wird.
Dennoch sollten sich keine auffällig großen Unterschiede wie hier impliziert ergeben:
die von gestern war viel kleiner.
Denn das deutet ja darauf hin, dass offenbar Daten bzw. ganze Tabellen fehlen und das sollte natürlich alarmieren. Also wenn beispielsweise 3 Sicherungen GZ komprimiert je um die 300 MB hatten - und die "von gestern" dann plötzlich nur 170 MB. Das wäre dann nicht normal. Eine DB wird selten drastisch kleiner, sondern (gerade in Foren etc.) meistens nur größer.
Was hat denn phpMyAdmin damit zu tun, wenn Du das Backup mit dem Dumper erstellt und wieder eingespielt hast? Dieses Tool brauchst Du dazu nicht.
Verstehe Du hast damit also nur geguckt, nicht gesichert oder wieder eingespielt? Dann spricht natürlich nichts dagegen.
Hast Du denn einen Vergleichswert zu den 200.000 in "post" aus einem anderen Backup, der diese 75% bestätigen würde? Bzw. wie viele sollten es nach dem letzten Backup etwa sein?
Und ganz wichtig: WIE hast Du das Backup mit dem Dumper erstellt, via PHP oder Perl-Script?
Falls PHP, hast Du evtl. falsche Parameter für die Selbstaufrufe gesetzt und das Script hat möglicherweise tatsächlich abgebrochen wie es bei phpMyAdmin der Fall wäre.
Fange gerade mit dem ersten Wert klein an (den zweiten Wert ruhig deutlich höher) und steigere testweise langsam beide Werte bis zum ersten Abbruch, dann hast Du die (Leistungs)-Grenze Deines persönlichen Servers. Bei zweiten Wert dann knapp unter dem des Abbruchs bleiben, dann funktioniert es auch via PHP klaglos.
Wichtig ist aber die anschließende Erfolgsmeldung auch zu kontrollieren, daher mein Hinweis oben. Beide Scripte melden Dir jeweils den Erfolg mit Anzahl Tabellen und Datensätzen sowie der dazu benötigten Zeit in Sekunden. Perl setzt zusätzlich ein "#EOS" (End of script" ans untere Ende.
Die vollständige Meldung im Fußbereich sieht dann etwa so aus:
| Everythings is done: closing script (date) (time) total time used: xxx sec. #EOS (End of script) |
Wenn Du Perl auf dem Server ausführen darfst, mache es am besten darüber, das ist am sichersten. Das Script kannst Du dann auch in eine Crontable einbinden und musst auch nichts weiter konfigurieren. Der Browser ist in diesem Fall gar nicht beteiligt, also auch keine Selbstaufrufe erforderlich. Das Script wird 1x angestoßen und läuft anschließend automatisch durch bis zum Schluss.
Mal eine andere Frage: Hast Du denn den Hoster gewechselt, oder warum dieses Szenario? Denn einen Server-Wechsel innerhalb des Anbieters führt normalerweise deren Support durch (zumindest bei en namhaften Hostern ist das so), damit hast Du eigentlich gar nichts zu tun. Und die haben alle Dumps redundant gespiegelt, da braucht es diesen Aufwand gar nicht. Die Domain kann man auch außerhalb des Datenbank-Firlefanz neu an die IP anpassen oder auf Wunsch auch wechseln.
Und noch ein anderer Hinweis: Falls Du Konsolen-Zugriff (SSH) bei Deinem Hoster haben solltest, mache das Ganze am besten darüber. Dann brauchst Du nicht mal Tools wie den Dumper dazu und das wäre die schnellste und sicherste Methode überhaupt. Allerdings muss man sich auch damit natürlich vorher beschäftigen.
Allerdings muss man sich auch damit natürlich vorher beschäftigen.
Und noch ein anderer Hinweis: Falls Du Konsolen-Zugriff (SSH) bei Deinem Hoster haben solltest, mache das Ganze am besten darüber. Dann brauchst Du nicht mal Tools wie den Dumper dazu und das wäre die schnellste und sicherste Methode überhaupt. Allerdings muss man sich auch damit natürlich vorher beschäftigen.
Datensicherung mit SSH-Zugang.
So habe ich es dann auch gemacht.
Schon der Dump des Dumpers war fehlerhaft.
Also den Dump über SSH-Zugang gemacht, den Import des Dumps dann mit dem Dumper.
Die von MyOssDumper erstellten Dumps benötigen 135 Minuten für den Import,
der Dump über den SSH-Zugang wurde vom Dumper in 12 Minuten importiert.
Aber die Eingangsfrage war ja eine andere:
Ich bekomme jetzt zwar den rescue_mode nach dem Import angezeigt wo ich die neue IP eintrage.
Klickt man dann auf Dashbord auf dem neuen Server, dann landet man im Dashbord vom alten Forum.
Alle anderen Links funktionieren.
Wo finde ich nun diesen Eintrag?
eine htaccess ist es nicht, wenn ich eine übersehen habe.
Du hast nicht ganz zufällig den Menüpunkt als externen Link angelegt und dort die alte URL reingeschrieben?
Du hast nicht ganz zufällig den Menüpunkt als externen Link angelegt und dort die alte URL reingeschrieben?
Alles ist möglich, aber nein da steht:
Zeigt man mit der Maus auf den Link, dann steht da auch die neue IP, nach dem Klick ist es der alte Server.
Ich finde aber keine htaccess mehr.
Ok, das heißt nicht, das da doch eine ist.
IP
IP? Cache deines Browser schon geleert? Der macht ja manchmal auch verrückte Sachen.
IP? Cache deines Browser schon geleert? Der macht ja manchmal auch verrückte Sachen.
Stimmt habe ich, aber vermutlich nicht alles. Habe jetzt Testuser drauf angesetzt, bei denen klappt es.
Thema gelöst.
Tatsächlich liegt das in Einzelfällen bei Serverwechseln auch schon mal am Wohnort und dem Standort des zuständigen DNS Servers bzw. dessen Reaktion auf neue IPs etc. Ich hatte das in ähnlichen Fällen auch schon mehrfach, mal konnte ich sofort zugreifen und einige andere User dafür nicht, mal umgekehrt.
Das Thema sollte aber normal in 1 bis 2 Tagen duch sein. Auffällig war bei Dir aber, dass es ja nur das Dashboard betraf und nicht die gesamte Domain. Was halt eher auf .htaccess oder/und Cache deutet.
Ok, gute Wahl und dann ist die Sicherung natürlich auch komplett.
[citation needed]
Der MySQLDumper ist die schlechteste Möglichkeit zur Sicherung der Datenbank. mysqldump ist das beste, danach kommt die ins Control Panel des Hosters integrierte Funktion, danach kommt ein Umzug zu einem Webhoster der einem gescheite Tools zur Verfügung stellt, danach kommt phpMyAdmin und ganz weit später kommt der MySQLDumper.
Siehe auch: RE: Umlaute fehlerhaft
Oh, das sehe ich aber komplett anders.
Die rein PHP basierten Tools kannst Du allesamt komplett vergessen, weil die spätestens bei größeren Datenbanken und Webhostingpaketen ins Timeout laufen.
Genau dafür wurde der Dumper ja ursprünglich entwickelt, da längst nicht alle Hosting Kunden auch über SSH Zugriff verfügen.
Ansonsten ist das natürlich die beste Wahl, darauf hatten wir auch im Team damals immer hingewiesen und das dürfte soweit auch klar sein. Schrieb ich ja ebenfalles oben.
Aber bitte keinesfalls auf phpMyAdmin verlassen! Das ist aus den bekannten Gründen die schlechteste Wahl und aus diesem Grunde hatten damals (zur offiziellen Zeit des Dumpers) auch einige Hoster den Dumper als Alternative angeboten.
Zum Thema Umlautproblematik bei Serverwechsel hatte Daniel damals einen sehr wertvollen Thread mit Hintergründen und Abhilfen verfasst. Darüber herrscht leider bis heute sehr viel Unkenntnis und daher kommt es damit immer wieder mal zu Problemen, wenn man nicht bestimmte Dinge beachtet. Aber das ist wieder ein völlig anderes Thema und beträfe ja ebenso den Umgang mit anderen Tools.
Wir sind uns aber alle einig, dass mysqldump die beste Option von allen ist, sofern sie zur Verfügung steht.
Äh:
Oh, das sehe ich aber komplett anders.
Wir sind uns aber alle einig, dass mysqldump die beste Option von allen ist
Na was denn nun? Entweder siehst du es komplett anders oder nicht. Erneut ein Thema bezüglich des Überdenkens deiner Argumentation.
Die rein PHP basierten Tools kannst Du allesamt komplett vergessen
Äh und auf was basiert MySQLDumper noch gleich? Richtig, PHP!
Das einzige, was nicht per PHP läuft, ist der Cronjob, wenn man ihn konfiguriert. Wenn du aber über die Oberfläche regulär ein Backup machst, läuft das per PHP.
Und je nach Hoster funktioniert phpMyAdmin nicht schlechter als der MySQLDumper, da haben viele Hoster nachgelegt und die Limits entsprechend verändert. Aber dazu müsste man sich informieren bzw. regelmäßig noch solche Dienste nutzen, statt aus seinen „20 Jahren Erfahrung“ zu sprechen, die aber mit der heutigen Realität leider nicht mehr viel zu tun haben.
Kernaussage deines letzten Beitrags als: Du kannst dich nicht entscheiden, was nun wie ist und Kenntnis von dem, was du da redest, hast du offensichtlich auch nicht. Manchmal ist es besser, nichts zu schreiben, statt Unsinn zu schreiben. 
Don’t have an account yet? Register yourself now and be a part of our community!
