RootForum Community

Hi!

Gestern wurde mein Server gehackt. Die Passwörter sind geändert und alle index.* sind mit einem Hackerspruch überschrieben. Mit dem Rescure System habe ich nun alle Dateien gesichert, aber ich finde die Datenbanktabellen nicht.

In /var/lib/mysql liegt eine 146MB Große p15xxxxxx-bin.001 in der Confixx anscheinend Verwaltungsdaten ablegt.

Wo liegen die Usertabellen? Da meine wichtigste Seite ein CMS ist ist sie ohne die Tabellen tot.

Habe einen Rootserver bei 1&1 mit SuSE.

MfG
Wolfgang

also die *.bin datei wird bei der replikation zweier mysql-server benötigt...

im gleichen verzeichniss sollten auch die db liegen....

ansonsten ist das datadir auch in der /etc/my.cnf oder im init script angegeben...

Die p15xxxxxx-bin.001 ist zwar nur eine Log-Datei, aber falls deine Datenbank gedroppt wurde, könnte man sie aus der glaube ich wieder herstellen - also nicht löschen!

Im Verzeichnis /var/lib/mysql sollten bei SuSE die Datenbanken liegen. JEde Datenbank hat hier ein weiteres Unterverzeichnis. Wenn deine Datenbank also z.B. usr_web1_1 heißt, dann geh mal in folgendes Verzeichnis:

cd /var/lib/mysql/usr_web1_1/

Mir "dir" kannst du dir die Dateien anzeigen lassen. Diese Dateien sind die Datenbanktabellen, die du in Sicherheit bringen solltest!

Besser wäre es u.U. jedoch, nicht einfach diese Dateien zu kopieren, sondern einen orderntlichen Dump anzulegen, der dann nach der Re-Initialisierung deines Servers eingespielt wird. Den Dump machst du so:

mysqldump -uroot -pROOTPASSWORT -hlocalhost usr_web1_1 > /tmp/backup_usr_web1_1.sql

Du kannst ihn auch noch komprimieren:
gzip -9 --best /tmp/backup_usr_web1_1.sql

So sicherst du die Datenbank "usr_web1_1". Wenn du andere DB's hast, solltest du genauso mit ihnen verfahren.


Ach ja: Lass am besten den Server neu aufsetzen, nachdem du alles gesichert hast!!! Denke dir in Zukunft gute Passwörter aus (mind. 10 Zeichen, inkl. Kleinbuchstaben, Großbuchstaben, Ziffern und Sonderzeichen) und aktiviere den PHP SafeMode.

Odysseus wrote:Die p15xxxxxx-bin.001 ist zwar nur eine Log-Datei, aber falls deine Datenbank gedroppt wurde, könnte man sie aus der glaube ich wieder herstellen - also nicht löschen!

mhh ich dachte ich hätte oben schon geschrieben das *.bin Dateien sind binäre log Dateien die zur Replikation zweier server benutzt werden... und aus dieser lassen sich die mysql-db nicht wieder herstellen... :-D

Odysseus wrote: Im Verzeichnis /var/lib/mysql sollten bei SuSE die Datenbanken liegen. JEde Datenbank hat hier ein weiteres Unterverzeichnis. Wenn deine Datenbank also z.B. usr_web1_1 heißt, dann geh mal in folgendes Verzeichnis:

mhh hatte ich oben auch schon geschrieben.... aber najanu... :-D

Odysseus wrote: Besser wäre es u.U. jedoch, nicht einfach diese Dateien zu kopieren, sondern einen orderntlichen Dump anzulegen, der dann nach der Re-Initialisierung deines Servers eingespielt wird. Den Dump machst du so:

mysqldump -uroot -pROOTPASSWORT -hlocalhost usr_web1_1 > /tmp/backup_usr_web1_1.sql

mhh nun kann er aber im rescue system (siehe oben) schlecht einen dump erstellen... :-D

Odysseus wrote: Ach ja: Lass am besten den Server neu aufsetzen, nachdem du alles gesichert hast!!! Denke dir in Zukunft gute Passwörter aus (mind. 10 Zeichen, inkl. Kleinbuchstaben, Großbuchstaben, Ziffern und Sonderzeichen) und aktiviere den PHP SafeMode.

die aussage lasse ich einfach mal so stehen... ob das ein system sicher macht - sei jedem rootserver besitzer selbst überlassen... :lol:

Odysseus wrote:Mir "dir" kannst du dir die Dateien anzeigen lassen.

s/"dir"/"ls"/

Unter SuSE ist dir = ls -l

Hi,

mhh ich dachte ich hätte oben schon geschrieben das *.bin Dateien sind binäre log Dateien die zur Replikation zweier server benutzt werden... und aus dieser lassen sich die mysql-db nicht wieder herstellen...

wenn du jetzt noch einen plausiblen Grund nennst, warum das nicht gehen sollte - mal ganz davon abgesehen steht bei mysql.com dass es geht - dann glaub ich es dir vielleicht.

coolsurfer

GameCrash wrote:Unter SuSE ist dir = ls -l

Das ist kein Grund Jemandem eine falsche Syntax beizubringen! Zudem existiert dieser Alias nicht auf jedem SuSE...

coolsurfer wrote:Hi,

mhh ich dachte ich hätte oben schon geschrieben das *.bin Dateien sind binäre log Dateien die zur Replikation zweier server benutzt werden... und aus dieser lassen sich die mysql-db nicht wieder herstellen...

wenn du jetzt noch einen plausiblen Grund nennst, warum das nicht gehen sollte - mal ganz davon abgesehen steht bei mysql.com dass es geht - dann glaub ich es dir vielleicht.

coolsurfer

Wenn man ein SnapShot der Datenbank hat, wie sie zum Zeitpunkt des Begin des binlogs war, geht das. Wenn man natürlich alle BinLogs seit Begin des Serverbetrieb hat, gehts. Aber im Normalfall hilft einem der binlog alleine nicht weiter.

Joe User wrote:

GameCrash wrote:Unter SuSE ist dir = ls -l

Das ist kein Grund Jemandem eine falsche Syntax beizubringen! Zudem existiert dieser Alias nicht auf jedem SuSE...

ich sehe nicht, wo das syntaktisch falsch wäre... man kanns auch wirklich übertreiben mit der Alles-Was-Aus-Redmond-Kommt-Ist-Vom-Teufel-Besessen... den Alias haben fast alle Distris drin - übrigens sogar Debian ;)

ich sehe nicht, wo das syntaktisch falsch wäre... man kanns auch wirklich übertreiben mit der Alles-Was-Aus-Redmond-Kommt-Ist-Vom-Teufel-Besessen... den Alias haben fast alle Distris drin - übrigens sogar Debian

Ein "dir" ist zwar sytaktisch nicht falsch, unter Unix ist und bleibt das Kommando, sich Files oder Directories anzeigen zu lassen nun mal ls, egal, ob dafür ein Alias existiert oder nicht.
Setz mal einen "SuSE-Verwöhnten", der sich auf solche Aliase verläst vor ein "richtiges" Unix, und ich prophezeie, dass er sich fast gar nicht mehr zurechtfinden wird.

Es geht gerade für Joe User, der (da bin ich verdammt sicher) am allerwenigsten in die "Anti-M$"-Ecke gedrängt werden kann nicht um den immerwährenden OS-Flame, sondern einzig und allein um o.g. Punkte.

CaptainCrunch wrote:Es geht gerade für Joe User, der (da bin ich verdammt sicher) am allerwenigsten in die "Anti-M$"-Ecke gedrängt werden kann nicht um den immerwährenden OS-Flame, sondern einzig und allein um o.g. Punkte.

ACK und danke für die Klarstellung.