Why Always Clone First?

Modified on Fri, May 19, 2023 at 1:15 PM

Before I get into it, let me define a few words as I use them, so that there is no confusion:


Drive copy - file or partition level copy from one drive to another
Drive clone - sector-by-sector copy of a drive from one physical drive to another
Drive image - sector-by-sector copy of a drive from one physical drive to a file


The short answer to the main quesion, "Why always clone first?", is because it is safer. But, I'm sure that you were hoping for a better explanation than that. To answer it, let me first start with a short story.

Many years ago I had a reseller send me a drive for data recovery. When he first received the laptop containing the hard drive, the customer was having issues with Windows.  So, the tech removed the hard drive and ran a full test which reported that it had bad sectors.  After that, he did a full scan of the drive with a data recovery program to reconstruct the file system.  Now, a couple days into it, he selects the files and folders his client wants recovered and the drive stopped responding.  This is when he stopped and brought it into my lab for us to assess it.
Our first step was to inspect it in our clean room only to discover that the drive had suffered a fatal head crash with rings etched into the platters and debris everywhere.  Unfortunately, this drive was no longer recoverable and the customer lost 100% of his data. This data loss was 100% preventable, had the technician approached the situation differently.
In his first step to test the drive, the technician read every sector once, yet did not copy a single sector to another drive
In his second step to scan the drive with data recovery software, he again read every sector on the drive a second time, yet did not copy a single sector to another drive
In his third step to save the files out, it was too late
When we receive a drive for recovery, whether it be because the drive has phsyical issues or when the customer says the drive is healthy and they just want to recover a lost file, we always, always, always start by cloning/imaging the drive (after necessary phsyical assessments are done in the clean room, of course). When cloning a drive we are essentially testing every sector of the drive while making a backup copy of every sector we have read.  So, when the clone is done, if a file system recovery is still needed on the copy, we are doing so on a known good drive, without risk of making things worse.

But what about healthy drives? Why do we waste time cloning them?


Well, it comes down to being safe and not making any assumptions. At least 75% of the time, "healthy" drives are found to not be as healthy as the customer thought. So, we don't want to be victims of the scenario previously mentioned.  It is better to play it safe.


What if the drive is large and the volume of files to be recovered is small? Isn't it less taxing on the drive to just get the targeted data?


This is one of those, Yes & No, answers.  Yes, it can be less taxing if done right, yet it can be extremely taxing if done wrong. Let me break that down for you, starting with the no.


No, when you directly read a drive, the heads bounce all over the place going back and forth between the file table and the locations where the file sectors are stored. Not only are you increasing the wear on the heads, it requires you to constantly re-read sectors in the file table. If the drive is unstable, one might be lucky and get 100MB/sec transfer rates, but usually are stuck at speeds under 5MB/sec.


Yes, if your file recovery software is connected with background drive cloning/imaging. All data recovery professionals use special data recovery hardware/software combination to give them even more control of the patient drive while having the ability to image sectors from targeted files in a linear process.  Basically, they select the sectors that they want to copy and the drive will only copy those sectors in order, skipping the sectors that they haven't selected. Not only does this proecess prevent the need to constantly re-read sectors from the patient drive, it tends to be a lot faster.  What the previous method would do in days could be done in hours this way.


Not so fast! What about really large RAID arrays that could contain dozens of drives and hundreds of TB of storage?


In my opinion, while it requires a lot of storage and time, it is even more essential to clone every drive of a RAID for data recovery. I just recently assessed a 36 x 10TB RAID where the customer reported only 2 drives offline. Yet, as part of our assessment process, there were less than 10 drives that were not in some sort of state of early failure.  The chances that another drive fails before the recovery completed is staggering. We have found that the two most common reasons for unrecvoerable RAIDs are physical failure beyond recovery which is far less common than irreversible data loss from previous recovery attempts on the original drives.


But, what about unstable drives? What is so great about cloning/imaging?


This really depends on the quality of software and hardware being used to do the job. With the help of data recovery hardware, we have the added luxury of being able to control the drive's power and resets, meaning that when a drive goes unresponsive, we can give it a little nudge to snap out of it. The key featues with the software is our ability to control how long to fight with a sector read, what to do when we are unable to read a sector (stop & power off, skip a block, jump to another head, try again and so forth) and to work with multiple passes, so that we get the more easily read sectors copied before we put too much effort reading those which may not be read or bad enough to kill the heads.


So, what is available for you to clone a drive with a log and multiple passes?

Multiple pass cloning software
File system recovery software with multiple pass imaging taskss
Data recovery cloning hardware
DeepSpar USB stabilizer + windows software of your choice (comes with R-Studio Technician)

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article