Festplatten sterben selten derart spontan, wie es den meisten Anwendern erscheint. Wer geeignete Tools einsetzt, bemerkt das Siechtum rechtzeitig und kann darum Ersatz beschaffen.

Festplatten besitzten prinzipbedingt mechanisch bewegliche Teile: Die Scheiben rotieren mit 5400 oder 7200 oder noch mehr Umdrehungen pro Minute und die Mechanik der Köpfe ist starken Beschleunigungen und Verögerungen ausgesetzt. Das ganze macht eine Festplatte zum Verschleißteil. Die Hersteller geben eine mittlere Lebensdauer für ihre Produkte an – einen rein statistischen Wert, der nicht ausschließen kann, dass ein Gerät schon nach einem Monat Betrieb sein Leben aushaucht. Nach Morphys Gesetz passiert sowas natürlich immer zur Unzeit, also wenn das Backup gerade veraltet ist oder am Wochenende, wenn kein Computerladen offen hat.

Glück hat noch, wer beim Booten seines Rechners eines Tages eine Fehlermeldung folgender Art sieht:

SMART Failure Predicted on Primary Master: Maxtor 34098H4
Warning! Immediately back-up your data and replace your hard disk drive. A Failure may be imminent.

Die Meldung besagt, dass ein Versagen Ihrer Systemplatte droht. Sie werden aufgefordert, Ihre Daten sofort zu sichern und die Festplatte auszutauschen. Hier meldet das Rechner-BIOS, dass das Fehler-Erkennungssystem SMART der Platte zugeschlagen hat.

SMART an Bord

SMART ist die Self-Monitoring, Analysis and Reporting Technology, über die moderne ATA- und SCSI-Festplatten sowie SCSI-Bandlaufwerke verfügen. Neben der laufenden Protokollierung von Messwerten und Fehlern sind auch Funktionen zum Selbsttest der Geräte eingebaut. Gut wäre natürlich, von dem bevorstehenden unangenhmen Ereignis früher zu erfahren. Dafür sorgt das Softwarepaket Smartmontools. [1] Es dient dazu die SMART-Funktionen Ihrer Geräte aufzurufen und zu steuern – dank des zugehörige Daemon-Prozesses smartd auch automatisch.

Die Programme sind unter den aktuellen Versionen der Betriebssysteme Linux, FreeBSD, NetBSD, Solaris, Darwin und auch unter Microsoft Windows lauffähig. Die Linux-Version gibt es als Binary-RPM und als Source von [1]. An gleicher Stelle sind die Installationsarbeiten beschrieben. Smartmontools unterstützt die ATA/ATAPI-Standards ab Version 3 bis aktuell 7. Vorläufer war das Softwarepaket Smartsuite, dessen Entwicklung nach Version 2.1 im September 2001 verebbte.

Listing 1 zeigt, wie Sie mit smartctl Basisinformationen zum Gerät interaktiv abfragen. Die defekte Festplatte im obigen Beispiel ist als Primary-Master am IDE-Bus angeschlossen, darum wird sie über /dev/hda angesprochen. Grundsätzlich sind alle Kommandos unter Kennung root abzusetzen, weil der Zugriff auf die Gerätedateien für weniger priviligierte Kennungen nicht gestattet ist.

# smartctl -i /dev/hda
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
=== START OF INFORMATION SECTION ===
Device Model:     Maxtor 34098H4
Serial Number:    L4101EJC
Firmware Version: YAH814Y0
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   6
ATA Standard is:  ATA/ATAPI-6 T13 1410D revision 0
Local Time is:    Tue Aug 10 12:17:11 2004 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Sie erfahren, dass es sich um eine Festplatte vom Typ 34097H4 des Herstellers Maxtor mit der Seriennummer L4101EJC handelt, dass eine Version YAH814Y0 der Herstellersoftware an Bord ist und dass das Gerät dem ATA/ATAPI-Standard Version 6 entspricht. Für einen Umtausch innerhalb der gesetzlichen Gewährleitungszeit kann insbesondere die Kenntnis dieser Seriennummer wichtig sein.

Der SMART-Support ist bereits aktiviert, wie die letzte Zeile des Berichts mitteilt. Dies geht hier auf eine entsprechende Einstellung im BIOS des Rechners zurück. Erscheint bei Ihnen dort die Angabe Disabled, so rufen Sie zur Aktivierung smartctl mit der Option -s on auf.

Wie geht es uns denn heute?

Die Option -H bei Aufruf von smartctl fragt den so genannten Health-Status, also der Gesundheitszustand des Geräts ab. In Listing 2 lautet das Resultat FAILED, was auch der Grund für die Warnung beim Booten ist. Hier hat die Festplatten-interne SAMRT-Logik bereits 637 Mal einen defekten Sektor auf den Magnetscheiben ersetzt. Dabei bedient sich die Automatik einer “eisernen” Reserve ungenutzter Sektoren. Diese sind nun leider aufgebraucht. Wäre dagegen alles in Ordnung, dann lautete das Ergebnis PASSED.

# smartctl -H /dev/hda
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   001   001   063    Pre-fail  Always   FAILING_NOW 637

Der ATA-Standard definiert eine ganze Reihe von Attributen, die technische Eigenschaften des Geräts beschreiben [4]. Es bleibt den Herstellern überlassen, darüber hinaus eigene Attribute zu verwalten. Auch bei den Formaten zur Speicherung der Daten gibt es Unterschiede, insbesondere beim Attribut #9, das die Betriebszeit des Geräts angibt. Darum beinhalten die smartmontools eine Datenbank, in der die Belegung der Attribute bei den verschiedenen Modellen dokumentiert ist. Sollte Ihr Modell der letzten Version der Smartmontools nicht bekannt sein, so wenden Sie sich zur Behebung dieses Missstandes mit entsprechenden Informationen an die Mailingliste Smartmontools-database [2]. Das genaue Prozedere beschreibt die Smartmontools-Homepage.

Mit Option -A zeigt smartctl die Werte aller Attribute (siehe Listing 3). Kritische Zustände sind anhand des Vergleichs mit vom Hersteller vorgegebenen Schwellen zu erkennen. Die Spalte VALUE enthält den aktuellen Wert, die Spalte WORST den bislang schlechtesten aufgetretenen Wert und THRESH die vom Hersteller angegebene Schwelle. Fällt der aktuelle Wert auf den Wert der Schwelle oder darunter, so gilt das entsprechende Attribut als schadhaft. Im Beispiel oben (Listing 2) ist die Schwelle für das Attribut Reallocated_Sector_Ct mit 63 angegeben. Mit Angabe 1 liegt der aktuelle Wert schon sehr weit darunter und führt zur Ausweisung des Fehlerfalles FAILING_NOW in der Spalte WHEN_FAILED.

# smartctl -A /dev/hda
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
=== START OF READ SMART DATA SECTION ===
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     0x000a   253   252   000    Old_age   Always       -       41
  3 Spin_Up_Time            0x0027   222   222   063    Pre-fail  Always       -       4458
  4 Start_Stop_Count        0x0032   253   253   000    Old_age   Always       -       35
  5 Reallocated_Sector_Ct   0x0033   001   001   063    Pre-fail  Always   FAILING_NOW 637
  6 Read_Channel_Margin     0x0001   253   253   100    Pre-fail  Offline      -       0
  7 Seek_Error_Rate         0x000a   253   252   000    Old_age   Always       -       0
  8 Seek_Time_Performance   0x0027   252   246   187    Pre-fail  Always       -       38203
  9 Power_On_Minutes        0x0032   253   253   000    Old_age   Always       -       16h+46m
  […]

Wichtig zur Beurteilung ist auch der Typ des Attributs, den die Spalte TYPE in Listing 3 angibt. Old_age-Attribute charakterisieren normale Alterungsprozesse der Festplatte. Kritisch sind Fehler bei den mit Pre-fail bezeichneten Attributen, da hier tatsächlich ein Versagen innerhalb der nächsten Stunden droht! In diesem Fall empfiehlt sich der sofortige Austausch des Geräts.

Online- und Offline-Tests

Sobald bei einem Gerät SMART aktiviert ist, schreibt es Messdaten über seine Funktionsfähigkeit ohne Einbußen der System-Performance im laufenden Betrieb mit. Das gilt für alle Attribute, die in der Spalte UPDATED im Listing 3 mit Always bezeichnet sind. Die Manpages der Smartmontools bezeichnen dieses Verfahren als Online-Test.

Welche SMART-Methoden Ihr Gerät beherrscht und wieviel Zeit die verschiedenen Tests benötigeb, fördert der Aufruf von smartctl mit der Option -c zutage (siehe Abb. 1).Auf gleiche Weise können Sie auch den Fortschritt des Tests im Abschnitt Self-test execution status verfolgen.

Abbildung 1: Report über die SMART-Fähigkeiten des Geräts.

Beim so genannten Offline-Test sind Einbußen bei der Performance möglich. In der Praxis werden Sie diese jedoch kaum spüren, denn solange das Betriebssystem auf das Gerät regulär zugreift, werden die Aktivitäten des Offline-Tests unterbrochen. Der Offline-Test startet mit smartctl -t offline /dev/Gerä.

Ein periodisches Ausführen – üblicherweise alle vier Stunden – beauftragt man mit der Option -o on, sofern der Hersteller die entsprechende Funktion eingebaut hat. Letzteres ersehen Sie aus der Abfrage der SMART-Fähigkeiten Ihres Geräts ersehen (siehe Abb. 1). Im Abschnitt Offline data collection capabilities finden Sie dann die Aussage Auto Offline data collection on/off support. Ein Offline-Tests, unabhängig davon, ob er ausdrücklich oder automatisiert durchgeführt wurde, aktualisiert all jene Attribute, die in der Spalte UPDATED (Listing 3) mit Offline bezeichnet sind.

Während Online- und Offline-Test nur Daten sammeln, lässt der Selftest tatsächlich Tests ablaufen. Sie erheben die elektrischen und mechanischen Eigenschaften des Geräts sowie den Durchsatz beim Lesen. Selftests sind gleichfalls im laufenden Betrieb gestattet, da sie aussetzen, sobald das Betriebssystem regulär auf das Gerät zugreifen will. Gegenteiliges bewirkt die Option -C: Dann so steht das Gerät nicht mehr zur Verfügung. Diesen so genannten Captive-Mode sollten Sie darum nur auf Medien anwenden, die gerade nicht im Dateibaum hängen.

Ein kurzer Selbsttest, er mit der Option -t short, dauert nur wenige Minuten. Ein eingehender Selbsttest dagegen nimmt je nach Größe der Festplatte eine Stunde oder länger in Anspruch. Um ihn zu starten, geben Sie smartctl die Option -t long auf den Weg.

Das Ergebnis des Tests hält das Gerät in seinem Self-Test-Log fest. smartctl bringt es für Sie mit der Option -l selftest zur Anzeige (siehe Listing 4). Angaben zu jüngst durchgeführten Tests stehen am Anfang der Liste. Der Test bricht automatisch ab, wenn er auf einen Fehler stößt. Die Spalte Remaining zeigt dann, wieviel Prozent des Tests noch nicht erledigt sind. Findet der Test Fehler auf der Festplatte, dann steht die logische Adresse des ersten fehlerhaften Blocks in Spalte LBA. Der Abbruch des Tests in Zeile # 2 von Listing 4 hatte die Autorin mit smartctl -X /dev/hdb selbst proviziert.

# smartctl -l selftest /dev/hdb
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%       453         -
# 2  Extended offline    Aborted by host               90%       451         -
# 3  Short offline       Completed without error       00%       451         -

Neben dem Self-Test-Log gibt es auch ein Error-Log, das Informationen zu den letzten fünf aufgetretenen Fehlern enthält. smartctl bringt es bei Angabe der Option -l error zur Anzeige.

Automatisierte Überwachung mit smartd

Mit dem vorgestellten smartctl-Aufrufen müssen die Befunde ausdrücklich abgefragt werden, was für die dauernde Überwachung untauglich ist. Hier kommt nun smartd ins Spiel. Es handelt sich um einen Hintergrundprozess (Daemon) der, nach den Vorgaben des Benutzers, SMART-Attribute automatisiert abfragt und Selbsttests startet. smartd protokolliert seine Statusmeldungen und Fehlermeldungen im Syslog, was beispielsweise auf Wunsch im Fehlerfall ein Informieren per E-Mail möglich macht.

Es ist sinnvoll, dass Sie das Starten und Stoppen von smartd in den Boot- und Shutdown-Prozess Ihres Rechners einbinden. Dazu bringen die Smartmontools neben den ausführbaren Programmen /usr/sbin/smartctl und /usr/sbin/smartd auch ein Shellskript namens smartd mit, das in der Regel unter /etc/rc.d/init.d liegt. Ein chkconfig --add smartd setzt entsprechende Links bei den verschiedenen Runleveln. Achtung: Unter Suse Linux müssen Sie das Shellskript smartd dazu gegebenenfalls vorab vom Verzeichnis /etc/rc.d/init.d nach /etc/init.d verschieben!

Um smartd mit speziellen Optionen zu starten, setzen Sie die Variable smartd_opts im Shellskript Ihren Wünschen entsprechend. Zum Beispiel legt die Option --interval N fest, alle wieviel Sekunden smartd aktiv wird. Voreingestellt ist ein Intervall von 1800 Sekunden, was 30 Minuten entspricht. Schauen Sie mit smartd --help, welche Optionen beim Aufruf spezifiziert werden. Eingehendere Erläuterungen dazu erhalten Sie mit man smartd.

Die weitere Konfiguration von smartd erfolgt über Einträge in der Datei /etc/smartd.conf. Sollte sie nicht vorhanden sein oder in ihr die Anweisung DEVICESCAN aktiv sein, so versucht smartd beim Start auf alle möglichen ATA- und SCSI-Devices in Ihrem System zuzugreifen, das heißt von /dev/hda bis /dev/hdt und /dev/sda bis /dev/sdz. Für alle gefundenen Geräte wird SMART aktiviert und die Überwachung gestartet.

Feinabstimmung mit smartd.conf

Nach welchen Methoden die Überwachung läuft, bestimmen Sie durch entsprechende Anweisungen nach dem Schlüsselwort DEVICESCAN für alle Geräte. Wenn Sie keine speziellen Anweisungen erteilen, so werden die für den Gerätetyp (ata, scsi, 3ware..-) vorgesehenen Standards angewandt, über die man smartd.conf Auskünfte geben kann.

Häufig wechselnde Attribute, wie die Temperatur (Attribute #194 und #231) oder die Betriebszeit (Attribute #9), sollten Sie bei der Überwachung ausschließen, um die Meldungen im Syslog überschaubar zu halten. Das erreicht die Anweisung -I 194 -I 231 -I 9 in der Datei smartd.conf. Wenn Sie im Fehlerfall per E-Mail unterrichtet werden wollen wie in Abb. 2, dann geben Sie dort die Anweisung -m gefolgt von Ihrer E-Mail-Adresse an.

Abbildung 2: Benachrichtigung per E-Mail über einen fehlgeschlagenen Health-Check.

Wenn Sie Regeln für die Überwachung der einzelnen Geräte unterschiedlich definieren wollen, kommentieren Sie die Anweisung DEVICESCAN aus. Geben Sie stattdessen Anweisungen bezogen auf das jeweilige Gerät an. Ein Beispiel aus der beim Paket mitgelieferten Vorlage veranschaulicht das:

/dev/hda -a -o on -S on -s (S/../.././02|L/../../6/03)

Die Anweisung bezieht sich auf die Primary Master Disk am IDE-Bus und bedeutet: Überwache alle Attribute (-a), aktualisiere auch die Offline-Attribute in regelmäßigen Abständen (-o on), speichere geänderte Attributwerte automatisch und dauerhaft auf dem Gerät (-S on) und fordere einen kurzen Selbsttest der Festplatte täglich um 2:00 Uhr morgens und einen eingehenden Selbsttest an jedem Samstag um 3:00 Uhr morgens an.

Die Definition der Zeiten für den Selbsttest erfolgt über die Option -s gefolgt von einem regulären Ausdruck der folgendem Format entsprechen muss:

T/MM/DD/d/HH

T steht dabei für den Typ des Selbsttests, im Beispiel S für den Short-Selftest und L für den Long-Selftest. MM ist der Monat des Jahres, von 01 für Januar bis 12 für Dezember. Als Platzhalter für beliebige Werte können Sie Punkte einsetzen. An dieser Stelle gilt der Ausdruck dann für jeden Monat, wie im Beispiel oben. Das folgende Feld DD steht für den Tag des Monats von 01 bis 31.

Möchten Sie einzelne Wochentage ansprechen, dann nutzen Sie das Feld d von 1 für montags bis 7 für sonntags. Das letzte Feld steht für die Stunde des Tages, angefangen mit 00 für die Stunde von Mitternacht bis 1:00 Uhr früh bis zu 23 für die letzte Stunde vor Mitternacht. Eingehende Erläuterung zu den vielfältigen Konfigurationsmöglichkeiten der automatisierten Überwachung mit smartd erhalten Sie mit man smartd.conf.

Ausfälle werden unwahrscheinlich

Durch den Einsatz von smartd sind Systemausfälle zwar nicht auszuschließen, weil ein Schaden auch mal ohne Vorwarnung eintreten kann. Aber selbst dann kann die Überwachung Ihrer Laufwerke noch von großem Nutzen sein, denn nicht jeder Schaden hat gleich erkennbare Auswirkungen. Im schlimmeren Fall würden Sie es bis zum nächsten regulären Festplattencheck gar nicht merken und die Verluste wären umso größer. Es spricht also alles dafür, die Smartmontools einzusetzen.