fortsetzung von cback

Posted: 2005-09-17, 22:02 fortsetzung von cback ;)

@DSB: machen wir hier weiter`? Wink

Posted: 2005-09-17, 22:54 Re: fortsetzung von cback ;)

Posted: 2005-09-17, 23:03 Re: fortsetzung von cback ;)

So denn, da ich die Diskussion auf CBACK.de im Forum ja mitbekommen habe muss ich jetzt auch mal etwas dazu beitragen. Fakt ist, dass ich selbst bereits einige Server mit der unterschiedlichsten Konfiguration mit Hilfe des MySQLDumpers umgezogen habe. Zuvor hatte ich noch immer andere Tools probiert. Zuerst einmal fing man da mit phpMyAdmin an, was natürlich bei Datenbanken über 2MB schon oft in die Hose ging. Danach folgte ein Backup über SSH was natürlich etwas komplizierter anzufertigen war als über ein Webinterface. Und dann fand ich zufällig diesen MySQLDumper von hier und seit dem schwöre ich auf cback.de und all meinen Projektseiten auf dieses Tool.

Ich selbst empfehle den MySQLDumper auch gerne weiter, wenn jemand ein Forum umziehen oder sichern möchte. Als Hersteller der Orion Distribution der phpBB Forensoftware muss ich sagen, dass der MySQLDumper bisher immer tadellose Backups angefertigt hat und bei mir für die Empfehlung auch bislang noch kein negatives Feedback eingegangen ist. Die Such- und Posttabelle der phpBB Forensoftware ist schon ein gewaltiger brummer, da streiken einige Backuptools schon beim Backup oder was später noch schlimmer ist beim Wiederherstellungsversuch, da sie Probleme mit der Struktur haben. Der MySQLDumper allerdings läuft sogar bei Datenbanken von über 200MB tadellos durch und die Funktionen mit Cronjobs usw. unterstützen einen Admin doch sehr bei seinen täglichen Backups der Datenbank.

Also ich find den mysqldumper spitze, nicht umsonst wurde das Skript nun das einzige Backuptool für meine Seiten. Macht weiter so, großartige Arbeit Thumbsup

Bye,
Christian

Posted: 2005-09-17, 23:25 Re: fortsetzung von cback ;)

@Christian
Danke für Deine positive Meinung.
Wir haben uns auch sehr viel Mühe gegeben den MySQLDumper so zu programmieren, dass er auf nahezu jeder Serverumgebung funktioniert.
Jeder Hoster verfolgt ein anderes Sicherheitskonzept und es ist nicht leicht ein Script zu schreiben, welches alle relevanten Sicherheitseinstellungen abfängt und wirklich auf jedem Server (sei er auch noch so chaotisch konfiguriert) tadellos funktioniert.
Trotzdem können wir glaube ich zurecht behaupten, dass MySQLDumper nahezu auf jedem Server funktioniert.

Ein Beispiel:
Aufgrund der Uploadbegrenzung von manchen Hostern (z.B. funpic) haben wir Multipart eingeführt, welches das automatische Aufteilen des Backups in mehrere Dateien bei einstellbarer Größe erlaubt. Daraus ergaben sich umfangreiche "Probleme" bei der Darstellung der Backupfiles in der Fileübersicht. Nun musste ja erkannt werden, ob es sich um ein Multipartfile handelt und wieviele Teile es hat. Das alles regelt MySQLDumper anstandslos.
Es ist sogar so sicher programmiert, dass MySQLDumper beim Klick auf ein Multipartfile, welches nicht das erste in der Reihe ist, dies erkennt und dann automatisch nach dem ersten File sucht. So wird das Restore korrekt durchgeführt auch wenn der Anwender die falsche Datei wählt.
Das sind so Kleinigkeiten, die die Anwendung leicht machen, bei denen der Anwender aber nicht sieht, wieviel Konzept- und Programmierarbeit dahinter steckt.

Es gibt meines Wissens nach kein Programm, welches so umfangreiche Konfigurationsmöglichkeiten bietet, zuverlässig funktioniert und zudem auch noch kostenlos ist.

@SNap
Das kleinere Bugs auftreten liegt unter anderem auch daran, dass die Hoster neue Konzepte einführen auf die wir programmtechnisch natürlich erst reagieren können, wenn wir Kenntnis davon erhalten.
Du sagst oben zwar nicht direkt, dass Dein Datenverlust im Zusammenhang zu MySQLDumper steht - trotzdem sieht das für mich ein wenig wie Rufmord aus.
Ich wiederhole mich nochmal: MySQLDumper holt die Daten beim Backup lediglich vom MySQL-Server ab und verändert die vorhandenen Daten in der DB nicht. Insofern ist es technisch einfach nicht möglich, dass MySQLDumper für den Verlust verantwortlich sein kann.
Schau in den Quelltext. Immerhin ist das ein OpenSource-Projekt wo der Quelltext einsehbar ist. Zeig mir die Stelle im Code, die für einen Datenverlust verantwortlich sein könnte.

Posted: 2005-09-18, 09:57 (No subject)

wie gesagt, es war ein Backup mit Optimierung Wink

und beim Optimieren kann imho sehr wohl was schiefgehen. Es soll auch kein Rufmord sein, nur eine Beobachtung. Und die nicht mal direkt Wink

da ich nicht mit dabei war, ich war nur mit im chat und habe nur das Ergebnis gesehen: Ein leeres Board Wink

Also wie gesagt sollte kein Rufmord darstellen! ICh habe Dmper auch oft benutzt (zum testen) aber mir ist es viel zu langsam (Normal durch das parsen). Ein Backup meiner 100MB DB dauert so ca. 45 Minuten, das ist indiskutabel.. das Restore würde wahrscheinlich sehr viel länger dauern!

Posted: 2005-09-18, 11:12 (No subject)

Posted: 2005-09-18, 13:10 (No subject)

Da ist Cron und per Mail senden ja ganz nett. Während ich schlafe wirdn Backup gemacht und am nächsten Morgen hab ich Post *gg*

EDIT:

Grad Spaßeshalber mal probiert. Noch aufm VServer mit einer DB Gesamtgröße von 110MB. Die Stoppuhr sagt 8 Minuten, 30 Sekunden, 12 Ms - Seh da kein Problem drin. Habe auch gerade Lokal eingespielt => Backup intakt.