Nov 2, 2019
10
0
10
I have 4 disks of 1TB in RAID 10 with 2 NTFS partitions, one of 500GB and one of 1,3TB.
After some time 2 disks of 4 are dead, and one has bad blocks but I can access it.
Because this is an old computer I left it without a backup for some time ;-(

With some programs like "ReclaiMe Free RAID Recovery" I can mount the first partition of 500GB (and recover all files), but the second is smashed up.
I can get folder and files with the correct size but all files over 64kB aren't good.

If I compare with hex editor the original file (for example one image) with that on broken RAID the files is the same first 61440 bytes then broken 4096 bytes then good 61440 bytes and so on...

Can anyone help?
 
Last edited:
Solution
Here is a hypothetical example of a striped RAID with 4 clusters per stripe.

Notice what happens to the cluster numbers when there is an offset of 1 cluster.

Code:
Stripe size = 4

Offset = 0

-1   0   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

   --------+---------------+-------------------+---------
     : -5  | 0 : 1 : 2 : 3 |  8 :  9 : 10 : 11 | 16 :
   --------+-----------------------------------+---------
   --------+---------------+-------------------+---------
     : -1  | 4 : 5 : 6 : 7 | 12 : 13 : 14 : 15 | 20 :
   --------+---------------+-------------------+---------


Offset = -1

   --+-----------------+------------------+--------------
     | -5  : 0 : 1 : 2 | 3 :  8 :  9 : 10 | 11 : 16 ...
Nov 2, 2019
10
0
10
What is the stripe size?

Is there any chance of repairing the bad drives? Do they still spin up?

I would clone your drives, especially the one that has bad blocks.
Stripe size is 64kB.
The last working RAID 10 was on 2 drives. One of them is OK and one has bad sectors.
I made images of both.
With 2 disks is like RAID 0.
 
Nov 2, 2019
10
0
10
Initially, RAID 10 was with 4 disks. 2 disks died and it working on only 2.
I know that backup is essential thing but this was an old computer and I forget to backup new files.
My bad.
 
Nov 2, 2019
10
0
10
After comparing the original image to the one found on RAID, I found that the wrong 4096 bytes in principle were shifted for 64kB. If you look at the image (in the link) 4096 bytes at position 00015000 should essentially be at position 00005000.
4096 bytes in position 00015000 -> 00005000
4096 bytes in position 00025000 -> 00015000
4096 bytes in position 00035000 -> 00025000
4096 bytes in position 00045000 -> 00035000
...
All wrong 4096 bytes should essentially be offset earlier in the file.
If I do it manually with hexeditor the file will be correct except the last 4096 bytes.
 
Last edited:
Nov 2, 2019
10
0
10
Thank you arsomartinera.
I already created virtual RAID with R-studio and other programs.
The first partition is OK, but the second one is not.
On second partition of 1.3TB I can get all files but files over 64kB aren't good.
I've explained it before with one image file. Please see the post before.
 
What do you see if you carve the file directly out of the contiguous space rather than relying on the file system to serve it up? Note that 4KB is the default cluster size. Perhaps that's the clue???

Is this a case of specifying the wrong offset? What if the second volume requires a 4KB offset?
 
Last edited:
Nov 2, 2019
10
0
10
I can't locate the file without a virtual RAID setup.
It turns out that virtual RAID connects 15 of 16 clusters well. 😕
60kB (15 clusters) are good in file 4kB not good (shifted with offset od 64kB), 60kB good, 4kB not good (shifted with offset od 64kB or 16 clusters), etc.
 
Last edited:
Nov 2, 2019
10
0
10
How to force eg DMDE to regenerate all 16 clusters well?
It was Intel software RAID 10 on ASUS motherboard.

Besides this the first partition is good and I can get all the files without a problem. Only the second partition is a problem for now...
 
Here is a hypothetical example of a striped RAID with 4 clusters per stripe.

Notice what happens to the cluster numbers when there is an offset of 1 cluster.

Code:
Stripe size = 4

Offset = 0

-1   0   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

   --------+---------------+-------------------+---------
     : -5  | 0 : 1 : 2 : 3 |  8 :  9 : 10 : 11 | 16 :
   --------+-----------------------------------+---------
   --------+---------------+-------------------+---------
     : -1  | 4 : 5 : 6 : 7 | 12 : 13 : 14 : 15 | 20 :
   --------+---------------+-------------------+---------


Offset = -1

   --+-----------------+------------------+--------------
     | -5  : 0 : 1 : 2 | 3 :  8 :  9 : 10 | 11 : 16 :
   --+-----------------+------------------+--------------
   --+-----------------+------------------+--------------
     | -1  : 4 : 5 : 6 | 7 : 12 : 13 : 14 | 15 : 20 :
   --+-----------------+------------------+--------------

-5   0   1   2   -1   4   5   6   3   8   9   10   7   12   13   14   11   16                  
 ^                ^               ^                ^                  ^
 
Solution
How to force eg DMDE to regenerate all 16 clusters well?
It was Intel software RAID 10 on ASUS motherboard.

Besides this the first partition is good and I can get all the files without a problem. Only the second partition is a problem for now...
I can't explain why there is an apparent offset in the second partition, but DMDE allows you to assemble a logical RAID volume by specifying the offset and stripe size.

BTW, the cluster size is a red herring. Sorry. AISI, there is a physical 4KB offset, but it has nothing to do with the file system.
 
Nov 2, 2019
10
0
10
DMDE allows specifying the offset but only without offset I get the list of all files and folders. I tried to offset the first disk for 7 sectors, 120 sectors, the second disk also but without success.
I don't understand how it gets 15/16 clusters good ???
With every change of offset I lost the primary partition.
 
Last edited:
You can check the integrity of the RAID parameters by examining the NTFS metafiles. For example, data recovery professionals refer to the sequentially numbered records in the $MFT (with caveats).

Code:
Offset(h) 00       04       08       0C

00000000  46494C45 30000300 BD4FB003 00000000  FILE0...........
00000010  01000100 38000100 98010000 00040000
00000020  00000000 00000000 06000000 00000000  -> 0x0
                                     ^^^^^^^^
........
00000400  46494C45 30000300 2D0F0001 00000000  FILE0...........
00000410  01000100 38000100 58010000 00040000
00000420  00000000 00000000 04000000 01000000  -> 0x1
                                     ^^^^^^^^
........
00000800  46494C45 30000300 730F0001 00000000  FILE0...........
00000810  02000100 38000100 58010000 00040000
00000820  00000000 00000000 04000000 02000000  -> 0x2
                                     ^^^^^^^^
The $LogFile is another possibility, also with caveats.

Code:
Offset(h) 00       04       08       0C

00004000  52435244 28000900 F9098003 00000000  RCRD............
00004010  01000000 0C000100 C80F0000 00000000
00004020  EA098003 00000000 D30D0000 00000000  -> 0xDD3
                            ^^^^
........
00005000  52435244 28000900 F00B8003 00000000  RCRD............
00005010  01000000 0C000200 D80F0000 00000000
00005020  F00B8003 00000000 D40D0000 00000000  -> 0xDD4
                            ^^^^
........
00006000  52435244 28000900 F60D8003 00000000  RCRD............
00006010  01000000 0C000300 B00F0000 00000000
00006020  EA0D8003 00000000 D50D0100 00000000  -> 0xDD5
                            ^^^^
The $MFT sometimes includes empty records.

The $LogFile is a circular log, so there may be a discontinuity somewhere in the middle.
 
Last edited: