Data Recovery and Disk Utilities Forum @R-TT

Yes, it is true. But I'm sure comes from data in the parameters.
Remember I'm doing tests with a raid that works. The files that are corrupted in the RStudio, I can easily see if I assemble the raid in linux.

What data you'd need to see the records?

Thanks,
and sorry for the inconvenience, but RStudio is with the best results I have obtained, and I want to understand how it works to buy it.

The files may be corrupted because something was written to the disk during array rebuild or because the RAID parameters are incorrect. It's hard to say without seeing actual data on the disks.

What I want to find out, is why the files are corrupt.
Considering that the raid5 is fine, and that the files go corrupt, let me doubt if files in raid5 in poor condition, they are really bad or is it a configuration problem with RStudio.

thanks

And creating a RAID out of the regions that started from Sector 1024?

I'm testing with a raid5 of 1GBx5 = 4GB. No Problem scaning all the raid.

Using offset=1024 dont work. Wen I scan with this value, when I scan with this value, and when I open Recognized0 to view the files, appears Root and is full of $inodes, with a red cross. No dirs, no files.

thanks

Try to create regions starting from Sector 1024 on the disk and create a RAID out of them. You don't have to scan the entire raid to find partitions on it, only first 5 GB would be enough.

Hi,

It does not work.

When I do a scan to Block Raid with default values​​, except that change BlockSize 512k, appears all but some corrupted files. When I change the offset to any other value, disappears "Direct Volume" that is displayed when I assembled the BlockRaid, performed a scan but nothing appears.

thanks

You need to enter 1024 sectors to the offset of the disks in the RAID parents tab, Super offset is the offset on the disks of the RAID, not its file system.

/dev/sdb1:
    Data Offset : 1024 sectors
   Super Offset : 8 sectors
   Device Role : Active device 0

Hi Alt,

Excuse the delay in responding, I was doing some tests.

What you did not answer, was if it is possible to use RStudio license for windows in linux version

In tests I have done in RStudio, I have found results that confuse me, and has led me to error, possibly: RStudio detected disks in reverse order. First list the last and then list the first.

1) The last disk to appear is called SoftRAID1. This is the raid5 detected by the system. When I make a scan to it, appears "Recognized", then I say show me the files found. Root appears here and the complete structure of the raid. All files are in good condition.
2) after realizing the order of the disks, I've re-created a BlockRaid5 with the correct order of disks. I have tried almost all parameters. Never shows the correct structure of raid5 with files.

And, examining the disks rom raid I have this:

[code]/dev/sdb1:
Data Offset : 1024 sectors
Super Offset : 8 sectors
Device Role : Active device 0[/code]

Is the same in all disks. How can I put this data into rstudio ? I have see only one offset data in the block raid created. This offset is "Super Offet" or "Data Offset" from the originals ?


Back to ask, is anything special I should do to assemble the raid5 in r-studio?

Thanks for the help and patience.

1. The windows version is a little bit ahead of its Linux counterpart.
2. Windows, Linux, or Mac are different versions, but this is about the host OS on which the program is to run. Any version supports all supported files systems. That is, if you use the Windows version, you'll be able to recover files from with NTFS, HFS, extFS, etc, disks. The same is for the Linux and Mac versions.
3. Those aren't files, those are recognised partitions, that is, partitions that R-Studio believes reside or resided on the disk. The color shows how much info on this partition remains on the disk. See more on R-Studio on-line help: [url=http://www.unformat-unerase.com/Unformat_Help/discscan.html]Disk Scan[/url], on the bottom.
4. A red cross means that the file has been normally deleted. It may be recovered.
5. It looks like ext4 is a problem for this matter.