| Author |
Message |
Dave
uses MSD regulary
Joined: 01 May 2009
Posts: 24
|
 Posted:
2009-05-02, 03:18 Lite-Version und mehr... |
  |
Ich bin durch die Suche nach einem Gegenstück zu bigdump.php auf diese Seite gestoßen. Hab MySQL-Dumper mal kurz getestet und bin recht begeistert. Es ist nicht das was ich eigentlich wollte, aber im Prinzip etwas das ich schon lange gesucht habe (ohne es zu wissen).
Was allerdings wirklich cool wäre, wäre eine Lite-Version - eben wie bigdump.php (I love that script). Als eine One-File-Lösung die man nur über config-Parameter im Script steuern, und einfach in eigene Projekte einbinden kann.
Ich brauche halt für einige DAU-Leute eine 1-Click-Lösung, um ihre Datenbank zu sichern ("Willst Du ein Backup machen, dann klick auf den Button").
Das ist es was ich an bigdump auch nett finde, da kann man mal eben die DB-Parameter reinschreiben, das auf den Server wuppen und einen Dump einspielen (leider eben nur
Was auch noch nett wäre, wenn man erst ein Backup in mehreren Files machen könnte und die DANN anschließend in EINE Zip-Datei gepackt werden könnten. Das wäre nicht nur vom der Komprimierung effektiver sondern auch von der Handhabung.
Was ich mir schon seit langem wünsche ist ein Backuptool um ein Backup nicht als Dump auszuführen sondern direkt in eine andere Datenbank zu schieben (um so zum Beispiel ein Projekt vom lokalen Entwicklungsserver auf das Livesystem zu verschieben).
Praktisch wäre auch, wenn man verschiedene Backupeinstellungen sichern könnte (bin mir nicht sicher ob es nicht schon geht). Ich würde gerne die Datenbank meines Portals übertragen. Da habe ich verschiedene Prioritäten (bzw hätte das gerne).
Backup 1. Komplettbackup mit allen Tabellen
Backup 2. Forum kompeltt
Backup 3: CMS kompeltt
Backup 4. Forum ohne Tabellen für die Suche (benutze auch phpBB und die kann man sehr einfach wieder herstellen). Die Suchtabellen hätte ich allerdings gerne als reinen Structure-dump (also Tabellenstruktur ohne Daten)
So könnte ich einfach per Cron steuern, dass er einmal im Moant Backup1 durchgührt einmal pro Woche Backup 2 und 3 und jeden Tag Backup 4.
Was natürlich noch ein Traum wäre, ist ein inkrementelles Backup... Wäre halt aufwändig und ginge nur auf Binärbasis.
Gruß, Dave
|
|
     |
|
Anzeigen
|
|
Posted:
Anzeigen |
|
|
| |
|
moepschen
Moderator
Age: 33
Joined: 21 Jan 2006
Posts: 809
Location: Frankfurt (Oder)
|
|
Posted:
2009-05-02, 11:53 (No subject) |
|
|
  |
|
Dave
uses MSD regulary
Joined: 01 May 2009
Posts: 24
|
|
Posted:
2009-05-02, 16:52 (No subject) |
|
Quote: Noch einfacher gehts doch kaum.
Ja und man kann auch SEHR einfach ein Backup wieder zurückspielen und sich damit die Datenbank zerschießen. Ich habe Kunden die sind froh wenn sie den Computer anbekommen, die wissen nichtmals was ne Datenbank ist. Da kommt ein bildschirmfüllender roter Button in den Adminbereich: "Klickst Du hier, machst Du Backup von Deiner Homepage" und das bekommen die dann per Mail zugeschickt. Eine Möglichkeit des Rückspielens kann und DARF der Kunde nicht haben.
Abgesehen davon ließe sich sowas - wie oben bereits erwähnt - dann SEHR einfach in eigene Projekte integrieren.
Für die Server-Verwaltung ist das Tool ganial und dafür werde ich es auch nutzen. Es ist aber nicht schlank. Ich muss ziemlich oft Datenbanken hin und herschieben. Schau Dir mal bigdump an. Das Script ist 30kb groß. Eine Datei, hat man schnell hochgeladen. MSD hat über 1,2 MB.
Ich kenne viele professionelle Entwickler die sowas suchen. bigdump erfreut sich da nach wie vor SEHR reger Beliebtheit, obwohl das Script uralt ist und nicht wirklich viel kann. Aber es ist schlank und es ist irre schnell. Ein Script, welches in beide Richtungen funktioniert, schlank ist und den Funktionsumfang von mysqldumper bietet, wäre genial.
Quote: Was meinst du mit mehrere Dateien in eine packen?? Meinst du für jede Tabelle eine eigene Datei?? Ist irgendwie blöd und diese Diskussion gab es erst vor kurzem
Nein... Mysqldumper sichert den Query und schreibt es on-the-fly in die ZIP-Datei. Wenn man mehrere Dateien wünscht, hat man mehrere Zip-Dateien.
Praktischer wäre es aber wenn ERST die Textdateien in der eingestellten Größe auf Platte gesichert würden und dann daraus am Ende eine Zip-Datei erstellt würde.
Das Aufteilen in mehrere Dateien braucht man ja nur, um noch Editierbare Dateigrößen zu haben.
a) hat so nur eine einzige Datei, und trotzdem kleinere Dump-Dateien
b) kann man so viel effektiver Zippen.
Quote: aber letztendlich scheitert es daran, das jeder DAU wissen muß, das er eben das erste Backup behalten muß und nicht löschen darf....
Sorry, das ist imo ein ziemlich dummes Argument. Nach dem Motto: "Wir bauen in unsere Autos keine Fensterheber ein, weil der Käufer sich die Finger einklemmen könnte
Ein DAU-sicheres Script, lässt dem Benutzer garnicht die Wahl. Der muss garnicht wissen, dass ein Backup aus mehreren Dateien besteht. Zudem kann man sowas eben auch mit einer gezippten Datei lösen, die man dann entpackt und nach dem Backup wieder packt.
Aber abgesehen davon: Wollt Ihr nur für Daus entwickeln? Meiner Meinung nach ist ein gut durchdachtes SQL-Script welches sich per Web steuern lässt eine echte Marktlücke.
Quote: Verschiedene Backupeinstellungen kannst du mit der 1.23 speichern.
thx, muss ich mal Testen. Ist 1.23 den schon stable?
Gruß, Dave
|
|
| |
|
JayD
Moderator
Age: 50
Joined: 12 Apr 2009
Posts: 1017
Location: Ruhrgebiet
|
|
Posted:
2009-05-02, 19:20 (No subject) |
|
Hallo Dave,
als "dumm" sehe ich das Argument nicht an, Du sprichst ja selber die "DAU's" an und wünscht Dir eine einfache Funktion für Kunden. 
Und genau das ist damit gemeint: Viele wissen nicht einmal was eine Datenbank ist geschweige denn nach welchen Regeln sie arbeitet.
Da sind Begriffe wie "inkrementell", "differentiell" und "Vollbackup" erstrecht böhmische Dörfer.
Der Vergleich mit kindergesicherten Fensterhebern hinkt deshalb meines Erachtens etwas.
Ein einfaches PHP Script zur Schnellsicherung ist schnell geschrieben, soetwas habe ich vor langer Zeit mal ebenfalls geschrieben. Das kann man ja auch gut und gerne (wie Dein erwähntes Bigdump) zusätzlich benutzen wenn man möchte.
Aber dazu braucht man keinen MySQLDumper und das sind auch nicht seine Vorzüge. Er ist nicht für "Dau-Kunden" ohne jegliche Admin-Kenntnisse gedacht, sondern zur schnellen und sicheren DB-Sicherung und Verwaltung.
Für fachunkundige Kunden empfiehlt sich ein Hoster, welcher eh von sich aus tägliche Backups durchführt und dem Kunden vorhält (macht beispielsweise Artfiles). so muss sich der Kunde um nichts kümmern und braucht auch keine "Rücksicherungs-Kenntnisse", sondern kann beruhigt schlafen.
Wer (wie z.B. ich) trotz Hoster-Sicherung zusätzliche und auch modifizierte Backups fährt, der weiß dann doch was er tut und hat keine Angst vor der Restore-Funktion.
Also warum weiter abspecken, wo die meisten User sich doch eher noch weitere Funktionen wünschen?
Datensicherheit sollte nicht zur "Super-Dau-Knopfdruck-Angelegenheit" mutieren, sondern technisch nachvollziehbar bleiben. Ist zumindest meine Meinung.
Wer als Kunde keinerlei Ahnung von der Technik hat, sollte diese von einem Fachmann betreuen lassen und nicht selber "rumwurschteln".
ZIP-Files können auf vielen Servern online bearbeitet werden, auch Online-Programme wie Net2FTP können ZIP in beiderlei Richtung erstellen und wieder entpacken. Das sollte also auch kein Problem sein.
Und einzelne Tabellen lassen sich mit dem Dumper ebenfalls sichern und rücksichern. Multipart hat einen anderen Grund, unter Anderem den das nicht alle Server/Hoster derart große Dateien zulassen und sich kleinere Dateien auch besser handhaben lassen.
Zur Not gibt es sogar PC-seitig Freeware-Programme wie den "Datei-Splitter", welcher beliebige Dateiformate in beliebig kleine "Happchen" samt Ordner und Zip-File aufteilt und z.B. per Mail versendbar macht.
Jeder User hat andere Detail-Ansprüche, und manchmal muß man ggf. ein Zusatz-Tool bemühen, da nicht ein Programm alle Eventualitäten abdecken kann.
Zur Letzten Frage: Die Rev. 375, welche Du hier downloaden kannst, ist auf aktuellem Kenntnis-Stand und soweit "stable-fixed", ja.
_________________
Gruß,
Jörg
Anfragen zu vBulletin, welche nichts mit Datenbanken bzw. dem Dumper zu tun haben, bitte nicht hier sondern im vBulletin-Support-Forum stellen.
Aus technischen Gründen befindet sich der Rest der Signatur auf der Rückseite dieses Beitrags.
|
|
| |
|
Dave
uses MSD regulary
Joined: 01 May 2009
Posts: 24
|
|
Posted:
2009-05-03, 03:18 (No subject) |
|
Quote: Für fachunkundige Kunden empfiehlt sich ein Hoster, welcher eh von sich aus tägliche Backups durchführt
Wir SIND der Hoster (für unsere eigenen Kunden) und wir BIETEN Backups an, aber gegen Aufpreis. Ich will den Kunden aber zusätzlich die Gelegenheit geben, auf einfache Weise selber ein Backup zu machen...
Quote: Datensicherheit sollte nicht zur "Super-Dau-Knopfdruck-Angelegenheit" mutieren, sondern technisch nachvollziehbar bleiben. Ist zumindest meine Meinung.
Datensicherheit ist eine Angelegenheit die jeden was angeht. Und es ist mein Job als Programmierer, es für den Super-DAU zur Knopfdruck-Angelegenheit zu machen....
Aber ich hab's schon kapiert, Ihr wollt es nicht...
|
|
| |
|
JayD
Moderator
Age: 50
Joined: 12 Apr 2009
Posts: 1017
Location: Ruhrgebiet
|
|
Posted:
2009-05-03, 04:31 (No subject) |
|
"Nicht wollen" würde ich so nicht sagen. Ich denke eher, dass zur Zeit eine derartige "Knopfdruck-Funktion" keine Priorität besitzt.
Aber speziell dazu müssten wir DSB befragen, er kennt seine diesbezüglichen Absichten am besten.
Quote: Datensicherheit ist eine Angelegenheit die jeden was angeht.
Da stimme ich zu 100% zu, keine Frage. Man kann es nicht oft genug betonen und empfehlen.
Ich hatte meine Aussage hierauf bezogen:
Quote: Ja und man kann auch SEHR einfach ein Backup wieder zurückspielen und sich damit die Datenbank zerschießen. Ich habe Kunden die sind froh wenn sie den Computer anbekommen, die wissen nichtmals was ne Datenbank ist.
Genau deshalb sollte man (auch bei der Datensicherung) schon wissen, was man tut. Das meinte ich mit entspr. Kenntnissen.
Davon ab kann man bei erfolgtem Backup auch jederzeit die (durch evtl. falsche Rücksicherung) zerschossene Datenbank wieder herstellen.
Also auch kein Problem, selbst wenn der Kunde "Herr/Frau Super-Dau" mal Mist gemacht hat.
Eine zerschossene DB (oder auch andere Daten) wird bekanntlich erst dann zum ernsthaften Problem, wenn man keinerlei (aktuelle) Backups besitzt....
Aber ich verstehe Dein Anliegen durchaus und grundsätzlich ist diese "Knopfdruck-Geschichte" sicherlich eine gute Sache.
_________________
Gruß,
Jörg
Anfragen zu vBulletin, welche nichts mit Datenbanken bzw. dem Dumper zu tun haben, bitte nicht hier sondern im vBulletin-Support-Forum stellen.
Aus technischen Gründen befindet sich der Rest der Signatur auf der Rückseite dieses Beitrags.
|
|
| |
|
DSB
Developer
Age: 41
Joined: 30 Apr 2004
Posts: 16070
Location: Reichenberg bei Würzburg
|
|
Posted:
2009-05-03, 19:04 (No subject) |
|
« Dave » wrote:
Wenn man mehrere Dateien wünscht, hat man mehrere Zip-Dateien.
Praktischer wäre es aber wenn ERST die Textdateien in der eingestellten Größe auf Platte gesichert würden und dann daraus am Ende eine Zip-Datei erstellt würde.
Das würde aufgrund von RAM- und Laufzeitbeschränkungen nur bis zu einer bestimmten Dateigröße funktionieren. Man kann nicht per PHP beliebig große Dateien nachträglich zippen. Das ist also technisch nicht zuverlässig machbar.
Die andere Diskussion über den Fall, dass ein Kunde mal versehentlich auf "Wiederstellung" klickt eine Backupdatei anklickt, einen Wiederherstellungsprozess startet, die dann aufpoppende Sicherheitsabfrage "Sollen die Daten der Datei x in die Datenbank y eingespielt werden?" ignoriert, nichts versteht und dadurch seine Datenbank überschreibt, finde ich ziemlich konstruiert.
Mein Vergleich dazu: Du willst ein Auto, was keinen Rückwärtsgang hat, weil einer Deiner Kunden damit einmal rückwärts gegen einen Laternenpfahl gefahren ist und sich die Stoßstange verbeult hat.
Man kann nicht alles programmtechnisch abfangen und ein Mindestmaß an Kenntnis, was man da tut, muss man von jedem Anwender verlangen können.
Wenn Du Deinem Kunden die Wiederherstellung erschweren willst, dann bearbeite die menu.php und nimm einfach den Link zur Wiederherstellung aus dem Menü raus und/oder entferene die Datei restore.php. Das ist in 2 Minuten erledigt.
Was die Dateigröße angeht, kannst Du den Dumper auch weiter verkleinern, indem Du die Sprachordner löschst, die Du nicht benötigst. Die Größe kommt hautpsächlich durch die mittlerweilen reichlich vorhandenen Sprachdateien zustande.
_________________
Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
| |
|
Dave
uses MSD regulary
Joined: 01 May 2009
Posts: 24
|
|
Posted:
2009-05-04, 03:02 (No subject) |
|
Quote: Die andere Diskussion über den Fall, dass ein Kunde mal versehentlich auf "Wiederstellung" klickt
Ich hab die Diskussion nicht angefangen. Ich sagte lediglich, dass es praktisch wäre, so eine Lightversion ohne großartiges Frontend zu haben, um sie in eigene Scripte einzubinden.
Quote: Mein Vergleich dazu: Du willst ein Auto, was keinen Rückwärtsgang hat, weil einer Deiner Kunden damit einmal rückwärts gegen einen Laternenpfahl gefahren ist und sich die Stoßstange verbeult hat.
Nein, ich will den Zugriff auf den Motor nur soweit beschränken, dass der User Öl nachfüllen, und die Batterie austauschen, sonst aber keinen Unsinn anstellen kann.
Quote: Wenn Du Deinem Kunden die Wiederherstellung erschweren willst, dann bearbeite die menu.php und nimm einfach den Link zur Wiederherstellung aus dem Menü raus und/oder entferene die Datei restore.php. Das ist in 2 Minuten erledigt.
Wie gesagt, es soll garkeine Wiederherstellung geben, garkeine Optionen, und keine Einstellungen. Ein Button und sonst nix.
Gruß, Dave
|
|
| |
|
|
|
CrackerTracker © 2004 - 2012 CBACK.de
Powered by Orion based on phpBB
© 2001, 2002 phpBB Group
CBACK Orion Style based on FI Theme
All times are GMT + 2 Hours
phpBB SEO
|
