DriveReady SeekComplete Error / Festplattendefekt

[blacksavior]

Hallo Zusammen!
Wir hatten heute Morgen um 4:15 einen "DriveReady SeekComplete Error" auf unserem Root-Server.

Code: Select all

Mar  6 04:15:35 p12345678 kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar  6 04:15:35 p12345678 kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=1745, sector=1743
Mar  6 04:15:35 p12345678 kernel: end_request: I/O error, dev hda, sector 1743
Mar  6 04:15:36 p12345678 kernel: EXT3-fs error (device hda1): ext3_get_inode_loc: unable to read inode block - inode=6593, block=210
Mar  6 04:15:36 p12345678 kernel: Aborting journal on device hda1.
Mar  6 04:15:36 p12345678 kernel: ext3_abort called.
Mar  6 04:15:36 p12345678 kernel: EXT3-fs abort (device hda1): ext3_journal_start: Detected aborted journal
Mar  6 04:15:36 p12345678 kernel: Remounting filesystem read-only

Ich befürchte, das die Festplatte vielleicht schaden genommen hat. Aber da das System noch ohne Probleme läuft, ausser dass das Confixx-Counterscript Minütlich mekert:

Code: Select all

chmod: changing permissions of `/etc/mail/spamassassin': Read-only file system

Der Rest der Partitionen ist scheinbar noch ok. Betrifft derzeit "nur" hda1:

Code: Select all

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             510M  334M  151M  69% /
tmpfs                  20M     0   20M   0% /dev/shm
/dev/hda5             4.9G  788M  4.2G  16% /usr
/dev/hda6             4.9G  601M  4.3G  13% /var
/dev/hda7              27G   11G   16G  42% /home
tmpfs                 122M  696K  121M   1% /tmp

Möchte somit gerne das weitere Vorgehen erst kurz diskutieren. Ausserdem kann ich wärend der derzeit laufenden Datensicherung sowieso nichts anderes machen.
Zur Diskusion stehen:
- Ist es ein Festplatten-/Hardwarefehler?
- Ist er Permanent, also ein Hardwaredefekt, oder nur Temporär durch einen Softwareseitige falschen zugriff auf die platte?
- kann die platte ohne weiteres wieder als "rw" gemountet werden? Wenn ja, zu empfehlen?

Der Rechner
- alter 1&1 Rootserver mit 2000GHz CPU und 256MB Ram
- Suse 9.1; Originales 1&1 Standardimage
- Produktivsystem


MfG
BlackSavior

[niemand]

Ich würde die Daten sichern und den Provider diesbezüglich anmailen, damit der eine neue Platte reinsetzt.

Btw., 2THz CPU mit nur 256MB RAM bringt nichts ;)

cu

[blacksavior]

Btw., 2THz CPU mit nur 256MB RAM bringt nichts

Wie, bin ich hier der einzige mit 'ner 2000GHz CPU? :lol:

Sind gerade am überlegen, wie schwerwiegend der Defekt ist. Da dies noch ein raidloser Server ist, heist Plattentausch auch gleich, das wir das ganze System neu einrichten müssen. Und so eine Offtime möchte ich gerne umgehen.
Ich muss dazu sagen, das sowieso eine Migration auf ein neues System geplant war (Leistung und Hardwareraid). Aber der neue ist nicht mal bestellt. Und bis wir den haben und dann alles so eingerichtet ist, wie wir uns das vorstellen vergehen ein paar Wochen.
Also heist die Frage der Fragen ob man es einfach wartet bis der neue da ist und auf den Überlebenswillen der Platte setzt. Einfach einen Reboot riskiert und hoffen, dass die Partitionen dann alle wieder RW gemountet werden, bzw. überhaupt.
Datensicherheit ist sowieso durch eine nächtliche Datensicherung gegeben. Um die Verfügbarkeit geht es hauptsächlich.

Gruß BlackSavior

PS: Sollte noch wer einen Rechtschreibfehler finden, so darf er ihn gerne behalten. Die dienen nur der allgemeinen BElustigung :o)

[alexander newald]

Ich denke, dass die Platte gerade einen SOS Ruf gesendet hat. Wieder rw mounten ist nicht gut. Wie vorher schon gesagt: Als erstes alles von der Platte sichern, was man noch brauchen könnte/müsste. Erst dann irgendwas versuchen. Ach ja, wenns sich vermeiden lässt nicht rebooten. Meist kommen dann defekte Platten nicht mehr hoch.

[blacksavior]

Danke für den Tipp,
Backups sind, wie oben geschrieben, heute morgen schon gelaufen.

Die Frage ist, ob und wenn wie lange ein System mit einer als R gemounteten "/" laufen kann. Auf hda1, also auf "/" liegen direkt:

"/", "bin", "boot", "dev", "etc", "lib", "lost+found", "media", "mnt", "mysql", "opt", "proc", "root", "sbin", "srv" und "sys"

Die meisten sind wohl unkritisch da dort so oder so nicht automatisch geschrieben werden sollte. Die Frage ist ob eines der Verzeichnisse zwingend RW braucht oder - für eine gewisse Zeit - R reicht.

"var", "usr" und "home" haben eigene Partitionen.

Gruß BlackSavior

[blacksavior]

PS:

Natürlich sind derzeit Änderungen durch Confixx an EMailadressen, Apacheeinstellungen etc nicht möglich, was den Betrieb derzeit aber nur minimal einschränkt.

[alexander newald]

/mysql ? Sind da die Datenbanken drin? Wenn ja, kann man keine Daten in der mySQL DB mehr ändern.

[bfrackie]

hast du mal gefragt, ob 1&1 dir die platte auf ne neue spiegelt und dann die neue einsetzt?

somit wärste alle sorgen los :-)

Bart

[blacksavior]

Gerade nachgesehen, mysql ist nur ein symlink auf /usr/mysql. Ist original 1und1 Image. Keine Ahnung was der soll.

Das Spielegln durch 1und1 ist so eine Sache. Es birgt etwa das gleiche, wenn nicht so gar ein höheres Risiko wie ein Reboot, von dem mir hier ja auch abgeraten wurde.
Ich hab zwar noch nicht nachgefragt, aber Spiegelt 1und1 überhaupt Platten? Hat jemand das schonmal von denen machen lassen? Gabs dabei Probleme, zeitlich oder technisch?

Gruß BlackSavior

[blacksavior]

Hallo nochmal!

Abschließend noch ein paar Worte wie wir mit unserem Problem umgegangen sind:

- Natürlich haben wir Datensicherungen gemacht. Die macht unser System so wieso Nächtlich auf einen FTP-Backup-Space.

- Zusätzlich ab und an ein Backup heruntergeladen, damit wir im Worst-Case Kunde für Kunde zurückspielen könnten.

- Keinen Reboot da das zum Komplettausfall hätte kommen können.

- Spiegeln der Platte durch 1&1 haben wir auch nicht gemacht - nichtmal nachgefragt. Sagen wir mal das Spiegeln wäre gescheitert. 1&1 hätte bestimmt nicht nochmal die defekte Platte eingebaut sondern eine neue mit Standardimage. Die Ausfallzeiten wärend unserer Wiederherstellung wären tödlich gewesen.

- re-mount der ro-Partition war nicht möglich, da es sich um die "/" Partition gehandelt hat.

- Dadurch verzichteten wir für einige Zeit auf das Anlegen von neuen Accounts, E-Mailadressen, SPam-Regeln und alles was sonnst noch ins /etc will.

- Neuen Server bestellt - war sowieso geplant - und neu eingerichtet. (Plesk 8 anstatt Confixx, neuester Indianer, Php 5.1.2, MySQL 4.x, parallel MySQL 5.x)

- Alles ein paar Tage getestet.

- Dann in einer Nachtaktion postfix heruntergefahren und jeden Account einzeln per Plesk Migration herübergeholt. Parallel bei Schlundtech die DNS-Einträge geändert und den neuen Server als Primary DNS angegeben.

- Den alten Server noch ein paar Tage im Parallelbetrieb falls ein DNS noch auf eben diesen verweist. Postfix auf dem Alten deaktiviert gelassen.

Mit diesem Vorgehen sind wir mit minimalen Ausfallzeiten noch mal an einer Katastrophe vorbeigeschrammt. Die Nachtaktion dauerte zwar fast neun Stunden. Da sich der Secondary DNS aber nicht geändert hatte, hatten die Surfer keinen Ausfall. Nur der E-Mail-Dienst, und dabei auch nur SMTP für die Kunden und MX, sind für relativ kurze Zeit ausgefallen. Dadurch bekamen einige E-Mailsender Emails zurück, bzw. unsere Kunden Teilweise einen SMTP-Server Timeout. Aber sobald wir einen Kunden auf den neuen Seerver Migriert hatten, lief der Dienst für seine Accounts wieder. Und da wir zuerst die Wichtigsten Kunden migrierten, war der Ausfall hierbei auch nur minimal.


Noch einmal ein Dankeschön an die Hilfe weiter oben.

MfG BlackSavior