Duddle
30.06.07, 07: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
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