Macrium Support Forum

Preparing to restore to a new disk ; is it better to image, or to clone ?

https://forum.macrium.com/Topic40734.aspx

By Clairvaux - 18 October 2020 8:42 PM

I am about to retire my old mechanical disk devoted to data, and replace it with a brand new one. The program Hard Disk Sentinel says this about the existing disk :

There are 3 bad sectors on the disk surface. The contents of these sectors were moved to the spare area.
The drive found 2 bad sectors during its self test.
There is 1 weak sector found on the disk surface. It may be remapped any time in the later use of the disk.

What is the best method to ensure existing problems do not port over to the new disk ? Clone, or image then restore ?

I use a separate system disk, and I already replaced the old mechanical disk devoted to it with an SSD. If memory serves right, I imaged and restored.

[Note : I'm not a new member. I've been using Macrium for years. For some reason, the forum doesn't want to send me email alerts. So I tried repeatedly to reconfirm my email address, but I never receive the activation mail, despite the forum saying it sent it. That's why it says "awaiting activation", and it seems I'm set to wait for ever. That's the email I used to buy Macrium ages ago, and the system recognizes it.]
By capair45 - 18 October 2020 10:32 PM

Here are some thoughts.  If it was me, I would image the disk, and then restore that to the new one but either method should work.

Disk cloning is the process of copying the entire contents of one hard drive to another including all the information that enables you to boot to the operating system from the drive. A cloning program enables you to make a one-to-one copy of one of your computer's hard drives on another hard drive. This second copy of the hard drive is fully operational and can be swapped with the computer's existing hard drive. If you boot to the cloned drive, its data will be identical to the source drive at the time it was created. A cloned drive can be used to replace its source drive in a computer in the event that something bad happens to the original drive.

Disk imaging is the process of making an archival or backup copy of the entire contents of a hard drive. A disk image is a storage file that contains all the data stored on the source hard drive and the necessary information to boot to the operating system. However, the disk image needs to be applied to the hard drive to work. You can't restore a hard drive by placing the disk image files on it; it needs to be opened and installed on the drive with an imaging program. Unlike cloned drives, a single hard drive can store several disk images on it. Disk images can also be stored on optical media and flash drives.

Unless you have a clone ready-made and available for immediate use, you’ll probably be restoring an image to get back to normal. This is because if your hard drive won’t boot, you can’t clone it.
By jphughan - 18 October 2020 11:51 PM

As long as all of the data is still readable, then problematic sectors don't carry over to other drives because the very nature of problematic sectors is that they are specific to the hardware itself.  Copying data from one drive to another won't cause the data to be copied in a way that will inflict damage on the destination.  Even if you had bad sectors where active data resided, then to my knowledge there's no difference in terms of how Reflect handles that situation when reading the source as part of a clone operation vs. an image backup, but Macrium Support might be able to weigh in on that here.

Apart from that potential difference though, there isn't going to be a difference in the end result on the new disk between these two migration methods.  The only differences are in how you get there.  All else being equal, a clone will be faster because you're copying data straight from source to the destination in a single operation.  But it requires you to have the appropriate hardware to have the source and destination devices connected simultaneously, e.g. multiple drive bays/slots or appropriate adapters.  Not everyone has those, especially those with laptop users working with M.2 SSDs, since most laptops only have one M.2 slot for storage and not everyone has M.2 SATA or M.2 NVMe to USB adapters.

By comparison, an image and restore is a two-step process where you "park" your data on a third device, such as an external hard drive or network location.  Essentially, you capture the content of your source disk to a file, and then as a separate process restore the contents of that file to your destination.  That takes longer because you have to write your data to that intermediate location and read from that location to your destination rather than going straight from source to destination.  But if you don't have the type of hardware I described above for a clone operation, then this might be easier overall.  And it has the side benefit of leaving you with a nice backup of your source disk all wrapped up in a single file.
By jphughan - 18 October 2020 11:57 PM

capair45 - 18 October 2020 10:32 PM
...if your hard drive won’t boot, you can’t clone it.

This isn't true.  Rescue Media can be used to clone a drive from an unbootable system.  It IS true that if your system is unbootable and you clone its drive, then the clone target might not be bootable either, but that would also be true if you were to capture an image of the source drive in that state and restore that image onto a new drive.  So cloning vs. imaging isn't a meaningful distinction when dealing with what to do about an unbootable system.  But it seems that the OP is just asking about the best way to go about performing a one-off migration to a new drive, not the best choice for a recurring mechanism of maintaining a data backup going forward.  But for the record, image backups are a far better choice for that purpose than periodically cloning your source disk to another "cold spare" disk.
By Clairvaux - 19 October 2020 12:22 AM

jphughan - 18 October 2020 11:51 PM
As long as all of the data is still readable, then problematic sectors don't carry over to other drives because the very nature of problematic sectors is that they are specific to the hardware itself.  Copying data from one drive to another won't cause the data to be copied in a way that will inflict damage on the destination.  Even if you had bad sectors where active data resided, then to my knowledge there's no difference in terms of how Reflect handles that situation when reading the source as part of a clone operation vs. an image backup, but Macrium Support might be able to weigh in on that here.

Thank you for a very educational explanation.

The problem is, I'm not sure that all the data is readable. I've read a hundred times the help of Hard Disk Sentinel, but I still don't understand fully the  difference between a weak and a bad sector, a bad sector which is still there and another which has been reallocated, etc.

This is "only" a data disk, and it's only slightly damaged (apparently), so the odds are few that an important document of mine could be corrupted. But still, if Macrium Support could advise, it would be helpful.

Also , if I decide to image and restore, as I probably will (my hardware setup would permit me to clone, as well), should I enable the Macrium option of "Ignore bad sectors" ? What would be the consequences, exactly ?
By jphughan - 19 October 2020 1:07 AM

Happy to help! Smile  I'm not sure what a "weak sector" is either.  A reallocated sector means that the original sector was bad, but it was able to get a good read of the data that it stored and then copied that to a "spare sector".  Drives have some amount of spare sectors not counted as part of their total capacity and not directly accessible specifically for this purpose of being used as spares for any "main sectors" that go bad.  After a spare sector is swapped in, the drive firmware marks the original sector as bad and doesn't allow data to be written to it anymore, using the spare sector instead.  So maybe a "weak sector" is one that the drive doesn't think is bad enough to be swapped out with a spare but hasn't fully failed yet either?

Your question about the "Ignore bad sectors" option jogged my memory about a key distinction, although not one between cloning and imaging.  By default, that option is not checked, and thus if you attempt to image a drive that contains bad sectors, the job will fail.  If you want to image the drive anyway, you have to enable that option.  In that case, Reflect will log any bad sectors it finds, but it can't guarantee that it gathered all data from those sectors accurately -- but under a bad sector scenario, that of course might still often be better than nothing, which is what you'd get with a failed job.  I believe -- but am not certain -- that clone jobs work the same way and apply that setting, even though it's in a preferences section called "Advanced Backup Options".  The key distinction though is that if you perform an image backup in the Rescue Media environment, then that option is forced on, with no way to disable it.  I'm not sure why Macrium did that, but I've seen them say that here, and I've confirmed it in my own testing with a dying drive.  And here again, I believe this same behavior applies for clone operations performed in Rescue, but I'm not certain.  In any case, I wouldn't recommend enabling that upfront, and even if you DO have it enabled, then you'd see indications of problem sectors in the log.  If you don't see any actual errors in the log, then Reflect didn't encounter any bad sectors, in which case the setting was moot.  If your scanning tools are checking the entire drive, it's entirely possible that any bad or weak sectors on the drive are not currently storing any meaningful data, in which case a Reflect image/clone may well go off without a hitch, since Reflect only worries about copying data blocks that contain actual data as opposed to scanning the entire partition/disk space (unless you specifically put it into forensic mode to achieve the latter, but there's no reason to do that in this scenario.)
By capair45 - 19 October 2020 2:23 PM

jphughan - 18 October 2020 11:57 PM
capair45 - 18 October 2020 10:32 PM
...if your hard drive won’t boot, you can’t clone it.

This isn't true.  Rescue Media can be used to clone a drive from an unbootable system.  It IS true that if your system is unbootable and you clone its drive, then the clone target might not be bootable either, but that would also be true if you were to capture an image of the source drive in that state and restore that image onto a new drive.  So cloning vs. imaging isn't a meaningful distinction when dealing with what to do about an unbootable system.  But it seems that the OP is just asking about the best way to go about performing a one-off migration to a new drive, not the best choice for a recurring mechanism of maintaining a data backup going forward.  But for the record, image backups are a far better choice for that purpose than periodically cloning your source disk to another "cold spare" disk.

That wording wasn't the best choice I suppose.  If my system was unbootable, I would not attempt to clone the drive for the reasons you mention.  I'd simply restore from an image that had already been taken when the system was in a stable state..
By jphughan - 19 October 2020 2:27 PM

capair45 - 19 October 2020 2:23 PM
That wording wasn't the best choice I suppose.  If my system was unbootable, I would not attempt to clone the drive for the reasons you mention.  I'd simply restore from an image that had already been taken when the system was in a stable state..

Oh ok, yes that makes perfect sense. Smile
By Clairvaux - 19 October 2020 3:24 PM

jphughan - 19 October 2020 1:07 AM
Happy to help! Smile  I'm not sure what a "weak sector" is either.  A reallocated sector means that the original sector was bad, but it was able to get a good read of the data that it stored and then copied that to a "spare sector".  Drives have some amount of spare sectors not counted as part of their total capacity and not directly accessible specifically for this purpose of being used as spares for any "main sectors" that go bad.  After a spare sector is swapped in, the drive firmware marks the original sector as bad and doesn't allow data to be written to it anymore, using the spare sector instead.  So maybe a "weak sector" is one that the drive doesn't think is bad enough to be swapped out with a spare but hasn't fully failed yet either?

Your question about the "Ignore bad sectors" option jogged my memory about a key distinction, although not one between cloning and imaging.  By default, that option is not checked, and thus if you attempt to image a drive that contains bad sectors, the job will fail.  If you want to image the drive anyway, you have to enable that option.  In that case, Reflect will log any bad sectors it finds, but it can't guarantee that it gathered all data from those sectors accurately -- but under a bad sector scenario, that of course might still often be better than nothing, which is what you'd get with a failed job.  I believe -- but am not certain -- that clone jobs work the same way and apply that setting, even though it's in a preferences section called "Advanced Backup Options".  The key distinction though is that if you perform an image backup in the Rescue Media environment, then that option is forced on, with no way to disable it.  I'm not sure why Macrium did that, but I've seen them say that here, and I've confirmed it in my own testing with a dying drive.  And here again, I believe this same behavior applies for clone operations performed in Rescue, but I'm not certain.  In any case, I wouldn't recommend enabling that upfront, and even if you DO have it enabled, then you'd see indications of problem sectors in the log.  If you don't see any actual errors in the log, then Reflect didn't encounter any bad sectors, in which case the setting was moot.  If your scanning tools are checking the entire drive, it's entirely possible that any bad or weak sectors on the drive are not currently storing any meaningful data, in which case a Reflect image/clone may well go off without a hitch, since Reflect only worries about copying data blocks that contain actual data as opposed to scanning the entire partition/disk space (unless you specifically put it into forensic mode to achieve the latter, but there's no reason to do that in this scenario.)

Is a bad sector still a bad sector, to Macrium, once it's been reallocated ?

The help says : if there is a bad sector, you'll get an Error 23. If you can't repair the source disk, you should activate Ignore Bad Sectors. Then, after Restore, run CHKDSK /B on the target disk.

https://knowledgebase.macrium.com/display/KNOW72/Imaging+disks+with+bad+sectors

That's what I did. I'm not sure how the option was during the full and incrementals. I don't think I ever got Error 23.

But CHKDSK /B did correct a few things after restore :

Removing 1 clusters from the Bad Clusters File.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.
By jphughan - 19 October 2020 3:31 PM

A bad sector, which is a hardware issue, is not seen as a bad sector after the drive swaps that sector out for a spare sector, because the drive firmware has performed that swap in the background, transparently to "external" applications -- with the possible exception of vendor tools specifically designed to get a lower-level view of the drive's status and behavior.  But if the drive realized that the original sector was bad but couldn't copy all of the data to the spare sector, then the original sector will no longer be used, but the spare sector might not have all the data either, which can certainly create higher-level issues.

A "cluster" though is a file system concept, not a hardware concept.  I'm less familiar with them though, so I don't want to venture too far out on a branch here.  But my guess is that you may have had a sector on your source drive go bad in a way that didn't allow all of its data to be read, even to be copied to a spare sector.  If so, then the original disk's bad sector itself won't carry over as a result of a Reflect image restore, since that's a hardware issue, but if the sector going bad resulted in some data loss, then Reflect of course can't restore onto the new disk what it wasn't able to back up in the first place from the original disk.  And I would expect that one possible result of restoring incomplete or bad data can create file system issues on the new target.  Again, the bad sector itself doesn't carry over, but the consequences of it can.
By Clairvaux - 20 October 2020 7:17 PM

jphughan - 19 October 2020 3:31 PM
My guess is that you may have had a sector on your source drive go bad in a way that didn't allow all of its data to be read, even to be copied to a spare sector.

That's quite possible, indeed. Thank you.
By Clairvaux - 20 October 2020 10:01 PM

I have now made an extra attempt. My previous restore was a test one. Now I want to retire the old disk, transfer data to the new one, and stop writing to the old disk.

So I tried to make a new image + restore, the last one. Image failed,as it has been doing so often for, I think, years now.

I'm all the more worried since I did that from the Rescue environment (booting from the special Macrium partition), in order to avoid possible VSS problems. Well, it failed, as has been so often the case lately, when I try to do a full as opposed to differentials or incrementals (but those fail, too).

The error message was one I often get :
Backup aborted! - Unable to read from disk - Error Code 1117 - The request could not be performed because of an I/O device error.

But they vary. I get all sorts.

So I tried to clone instead, and it worked. However, it worked too well. It completed in 8 minutes. For 154 GB of data. (And I did not tick the box Ignore Bad Sectors.) Whereas when I cloned my system disk, it took 3 hours and 22 minutes for 148 GB.

So two questions here :

  1. Can that really be the result of Rapid Delta Clone ? My data was already on the target disk, and the differences were likely very small. Does not Macrium verify the result of its work, when cloning ? Just the verifying phase takes a lot of time when imaging. 
  2. Can any hints can be taken from this to troubleshoot my endless imaging failures ? Cloning a disk worked twice (admittedly, this is not very much). This happens inside the computer. Imaging fails very often, in multiple software and hardware situations, but the common point is it happens whith target disks outside of the computer. It happens with incrementals, differentials and fulls (especially with fulls), and it happens with an USB 2 cable, 2 different USB 3 cables and an eSATA cable. It also happens with different disk enclosures (2 different models, and 2 pieces of the same model). The target disks themselves are the same model (there are 2 of them).
By capair45 - 20 October 2020 10:19 PM

See this:  https://knowledgebase.macrium.com/display/KNOW7/Error+Code+1117+IO+error

A "Read" error suggests a problem with the source disk.
By jphughan - 21 October 2020 1:21 AM

My only theory as to why imaging would fail while cloning when using Rapid Delta Clone would succeed is that an RDC clone doesn't require Reflect to read all data on the source disk, only the data that has changed, which it can determine based on analyzing the file system rather than having to compare every individual data block.  So your particular scenario might have allowed for an RDC clone that sidestepped the problem areas on the source disk.

Yes, RDC can drastically reduce cloning time if the destination already has a previous clone state on it.

Verification doesn't apply to cloning.  If that is surprising to you, that might be because you may have an understandable and fairly common misunderstanding about how verification works in image scenarios.  Contrary to some people's expectations, a verification does NOT involve re-reading the source data to verify that it matches what was written into the image backup file.  Instead, it involves reading just the resulting image file to verify that it is fully readable and is not corrupted, the latter of which is determined based on performing a checksum comparison (again, NOT by rechecking the data on the actual source).  Of course if your system is such that you can't write an image backup file to a target without it immediately becoming partially unreadable or corrupt, you've very likely got rather larger issues on your hands.  This is largely why I personally consider verification to be a rather pointless exercise.  For further reading, this post of mine contains links to two other threads that you might find illuminating, one of which has fairly extensive explanations from Macrium themselves.  But in any case, performing this type of verification in a clone scenario wouldn't be possible because unlike an image file, a clone destination doesn't have checksums of all of its data blocks to verify against.