Manch einer wird sich die letzten Tage gewundert haben, warum diese Seite nicht angesprochen werden konnte. Der Grund ist ganz einfacher: Das Festplatte meines Roots hats erwischt und dabei sind nen Haufen Sektoren drauf gegangen. Auslöser war ein Fehler im Stromnetz des Rechenzentrums, in dem der Root steht. Dort hats den Core-Switch und die DHCP-Server erwischt… Als mir der Techniker den Grund zugemailt hatte, weshalb der Server nicht mehr geht(bread: Cannot read the block (22380544): (Input/output error), habe ich erstmal etwas ratlos geschaut, denn mit Datenwiederherstellung hatte ich bisher nur unter Windows Erfahrungen gesammelt. Über mein frisch erworbenes Wissen habe ich nun diesen (teilweise klingt er verwirrend, hat aber alles seinen Sinn) Artikel geschrieben.

Backups sind gut und schön, aber nie so aktuell wie das normale System, daher habe ich mich lieber dran gemacht, die Daten von der Platte zu ziehen. Beginnen wir von Vorne:

Betroffene Platte: Maxtor 6Y200M0 (S-ATA), eingebunden als sda, / liegt auf sda2, swap ist sda1

Boot ins Rescue-System, da die Platte nicht mehr vom System gelesen werden kann. Erstmal ausprobiert, ob mans die Platte noch mounten kann:

1
2
3
4
5

RESCUE:~# mount -o ro /dev/sda2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sda2,
 missing codepage or other error
 In some cases useful info is found in syslog - try
 dmesg | tail or so

Sieht also erstmal relativ schlecht aus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

RESCUE:~# reiserfsck --check /dev/sda2
[Blabla]
Replaying journal..
Reiserfs journal '/dev/sda2' in blocks [18..8211]: 0 transactions replayed

The problem has occurred looks like a hardware problem. If you have
bad blocks, we advise you to get a new hard drive, because once you
get one bad block that the disk drive internals cannot hide from
your sight,the chances of getting more are generally said to become
much higher (precise statistics are unknown to us), and this disk
drive is probably not expensive enough for you to you to risk your
time and data on it. If you don't want to follow that follow that
advice then if you have just a few bad blocks, try writing to the
bad blocks and see if the drive remaps the bad blocks (that means
it takes a block it has in reserve and allocates it for use for
of that block number). If it cannot remap the block, use badblock
option (-B) with reiserfs utils to handle this block correctly.

bread: Cannot read the block (22380544): (Input/output error).

Aborted

Wie man sehen kann ist das schon mal einer der Blöcke die kaputt gegangen sind. Aber das war ja auch erstmal nur ein kleiner Oberflächencheck, nix was ernsthaft was beheben würde…

An dieser Stelle erstmal ein Tipp: Folgende Tools sollten installiert werden, damit ein Wiederherstellung schnell möglich ist:

apt-get install ddrescue screen netcat badblocks

Nun startet man zunächst einen screen. Wozu soll das dienen? Ganz einfach: Die folgenden Prozesse sind sehr kritisch. Sollte nun die SSH-Verbindung abbrechen oder möchte man einen zweiten Mitarbeiter / Helfer zuschauen lassen, so ist dies mit Screen relativ einfach zu lösen. Mit screen -R rescue startet man eine Konsole, in der nun die folgenden Prozesse ausgeführt werden können. Vielleicht könnte man das auch anders lösen, ich habs so gemacht und es hat geklappt(Bei mir ist tatsächlich der 24h-Disconnect einmal dazwischen gekommen)

DIE FOLGENDEN SCHRITTE GESCHEHEN AUF EIGENE GEFAHR! ICH BIN KEINESFALLS FÃœR IHRE DATEN VERANTWORTLICH! LESEN SIE ZUERST DEN KOMPLETTEN ARTIKEL MEHRMALS!

Jetzt sollte man erstmal einen ausführlichen Check auf defekte Sektoren durchführen

1

badblocks -n -o /home/bablocks.log /dev/sda2

Das kann ne Weile dauern, ich hab derweil ganz gut essen können ;)

Bei mir stellte sich heraus, dass eine ganze Menge Blöcke betroffen waren… was nicht so gut ist, aber ich wollte unbedingt an die Daten.

Was jetzt ganz wichtig ist: fsck hats schon gesagt, aber hier nochmal in aller Deutlichkeit: Die Festplatte hat sehr wahrscheinlich einen Hardwareschaden. Sollte man die Möglichkeit haben, so sollte man nun eine neue Festplatte von gleicher oder größerer Kapazität einbauen um darauf die Daten zu kopieren und dort dann zu bearbeiten. Wenn man nun auf der alten Platte weiterarbeitet, so besteht die Möglichkeit, dass die Daten ganz verloren sind. Ich gehe im folgenden nur auf die Möglichkeit ein, dass man eine zweite Platte zur Verfügung hat.

Anmerkung: Ich habe einen zweiten Server in einem anderen Rechenzentrum noch genutzt und via Netcat  einmal das komplette Image der kaputten Platte rübergeschubst, um es redundant auf einem RAID1 zu halten, was aber nicht für die Wiederherstellung notwendig ist. Auf den folgenden Link klicken, wenn man das machen möchte:

Vorrausetzungen:

  1. Genug Traffic (Mindestens soviel wie gesichert werden soll, bei mir warens knapp 200GB)
  2. Genug Zeit (Mal nen Techniker an der Platte horchen lassen ;))
  3. Ausreichend schnelle Verbindung zwischen den Servern (Bei mir warens 12MB/s und das war ziemlich lahm)

Folgendes auf dem Zielrechner ausführen: netcat -l -p 1337 > /SpeicherortMitGenugKapazität/serverimage.mnt

Folgendes auf dem zu backuppenden Rechner ausführen: dd_rescue -A -l /home/ddrescue.log /dev/sda|netcat ZIELRECHNER 1337 wobei ZIELRECHNER duch die Adresse des obenstehenden Rechners auszutauschen ist. Der Port 1337 ist natürlich auch auszutauschen, muss aber natürlich bei beiden Eingaben identisch sein.

Jetzt nur noch ne Weile warten ;)

Wenden wir uns dem eigentlichen Backup zu: Vorraussetzungen bei mir: Neue Festplatte: Maxtor 250GB S-ATA @ sda Alte Festplatte Maxtor 200Gb S-ATA @sdb

Nun kopiert man die Daten zunächst inklusive sämtlicher Partitionen und mbr auf die neue Platte mittels dd_rescue. Dieses Programm hat gegenüber dd den Vorteil, dass bei Fehlern ersten Nullen geschrieben werden können und zweitens, dass über Fehler weggeangen wird und nicht der Programmlauf abbricht.

Here we go:

1
2

apt-get install ddrescue
dd_rescue -A -l /home/dd_rescue.local.log /dev/sdb /dev/sda

Das wird nun ne Weile dauern, bei mir hat der Rechner mit 50-60MB/s die Daten rumgeschaufelt. Fehler wurden versucht zu beheben, wenn nicht möglich, werden (dank -A) Nullen geschrieben. Das Log ist unter /home/dd_rescue.local.log zu finden.

Anschließend sollte man die Platte erstma bearbeiten. Ich habe erstmal die Festplatte folgendermaßen behandelt:

1

reiserfsck --fix-fixable /dev/sda

Die Nachfrage muss man mit “Yes” beantworten. Nun versucht erstmal reiserfsck die Festplatte zu retten und die kaputten Blöcke zu reparieren. Manchmal reichts aus, überprüfen sollte man dies mit (wie oben zu sehen) badblocks.

Wenn immer noch badblocks auftreten, dann muss der Dampfhammer ran(sda2 ist die /-Partition auf der neuen Platte):

1

reiserfsck --rebuild-tree -l /home/rebuild_tree.log /dev/sda2

Muss man ebenfalls mit “Yes” beantworten. Das wird nun ne Weile dauern.

Bei mir waren glücklicherweise einfach nur nen paar Libraries zerschossen, diese konnte ich dann einfach via

1

apt-get install --reinstall PACKETNAME

neuinstallieren. Hier kann man jedoch keine Anleitung geben, denn bei jedem ist was anderes kaputt. Man sollte auf jeden Fall sich das Log mal reinziehen, da steht manchmal ne ganze Menge drinnen. Helfen tuts häufig einfach mal, in der Rettungs-Konsole die Programme zu starten. Geht wie folgt:

1
2
3
4
5

mkdir /mnt/rescue
mount /dev/sda2 /mnt/rescue
mount --bind /dev /mnt/rescue/dev/
mount --bind /proc /mnt/rescue/proc/
chroot /mnt/rescue /bin/bash

Nun ist man praktisch direkt im File-System der Festplatte und kann alle Änderungen vornehmen. Mittels des Packetmanagements kann man Packete neu installieren, diese werden dann auf die Festplatte und nicht ins Rettungsystem installiert. Bei mir wollte z.B. der Mailserver keine Mails anehmen, ich vermutete bei saslauthd den Fehler, denn /etc/init.d/saslauth start gab nur ein “Failure” aus. Einmal /usr/sbin/saslauthd -a pam aufgerufen, gab es einen Fehler wegen einer nicht erfüllten Abhängigkeit. Auf http://packages.debian.org/PACKETNAME  lassen sich die Abhängigkeiten von PACKETNAME auflisten und evtl dann nachinstallieren.

Dieser Artikel kann nur ein Anstoß sein, denn normalerweise sind die Fehler sehr verschieden. Daher sollte man immer sehr genau alle Meldungen lesen, verstehen und erstma bei den bekannten Suchmaschinen recherchieren. Wem diese Zeit zu schade ist, der braucht nicht die Daten wiederherzustellen.

Ich wiederhole von oben: Ich übernehme keinerlei Haftung für ihre Daten.