chkdsk - Feind meiner Daten
Das Programm Checkdisk (chkdsk) ist dazu da Fehler im Dateisystem zu bereinigen und dies geschieht in der Regel durch das "Herausschneiden" von beschädigten Teilen.
Das sorgt für Datenverlust denn, die losen Enden die einfach abgeschnitten werden, enthalten meist noch benötigte Daten. Im besten Fall kann man danach einfach mit einem Programm zur Datenrettung diese verlorenen Daten wieder zusammensuchen und retten.
Es macht aber wenig Sinn zuerst die Daten löschen zu lassen und danach diese wieder aufwendig rekonstruieren zu lassen. Oft gehen hierbei auch Ordner- und Dateinamen verloren und Checkdisk sorgt für ein ziemliches Durcheinander in den Daten weil "beschädigte" Dateien zum Teil verschoben und umbenannt werden!
1b15e000: 4649 4c45 3000 0300 216a 2000 0000 0000 FILE0...!j .....
1b15e010: 0100 0100 3800 0100 8001 0000 0004 0000 ....8...........
1b15e020: 0000 0000 0000 0000 0400 0000 2400 0000 ............$...
1b15e030: 0300 0000 0000 0000 1000 0000 6000 0000 ............`...
1b15e040: 0000 0000 0000 0000 4800 0000 1800 0000 ........H.......
1b15e050: d89c e34e 150e d801 875d e852 150e d801 ...N.....].R....
1b15e060: 875d e852 150e d801 2b59 ea52 150e d801 .].R....+Y.R....
1b15e070: 2000 0000 0000 0000 0000 0000 0000 0000 ...............
1b15e080: 0000 0000 0501 0000 0000 0000 0000 0000 ................
1b15e090: 0000 0000 0000 0000 3000 0000 7000 0000 ........0...p...
1b15e0a0: 0000 0000 0000 0200 5400 0000 1800 0100 ........T.......
1b15e0b0: 0500 0000 0000 0500 d89c e34e 150e d801 ...........N....
1b15e0c0: d89c e34e 150e d801 d89c e34e 150e d801 ...N.......N....
1b15e0d0: d89c e34e 150e d801 0030 0000 0000 0000 ...N.....0......
1b15e0e0: 0000 0000 0000 0000 2000 0000 0000 0000 ........ .......
1b15e0f0: 0900 7400 6500 7300 7400 3100 2e00 7400 ..t.e.s.t.1...t.
1b15e100: 7800 7400 0000 0000 4000 0000 2800 0000 x.t.....@...(...
1b15e110: 0000 0000 0000 0300 1000 0000 1800 0000 ................
1b15e120: f999 4f94 6479 ec11 9136 0019 99bd 0a16 ..O.dy...6......
1b15e130: 8000 0000 4800 0000 0100 0000 0000 0100 ....H...........
1b15e140: 0000 0000 0000 0000 0200 0000 0000 0000 ................
1b15e150: 4000 0000 0000 0000 0030 0000 0000 0000 @........0......
1b15e160: 4621 0000 0000 0000 4621 0000 0000 0000 F!......F!......
1b15e170: 2103 4508 0000 0000 ffff ffff 8279 4711 !.E..........yG.
1b15e180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
1b15e190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
1b15e1a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
1b15e1b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
1b15e1c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
1b15e1d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
1b15e1e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
1b15e1f0: 0000 0000 0000 0000 0000 0000 0000 0300 ................
Dateisystemeinträge beginnen immer mit FILE0 und enthalten neben vielen anderen Informationen den Dateinamen (rot), die Versionsnummer (blau) und die so genannten Fixup-Bytes (grün).
Wird eine Datei neu angelegt, wird zuerst der Dateisystem-Eintrag geschrieben. Wird eine Datei verändert, wird zuerst die Versionsnummer erhöht. Danach wird die Datei auf den Datenträger geschrieben.
Nachdem die Datei auf die Festplatte geschrieben wurde, werden die Fixup-Bytes auf den gleichen Wert gesetzt wie die Versionsnummer! Da wir die Daten in der Little-Endian Bytereihenfolge betrachten, müssen wir die 0300 als 0x0003 lesen! Hier sehen wir also, dass die Datei in der dritten Version vorliegt.
Weiters sehen wir, dass die Datei vollständig geschrieben wurde da Versionsnummer und Fixup-Bytes übereinstimmen! Wäre der Schreibvorgang in der Mitte der Datei abgebrochen worden, wäre nur die Versionsnummer erhöht worden und die Fixup-Bytes würden noch auf 0x0002 stehen.
Dies werde ich nun simulieren indem ich die Versionsnummer mit einem Hex-Editor wie folgt manipuliere:
1b15e000: 4649 4c45 3000 0300 216a 2000 0000 0000 FILE0...!j .....
1b15e010: 0100 0100 3800 0100 8001 0000 0004 0000 ....8...........
1b15e020: 0000 0000 0000 0000 0400 0000 2400 0000 ............$...
1b15e030: 0400 0000 0000 0000 1000 0000 6000 0000 ............`...
...
1b15e1f0: 0000 0000 0000 0000 0000 0000 0000 0300 ................
Danach kann ich chksdk manuell ausführen:
PS C:\Windows\system32> chkdsk G: /f
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet chkdskme.
Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
Beschädigtes Datensatzsegment 24 wird gelöscht.
256 Datensätze verarbeitet.
Dateiüberprüfung beendet.
Phasendauer (Datei-Datensatz Überprüfung): 12.53 Millisekunden.
0 große Datensätze verarbeitet.
Phasendauer (Wiederherstellung für verwaisten Datei-Datensatz): 3.06 Millisekunden.
0 ungültige Datensätze verarbeitet.
Phasendauer (Prüfung auf falschen Datei-Datensatz): 0.74 Millisekunden.
Phase 2: Die Dateinamenverknüpfung wird untersucht...
Indexeintrag test1.txt in Index $I30 der Datei 5 wird gelöscht.
1 Analysedatensätze verarbeitet.
Ein Indexeintrag wird aus dem Index $O der Datei 19 gelöscht.
276 Indexeinträge verarbeitet.
Indexüberprüfung beendet.
Phasendauer (Indexüberprüfung): 24.28 Millisekunden.
0 nicht indizierte Dateien überprüft.
Phasendauer (Wiederverbindung für verwaisten Datensatz): 2.18 Millisekunden.
0 nicht indizierte Dateien wiederhergestellt.
Phasendauer (Wiederherstellung für verwaiste Datensatz): 1.12 Millisekunden.
1 Analysedatensätze verarbeitet.
Phasendauer (Überprüfung von Analysepunkts und Objekt-ID): 3.70 Millisekunden.
Phase 3: Sicherheitsbeschreibungen werden untersucht...
Überprüfung der Sicherheitsbeschreibungen beendet.
Phasendauer (Überprüfung für Sicherheits-Deskriptor): 12.34 Millisekunden.
10 Datendateien verarbeitet.
Phasendauer (Datenattributüberprüfung): 1.08 Millisekunden.
CHKDSK hat freien Speicher gefunden, der in der MFT-Bitmap (Master
File Table) als zugeordnet gekennzeichnet ist.
CHKDSK hat freien Speicher gefunden, der in der Volumebitmap als
zugeordnet gekennzeichnet ist.
Es wurden Korrekturen am Dateisystem vorgenommen.
Es sind keine weiteren Aktionen erforderlich.
1328128 KB Speicherplatz auf dem Datenträger insgesamt
8000 KB in 6 Dateien
72 KB in 12 Indizes
0 KB in fehlerhaften Sektoren
5956 KB vom System benutzt
5248 KB von der Protokolldatei belegt
1314100 KB auf dem Datenträger verfügbar
4096 Bytes in jeder Zuordnungseinheit
332032 Zuordnungseinheiten auf dem Datenträger insgesamt
328525 Zuordnungseinheiten auf dem Datenträger verfügbar
Gesamtdauer: 62.36 Millisekunden (62 ms).
Das Prüfen des Test-Datenträgers (2GB USB Stick) hat nur 62 Millisekunden benötigt. Ein Datenrettungs-Programm wie zB r-Studio oder UFS-Explorer würde für diesen Datenträger 15-20 Sekunden benötigen...
Diese Geschwindigkeit hat einen Preis - Ihre Daten!
Das Dateisystem und die Datei wird nicht repariert. Die beschädigte Datei wird einfach gelöscht!
Dazu sollte man wissen, dass Ordner quasi auch nur Dateien sind, die eine Liste der darin enthaltenen Dateien und Unterordner darstellen. Das kann dazu führen, dass das Eintragen einer Datei in einem Ordner nicht beendet wurde und darum der gesamte Ordner gelöscht wird. Damit sind dann auch die darin enthaltenen Unterordner nicht mehr im Dateisystem verfügbar.
So sieht eine Kunden-Platte nach chkdsk aus:
Im Ordner found.001 finden wir sehr viele Unterordner, die wiederum Dateien enthalten.
Außerdem gibt es einige Dateien, die file########.chk heißen!
Wir sehen im Bild, den Inhalt der Datei file00000006.chk und erkennen anhand der ersten 2 Bytes (0xFF und 0xD8), dass dies eine JPEG-Datei ist.
Wir haben also einige Datei- und Ordnernamen verlohren. Außerdem müssen wir herausfinden was für Dateitypen sich hinter file########.chk verbergen.
Darüber hinaus fehlen einige Dateien. Darum haben wir nach dem Klonen der HDD zuerst nach verlorenen bzw. gelöschten Dateien gesucht.
Wenn Sie wissen möchten warum wir so vorgehen, dann lesen Sie bitte folgenden Post: Was passiert bei Datenrettung mit Software?.
Nach der Wiederherstellung der Daten zeigt sich das ganze Ausmaß der Zerstörung:
diskdoctor@DESKTOP-BKNCCT2:/mnt/i/Recovery$ du -sh *
21M $Extend
87G $LostFiles
1.4G $RECYCLE.BIN
13M 33ee18d46b686758b3df34e8
15M 6b208ee7674deeb54dbbb941
63M 810a328b44168bf388b5
48K Config.Msi
5.5G Desktop Festplatte -C- 06-01-2***
20G Eigene Dateien
465M Firefox-Downloads
31M F********** Wasserschaden
23M Gopal-Karten und Software und sonstige
4.1G Hochzeit m***** l***
26G M**** Notebook
7.8G M**** Notebook Asus R**** 2***
7.4G Programme
7.8M RECYCLER
3.0G System Volume Information
8.0K Thumbs.db
630M Videos iphone B*****
572K bootex.log
16K bootsqm.dat
3.7G found.001
194G windows
Zuerst fällt uns auf, dass ca. 3,7GB an Daten in found.001 gelandet sind. Diese sind Dateien und Ordner, die man von Hand prüfen und wieder einsortieren muss.
Im Ordner $LostFiles sind weitere 87GB an Daten, die gelöscht wurden!
Werfen wir Kurz einen Blick in diesen Ordner:
diskdoctor@DESKTOP-BKNCCT2:/mnt/i/Recovery$ ls -l \$LostFiles/\$Group100000000000001/
total 0
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder0000001E'
drwxrwxrwx 1 root root 512 Jan 20 11:36 '$Folder0000001F'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder000000EF'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder000000F0'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder00000176'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder0000018A'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder000001A0'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder000001BB'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder000001CA'
drwxrwxrwx 1 root root 512 Jan 20 11:57 '$Folder000001DB'
... usw.
Eine weitere Datenrettung bei der chkdsk viele intakte Dateien gelöscht hat:
Von 9950 Dateien konnten 9678 gerettet werden! In diesem Fall waren dies 102GB an Daten die CHKDSK temporär unbrauchbar gemacht hat!
Fazit
Checkdisk hat wie wir sehen nicht die Aufgabe Daten zu retten sondern das Dateisystem wieder in einen konsistenten Zustand zu versetzen damit das Betriebssystem booten oder die Festplatte wieder eingehängt werden kann. Das geschieht auf Kosten der Daten!
Wir wollen bei einer Datenrettung aber nicht unbedingt, dass die Platte wieder vom Betriebssystem gelesen werden kann. Vor allem nicht, wenn das Betriebssystem dann nach einem Datenverlust anfängt die Platte zu defragmentieren oder durch andere Aktivitäten verlorene Daten zu überschreiben.
Besonders Gefährlich wird dies wenn es sich um ein neues Festplatten-Modell oder eine SSD handelt. Bei diesen Datenträgern kann der TRIM-Befehl binnen Minuten oder gar nur Sekunden die Daten unwiederbringlich vernichten!
Führen Sie also keinerlei Dateisystemreparatur aus, sondern klonen Sie die Platte lieber. Genau um solche Probleme zu beheben sind diese Tools geschaffen worden!
Hierbei ist es egal ob wir von chkdsk unter Windows oder fsck am Mac oder in Linux sprechen. Alle diese Tools arbeiten zu einem gewissen Grad gleich und verursachen nur Datenverlust und zusätzlichen Aufwand die Daten zu sichern und einzusortieren.