HDD-Problem

hahni

Active Member
Hallo zusammen,

vor wenigen Tagen ist ein Server im RZ aus unerklärlichen Gründen abgestürzt. Laut Logs war das ein Problem mit dem Festplatten-Cache. Ich habe der Sache keine Bedeutung beigemessen, bis dies gestern in der Nacht wieder passiert ist. "smartctl -a /dev/sda" gab folgendes aus:
Code:
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD2502ABYS-02B7A0
Serial Number:    WD-WCAT1F653717
Firmware Version: 02.03B03
User Capacity:    251.059.544.064 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Jan 29 05:07:51 2012 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                 (4800) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (  59) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.

SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   200   198   021    Pre-fail  Always       -       966
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       17
  5 Reallocated_Sector_Ct   0x0033   185   185   140    Pre-fail  Always       -       116
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       6994
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       15
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       13
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       3
194 Temperature_Celsius     0x0022   112   109   000    Old_age   Always       -       31
196 Reallocated_Event_Count 0x0032   187   187   000    Old_age   Always       -       13
197 Current_Pending_Sector  0x0032   199   199   000    Old_age   Always       -       42
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
Warning: ATA error count 448 inconsistent with error log pointer 1

ATA Error Count: 448 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 448 occurred at disk power-on lifetime: 6990 hours (291 days + 6 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 41 00 f7 04 2c e0  Error: ABRT at LBA = 0x002c04f7 = 2884855

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 f7 04 2c 00 0a  10d+10:11:56.570  READ DMA
  ec 00 00 00 00 00 00 0a  10d+10:11:56.549  IDENTIFY DEVICE
  ef 03 42 00 00 00 00 0a  10d+10:11:56.533  SET FEATURES [Set transfer mode]

Error 447 occurred at disk power-on lifetime: 6990 hours (291 days + 6 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 41 00 f7 04 2c e0  Error: ABRT at LBA = 0x002c04f7 = 2884855

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 f7 04 2c 00 0a  10d+10:11:52.574  READ DMA
  ec 00 00 00 00 00 00 0a  10d+10:11:52.553  IDENTIFY DEVICE
  ef 03 42 00 00 00 00 0a  10d+10:11:52.536  SET FEATURES [Set transfer mode]

Error 446 occurred at disk power-on lifetime: 6990 hours (291 days + 6 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 41 00 f7 04 2c e0  Error: ABRT at LBA = 0x002c04f7 = 2884855

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 f7 04 2c 00 0a  10d+10:11:48.729  READ DMA
  ec 00 00 00 00 00 00 0a  10d+10:11:48.697  IDENTIFY DEVICE
  ef 03 42 00 00 00 00 0a  10d+10:11:48.678  SET FEATURES [Set transfer mode]

Error 445 occurred at disk power-on lifetime: 6990 hours (291 days + 6 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 41 00 f7 04 2c e0  Error: ABRT at LBA = 0x002c04f7 = 2884855

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 f7 04 2c 00 0a  10d+10:11:44.720  READ DMA
  ec 00 00 00 00 00 00 0a  10d+10:11:44.699  IDENTIFY DEVICE
  ef 03 42 00 00 00 00 0a  10d+10:11:44.680  SET FEATURES [Set transfer mode]

Error 444 occurred at disk power-on lifetime: 6990 hours (291 days + 6 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 41 00 f7 04 2c e0  Error: ABRT at LBA = 0x002c04f7 = 2884855

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 f7 04 2c 00 0a  10d+10:11:40.704  READ DMA
  ec 00 00 00 00 00 00 0a  10d+10:11:40.684  IDENTIFY DEVICE
  ef 03 42 00 00 00 00 0a  10d+10:11:40.684  SET FEATURES [Set transfer mode]

SMART Self-test log structure revision number 1 No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1  SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Was könnte dies sein? Rein vorsorglich habe ich die HDD ausgetauscht. Mit "badblocks -s /dev/sda" gab es keine Fehler. Folglich habe ich die Platte sektorenweise kopiert.

Viele Grüße

Hahni
 

hahni

Active Member
Da man pro Beitrag nur 10000 Zeichen schreiben darf, folgt hier der Rest meines Posts:

Leider ließ sich der Server nicht mehr remote herunterfahren. Am Bildschirm stand dann z.B.:
Code:
[882310.151434] BUG: soft lockup - CPU#0 stuck for 11s!  [quotaoff:25023]

Beim Reboot samt Filesystem-Check sah die Sache dann so aus:
Code:
Pass 1: Checking inodes, blocks, and sitzes
Inodes that were part of a corrupted orphan linked list found. Fix<y>? yes

Inode 393266 was part of the orphaned inode list.  FIXED.
Inode 393271 was part of the orphaned inode list.  FIXED.
Inode 393275 was part of the orphaned inode list.  FIXED.
Inode 393306 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -1599520
Fix<y>? yes

Free blocks count wrong for group #48 (1944, counted=1945).
Fix<y>? yes

Free blocks count wrong (52089543, counted=52089544).
Fix<y>? yes

Inode bitmap differences:  -393259 -393266 -393271 -393275 -393306
Fix<y>? yes

Im "lost+found"-Ordner sind keine Dateien enthalten und es handelt sich um ein ext3-Filesystem. Für mich wäre nun interessant zu wissen, ob die Fehlermeldungen und Fixes bewirkt haben, dass Daten verloren gegangen sind oder ob durch die Journal-Funktion dies eher unwahrscheinlich ist?

Angemeldet gabs zuvor auch noch Fehler im Filesystem:
Code:
root@server:~# fsck /dev/sda1
fsck 1.40.8 (13-Mar-2008)
e2fsck 1.40.8 (13-Mar-2008)
/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes

Inode 393266 was part of the orphaned inode list.  FIXED.
Inode 393271 was part of the orphaned inode list.  FIXED.
Inode 393275 was part of the orphaned inode list.  FIXED.
Inode 393306 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
_

Mit "tune2fs" habe ich eingestellt, dass nach dem Reboot immer ein FS-Check gemacht werden soll. Sofern das Tool zuverlässig ist, gibt es nun keine Probleme mehr.

Viele Grüße

Hahni
 

neurex

Member
Wir hatten hier erst kürzlich einen ähnlichen Fall mit einem Server und IDE-Platten (wehe einer sagt jetzt was).

So wie ich das bis jetzt verstanden habe bedeuten diese orphaned Fehlermeldungen nur das Dateien im Journal gelinkt sind, welche aber schon nichtmehr vorhaden sind (weil sie z.b. gelöscht wurden) und deswegen ausgetragen wird (korrigiert mich wenn ich falsch liege) also nicht Besorgnis erregend.

Allerdings deuten die ganzen anderen Fehler meines erachtens nach auf einen Festplattendefekt hin. Wir hatten diese auch (vielleicht in anderer Form) und smartctl zeigte keinerlei Fehler. Was auch daran lag das die Platten selbst nicht kaputt waren sondern der ATA-Bus des Mainboards und (das hab ich selbst noch nicht erlebt) die HotSwapline des Servers. Normalerweiße vermutet man eher kaputte Kabel aber dort ging aus irgendeinem Grund beides kaputt...

Was stand den in der warn.log?
 

hahni

Active Member
Coole Sache, dass du dich diesbezüglich gemeldet hast. Eigentlich ging ich nicht mehr davon aus, überhaupt noch eine Antwort zu bekommen ;)!

Leider habe ich die warn.log nicht betrachtet und wenn ich mich recht entsinne, ist die nun auch nicht mehr vorhanden.

In meinem Fall war es wohl so, dass der Cache der Platte kaputt war. Diesen Fall hatte ich z.B. noch nie.

Ob nun Daten fehlen oder nicht, ist leider sehr schwer auszumachen bei den vielen 10000 Dateien. Die geöffneten Dateien waren auf jeden Fall beschädigt.

Das waren aber zumeist Logfiles für die Seitenzugriffe oder die Mail-Statistiken. Das aber kann ich verschmerzen.

Ich hatte die Platte mit badblocks geprüft und anschließend 1zu1 kopiert. Also würdest du dir nicht so große Sorgen machen wie ich, dass Daten nun fehlen?
 

neurex

Member
Kein Problem.

Allerdings ist folgendes in solch einem Fall immer zu empfehlen. Kopiere zuerst IMMER die komplette Platte per dd auf eine größere (also Block für Block). Wenn du nämlich Pech hast ist die Platte soweit das du sie nur noch einmal lesen kannst und wenn du davor badblocks oder ähnliches drüberlaufen lässt ist diese Chance schonmal weg...

Gut, wer ein Backup in Ehren hat ;)

Na ja... schwer zu sagen. Wenn der Cache kaputt ist sind zumindest die Dateien kaputt danach alle noch geschrieben wurden bzw. ist dies sehr wahrscheinlich weil die Intigritätsprüfung meistens nichtmehr weiter hilft.

Schwer abzuschätzen. Merkt man dann immer erst im laufenden Betrieb wieder wenn was nicht funktioniert...
 

hahni

Active Member
Ein Backup hatte ich. Allerdings ist der Fehler in den letzten 5 Tagen aufgetreten und ich habe immer nur ein Backup des Vortages.

Im laufenden Betrieb ist mir nichts mehr aufgefallen, was fehlen könnte. Ich hoffe, dass ich mit einem Schock und ohne Datenprobleme davon gekommen bin.

In Zukunft werde ich auch zuerst kopieren und dann prüfen, ob ein HDD-Fehler vorliegt. Bisher mache ich immer ein tar.gz-File aller wichtigen Daten.

Allerdings behagt mir das nicht so ganz: der Aufwand ist im Schadensfall für die Wiederherstellung zu lang. Gibt es die Möglichkeit, eine 1zu1-Kopie im laufenden Betrieb durchzuführen und auf einem Backup-Space zu speichern?

Im Endeffekt so etwas wie ein Acronis-Backup in Echtzeit, welches man auf eine neue Platte ebenso leicht zurücksichern kann ohne viel Mühe zu haben?
 

neurex

Member
Also ich weiß nicht so recht ob es ratsam ist im Schadensfall im laufenden Betrieb ein Backup zu ziehen.

Ich würde das wirklich abgekapselt machen und dann eben mit dd eine 1:1 Kopie...
 

nowayback

Well-Known Member
Das günstigste dürfte wohl ein Raid 1 sein, in Verbindung mit regelmäßigen Backups. Dann haste schon mal nen Großteil deiner Daten gerettet und das 1:1 kopieren wurde bereits im Betrieb erledigt ;) Du musst dann nur noch die defekte Platte austauschen und fertig.

Die regelmäßigen Backups dienen vor allem um gelöschte oder geänderte Dateien wiederherstellen zu können - haben also nichts direkt mit nem Plattenfehler zutun. Das diese Backups irgendwo extern gelagert werden sollten, denke ich, ist logisch.

Das sollte für die meisten Situationen als Sicherungsmaßnahmen ausreichen.


Grüße
nwb
 

hahni

Active Member
RAID1 habe ich mir für die wichtigsten Server auch schon vorgestellt. Das oft eingesetzte SW-Raid mag ich nicht. Wenn dann eine physikalische Lösung. Aber eine andere Mögichkeit, bei Geräten ohne RAID1 im Echtbetrieb eine 1zu1-Kopie zu machen, kennst du nicht?
 

neurex

Member
Vielleicht mit einem rsync, der müsste eigentlich alles sichern können bis auf Geräte(dateien), etc.

Müsste man mal ausprobieren, die werden ja beim starten eh neu erstellt...
 

hahni

Active Member
Du meinst das "/proc"-Verzeichnis? Das stimmt. Das sichere ich bisher bei meinen "tar.gz"-Files auch nicht mit. Doch wie könnte eine solche rsync-Lösung aussehen? Ein Image und dieses einfach auf eine neue Platte zurück zu spielen wäre mir am Liebsten. Also so einfach wie möglich...
 

hahni

Active Member
Ich bin zwar eher für eine tägliche Vollsicherung, aber die Sache geht schon mal in die richtige Richtung. Allerdings ist das Rückspielen meiner Meinung nach immer noch zu aufwändig, weil die neue Platte auch wieder im Vorfeld partitioniert und formatiert sein muss... Mein Idealziel wäre also immer noch das Fullbackup in einem Image, dass man einfach zurückspielen kann...
 

Werbung

Top