Backup einer Datenbank möglich? [Lösung]

[Tim Hildebrandt]

Hallo Liste,

nach zwei schlaflosen Nachten und den erforderlichen Schnellkursen in
einigen Linux-Befehlen habe ich eine Lösung meines Problems gefunden, die
ich Euch an dieser Stelle kurz mal posten möchte - falls jemand von Euch
einmal in ähnliche Probleme kommt. 

Aber zuerst ein kleines Review bezüglich der Organisation von Datenbanken
durch MySQL (Profis können ja weiter unten weiterlesen):


---------------------SCHNIPP-----------------------------

- Also MySQL organisiert Datenbanken als Ordner. Alle Ordner unterhalb des
in den Einstellungen angegebenen Pfades werden automatisch aul Datenbanken
interpretiert. Sei also der Pfad

/var/lib/mysql/

der "Root" des Servers, so wäre der Ordner

/var/lib/mysql/my_db/

automatisch eine Datenbankdefinition.



- Tabellen setzen sich immer aus drei Dateien zusammen (MyISAM):

.MYD
.MYI
.frm

Diese drei Dateien repräsentieren eine Tabelle. Dabei verwendet MySQL eine
geschickte Aufgabenverteilung, die die Geschwindigkeit der betrachteten
Tabelle zu optimieren und die Strukturen quasi durch sich selbst
beschreibbar zu machen:

.frm -> Das "Gehirn" der Tabelle. Hier wird gespeichert, wie die Spalten
heißen, welche Datenlänge diese haben und in welcher Reihenfolge die Spalten
angeordnet sind

.MYI -> Die Indexdatei. Hier werden alle Indizes gespeichert, die in der
Tabelle definiert werden. Bei sehr großen Datenbeständen macht es Sinn, über
entsprechende MySQL-Befehle (OTIMIZE TABLE) die Indexdaten neu schreiben zu
lassen.

.MYD -> Der "Body" der Tabelle. Hier liegen dann letztlich die Nutzdaten
drin.

----------------------SCHNAPP---------------------------


So, und nun zu meiner Lösung:

Was bei uns passiert ist, ist der denkbar ungünstigste Fall von
Datenverlust: Die .frm Dateien unserer Tabellen wurden aufgrund eines
Backupfehlers zerstört und waren auch nicht mehr zu rekonstruieren.
Jedenfalls nicht so einfach... Es funktioniert aber mit etwas detektivischem
Spürsinn dennoch, denn: Aufgrund der restlichen beiden Dateien lassen sich
zumindestens die Anzahl der Spalten, deren Datentypen sowie alle Indizes mit
ihren Datenlängen rekonstruieren. Man hat dann zwar immer noch nicht die
Spaltennamen, aber immerhin weiß man, wie die Tabelle strukturiert ist.

Man nehme also eine Linux-Konsole und sinnvoller weise wechselt man in das
Verzeichnis, das die böse, böse Datenbank beinhaltet, bzw. in dem die
Tabellen liegen:

/mein/db/ordner/mysql/meine_db/


Hier gibt man den folgenden Befehl ein: myisamchk -dvv meinetabelle

Als Ergebnis erhält man die Aufstellung der Spalten und Indizes (Es könnte
sein, dass das jetzt von der Zeilenbreite her nicht ganz sauber wird):

table description:
Key Start Len Index   Type                     Rec/key         Root
Blocksize
1   2     4   unique  long                           1         8192
1024
2   126   40  multip. char packed stripped          34        16384
1024
3   86    40  multip. char packed stripped         646        19456
1024
4   6     40  multip. char packed stripped          20        12288
1024
5   171   4   multip. long                           4        10240
1024
6   46    40  multip. char packed stripped          20        14336
1024

Field Start Length Nullpos Nullbit Type
1     1     1
2     2     4                      no zeros
3     6     40                     no endspace
4     46    40                     no endspace
5     86    40                     no endspace
6     126   40                     no endspace
7     166   1
8     167   4                      no zeros
9     171   4                      no zeros
10    175   100                    no endspace
11    275   2      1       1
12    277   10                     blob


So, nachdem wir also wissen, wie die Tabelle aussieht, kann man sich nun
mittels phpMyAdmin an die Arbeit machen, eine identische Tabelle zu
generieren. Laut Aussage von MySLQ ist es dabei vollkommen schnuppe, wie die
Spalten heißen. Wichtig ist einzig die Reihenfolge und Datentypen der
Spalten sowie die Reihenfolge der Indizes.


Wenn man mit dieser Arbeit fertig ist, hat man ja automatisch in seinem
Verzeichnis bereits eine entsprechende .frm Datei mit identischen
Datenausmaßen erzeugt. Diese .frm Datei benennt man nun so um, dass diese
den selben Namen hat, die auch die zu rekonstruierenden .MYD/.MYI Dateien
haben.

Mittels myisamchk -e meinetabelle 

kann man nun feststellen, was mit der Tabelle los ist. im optimalsten Fall
kommt sowas wie:

"should be usable, but keys should be fixed"

Sprich, dit Tabelle ist nutzbar, aber die ID's  müssen neu geschrieben
werden. Dies erreicht man dann sinnvoller Weise über den Befehl:

myisamchk -r meinetabelle    oder
myisamchk -o meinetabelle

Die Rekonstruktion sollte mit der Meldung

DataRecords: 12345

also mit der Anzahl rekonstruierter Zeilen abschließen.


Wichtiger Hinweis: Dieser Vorgang funktioniert NICHT, wenn ein fehlerhaftes
Backupsystem auch die .MYD/.MYI Dateien versemmelt.

Was lernen wir daraus: Man läßt es bleiben oder macht es richtig!


Liebe Grüße
Tim