Zeitgesteuertes Restore

[Jorin]

Ich benutze "MySQL Dumper" als Backup Tool für die Datenbank.
http://www.mysqldumper.de/

Das läuft auch bequem als Cronjob und kann das Backup z.B. auch per eMail verschicken.

Oh, ein Experte? Kannst du mir verraten, wie man ein regelmäßiges Backup mit MySQLDumper per Cronjob erzeugen lassen kann? Habe mich versucht, zu informieren und einzulesen, aber gerade für Nicht-Experten ist das ja ein Buch mit sieben Siegeln und eine anfängergerechte Anleitung habe ich bisher nirgends entdecken können...

[mediman]

Ich benutze "MySQL Dumper" als Backup Tool für die Datenbank.
http://www.mysqldumper.de/

Das läuft auch bequem als Cronjob und kann das Backup z.B. auch per eMail verschicken.

Oh, ein Experte? Kannst du mir verraten, wie man ein regelmäßiges Backup mit MySQLDumper per Cronjob erzeugen lassen kann? Habe mich versucht, zu informieren und einzulesen, aber gerade für Nicht-Experten ist das ja ein Buch mit sieben Siegeln und eine anfängergerechte Anleitung habe ich bisher nirgends entdecken können...

Saubere Updates erzeugt man nur auf sehr wenigen Servern mit MySQLDumper. I.d.R. ist die Sicherung über Adminsoftware wie Plesk, Confixx`s Backup.pl oder HSComplete/Virtuozzo die deutlich bessere Variante.

MySQL selber hat eine ausreichend gute Dumpfunktion, die sich ohne weiteres per Cronjob starten lässt.

mediman

[Jorin]

MySQL selber hat eine ausreichend gute Dumpfunktion, die sich ohne weiteres per Cronjob starten lässt.

Hm, danke für den Hinweis. Weißt du auch, wie? Und wie schauts mit dem Umkehrfall aus (automatisiertes restore)?

[mediman]

So du möchtest können wir ja mal ein Script inkl. Crontab hier posten.
Thema automatisiertes Restore: in welchem Falle?

mediman

[Jorin]

Ohja, sehr gerne. Wie, in welchem Falle?

Ziel wäre, für das SMFPortal ein Testforum mit ACP-Zugang anzubieten. Testforum 1.1.1 ist bereits installiert, Admin-User ist angelegt, mittels Dateirechten sind die Server-Einstellungen im ACP deaktiviert. So können die User dort nicht allzu viel Mist veranstalten. Hoster ist informiert und einverstanden, natürlich wird es erstmal eine nicht-öffentliche Testphase geben. Weitere Info: Account bei www.cronjob.de ist vorhanden, um darüber den Cronjob laufen zu lassen. Denkbar wäre z.B. ein Restore alle 2 Tage nachts, da die DB ja recht klein ist (nur ein User, nur 2 Beiträge).

Welche Infos brauchst du noch?

[mediman]

Alles klar, du willst also die DB sozusagen alle 48h reseten, um die Spielerein rückgängig zu machen.
Für sowas würde ich zwar eine chrooted Umgebung nutzen, aber wie gesagt, das ist relativ easy zu tun.

Hast du Shellzugang? Dann mach ich dir ein *.sh Dingens ...

Mediman

[Jorin]

Zitat Wikipedia:

chroot steht für ,,change root" und ist eine Funktion auf Unix-Systemen um das Rootverzeichnis zu ändern. Sie wirkt sich nur auf den aktuellen Prozess und seine Kindprozesse aus. ,,chroot" selbst kann sich auf den Systemaufruf chroot(2) als auch das Dienstprogramm chroot( beziehen.

Ein Programm das auf ein Verzeichnis re-rooted wurde, kann nicht mehr auf Dateien außerhalb dieses Verzeichnisses zugreifen. Chrooting bietet somit eine einfache Möglichkeit, nicht vertrauenswürdige, Test- oder sonstwie gefährliche Programme in eine Sandbox zu versetzen. Es ist auch ein einfacher Jail-Mechanismus.

Klingt ja auch recht gut, ne Sandbox... Schön sicher, das Test-SMF sieht lediglich sein eigenes Verzeichnis, alles bestens. Wäre das schwerer einzurichten als das mit dem Restore? Was wären denn Nachteile? Da ich ja auch evtl. Testbeiträge und -Themen zurücksetzen möchte, brauche ich doch einen automatischen Restore?

Shellzugriff? Puh, da fragst du mich was.  Habe halt Zugriff auf Confixx, MySQL, den MySQLDumper, etc. Direkten Serverzugriff aber nicht, habe keinen eigenen. Aber ich könnte zur nächsten Tanke fahren... 

[dieter4]

Das müsste über ein PHP-Script geregelt werden. Sollte aber auch kein Problem darstellen? Das Script muss halt nur durch autorisierte Zugriffe ausgeführt werden dürfen. Evtl. wäre ein GET-Parameter mit einem Passwort (md5 kodiert) dafür sinnvoll.

[mediman]

du hast confixx, das reicht für mein script. du hast ja sicher zugriff auf die strukturen über html? z.b. phptmp und files?

mit ~/datei.sh kannste ein script ausführen, welches in einen für webbrowser nicht erreichbaren bereich liegt.

Sollte es nicht möglich sein auf einer Art der Shell zuzugreifen, ist, wie Neakro erwähnte, auch ein PHP Script möglich.

mediman

[dieter4]

Ich dachte bisher nicht, dass Confixx Shellscripte erlaubt, aber probieren kann man's ja mal.

[mediman]

Ich dachte bisher nicht, dass Confixx Shellscripte erlaubt, aber probieren kann man's ja mal.

Wenn du dem User als Confixx-Reseller bei Kunden ändern die Option "Shell Access" gibst, dann kann er *.sh ausführen.

Loggt er sich als User z.B. über Putty ein, dann landet er als User (angenommen webxx) bei /home/www/wexx und kann dort auch *.sh ausführen.

[Jorin]

du hast confixx, das reicht für mein script. du hast ja sicher zugriff auf die strukturen über html? z.b. phptmp und files?

Danke schonmal! 

Zugriff auf meine Verzeichnisse habe ich natürlich. tmp-Verzeichnis, html-Verzeichnis (also das, was dann im Web sichtbar ist), log-Verzeichnis, und einige mehr 

Ob über eine PHP-Datei oder anders ist mir eigentlich wurscht, nur nachvollziehbar muss es für mich sein 

[mediman]

Wie solll ich bei  nachvollziehbaren Sourcen eine Backdoor einbauen? 
Ich kommentiere jede Zeile.

mediman

[Jorin]

Kann man dich anderweitig bestechen? 

Jede Zeile muss ja nicht. Ne kleinere Erklärung, wie das letztendlich dann funktioniert, wäre ja schon mehr als ausreichend. Spitze, danke!

[mediman]

Eine Frage hab ich noch.

1. Sollen alle DB´s die unter deinem Kunden laufen (webX) gesichert werden? Oder möchtest du das im Script selber festlegen?
2. Hast du einen PuTTy-Zugang? SSH oder SSH2 oder ganz böse Telnet? Falls ned, kein Problem.
3. Ist die Rücksicherung statisch, d.h. wird nach 24h bzw. 48h immer wieder das selbe zurückgesichert?

mediman

[Jorin]

1) Nur eine DB. Nur die des Testforums. Also lieber selbst festlegen.
2) Hm, nö...
3) Statisch. Es gibt ein Backup, welches sich eigentlich nie ändert. Wieso ist das denn wichtig?

[mediman]

zu 1. Okay
zu 2. Macht nix
zu 3. Dann kann man diese ja im Backupordner ablegen, und muss sie ned irgendwoher zaubern.

Möchtest du, das jedesmal das Backup übershrieben wird, oder lieber sagen wir 7 Backups (jeder Wochentag) und dann neu?

[Jorin]

Hm, so wie: "Willkommen im Testforum. Heute ist Montag, gut geschlafen?" 

Nee, brauchts nicht. Immer das gleiche Backup bitte. Wäre nur schön, wenn man den Abstand zwischen den Restores editieren könnte. Also, ob es alle 48h, 96h, oder wie auch immer gemacht werden soll.

Edit: Wieso eigentlich Kunde? Es geht um mich/uns 

[Jorin]

Mal gaaaaanz vorsichtig nachfragen...?

[dieter4]

Mal gaaaaanz vorsichtig nachfragen...?

Schon verloren

Soll ich das Thema mal trennen? Mit dem anfänglichen hat es ja nichts mehr zu tun.

[Jorin]

Von mir aus gerne. Titel: "Zeitgesteuertes Restore" oder so...

[dieter4]

OK, fertig.

[Jorin]

Hoffentlich findet mediman den wieder 

[dieter4]

Schreib ihn doch an

[mediman]

hmm, versteckerer.

ich war leider die letzten tage sozusagen ausser gefecht.
so noch interesse besteht, mach ich des teil fettich.

pn genügert.

[mediman]

Grundsätzlich sieht die Sache also nach wie vor so aus, wie in den dir vor langer Zeit gemailten Infos:

Sicherungsskript (backup.sh)

Code Select Expand

#!/bin/sh
email_absender="[email protected]"
email_empfang="[email protected]"

vday=$(date +%u)
  rm dump_$vday.tar.gz
  mysqldump datenbankname -u username -p[passwort]>sql_backup.sql 2>/dev/null
  tar -czf dump_$vday.tar.gz sql_backup.sql 2>/dev/null
  if [ "$?" != 0 ]
  then
    backup_msg="Fehler bei der Sicherung"
  else
    backup_msg="Sicherung erfolgreich"
  fi
text="Backup beendet am `date +"%d.%m.%Y,%H:%M"`"
echo $text > datum.txt
echo $backup_msg >> datum.txt
echo $ftp_msg >> datum.txt
mail -s "Backup-Info Storage Device" -r $email_absender $email_empfang < datum.txt

Diese Code erstellt eine Sicherung der Datenbank. Dabei wird einmal pro Tag gesischert (je nachdem wann du den Job startest). Am Mittwoch heisst die Datei dann z.B. dump_3.tar.gz.

Die Dumps werden jeweils eine Woche aufbewahrt.
So du es nicht auskommentierst, wird auch eine Mail versandt.

Das Einspielen per Cron ist nochmals einfacher (restore.sh):

Code Select Expand

#!/bin/sh

mysql -u username -p[passwort] datenbank <sql_backup.sql

Achtung, im Order muss eine Datei mit dem cleanen Backup vorhanden (sql_backup.sql) sein, damit wird die DB zurückgesetzt!

Die Dateien vollkommen schmerzbefreit als Cron aufrufen.

Mediman

[Jorin]

Grundsätzlich sieht die Sache also nach wie vor so aus, wie in den dir vor langer Zeit gemailten Infos:

Eine Maill, die anscheinend wieder nicht an kam 

Hattest du mir nochmal was genaueres geschickt, was dies besser beschreibt? Wenn ich das recht verstehe, brauche ich zum automatischen Restore eines Backups, welches mir ja vorliegt, also lediglich den zweiten Code-Block, welchen ich in eine Datei irgendwas.sh reinsetze und die rufe ich dann als Cronjob auf? Das wars?

[mediman]

Oui Madame ...

mehr isses ned.

Besser is noch

Code Select Expand

mysql -u username -p[passwort] datenbank <sql_backup.sql 2>/dev/null

Das Passwort muss tatsächlich an p geklatscht werden, kein Leerzeichen!

Sinnigerweise sollte die DB, die Tables vorher leeren. Die Struktur wird ich nicht mit ins sql nehmen, also reine Inserts.

Dann z.b. einmal alle 24h sagen wir um 0300 aufrufen fettich ist!

Fragen?

[Jorin]

Ja, noch eine Frage... Kannst du mir nochmal für Doofies erklären, wie ich beim Backup-Skript einstelle, wann er ein Backup anlegt? Auch über den Cronjob? Weil du ja geschrieben hattest, es würde einmal pro Tag gesichert?

Und was mache ich mit "datum.txt" im skript? Muss ich das austauschen (gegen was)?

[mediman]

Ja, noch eine Frage... Kannst du mir nochmal für Doofies erklären, wie ich beim Backup-Skript einstelle, wann er ein Backup anlegt? Auch über den Cronjob? Weil du ja geschrieben hattest, es würde einmal pro Tag gesichert?

Und was mache ich mit "datum.txt" im skript? Muss ich das austauschen (gegen was)?

Wenn du einen Cronjob, sagen wir jeden Tag um 3 Uhr möchtest, dann sollte der Cronjob folgendermassen aussehen:

0 3 * * * /path/backup.sh

Oder

0 3 * * * sh /path/backup.sh

Kommt auf den Server an.

Zeitmässig muss im Script nix geändert werden!

In datum.txt wird der aktuelle Status gespeichert.
Diese Datei wird auch für den Mailversand genutzt.

[Jorin]

Ich verzweifle gerade am Restore. Ich habe im Verzeichnis ../testforum/backup zwei Dateien liegen: testforum_backup.sh mit deinem Code und testforum_backup.sql mit dem DB-Dump. Den Code in der .sh-Datei habe ich folgendermaßen angepasst:

Code Select Expand

mysql -u web78 -p[hierdasDBpaswortdenken] usr_web78_3 <testforum_backup.sql

Klappt aber nicht, wenn ich bei www.cronjob.de direkt auf die testforum_backup.sh verlinke. Eine Idee, woran es liegen könnte?

[mediman]

Was kommt denn als Fehlermeldung?
Kannst du überhaupt sh ausführen in einem normalen Ordner?
Falls ned, sag mir Bescheid, dann müssen wir das ein ganz klein wenig anders lösen (minimale Änderung)!
Hast du das Passwort in [], die dürfen natürloch nicht stehen bleiben.

Beispiel, Passwort heisst bla, dann muss es pbla heissen, niocht p[bla]

mediman

[Jorin]

Autsch! Denkfehler von mir, danke für die Hinweise, da muss ich noch ein bisserl was testen. Ich meld mich wieder...

[mediman]

okay

medi

[Jorin]

Das mit .sh weiß ich nicht, müsste ich den Hoster fragen...

Das mit dem Passwort hatte ich falsch (mit eckigen Klammern) und nun geändert. Habe beiden Dateien (dem .sh-Skript und dem SQL-Dump) nun 755 gegeben.

Trotzdem klappt es nicht. Er macht es einfach nicht. Möchtest du mal die FTP-Daten und meinen www.cronjob.de-Zugang per PM, um mal selbst nachschauen zu können?

[mediman]

Ja bitte per PM senden.

Ich denke du wirst keine Rechte haben *.sh Skripte auszuführen. So man das weiss, kann man das Ganze auch auf PHP/Perl Basis umstellen. Wobei Perl die deutlich leistungsfähigere Umgebung ist, diese aber für hier kaum benötigt wird.

medi