FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Thu May 13, 2021 01:00



Post new topic Reply to topic  [ 5 posts ] 
NTFS Partition Recovery 
Author Message

Joined: Thu Mar 17, 2011 18:48
Posts: 3
Post NTFS Partition Recovery
Hi y'all, I have an interesting problem, with multiple solutions but I was wondering if you could help.

My setup:
openSuSE 11.3
ntfs-3g 2010.3.6 integrated FUSE 27

I have a small external hard drive (actually just an old 100GB laptop HDD with a sata usb adapter, without a case) that I use for miscellaneous backup items. The other day after having backed up my android phone's SD card (and wiping said card) I accidentally dropped the drive. Fortunately it is in operable condition; I proceeded to mount the drive normally but after 2 minutes or so it was no longer readable. Crap. So I used ddrescue to image the entire drive and found that actually only maybe 2kB or so are unreadable. When I go to mount the image though I receive the following error(s).

Code:
laptop:/media/big # parted ./HDD.img
GNU Parted 2.2
Using /media/big/HDD.img
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit                                                             
Unit?  [compact]? B                                                       
(parted) print                                                           
Model:  (file)
Disk /media/big/HDD.img: 100030242816B
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End            Size           Type     File system  Flags
1      32256B  100027630079B  100027597824B  primary  ntfs         type=07

(parted) quit

laptop:/media # mount -t ntfs-3g -o loop,ro,offset=32256 ./big/HDD.img /media/smallHDD/

ntfs_mst_post_read_fixup: magic: 0x00000000  size: 4096  usa_ofs: 0  usa_count: 65535: Invalid argument
Index buffer (VCN 0x0) of directory inode 0x5 has a size (24) differing from the directory specified size (4096).
ntfs_mst_post_read_fixup: magic: 0x00000000  size: 4096  usa_ofs: 0  usa_count: 65535: Invalid argument
Index buffer (VCN 0x0) of directory inode 0x5 has a size (24) differing from the directory specified size (4096).


It looks like the MFT is corrupt. Maybe, maybe not.

Code:
laptop:/media # ntfsinfo -mf /dev/loop0
The device /dev/loop0, is mounted.
Forced to continue.
Volume Information
   Name of device: /dev/loop0
   Device state: 11
   Volume Name: DATA
   Volume State: 1
   Volume Version: 3.1
   Sector Size: 512
   Cluster Size: 4096
   Volume Size in Clusters: 24420800
MFT Information
   MFT Record Size: 1024
   MFT Zone Multiplier: 1
   MFT Data Position: 24
   MFT Zone Start: 0
   MFT Zone End: 3052604
   MFT Zone Position: 4
   Current Position in First Data Zone: 3052604
   Current Position in Second Data Zone: 0
   LCN of Data Attribute for FILE_MFT: 4
   FILE_MFTMirr Size: 4
   LCN of Data Attribute for File_MFTMirr: 524288
   Size of Attribute Definition Table: 2560
FILE_Bitmap Information
   FILE_Bitmap MFT Record Number: 6
   State of FILE_Bitmap Inode: 0
   Length of Attribute List: 0
   Attribute List: (null)
   Number of Attached Extent Inodes: 0
FILE_Bitmap Data Attribute Information
   Decompressed Runlist: not done yet
   Base Inode: 6
   Attribute Types: not done yet
   Attribute Name Length: 0
   Attribute State: 3
   Attribute Allocated Size: 3055616
   Attribute Data Size: 3052600
   Attribute Initialized Size: 3052600
   Attribute Compressed Size: 0
   Compression Block Size: 0
   Compression Block Size Bits: 0
   Compression Block Clusters: 0


I know there are maybe a dozen ways at this point to try and recover the data, but I'd really prefer to try and mount the image "natively" using ntfs-3g, instead of having to use a recovery program or having to mount the image and use chkdsk under Windows. Any suggestions? Maybe I'm missing something very simple? Thanks in advance for any help you can provide.

--Brent


Thu Mar 17, 2011 19:06
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: NTFS Partition Recovery
Hi,

Quote:
Index buffer (VCN 0x0) of directory inode 0x5 has a size (24) differing from the directory specified size (4096).

This means there is a problem in the root directory of the ntfs file system, so ntfs-3g will not be able to access your files.
Quote:
I know there are maybe a dozen ways at this point to try and recover the data, but I'd really prefer to try and mount the image "natively" using ntfs-3g, instead of having to use a recovery program or having to mount the image and use chkdsk under Windows. Any suggestions?

With a damaged root directory (and some probably surface damage), you will have to use a recovery program such as chkdsk which will try to recreate the directory and mark bad sectors to not be used any more. ntfs-3g will not do the trick.

Regards

Jean-Pierre


Thu Mar 17, 2011 22:30
Profile

Joined: Thu Mar 17, 2011 18:48
Posts: 3
Post Re: NTFS Partition Recovery
Thank you, I was hoping that there was a more interesting way to recover the data, but alas not. I mounted the image under Windows and used Runtime's GetDataBack for NTFS (which I use too frequently) and it was able to recover the data, albeit missing folder and file names and extensions. Any ideas on how to recover that as well?

On a side note, is there a good textbook or website that lays out NTFS in an intelligent manner? I mean my background is in Physics but I have plenty of computer science training; maybe something at the level of a university CS class?

Cheers
--Brent


Mon Mar 21, 2011 05:28
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: NTFS Partition Recovery
Hi Brent,

Quote:
I mounted the image under Windows and used Runtime's GetDataBack for NTFS (which I use too frequently) and it was able to recover the data, albeit missing folder and file names and extensions. Any ideas on how to recover that as well?

I just made an experiment : I deleted the index of the root directory (on a test partition image), so that I get an error similar to yours :
Code:
[root@pavilion2 ntfs-3g]# src/ntfs-3g ../../images/cf32M-9.tmp disk
ntfs_mst_post_read_fixup: magic: 0x4e905beb  size: 4096  usa_ofs: 18004  usa_count: 8274: Invalid argument
** mount failed, code 13

Then I started chkdsk :
Code:
The type of the file system is NTFS.
Volume label is ntfs-try.

CHKDSK is verifying files (stage 1 of 3)...
Deleting corrupt attribute record (160, $I30)
from file record segment 5.                 <=== this is the root directory
  672 file records processed.
File verification completed.
  4 large file records processed.
  0 bad file records processed.
  0 EA records processed.
  8 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
Correcting error in index $I30 for file 5.    <=== fixing the root directory
Correcting error in index $I30 for file 5.
Sorting index $I30 in file 5.
  790 index entries processed.
Index verification completed.
CHKDSK is recovering lost files.
Recovering orphaned file $MFT (0) into directory file 5.
Recovering orphaned file $MFTMirr (1) into directory file 5.
Recovering orphaned file $LogFile (2) into directory file 5.
Recovering orphaned file $Volume (3) into directory file 5.
[....]
Recovering orphaned file testperm (48) into directory file 5.
Recovering orphaned file .NTFS-3G (51) into directory file 5.
Recovering orphaned file fusetest (64) into directory file 5.
Recovering orphaned file DIRECTORY (77) into directory file 5.
Recovering orphaned file DIRECT~1 (77) into directory file 5.
Recovering orphaned file testxattr (79) into directory file 5.
  20 unindexed files processed.      <==== orphaned files in root directory again
Recovering orphaned file compress (112) into directory file 5.
CHKDSK is verifying security descriptors (stage 3 of 3)...
  672 security descriptors processed.
Security descriptor verification completed.
  59 data files processed.
Correcting errors in the Master File Table (MFT) mirror.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

     31309 KB total disk space.
      3025 KB in 192 files.
       144 KB in 61 indexes.
         0 KB in bad sectors.
      3845 KB in use by the system.
      2048 KB occupied by the log file.
     24294 KB available on disk.

       512 bytes in each allocation unit.
     62619 total allocation units on disk.
     48589 allocation units available on disk.

Then tried to mount again :
Code:
[root@pavilion2 ntfs-3g]# src/ntfs-3g ../../images/cf32M-9.tmp disk
[root@pavilion2 ntfs-3g]# ls -l disk
total 40
drwxr-xr-x 1 linux linux 24576 Mar 14 12:33 compress
drwxr-xr-x 1 root  root      0 Feb 26 14:38 DIRECTORY
drwxrwxrwx 1 linux linux     0 Mar 14 12:33 fusetest
drwx-w-rwx 1 linux linux  4096 Mar 14 11:43 linux
drwxrwxrwx 1 linux linux     0 Oct 16  2007 root
drwxr-xr-x 1 linux linux  4096 Mar 14 12:33 testperm
drwxrwxrwx 1 linux linux  8192 Mar 14 12:33 testxattr

All files are present, with names, timestamps, permissions, etc.
This solution is not politically correct, but it works.

Regards

Jean-Pierre


Mon Mar 21, 2011 11:31
Profile

Joined: Thu Mar 17, 2011 18:48
Posts: 3
Post Re: NTFS Partition Recovery
Hi Jean-Pierre--

You were indeed correct. I was able to mount the raw image under Windows, which was more difficult than I remember it ever being, and ran chkdsk. All was recovered. Below is the chkdsk output for anyone curious.

Code:
C:\Users\Brent>chkdsk /F G:
The type of the file system is NTFS.
Volume label is DATA.

CHKDSK is verifying files (stage 1 of 3)...
  130970 file records processed.
File verification completed.
  948 large file records processed.
  0 bad file records processed.
Correcting cross-link for file 51100.
  0 EA records processed.
  0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
Correcting error in index $I30 for file 5.ex entries processed)
Correcting error in index $I30 for file 5.
Sorting index $I30 in file 5.
Correcting error in index $SDH for file 9.
Correcting error in index $SDH for file 9.
Sorting index $SDH in file 9.
  156172 index entries processed.
Index verification completed.
CHKDSK is recovering lost files.


Thanks for the idea; it was a pain but far more efficient than using GetDataBack.

So very thankful
--Brent


Wed Mar 23, 2011 02:36
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.