PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : GAU: ext3-Recovery nach fehlerhaftem DRBD-Sync



Duddle
30.06.07, 08:32
Hallo!

Gestern gab es einen Daten-GAU auf unserem Web- und Fileserver (Debian Etch). Erstmal ganz kurz zur Vorgeschichte: Wir hatten einen zweiten Server identisch installiert und wollten beide mit DRBD 0.7 zusammenschalten, um später mit Heartbeat einen Hot-Failover zu haben. Dazu wurde die Struktur so verändert, dass Web, SQL und die Shares auf jeweils eigenen Partitionen liegen.
Es gibt also zwei Server:

NodeA -> /dev/hda2 und /dev/hdb2 sind /dev/md2 (RAID 1) verbunden und in /shares/ gemountet
Node_Backup -> /dev/hda2 in /shares/ gemountet (Software-RAID funktionierte hier irgendwie nicht)

Da NodeA noch die alte Datenstruktur hatte, haben wir zuerst Node_Backup installiert, mit den neusten Daten versorgt und online geschaltet, dann NodeA umgestellt. Jetzt wollten wir mit DRBD die Daten von Node_Backup auf NodeA spiegeln. Also DRBD-Dienst hochgefahren, beide waren Secondary/Secondary, daher auf Node_Backup drbdadm -- --do-what-I-say primary all, um die initiale Synchronisation zu starten. Es gab ein paar Probleme, deshalb haben wir die Sync abgebrochen (DRBD-Dienst gestoppt), deshalb haben wir (nach mkfs.ext3 auf NodeA) die Daten nochmal händisch von Node_Backup zu NodeA rübergeschoben und den online gebracht.
Danach haben wir auf Node_Backup nochmal mkfs.ext3 /dev/drbd2 gemacht, wir wollten nochmal sauber durchstarten. Situation bisher also:
NodeA -> neuste Daten
Node_Backup -> Datenpartition mit mkfs.ext3 formatiert

Jetzt wollten wir bevor es ins Wochenende geht die Synchronisation von NodeA zu Node_Backup starten. Also DRBD gestartet:
Auf NodeA:
/etc/init.d/drbd start -> warten auf Peer mit "yes" übergangen
drbdadm primary all

Auf Node_Backup:
/etc/init.d/drbd start

Jetzt meldet NodeA, dass er angeblich SyncTarget werden soll (obwohl Primary) und daher sich nicht mit Node_Backup verbinden will. Also auf Node_Backup nochmal drbdadm secondary all. Die Befehle invalidate und invalidate_remote funktionieren leider nur bei cstate connected. Daher dachten wir uns: naja, wir bringen die beiden Knoten nochmal in Secondary/Secondary, damit sie sich verbinden und auf ein "--do-what-I-say primary all" in die richtige Richtung syncen.
Was passiert? Beide gehen in Secondary, verbinden sich und sofort fängt Node_Backup (!!!) an, auf NodeA zu syncen! Die leere Festplatte synct auf die volle o_O!
Natürlich sofort DRBD gestoppt, es hat ca. 3 Sekunden arbeiten können.
Beide Platten sofort ausgehangen und read-only gemountet, um nicht noch mehr zu zerstören. Wie ich befürchtet hatte, war auf NodeA im Ordner nur noch "lost+found". fsck.ext -n hat auch keine Fehler gemeldet.

Ich habe jetzt keine Ahnung, was Node_Backup schon überschrieben hat. Ich kenne mich mit der internen Architektur von ext3 nicht aus, habe nur gelesen dass man zumindest diesen Superblock wiederherstellen kann. Ich vermute aber, dass DRBD schnell genug war, um schon mehr zu überschreiben. Und wenn die inodes weg sind, gibt es wenig Chancen, die Dateien zu retten, stimmt's?

Daher meine Fragen euch:

1. Wie finde ich heraus, bis wohin DRBD schon "synchronisiert" hat, also ob die inodes schon weg sind oder nur der Superblock?
2. Welche Möglichkeiten der Datenrettung habe ich in beiden Fällen?
3. Gäbe es irgendeine Möglichkeit, noch Daten aus der per mkfs.ext3-bearbeiteten Partition von Node_Backup zu holen

Bevor jetzt jemand (ganz zu recht) schreit "BACKUP": wir hatten nach der Umstellung der Datenstruktur zwar die Backupscripts angepasst, aber niemand hat wirklich geschaut, ob die Backups wirklich erstellt werden... Die Daten von www und SQL sind als Backup vorhanden, aber die von /shares/ hatte es nicht angelegt :-(

Naja, ich bedanke mich jedenfalls für jeden nützlichen Tipp. Montag beginne ich dann mit einem dd-Backup der (hoffentlich nicht zu sehr) zerstörten Datenpartition. Dann kann ich auch Ausgaben von irgendwelchen Programmen hier posten, falls solche Fragen kommen.


Danke im Voraus,

Duddle

cane
01.07.07, 03:36
Ichh sehe kaum Chancen - so wie ich dich verstehe sind die Daten doch nicht nur gelöscht sondern überschrieben worden...

Oder hat er nur gelöscht?

mfg
cane

bla!zilla
01.07.07, 11:18
Ich sehe auch nicht wirklich eine Chance, außer dem Restore über ein sicherlich vorhandenes Backup. Zumal es ja kein Dateisystemdefekt im eigentlich Sinne ist, sondern eine normale Dateisystemoperation.

drunkenPenguin
27.08.07, 06:12
Der Vollständigkeit halber (aktuell ist das Problem sicher nicht mehr -- aber vielleicht hat ja mal jemand anderes ein ähnliches) ein Verweis auf das Tool "debugfs". Dann und wann kann man mit diesem Werkzeug noch ein paar Daten zusammenkratzen, wenn man Zeit und Geduld hat.
Allerdings ist es fraglich, ob das hier noch geholfen hätte.

cane
27.08.07, 11:16
Ich habe in der Vergangenheit sehr erfolgreich Stellar Phoenix benutzt:

http://www.stellar-info.de/

mfg
cane

knallerbse
27.08.07, 11:28
cane: nur leider hilft das tool nichts, da wir hier von ext3 reden und nicht von einem windows dateisystem...

zum topic: da kann man glaub ich nicht viel machen... ist mir leider auch schonmal passiert und am ende hab ichs auch noch irgendwie geschafft das dateisystem komplett zu schrotten :(

Dellerium
27.08.07, 11:56
@knallerbse:

http://www.stellar-info.de/linux-datenrettung-software.html :)