Filesystem von Truecrypt-Container beschädigt !?

Lieber Besucher, herzlich willkommen bei: Linux Forum Linux-Web.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

kernspalt

unregistriert

05.05.2009, 09:43

Filesystem von Truecrypt-Container beschädigt !?

Ich habe auf einer externen Festplatte (NTFS) einen 450 GB Truecryptcontainer. Der TC-Container ist ext3 (es ist schon etwas länger her das ich den Container erstellt habe, bin mir nicht mehr zu 100 % sicher ob ext2 oder ext3) formatiert.
Nun habe ich ein DVD-Image das sich in dem Container befindet gebrannt und gleichzeitig 4 gb Daten auf den Container kopiert.
Beim kopieren ist mir aufgefallen das nur noch 3 GB Platz sind. Ich habe dann noch auf die schnelle einen 4 GB goßen Ordner gelöscht
der sowieso schon längst überfällig war. Im Nautilus wurden dann auf einmal 12 GB freier speicher angezeigt anstatt der zu erwartenden 7.
Habe mich zwar gewundert, aber vllt. war der gelöschte Ordner ja doch etwas größer.
Also habe ich als das Kopieren der Daten fertig war noch einmal 6 GB hinterhergeschoben. Bei 8 GB freiem Speicher kam dann allerdings
die Meldung, dass die Festplatte (bzw der Container) voll wär. Da ich weg musste habe ich noch den Brennvorgang abgewartet und den Rechner
runtergefahren.
Seid dem kann ich nun den TC-Container nicht mehr mounten.

Quellcode

mount: wrong fs type, bad option, bad superblock on /dev/mapper/truecrypt1,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen – versuchen
       Sie  dmesg | tail  oder so

Ich habe dann über Truecrypt nur das Filesystem eingehängt und versucht mittels fsck das FS
zu reparieren.

fsck -p /dev/mapper/truecrypt1

Dies gab folgende Meldung

Quellcode

fsck 1.41.3 (12-Oct-2008)
/dev/mapper/truecrypt1: Hinweis: Wenn mehrere Inodes oder Bitmap-Blöcke
neu geordnet werden müssen, oder ein Teil der Inode-Tabelle
verschoben werden muss, könnte es helfen, e2fsck erst einmal
mit der Option »-b 32768« zu starten. Das Problem könnte
im primären Blockgruppenbezeichner liegen, und seine
Sicherungskopie in Ordnung sein.

Also habe ich fsck -y -b 32768 /dev/mapper/truecrypt1 probiert, mit folgendem Ergebnis:

Quellcode

fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
Inode Tabelle für Gruppe 1888 ist nicht in Gruppe.  (Block 0)
WARNUNG: GROSSER DATENVERLUST IST MÖGLICH.
Zurücksetzen? ja

/dev/mapper/truecrypt1 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen.
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Fehler beim Zuweisen 256 grenzt an Block(s) in Block Gruppe 1888 for Inode-Tabelle: Could not allocate block in ext2 filesystem
Beginne e2fsck neu ...
fsck.ext2: Gruppen-Deskriptoren scheinen defekt zu sein... versuche es mit Backup-Blöcken...
Inode Tabelle für Gruppe 1888 ist nicht in Gruppe.  (Block 0)
WARNUNG: GROSSER DATENVERLUST IST MÖGLICH.
Zurücksetzen? ja

Das ganze wiederholt sich anscheinend beliebig oft. Nach dem 5ten mal habe ich abgebrochen.
Hab das ganze noch mit 2 alternativen Superblöcken ausprobier. Selbes Ergebnis.

Nun weiss ich nicht mehr weiter und hoffe auf Hilfe.

Edit: hab noch einen Tipp bekommen und mit fls -p -r /dev/mapper/truecrypt1 > filelist.txt wenigstens herausgefunden das die Dateien allen Anschein nach so ziemlich alle vorhanden sind. Wenn nicht sogar alle.

Zum Seitenanfang

ixo

Anfänger

Beiträge: 2

23.05.2009, 21:56

RE: Filesystem von Truecrypt-Container beschädigt !?

Hallo kernspalt,

ich weiß leider auch nicht, wie Du weiter vorgehen kannst. Außerdem hoffe, ich gieße jetzt nicht noch Öl in die Wunde. :hex:

Ich verwende auch TrueCrypt, allerdings in wesentlich geringerem Umfang, aber das spielt eigentlich keine Rolle. Du solltest Dir ein regelmäßiges Backup machen und eine gewisse Historie vorhalten. Dann hast Du gute Chancen, an Deine Daten wieder heranzukommen.

Um hier nicht nur neunmalkluge Ratschläge zu geben, schreibe ich 'mal noch, wie ich meinen TrueCrypt Container sichere. Das Problem ist, dass ich für die Sicherung die Daten nicht auslesen will, da sie dann natürlich (während der Sicherung) nicht mehr verschlüsselt sind. Die Sicherung selbst läuft bei mir unter Linux, da wir hier in einem Linux-Forum sind, gehe ich 'mal davon aus, dass das für Dich auch ok ist.

Ich verwende für die Sicherung storebackup. Das Tool kann (neben "normalen" Dateisicherungen) Image Dateien (oder Partitionen) als Ganzes auslesen und woanders ablegen. Das Ablegen erfolgt allerdings aufgesplittet in Blöcken, die gemäß ihrer Reihenfolge nummeriert sind. (Eine Kompression dieser Blöcke ist möglich, macht aber bei TrueCrypt natürlich keinen Sinn.)

Bei der zweiten Sicherung wird das Backup unter dem entsprechenden neuen Zeitstempel abgelegt (eigenes Directory). Die durchnummerierten Blöcke werden aber nur dann neu angelegt, wenn sie sich geändert haben. Blöcke, die sich nicht geändert haben, werden per Hardlink auf die Blöcke der existierenden Sicherung verweisen.

Auf diese Art gibt es stets full backups, aber der (zusätzliche) Plattenplatzbedarf ist der eines inkrementellen Backups.

Die Wiederherstellung eines TrueCrypt Containers erfolgt dann entweder mit dem mitgelieferten Tool oder einfach per `cat * > /irgendwo/tc.image` (oder ähnlich). Das Verfahren ist natürlich nicht sonderlich gut dafür geeignet, einzelne Dateien zurückzuholen

Bei der Datenmenge von 450 GB solltest Du (falls Du das so machen willst) die Datei auf jeden Fall lokal lesen (oder ein Gigabit Netzwerk haben), da die 450 GB Datei hauptsächlich gelesen wird, geschrieben werden ja nur die veränderten Blöcke (außer beim ersten Mal).

Alles Gute, ixo

Zum Seitenanfang