Raid Recovery

I hate to be the bearer of bad news, but it will be nearly impossible to recover the "old" RAID contents.

There are three (actually four) possible separate issues
1) It greatly depends on how EXACTLY the drives were formatted (under which OS and with which EXACT parameters) as by default a "normal" (i.e. non-quick) format operation on a Windows Vista (or later) OS will zero the whole extents of the drive (i.e. will erase all sectors on a volume)
2) the (possible) re-partitioning will have anyway most probably removed info from the beginning of the disks (which is normally used by most recovery software to determine some parameters of the RAID)
3) A "pure" Raid 1 would be unusual on four disks (though it is possible that the disks were used 2+2, i.e. in a RAID 0+1), whilst a RAID 10 (i.e. RAID 1+0) would be more probable
https://en.wikipedia.org/wiki/Nested_RAID_levels
4)There is no guarantee that the extents that were used by the Linux RAW image were not anyway overwritten by the new files of the "Win Server" installation.

If no re-partitioning was made and the format was done on a non-recent Windows system (or on some other OS that does not zero out sectors) or the /q parameter was used for formatting, there are good possibilities to recreate the RAID array (and it would make sense) otherwise it's a lost cause, but still, even if somehow it would be possible to recover parts of the preexisting RAID there would anyway be issue #4 ( .

What is perplexing is that you (or the IT division) have not a backup of the contents, "accidentally" in this case is simply not "enough" to justify what you report 😯 (particularly if done by an IT division).

The only thing that you may try doing (assuming that the filesystem previously used is known and it was not the same as the one now in use, as an example let's guess that the old one was EXT2/3/4 and that the current one is NTFS) could be to carve the disks for some structures typical of the "previous" filesystem and/or for some other "known content" of the Linux image.

If the filesystem is (and was) NTFS and formatted on the same Windows OS there is an additional issue (let's call it issue #5) that is that Windows uses normally the same area to allocate the $MFT so that even if the previous contents were not zeroed or overwritten they will be not indexed in any way and since I presume that the Linux *whatever* consisted of a very large file, there might be additional problems with possible fragmentation of the "old" filesystem.

jaclaz

1) It greatly depends on how EXACTLY the drives were formatted (under which OS and with which EXACT parameters) as by default a "normal" (i.e. non-quick) format operation on a Windows Vista (or later) OS will zero the whole extents of the drive (i.e. will erase all sectors on a volume)

Thank You, I didn't even think about that, but I am gonna check it with the IT guy and get back on you.

2) the (possible) re-partitioning will have anyway most probably removed info from the beginning of the disks (which is normally used by most recovery software to determine some parameters of the RAID)

I believe so, but doesn't some software (raid reconstructor) used entropy test to determine the config and raid type? wouldn't it help?

3) A "pure" Raid 1 would be unusual on four disks (though it is possible that the disks were used 2+2, i.e. in a RAID 0+1), whilst a RAID 10 (i.e. RAID 1+0) would be more probable
https://en.wikipedia.org/wiki/Nested_RAID_levels

Thank you on that note. The RAW image is about 900GB btw, I don't know would that helped you determine the RAID.

If no re-partitioning was made and the format was done on a non-recent Windows system (or on some other OS that does not zero out sectors) or the /q parameter was used for formatting, there are good possibilities to recreate the RAID array (and it would make sense) otherwise it's a lost cause, but still, even if somehow it would be possible to recover parts of the preexisting RAID there would anyway be issue #4 ( .

Could you shed some light on how to recreate the RAID array?

What is perplexing is that you (or the IT division) have not a backup of the contents, "accidentally" in this case is simply not "enough" to justify what you report 😯 (particularly if done by an IT division).

That is actually my first question, but You would not believe it. The dude that accidentally format it just yank the server and backup whilst they're running (and yes also the back up!), thinking that its his old (and empty) server, then move and format them. The back up is in the same rack, just one space below the main one roll roll
And if you know what's in the server and how important that data, it'll just make the story more unbelievable. ?

my plan is actually construct the RAID using the new win server config, and carve the RAW image from that RAID (finding the magic number and stop after 900GB), a long shot, but my last option.
any suggestion would be most welcome.

thank you.

Could you shed some light on how to recreate the RAID array?

Well, I know how this doesn't sound really-really "scientific", but usually with a hex/disk editor viewer one can see some "patterns" on a disk, and anyway (see below) you can always go empirically.
In the case of a RAID 0+1 or 1+0 (not repartitioned or re-formatted) you actually only need to check two disks (as the other two will be just a copy of the first two), and which one is the first disk is elementary as it will contain the first stripe (A1 in the pictures on the given wikipedia reference) which will contain the MBR, so it is easy to find the two "first disks" and the two "second disks".
Of course you should work on four "forensic sound" or "dd-like" images of the disks and not on the original devices.

Both formats do not have (like other RAID setups) any "extra" data, i.e. parity records, they are simply either a striped mirror or a mirror of a striped filesystem.
So you should have two couples of identical disks, you can easily take one disk from each set and then you have only two possibilities, either disk "A" is first disk or disk "B" is first disk.

Once you have determined the order of the disks, the number of possible parameters are not that many, you can well try them "blindly".

I would suggest you the DMDE software which allows to manually set the RAID parameters
http//dmde.com/
More or less the only variable you can "play with" should be stripe size, which in practice revolves commonly around four sizes; 16, 32, 64 and 128 kB (possibly also 256 Kb, but rare) of which AFAIK 64 and 128 Kb are the most common nowadays.

Of course if you can check how the (I presume hardware) RAID controller involved behaves by default, you might verify this, it is rare that the defaults are changed (unless there is a reason for that).

jaclaz

Some updates….

1. I've tried rebuilding the raid with raid reconstructor (to find the config etc) and dmde to cut/copy the sector. using both 64kb and 128k slices/stripes, with just 2 HDD.
*I cannot use raid reconstructor to copy the sector to an image, it kept on halting/producing error.

2. then I copy those rebuild raid to an image and use testdisk on them.

3. testdisk found several file system (ext3, HFS and NTFS). And I cut the one that have the same(close) size and format with the target raw image (that is Ext3 with approximately 900GB in size) .

4. the cut image from step 3 contains several folder and several files, at first it looked promising (home, var, etc, bin directory) but upon further inspection most of those folders are empty.

5. this happend with both 64 and 128kb stripes (the 128 shows even smaller amount of folder/files).

question.

1. after finishing step 1 and 2 (that is rebuilding the raid and copy the sector to an image). I tried to mount the raid, but windows cannot recognize it (keep asking to format it). but raid reconstructor could see the file structure.
does that mean my RAID config is wrong? or is that what happened if I use only 2 HDD (but I thought 01/10 won't have problem with just 2 HDD).

2. Any idea why most folder are empty? testdisk show "structure ok"
I don't have many experience with extx filesystem. is it the superblock being overwritten?

thank you very much.

Some updates….

1. I've tried rebuilding the raid with raid reconstructor (to find the config etc) and dmde to cut/copy the sector. using both 64kb and 128k slices/stripes, with just 2 HDD.
….

I am not following you.

Once you have (virtually) re-assembled the stripe in DMDE, what does it (meaning DMDE) "see?
It should be able to see (more or less) the same things that TESTDISK can (partitions/volumes/filesystems) orphaned in the MBR and EMBR logical chain, without any need to cut *anything*.

jaclaz

I am not following you.

Once you have (virtually) re-assembled the stripe in DMDE, what does it (meaning DMDE) "see?
It should be able to see (more or less) the same things that TESTDISK can (partitions/volumes/filesystems) orphaned in the MBR and EMBR logical chain, without any need to cut *anything*.

jaclaz

I just use DMDE to create the image of the new (after being formatted and being installed win server) RAID. then use testdisk to found the raw/dd file of the previous linux on that image.

I've tried using DMDE to find the linux raw image, but DMDE couldn't find it (automatically).

after creating the image of the new RAID (after being formatted), I then use testdisk on the image. testdisk find several partition (including what I presume the raw linux image).

if my process is somewhat inaccurate, please do correct me.

thank you.

if my process is somewhat inaccurate, please do correct me.

thank you.

I don't know. 😯

Usually (but not necessarily, and not necessarily in the case of an EXT2/3/4 volume specifically) DMDE finds the "same" things that Testdisk can find, it is entirely possible that this is not the case with that specific RAID, but it is also possible that *somehow* the RAID reconstruction was *somehow* incorrect and what Testdisk finds is a "false positive" in the sense that it is possible that the de-striping was not successful (wrong parameters?).

In any case I would try to NOT perform your "step 3", there is no real reason to "cut" anything, you can save the whole image "as is" (but in a non-striped sequence) and then run the tools (those or some more ones).

I mean, right now you have in theory something "striped" like
A1 B2 A3 B4 A5 B6…
ie. first stripe is on disk A, second is on disk B, etc.

I would first try to have (without modifying/cutting *anything*) a non-striped image *like*
C1 C2 C3 C4 C5 C6 …
i.e. with all stripes sequential on a same disk/image.

Then run of this non-striped image all the tools available (and even some more ones).

jaclaz

Challenge of data recovery from formatted (into new file system) or rebuilt (into new configuration) RAID arrays is rather common. In many cases it's possible to recover data.

There general algorithm is the following
1) Define new configuration and estimate damage after formatting and rebuilding. Maybe recovery is meaningless;
2) Define old configuration with needed data. Try to find out possibility to recover overwritten data (in case of RAID5 you can recover data from XOR). There are many ways used to recover data such as search previous RAID configuration metadata, using old configuration metadata, using files of previous RAID etc.
3) Recover data from old RAID configuration. This is like data recovering from formatted HDD. In this step it's necessary to exclude new RAID configuration data and try to rebuild data based on old RAID redundancy (if this is possible of course)

In your case looks like
- you know new configuration and can definitely rebuild it. It's known that some GBs of data are rewritten (Windows installation). The fact that TestDisk found other file system means that some data isn't rewritten and there is a chance to recover old data;

- in case where old and new RAID configurations are RAID 10 (or 01), you have to find out which drives were mirrors before and after rebuilding. For that you can search NTFS boot and ext3 superblocks;

- it's necessary to define how data were stored by proxmox. Needed raw-image can be fragmented. If there was host file system (with 1Tb capacity for RAID 10 or 01) then you have to recover it. If image is stored as LVM then you have to find LVM metadata. You can search manually image parties but it can take long time and requires deep knowledge in data recovery;

- Ext3 found and it looks healthy but you can't open partition. It can be caused by one of three reasons or all three ones altogether
a) old RAID parameters are wrong;
b) raw-image is fragmented;
c) ext3 metadata is formatted via Windows installation

To perform steps 1 and 2 of the algorithm you have to define old RAID parameters and recover host FS proxmox.
In step 3 you can try to recover lost data from old RAID redundancy. And use software to recover data from damaged ext3 (search and analysis of metadata).

You can perform all steps by PC-3000 Express RAID Edition System (www.acelaboratory.com)

Our advices are based on real data recovery experience.
Try to find a professional who has PC-3000 product with Data Extractor RAID Edition and our ACE Lab TS support engineers will help him to recover your RAID case.

Thanks,
ACE Lab Team