No such pattern going up. Should I search down? Is there a way in WinHex to search for any bytes other than 00? Maybe I can find the first sector that has bytes after the 0's start.

EDIT: Oops spoke too soon, I had it on count occurrences and thought it wasn't finding anything, there were 4 of them, let me find each one.

Sector 341:



Sector 339:



Sector 337:



Sector 335:

Please do same search down. Those sectors, which you are found not useful for us.

Sector 224773492:



I'm going to guess that this isn't what we need either, looks like it's part of a compressed file or something else, maybe a disk image.

So it's look like format kills file records and there is no way to get files in useful format back. Information about names, sizes, file fragmentation and etc are gone. And that is why no one utility helped. I am sorry.

Well, I appreciate your time. And everyone's responses. I will just use Active Partition Recovery to do a low level file recovery, at least I'll have most of the content, just no structure. Will take me some time to sift through 200k pictures and 500k text files, but I dug my own grave. Time to invest in some automatic backup.

Thanks all.

If you use Active@ File Recovery Pro, it will put the recovered files into folders named according to the meta data of the recovered files. Should take less time.

_________________
Sabo Computer Repairs & Data Recovery

Hi!

Sorry to come so late in the discussion.

The FORMAT command was used without the /q (Quick format) option.
Hence, data were truely erased (overwritten) during a few minutes.


If the write speed was around 100MB/s, which is a realistic approximation for classical drives, you should have lost about the first 12 Gigas in 2 minutes.


Instead of blindly running many utilities --which make things even worse if you installed them on the target RAID system-- you must understand that RAID 0 splits the data flows in two parts, which are then written to the drives. Before performing a data recovery, you must put together (aka reassemble) the stripes coming from both drives.
Some tools like Raid Reconstructor from Runtime allow you to create a virtual image. You can then run the recovery over the virtual image with GetDataBack.
The hardest part (especially if you're doing it for the first time) is to guess the size of the stripes, as well as order settings (disk order, offset, ...). This can be quite time consuming.
In no case should the RAID reconstuction attempts be done on the original drives.
You should clone them first for two reasons:
- reducing risks of additional errors
- reducing the risk due to mechanical fatigue, as several attempts of RAID-0 reconstruction can be intensive for the disks

I assume that your garbled content could come from the fact that your recovery sofwares are not reassembling the stripes or at least not correctly. Possibly are the stripes large enough so that you can read small files that are fully contained into a single stripe (on one disk) and this would explain why you get about 300 GB of data out of 900.


NO!
I agree with what other users told above. For successful data recovery, you must clone your drives and in no case write any byte of data on them.
As you seem being novice in the field of data recovery, there is a risk of you mixing the input and output disks during the cloning, especially if your input and output drive have the same capacity. Furthermore, for the cloning, you need a software that doesn't fail on defective sectors.

I would suggest that you ask a data recovery professional which already has performed RAID-0 recoveries.

It's look like you didn't read topic. Author have raid untouched and fully working and he searched for ntfs records and didn't find them, so there is nothing to do for pro.

Yeah, Active Partition Recovery is doing this. Photos/Images, Videos, Adobe files, etc. Each has it's own folder split by the file type and extension.

Thanks!



Correct, I fully realize what had happened, and know that I lost quite a bit, and in reality, it was more like 150-190MB/s



I don't think I need to reconstruct the RAID, because the RAID is still intact. I didn't split the drives and THEN format, I ran the format against the volume that was composed of the RAID. So the RAID itself was never altered.

I also wasn't actually doing any WRITE commands with ANY of the utilities I tried at that point. I only ran utilities to see what results I could get from each one. I knew better than to write anything as the entire drive was considered RAW anyway. I do have a backup clone of the RAID. (2 of them actually)



Yes, I am a novice to data recovery, but I also understand some low level programming and how data is stored in many devices. I actually used to be a developer for the android phone scene, both software and hardware wise. So I'm not a complete noob here, lol. My drives also do not have any defective sectors.

I only asked that about the format because I thought that it might help push the tools into reading the file structure properly as it was. But in reality, it already was reading them correctly, I had made the assumption that it was reading the drive separately, that's obviously not correct. The RAID is still considered a single drive. I was also not using many of the tools as they should be used in this case, like against the device rather than the broken partition.

I made my normal amount of mistakes going through each tool, again, never writing anything. But now I have learned a little more about how NTFS actually functions and stores data, and drHDD is correct that the $MFT is gone, by a long shot. The format 00'd everything out for quite a ways, far past the $MFT. I won't be able to directly recover the filename/folder structure, but I can at least recover the data, as the format didn't get very far, Maybe 10-30GB.

The broken files were just coming from PhotoRec, which I don't really trust anyway. I'm going to use Active Recovery, as it's getting far better results anyway. There's also several hundred thousand "text" files that were originally stored on this drive. (they didn't have the extension .txt but they were still just plain text files, macros, scripts, batch files, etc.)

I'm content with sifting through them. I know which ones are most important to me, and I know what the content is in them, so it will be fairly easy to recover what I'm looking for. The majority of the content was stuff that I can find online, so I'm not worried about it. And it's recovering my important PDF's.

So I've learned plenty from this experience. First and foremost, keep a backup of my important stuff, and secondly, be a little more cautious with format command when using my remote desktops.

Thanks for the details.

I had read that the RAID was still working but wondered why the recovered contents were garbled.

As quite a lot was destroyed, I would suggest you using GetDataBack, as it will allow you to retrieve lost files (when the $MFT was partially destroyed) as well as duplicates. Hence, you could possibly recover older versions of a file if it was lost.
You can also avoid recoverying useless files like .exe, .dll, .inf, .sys, a.s.o. by exluding some file extensions.

I assume that you installed the utilities on another partition than the RAID one.