ubuntuusers.de

Hallo community.

Ich möchte gerne die Dateien auf meinen Backupfestplatten hin und wieder scriptgesteuert (cron) auf ihre Lesbarkeit/Kopierbarkeit, überprüfen und eine Nachricht bekommen, wenn die Datei nicht (komplett) lesbar sein sollte. Dies sollte möglichst schnell von statten gehen.

Dafür gäbe es mehrere Ansätze:

• badblocks - dauert mir zu lange und überprüft auch Blocks, auf denen gerade keine Dateien liegen.

• smartctl - liefert keine 100%ige Sicherheit für die Lesbarkeit best. Dateien, nur eine mehr oder minder hohe Wahrscheinlichkeit für den Ausfall der HD.

Mein Ansatz wäre ein script auf der Basis von <cp>:

• rekursives Durchforsten des Quelldirectory

• kopieren jeder einzelnen Datei von der Quelle nach irgendeinem Ziel

• Falls nicht kopierbar, Ausgabe einer Fehlermeldung (aber nicht Abbruch ! sonder weiter mit der nächsten Datei)

• löschen der Zieldatei

• nächste Quelldatei

Hat jemand eine Idee, wie man das per script realisieren könnte? Oder gibt es bereits ein bash tool für sowas?

jauno schrieb:

Hallo community.

Ich möchte gerne die Dateien auf meinen Backupfestplatten hin und wieder scriptgesteuert (cron) auf ihre Lesbarkeit/Kopierbarkeit, überprüfen und eine Nachricht bekommen, wenn die Datei nicht (komplett) lesbar sein sollte.

Dafür hat man Prüfsummen entwickelt. Ist die einfachste Möglichkeit das umzusetzen.

Dies sollte möglichst schnell von statten gehen.

Aktuelle Verfahren verbrauchen linear zur Datenmenge entsprechend viel Zeit, d.h. je mehr Daten desto länger dauert die Überprüfung. Daran dürfte auch kein Weg vorbeiführen.

Oder gibt es bereits ein bash tool für sowas?

Neuere Dateisysteme (ZFS, btrfs) lösen das Problem auf Dateisystemebene. Mittels Scrubbing hat man hier die Möglichkeit, die Daten auf Konsistenz zu prüfen.

Dafür hat man Prüfsummen entwickelt. Ist die einfachste Möglichkeit das umzusetzen.

Das ist mir bekannt. Aber die Prüfsummen verändern sich ja nicht, wenn die Quelldatei nicht mehr lesbar ist aufgrund von physikalischen Defekten.

jauno schrieb:

Das ist mir bekannt. Aber die Prüfsummen verändern sich ja nicht, wenn die Quelldatei nicht mehr lesbar ist aufgrund von physikalischen Defekten.

Möglicherweise reden wir gerade aneinander vorbei, denn die Prüfsumme einer Datei ändert sich sehr wohl, wenn diese nicht mehr lesbar ist (sofern dann überhaupt noch eine Prüfsumme generiert werden kann).

Das erstellen der Prüfsumme aus einer Datei erfordert einen Lesezugriff, d.h.:

• lesen klappt, generierte Prüfsumme stimmt mit der vorher gespeicherten Prüfsumme überein → alles ok

• lesen klappt, Prüfsumme stimmt nicht mit der vorher gespeicherten Prüfsumme überein → Data rot, nicht ok

• lesen klappt nicht, erstellen der Prüfsumme bricht ab/schlägt fehl → vermutlich Hardwarefehler bzw. Festplattendefekt

Das erstellen der Prüfsumme aus einer Datei erfordert einen Lesezugriff, d.h.:

...

• lesen klappt nicht, erstellen der Prüfsumme bricht ab/schlägt fehl → vermutlich Hardwarefehler bzw. Festplattendefekt

OK. Neu für mich. Das heißt ich muß überprüfen, ob das Erstellen der Prüfsumme einer Datei beim Lesezugriff fehl schlägt. Dann wäre es ein physikalischer Fehler. Wie sähe das in der Linuxpraxis aus (sh command)? Und das wäre dann schneller als ein komplettes cp von a nach b?

jauno schrieb:

Wie sähe das in der Linuxpraxis aus (sh command)?

Der exitcode ($?) waere ungleich 0 (was fuer Erfolg steht). Siehe Shell/Bash-Skripting-Guide für Anfänger (Abschnitt „Umgebungsvariablen“)

Und das wäre dann schneller als ein komplettes cp von a nach b?

Es faellt der Schreibvorgang weg, allerdings muss die CPU die Hashsumme errechnen. Was davon schneller ist, kann ich ohne Tests auch nicht sagen.

Wenn keine Pruefsumme bildest, kannst du aber Bitflips und dergleichen aber nicht ausschliessen.

Ein flaches Verzeichnis kannst Du so prüfen und die Ergebnisse in einer Datei (md5sums) festhalten:

1

for f in *; do md5sum "$f"; done > md5sums

Testen tust Du es dann mit

1

md5sum -c md5sums

Mehr Hilfe zeigt

1
2

md5sum --help
man md5sum

Dafür kannst du rsync nehmen, entweder mit --dry-run testen oder nach /dev/null kopieren. Das checkt Prüfsummen nach dem Kopieren, kann es mit -c o.ä. aber auch sofort. Aber eigentlich bringt das zusammen mit null nix, sondern nur der reine Leseversuch mit null.

jauno schrieb:

Das erstellen der Prüfsumme aus einer Datei erfordert einen Lesezugriff, d.h.:

...

• lesen klappt nicht, erstellen der Prüfsumme bricht ab/schlägt fehl → vermutlich Hardwarefehler bzw. Festplattendefekt

OK. Neu für mich. Das heißt ich muß überprüfen, ob das Erstellen der Prüfsumme einer Datei beim Lesezugriff fehl schlägt.

Nach dem Kopieren auf das Sicherungsmedium erstellst Du eine Prüfsumme für jede Datei, z.B. mit sha256sum. Später dann kannst Du alle Prüfsummen mit sha256sum -c pruefsummendatei überprüfen. Dabei gibt es die Lesezugriffe.

Ein etwas intelligenterer Ansatz erstellt Prüfsummen für jede Datei einzeln, so dass man Prüfsummen selektiv neu generieren kann. Z.B.

1
2
3
4
5
6

find /backup -type f ! -name '*.sha256' -exec sh -c '
for f; do
  sum="$f.sha256"
  test "$f" -ot "$sum" || sha256sum "$f" >| "$sum"
done
' -- {} +

Prüfen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

find /backup -type f -name '*.sha256' -exec sh -c '
set -e

for sum; do
  f="${sum%.sha256}"

  if [ -e "$f" ]; then
    sha256sum -c "$sum"
  else
    rm "$sum"
  fi
done
' -- {} +

Dann wäre es ein physikalischer Fehler. Wie sähe das in der Linuxpraxis aus (sh command)?

s.o.

Und das wäre dann schneller als ein komplettes cp von a nach b?

Du musst nicht kopieren, wenn Du die Lesbarkeit prüfen willst. Da reicht auch ein cat oder dd mit Ausgabe nach /dev/null.

sebix schrieb:

jauno schrieb:

Und das wäre dann schneller als ein komplettes cp von a nach b?

Es faellt der Schreibvorgang weg, allerdings muss die CPU die Hashsumme errechnen. Was davon schneller ist, kann ich ohne Tests auch nicht sagen.

Ganz allgemein gesprochen können Hashsummen schneller erzeugt werden als Daten auf normale Massenspeicher geschrieben werden können. Zumal Daten schreiben je nach verwendetem Dateisystem wenig bis viel zusätzliche CPU-Last erzeugen kann. Den Schreibvorgang wegfallen zu lassen macht also schon Sinn.

Wenn keine Pruefsumme bildest, kannst du aber Bitflips und dergleichen aber nicht ausschliessen.

Es sei denn, die unterliegende Hardware (und evtl. das Dateisystem…) schützen dagegen. Das dürfte allerdings bei den wenigsten Setups der Fall sein…

rklm schrieb:

Nach dem Kopieren auf das Sicherungsmedium erstellst Du eine Prüfsumme für jede Datei, z.B. mit sha256sum.

Notiz am Rande: Da es hier lediglich um die Integrität von Daten und weniger um die kryptographische Sicherheit geht wäre ein schnelleres Hashverfahren (CRC-32, SHA1, MD5) zu bevorzugen.

Und – by the way – schönes Skript. Ich bin immer wieder fasziniert wie einfach man sowas zusammenklopfen kann, wenn man etwas Ahnung der Bash und den mitgelieferten Werkzeugen hat.

Developer92 schrieb:

Ganz allgemein gesprochen können Hashsummen schneller erzeugt werden als Daten auf normale Massenspeicher geschrieben werden können. Zumal Daten schreiben je nach verwendetem Dateisystem wenig bis viel zusätzliche CPU-Last erzeugen kann. Den Schreibvorgang wegfallen zu lassen macht also schon Sinn.

Ja, aber in erster Linie wegen des Overhead durch IO - nicht wegen der CPU.

rklm schrieb:

Nach dem Kopieren auf das Sicherungsmedium erstellst Du eine Prüfsumme für jede Datei, z.B. mit sha256sum.

Notiz am Rande: Da es hier lediglich um die Integrität von Daten und weniger um die kryptographische Sicherheit geht wäre ein schnelleres Hashverfahren (CRC-32, SHA1, MD5) zu bevorzugen.

Im Prinzip hast Du Recht, aber das Problem hier dürfte eher IO-gebunden sein. Mit anderen Worten, der Overhead für die Hash-Berechnung ist vermutlich gegenüber dem Aufwand für das Lesen von vielen Dateien extrem vernachlässigbar - zumindest auf einigermaßen moderner Hardware. Wie immer: messen hilft. (Wobei man hier vorsichtig sein muss, dass einem der Plattencache vom Betriebssystem und ggf. auf der Platte nicht in den Weg gerät.)

Und – by the way – schönes Skript. Ich bin immer wieder fasziniert wie einfach man sowas zusammenklopfen kann, wenn man etwas Ahnung der Bash und den mitgelieferten Werkzeugen hat.

☺

Besonders schön finde ich übrigens

1

test "$f" -ot "$sum" || ...

weil test sowohl "falsch" liefert, wenn die Datei "$f" neuer ist als "$sum", als auch, wenn "$sum" gar nicht existiert! Damit hat man sehr elegant alle Fälle erschlagen, in denen ein Schreiben von "$sum" nötig ist.

Ich würde für solche Dinge auch "einfach" das passende Dateisystem nehmen, btrfs kann mit dem aktuellen Kernel sogar Duplication auch für Daten. Das bedeutet das auf den gleichen Datenträger die Daten zwei mal geschrieben werden, im Falle eines fehlerhaften Sektors wird dann einfach der noch funktionierende Sektor genommen.

Mit Scrub, wie schon erwähnt, kannst du dann automatisiert das Dateisystem inkl. Inhalt auf Konsitenz prüfen lassen.

mfg Stefan Betz

encbladexp schrieb:

Ich würde für solche Dinge auch "einfach" das passende Dateisystem nehmen, btrfs kann mit dem aktuellen Kernel sogar Duplication auch für Daten. Das bedeutet das auf den gleichen Datenträger die Daten zwei mal geschrieben werden, im Falle eines fehlerhaften Sektors wird dann einfach der noch funktionierende Sektor genommen.

Aber es ist immer noch auf dem selben Gerät - man reduziert das Risiko nur ein wenig. Da wäre es deutlich sicherer und auch schneller das Dateisystem auf einen anderen Datenträger zu spiegeln.

Ja, RAID1/5/6, zusätzlich noch ne regelmäßig rotierte Offline Version der Daten.

mfg stefan Betz