Drive is decrypting really slooooooow... #11
Comments
|
It might be able to run faster; I'm not sure. I haven't coded in variable transfer sizes yet, nor am I sure how to make this user-specifiable in an easy way, nor do I know how ddrescue decides how fast to read the disk (if that is faster; same for any other tools I don't know about that are also faster). Currently reallymine decrypts by reading 50MB (52428800 bytes) at a time. You can change Do you have any ideas? |
|
Little more background... How long the transfer from the bad one take? Are you using the precompiled version of really mine? Also are you connecting through USBs? On Oct 17, 2016 8:25 PM, "Pietro Gagliardi" [email protected]
|
|
How long the transfer from the bad one take? It took about 15 hours to clone the 4 Tb failing drive form the MyBook enclosure to a healthy drive using a RapidSpar (hardware imaging tool). I have made 3 separate attempts using different variables. Attempt 1 - I used the healthy drive that I cloned the data to as the source. It was connected to my Core 2 duo workstation over SATA. The target drive was an OCW RAID encolsure with 4 x 4 TB SATA drives configured as a RAID 5 which was connected to the workstation using a USB3 cable. Reallymine was installed from the compiled version installed to a live version of DEFT 8.2 Linux that runs off of a PXE server. After 5 days I had an 80 Gb image file. Due to bed weather my image got cut a bit short. I scanned the image I had so far with R-Studo and I was able to recover $MFT and some good data. I could tell by the file tables that there just over 600 Gb of data on the drive. Attempt2 - I used the healthy drive that I cloned the data to as the source. It was connected to an HP Prolient DL360G5 with 2 x Quad Core Xeon processors and 16 Gb of DDR2 fully buffered ECC RAM over SATA. The target drive that I am saving the decrypred .img file to is a WD RED 4 TB drive (new) also connected to a SATA port. Reallymine was installed from the compiled version installed to a live version of DEFT 8.2 Linux that runs off of a PXE server. This drive is a decrypting at a rate of 1 Gb/2 Hr. In both attempt 1 and 2 when I first ran the command in Linux it took almost 12 hours before the disk.img file began to grow....odd. Attempt 3 - I used the failing drive from the MyBook enclosure and a healthy target drive both connected to a workstation with an dual core Atom processor and 4 Gb DDR3 RAM over SATA. This workstation has DEFT 8.2 Linux installed to it's hard drive. I only ran this as a short test as not to stress the failing hard drive too much. In this attempt the disk.img file began growing almost immediately after running the Reallymine command. I was able to decrypt at a rate of 1 Gb/1 1/2 Hr. Currently reallymine decrypts by reading 50MB (52428800 bytes) at a time. You can change NumSectorsAtATime in decrypter.go if you want to alter this yourself. I will have to try this in the morning. Thanks for the tip! ;-) If there is any additional info that would help out, please let me know and I will do what I can to help. |
|
I wonder if its having an issue with the processor types or the deft Linux My setup.. Hardware. i7 8 cores with 12 gigs of ram .. Running windows Down loaded the version one of the pre compiled. And decrypted source to how is the rapidspar compared to the ddi4? On Oct 18, 2016 1:28 AM, "FraserCorrance" [email protected] wrote: How long the transfer from the bad one take? It took about 15 hours to clone the 4 Tb failing drive form the MyBook I have made 3 separate attempts using different variables. Attempt 1 - I used the healthy drive that I cloned the data to as the Attempt2 - I used the healthy drive that I cloned the data to as the In both attempt 1 and 2 when I first ran the command in Linux it took Attempt 3 - I used the failing drive from the MyBook enclosure and a Currently reallymine decrypts by reading 50MB (52428800 bytes) at a time. I will have to try this in the morning. Thanks for the tip! ;-) If there is any additional info that would help out, please let me know and — Reply to this email directly, view it on GitHub |
|
Thank you for the feedback. I am going to look into getting Reallymine installed on a different distro of Linux to see if that makes a difference. I will let you know how that works out. As for the RapidSpar vs. DDI4... I did a review of the RS and listed some of my experiences here: http://www.hddoracle.com/viewtopic.php?f=180&t=1742 There is also some other good info here: http://www.hddoracle.com/viewtopic.php?f=180&t=1770 The oracle is great site. ;-) |
|
Give the 1st release a try see if that would help out a little better On Oct 18, 2016 11:07 AM, "FraserCorrance" [email protected] wrote:
|
|
The first one runs at the same rate as the second one. If the first one manages to run faster, I'd be surprised... |
|
Is the decryption of the symwave chip slower than the other chips. Im using
the same setup and the decryption process is about 5gigs per 10hours. Im
working on a terabyte drive....was the speed buffer tweak incorporated into
the main source after all..
Thanks in advance..
…On Oct 18, 2016 10:44 PM, "Pietro Gagliardi" ***@***.***> wrote:
The first release does print progress, yes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQE6xfoIH4e0hGTx64G9hv5tBuiAAjjiks5q1ZICgaJpZM4KZRNK>
.
|
|
It shouldn't be... Are you using the binary or the source? I forget what has the speed tweak and what doesn't. |
|
The binary second release
…On Mar 3, 2017 1:57 PM, "Pietro Gagliardi" ***@***.***> wrote:
It shouldn't be... Are you using the binary or the source? I forget what
has the speed tweak and what doesn't.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQE6xVWeWGS65FTnM5JvBnIv6-DwtTNRks5riHCfgaJpZM4KZRNK>
.
|
|
I don't think this will make anything faster, but I split decryption itself across all CPUs. You can try it on the |
|
Actually disregard the above comment; I'll make this a different issue instead; #38. |
I am having an odd issue with Reallymine and I am not really sure what it is that I am doing wrong here. I have reallymine installed into DEFT Linux (Ubuntu).
First, a bit of back story,...
My client brought in a 4 TB WD digital drive that was "no longer mounting". Looking at the drive's SMART data I noticed that the drive was in not in the best of health. The drive has 14 uncorrectable sectors and the drive's spinup time is 7 seconds. I cloned the entire drive to an identical WD drive that I had in stock. I scanned my target drive and could not see a file system. After calling the client I find out that the drive was from a MyBook enclosure. When the drive stopped mounting the client pulled the drive from the enclosure and threw out the enclosure....d'oh!
Using the healthy drive that I had cloned the failing drive to as the source I ran the following command in Linux:
reallymine decrypt /dev/sda /media/root/Data/clientname/data.img
Due to bad weather and power outages my image process was cut short. After 5 days of letting the program run it had created an 80 Gb image of the target drive. I scanned the image just to see what the data looked like and found that there was some good data but I was still 500 GB short of the amount the amount of data that the client has on this drive so I started the process again. This time I tried running it on a more powerful workstation with dual quad core Xeon processors in hopes that it would speed up the process but found that it was decrypting the drive only a little bit faster than the Core 2 Duo workstation I was using on my first attempt.
From the descriptions that I have read online it seems like this process should be running faster than it is. At the rate I am going this will take weeks.
Any ideas?
The text was updated successfully, but these errors were encountered: