Data Recovery and Disk Utilities Forum @R-TT

If it's not too late, try to use our new build of R-Studio. It now really processes ExtFS much better.

Thanks.

There is now very little doubt that we got the correct parameters for the RAID. We found several PDF files that were made out of PowerPoint presentations. Some of them were over 200 MB and all the slides and pictures in a select few displayed perfectly. Therefore, the damage to the drive (most probably the accidental format) has caused the inability to recover directories and the glitches on some of the media files.

R-Studio has detected over 57 TBytes of possible files in the "Extra Files" categories, but of course, most of them aren't correct (the volume had 4 TB or so when it went down).

Even though we have not been able to recover much, this has been a great learning experience for us and we appreciate your help and input. R-Studio is a great tool and we will definitely keep it close by for emergencies.

All best,

Jose

The size should exceed (number of disks - 1)*Stripe size.

Every time we ran a full scan the "extra files" feature was on.

Do you think a 622K file should have been big enough to determine if disk order/blocksize/offset was correct? With 4 disks, 64K block I think a stripe would be either 64K or 256K, correct? (I read about this, but right now forgot how it is setup).

Thanks!

My last thought is did you checked the "[40]Extra found files" on the Drive pane? This is the place where R-Studio puts files find using the scan for Known File Types (or file signatures). Probable, this is the last resort.

OK, so we are about ready to through in the towel...

As far as we can tell, the damaged RAID5 volume has the following attributes:

4 drives, using Partition 3 on the 4 drives (there is a hot spare, but that shouldn't matter).
Linux software raid inside a Synology 1010+.
Total volume size aprox. 5.4 TBytes
Left Synchronous
64K block
264 sector offset

I found several jpegs using the settings above, but they were fairly small. The biggest one was about 622 KB. Several folders previously in that volume did not show up even after a complete scan, so we can't find any larger jpegs.

This particular jpeg file opens up perfectly after recovery. Several other smaller jpegs do not open correctly, although 3 or 4 do. I would imagine that a 622 K jpeg would be big enough to ascertain if the stripe size/disk order/offset is correct, given our block settings - but I can't be sure (a 264-sectors offset is fairly large and I wonder if that might not be correct, but I also do not have enough experience to know if an incorrect sector offset might cause these symptoms, or if only the block size matters when viewing these recovered jpegs).

However, we do believe that these are pretty much the correct settings for the damaged RAID5 volume. Tried several block sizes, disk orders and offsets. None gave us a "direct volume" like with the settings above, and only these settings yielded a large amount of recovered files (aprox. 350GB on the direct volume, more after a scan - even though several of the media files we were able to recover have glitches in them). I think that the accidental reformat of the RAID5 volume by the Synology OS probably messed up some or all of the stripes in at least one RAID disk component. Even when the jpegs opened partially, the stripe order looked correct.

So, I think it's probably time to give up. After several weeks of partial success, I can only imagine that the entire volume got corrupted by the Synology's "parity check" routine. We also checked leaving one disk out (adding a "missing disk") and letting the program recover with the parity information, but the results were the same.

Any last thoughts welcomed!

Many thanks and all best,

Cleiber

I'd find a relatively large jpg file, preview it, and try to find a correct block size, judging on the stripe structure of the picture.

Yes, just sent them to my mail: raptorbck (at) gmail (dot) com .

I mean that the Synology may have reformatted the RAID5 (data) partition. I can find 3 volumes in there with R-Studio and the one that was lost was done with a previous version of the firmware, so it has a different "number" on it (please see the recovered information on the enclosed .png files).

Have used several different sector offsets and the one that appears to give me the most "found files", with some of the previous tree structure, is 264. It is also the only setting where I get both a "direct volume" and a black "recognized" on the list of discovered volumes/partitions (please see enclosed screenshot files). However, I am still having the problem of glitches every 30 seconds or so when playing back the media files. A lot of the folder structure is not being recovered, although there appear to be several "inodes" and "superblocks" listed on R-Studio's recovered list.

Also, when trying to recover certain files, R-Studio gives me several errors stating that "file fragment is outside the size of the disc/volume/partition" or something similar. This RAID5 volume is the last one on the disks (partition 3 on each disk, starting at around 4.5 GB on each disk). I assume R-Studio would know how to configure this software raid volume without any other settings tweaks, correct?

I am about to give up on this recovery effort as it does appear the files are damaged. If I can see parts of the files, I assume my sector offset is correct (although I was able to see some files with other sector offsets). Given the above, if you or anyone else has any ideas of something else I should try, please do let me know. I would also appreciate if you could let me know if you see something obviously wrong on the screenshots.

Many thanks,

José

PS.: Unable to upload files - get a "Could not upload attachment..." error. Files are only 220 KB each... Let me know if you would like to see them and where to send them. Thanks!

algorithm =2 shows that the RAID is left-symmetric.
But what do you mean by saying "may have been reformatted"? Do you mean reassembling the RAID, or just formatting the RAID?