Linux: Bad Blocks
Folgende S.M.A.R.T. Attribute sind die wichtigsten Indikatoren für fehlerhafte Sektoren:
Reallocated Sectors Count: Count of reallocated sectors. When the hard drive finds a read/write/verification error, it marks that sector as “reallocated” and transfers data to a special reserved area (spare area). This process is also known as remapping, and reallocated sectors are called “remaps”. The raw value normally represents a count of the bad sectors that have been found and remapped.
Current Pending Sector Count: Count of “unstable” sectors (waiting to be remapped, because of unrecoverable read errors). If an unstable sector is subsequently read successfully, the sector is remapped and this value is decreased. Read errors on a sector will not remap the sector immediately (since the correct value cannot be read and so the value to remap is not known, and also it might become readable later); instead, the drive firmware remembers that the sector needs to be remapped, and will remap it the next time it’s written.
Fehlerhafte Sektoren können nicht mehr gelesen werden, die Daten darin sind also verloren und müssen aus einem Backup wiederhergestellt werden.
BTRFS: Fehlerhafte Dateien identifizieren
Mit BTRFS kann die Datenintegrität überprüft werden, sogenanntes Scrubbing. Bei BTRFS überprüft das Scrubbing nur die Bereiche der Festplatte, auf der sich auch Daten befinden. Um einen “Scrub” zu starten, muss folgender Befehl als root auf einem gemounteten Subvolume ausgeführt werden:
# btrfs scrub start /dev/sda1
Der Status des Scrub kann folgendermaßen abgefragt werden:
# btrfs scrub status /dev/sda1
Hier eine Beispielausgabe eines fehlerhaften Dateisystems:
# btrfs scrub status /dev/sdc1
scrub status for 7e81436a-2de0-47cc-958a-7d03a1429f24
scrub started at Thu Oct 27 00:23:22 2016 and was aborted after 08:14:00
total bytes scrubbed: 2.92TiB with 9117 errors
error details: read=982 csum=8135
corrected errors: 0, uncorrectable errors: 9117, unverified errors: 0
Außerdem gibt es noch scrub cancel
zum Unterbrechen und scrub resume
zum Wiederaufnehmen eines Scrub.
In der dmesg Ausgabe finden sich dann Hinweise auf die fehlerhaften Dateien:
# dmesg | grep BTRFS | grep error
...
[15836.136406] BTRFS warning (device sdc1): checksum error at logical 1901610708992 on dev /dev/sdc1, sector 3719342680, root 5391, inode 12360, offset 189681664, length 4096, links 1 (path: photo/abc.jpg)
...
[15996.746912] BTRFS warning (device sdc1): i/o error at logical 1901610266624 on dev /dev/sdc1, sector 3719341816, root 5391, inode 12360, offset 189239296, length 4096, links 1 (path: photo/dfg.jpg)
...
Alternativ (ungetestet):
dmesg | grep BTRFS | grep path | sed -e 's/^.*path: //;s/)$//' | sort | uniq
BTRFS Datenrettung
RAID
Betreibt man BTRFS im raid1 Modus, können die fehlerhaften Dateien automatisch von der intakten Festplatte des Arrays repariert werden, siehe: https://blogs.oracle.com/wim/entry/btrfs_scrub_go_fix_corruptions
Ohne RAID
Hat man kein raid1 und will die Festplatte weiterhin nutzen (da nur ein oder zwei fehlerhafte Sektoren vorhanden sind), muss man die entsprechenden Sektoren mit dd
überschreiben und die fehlerhaften Dateien löschen und vom Backup zurücksichern.
Alternativ kann man natürlich auch die Daten auf eine neue Festplatte kopieren und die fehlerhaften Daten vom Backup zurücksichern oder das Backup als neues Live-Medium nutzen.