Backup & Restore der Tabellen mit database-Modul?
am 10.10.2005 - 16:23 Uhr in
Auf der Suche nach einer guten Möglichkeit für Backup / Restore der Tabellen bei einem hosted-Account (keine Konsole), habe ich u.a. das Modul "database" ausprobiert. Ich kann damit zwar problemlos ein Backup erzeugen, wenn ich es danach aber wieder via Database Modul einlesen will, erhalte ich die folgende Fehlermeldung:
Query failed: INSERT INTO locales_source VALUES("109"," includes/image.inc:61","The selected image handling toolkit \'%toolkit\' can not correctly process \'%function\'.");
Die gewählte Bildbearbeitungs-Bibliothek '%toolkit' kann '%function' nicht richtig verarbeiten.
Die gewählte Bildbearbeitungs-Bibliothek '%toolkit' kann '%function' nicht richtig verarbeiten.
Die gewählte Bildbearbeitungs-Bibliothek '%toolkit' kann '%function' nicht richtig verarbeiten.
(diese Zeile wird danach hunderte Male wiederholt)
Bis jetzt ist es mir nur gelungen Backups, welche ich via phpMyAdmin erstellt habe, danach via phpMyAdmin wieder ohne Fehlermeldungen einzulesen.
Welche Tools verwendet Ihr für automatische SQL-Backups (ohne Konsole) und welches sind Eure Erfahrungen für den Restore (ohne Konsole)?
Danke im voraus
Jürg
- Anmelden oder Registrieren um Kommentare zu schreiben
ich benutze phpmyadmin bzw.
am 21.10.2005 - 12:20 Uhr
ich benutze phpmyadmin bzw. den Service meines Providers, allerdings brauchte ich bisher auch noch keinen eigenen Server und arbeite bisher mit den normalen Angeboten
grds. (Java/J2EE) benutze ich Ant Scripts + CVS für backup + restore Arbeiten
das Database Modul ist m.M.n. noch nicht ausgereift genug, PHPMyAdmin hat einfach bessere und mehr Funktionen
MfG Micha
- work in progress mit Langmi.de
Ohne Konsole ist man wirklich limitiert
am 24.10.2005 - 17:07 Uhr
Vielen Dank für Dein Feedback. Als Nicht-Programmierer bin ich mit Ant bzw. CVS nicht vertraut, so dass ich eher nach anderen Lösungen suchen muss.
Vermutlich wird es in absehbarer Zeit so weit kommen, dass ich einen Server mit Konsole mieten muss. Neben den Backup- haben wir auch Performance-Probleme. Letzte Woche ist z.B. durch einen nicht-nachvollziehbaren Fehler die Tabelle „watchdog“ innert ein paar Sekunden auf 7.5 MB Grösse gewachsen. Das System generierte etwas 30'000 Einträge „Page not found“.
Als ich später ein Backup mit PhpMyAdmin erstellen wollte, funktionierte die komprimierte Version nicht mehr, ich konnte das Backup nur noch unkomprimiert erstellen. Allerdings gab es keine Fehlermeldung, sondern der mit gzip komprimierte Sqldump war nur ein paar Bytes gross. Ich habe dieses Problem deshalb nur mehr oder weniger zufällig bemerkt...
Ich suche deshalb nach wie vor eine zuverlässige Lösung für einen automatischen Backup!
Gruss
Jürg
ich bin mir sicher, dass es
am 24.10.2005 - 17:21 Uhr
ich bin mir sicher, dass es da noch andere Möglichkeiten als die Konsole gibt, davon abgesehen ist das Problem meist nicht der fehlende Konsolen-Zugriff sondern
- PHP Speicherlimit (liegt am Angebot des Hosts)
- phpmyadmin Speicherlimit (bezogen auf die up/downloads von zipped sqls, wiederum ist der Tarif schuld)
d.h. ab bestimmten Datenbankgrößen kommt man um eigene Server gar nicht mehr herum
ansonsten könnte man noch http://www.hotscripts.com/PHP/Scripts_and_Programs/Database_Tools/index.... oder generell google durchsuchen, m.M.n. ist phpmyadmin aber schon eines der besten Tools die man (in dem Host-Tarif-Bereich) bekommen kann
ich empfehle dir dich mit deinem Host abzusprechen, bei host-europe und all-inkl habe ich jedenfalls gute Erfahrungen gemacht
MfG Micha
- work in progress mit Langmi.de
Interessante Hinweise
am 25.10.2005 - 09:24 Uhr
Unglaublich, was es alles gibt! Vielen Dank für den Link und die Anregungen. Es scheint hier wirklich einige gute Lösungen zu geben.
Mit meinem Provider bin ich in Kontakt, vorallem wegen der zeitweise extrem langen Antwortzeiten. Zeitweise ist das drupal-System blitzschnell, danach ist es wieder ein paar Stunden lang extrem langsam. Dann kann ein logout leicht 1 Minute dauern.
Ich hatte mir im .htaccess File die Memory limite auf 26 MB gesetzt (php_value memory_limit 26M ). Dies hat aber keine spürbare Verbesserung bewirkt. Der Provider hat nun selbst eingesehen, dass es Probleme mit der Performance auf dem Server gibt (nachdem plötzlich seine eigenen html-Seiten eine Response Zeit von 10 Sek. und mehr hatten) und versprochen den Ursachen nachzugehen. Er sprach von „zuvielen Harddisk-Zugriffen“, wusste aber nicht weshalb.
Bei unseren Webseiten hat die zeitweise Lahmheit dazu geführt, dass mir die Leute ihre Artikel via Email schicken, mit der Bitte, dass ich sie selbst in drupal einfügen möge...
Ich werde nun mal ein paar Tage abwarten, um zu sehen, ob das Performance-Problem mit diesem Provider gelöst werden kann. Falls nicht, muss ich mir wirklich überlegen, einen Server zu mieten - ich zögere allerdings, da ich noch wenig Erfahrung mit Linux habe und auch bei Apache, php, usw. nicht aus dem Vollen schöpfen kann.
Nochmals vielen Dank für Deine guten Hinweise und Gruss
Jürg
Du hattest Recht auf der ganzen Linie...
am 29.10.2005 - 13:29 Uhr
In der Zwischenzeit hat sich einiges geklärt: Unser Provider hatte eine MySQL-Version im Einsatz, welche mit der eingesetzen php-Version nicht kompatibel war. Dies erklärt einerseits teilweise die unglaublichen Performance-Probleme und andererseits auch meine Probleme beim Restore von Backups.
Ebenfalls richtig lagst Du mit Deiner Vermutung des (zu) knappen Speichers. Ich bat unseren Provider versuchsweise ein SQL-Backup von mir für mich zu „restoren“, da ich es erst mühsam in 5 Teile aufspitten müsste. Und siehe da, er hatte überhaupt keine Probleme mit dem Restore!
Ich habe den Provider daraufhin gefragt, ob er mir mehr php-Speicher zur Verfügung stellen könne, er sagte aber, er wisse nicht wie und wo er dies einstellen könnte. Kann mir jemand einen Tip geben?
Danke im voraus und Gruss
Jürg
wenn dein Provider nicht
am 30.10.2005 - 12:33 Uhr
wenn dein Provider nicht weiß was er machen kann um sein Angebot zu steuern, solltest du schleunigst einen anderen Provider wählen :-)
ansonsten kann mans so machen wie hier beschrieben
MfG Micha
- work in progress mit Langmi.de
Memory nochmals erhöht
am 31.10.2005 - 16:22 Uhr
In der Datei .htaccess hatte ich dem Memory-Limit bereits auf 26 MB, ich habe ihn nun auf 32 MB erhöht und gleichzeitig noch einen ini_set-Eintrag für 32 MB in der Datei settings.php gemacht.
Seitdem unser Provider kompatible Versionen von mySQL und php einsetzt, haben sich die maximalen Zugriffszeiten von 1-2 Minuten auf etwa 10 bis 15 Sekunden reduziert. Dies ist aber immer noch recht mühsam, wenn man am System arbeiten will. Es ist jedoch sehr unterschiedlich, gerade jetzt wo ich diese Zeilen schreiben, liegen die Antwortzeiten bei etwa 1 bis 2 Sekunden – also sehr gut. Wenn es nur so bleiben würde!
Vielen Dank für Deinen Hinweis und Gruss
Jürg
Ich muß mich Micha
am 31.10.2005 - 19:49 Uhr
Ich muß mich Micha anschliessen. Wenn du ordentlich arbeiten möchtest, solltest zu einem professionellen Provider wechseln...
Providerwechsel aber wohin?
am 04.11.2005 - 17:47 Uhr
Danke für den Hinweis. Ja, ich sehe auch keine andere Möglichkeit mehr als den Provider zu wechseln. In der Zwischenzeit habe ich herausgefunden, dass unser Provider nur einen virtuellen Server betreibt...
Es sieht im Moment so aus, wie wenn die kostengünstige Lösung für mich wäre, einen Root DS Server zu mieten. Die kritische Domain ist eine .ch Domain und dafür verlangen z.B hosteurope oder server4you horrende Preise (85 bzw 90€ pro Jahr). Auf dem virtuellen Server könnte ich eine .de Domain installieren und die .ch-Domain(s) über einen externen Nameserver laufen lassen. Dabei gehe ich davon aus, dass ein Root DS Server wesentlich schneller wäre als irgend ein „Webpaket ohne root-Zugriff.“
Ich fürchte nur, dass ich mir mit dem Betrieb des eigenen Servers einen Haufen (serverseitige) Probleme einhalsen könnte. Deshalb zögere ich immer noch...
Selbstverständlich bin ich offen für jegliche Vorschläge!