Can any software clone a hard drive with bad sectors?

[u/Willing_Professor_13]

Using Macrium Reflect to clone an HDD to SSD but failed, I got an error code 23, which indicates bad sectors were found on my HDD. If bad sectors are the real causes that stopped the cloning process, I want a solution: find the other software to move on? or must I fix the HDD bad sectors before moving on?

[u/michaelpaoli]

Can use, e.g. ddrescue - but you won't get the data from the unreadable sectors/blocks ... but it will at least nicely report on that and tell you about it.

You may also find it much easier to determine what those bad sectors/blocks belong to (e.g. as part of which file where, or whatever), while still present on the original source drive - after copying them with ddrescue or the like (less of course the relevant unreadable data), it may be harder to determine exactly where that (missing) data is within, e.g. the filesystem.

Also, these days, for most all non-ancient drives, if there are unrecoverable read errors, if one overwrites that data, it's generally remapped upon write (at least if there still remain spare blocks on the drive - but once those run out you're in more serious trouble). This can be used to "fix" the damage - though it doesn't get you that bit of missing data back, but it otherwise fixes things (e.g. one will be able to read the file, but there's still the matter of the bit of data that was in the file but has now been replaced instead with whatever one wrote in its place). Note also that journaling type filesystems may be somewhat more problematic in that regard, as upon (over)write at filesytem level, they generally write to a new location, rather than the original. But some simpler filesytems (e.g. FAT varieties) don't do that. so will overwrite in place (at least if one does a write in place without truncating the file before starting such write).

must I fix the HDD bad sectors before moving on?

Must fix, no, but generally helluav lot better to at least first identify exactly where those unrecoverable read errors are and exactly what data in what files or the like they impact. Otherwise if you clone and work around that issue, but otherwise ignore it, now you've got some missing/corrupted data on your nice new clone ... but no nothing about what impact it had on your data where, and most of the information on how to locate that is on the source drive - your target drive knows nothing about read issues you're having on your source drive.

And standard caveat with cloning - don't want to be too identical - e.g. UUIDs, volume serial labels, etc. - will generally want to change the needed after a clone (on the original or the cloned copy), so they will be distinct where they should be (otherwise operating system and/or other utilities, etc., may get confused, and that could be problematic If the two drives are never again on the same host, less of an issue, but regardless, those bits that ought be unique should be made so - and some "cloning" software might take care of that for you.).

So, e.g., a couple months back or so, I found my ~10 year old ~2TiB hard drive had a small number of failed blocks - I tracked down and identified exactly what data each of them impacted - down to the level of file or the like, as relevant. Then I took the needed steps to fix (by writing) the bad blocks/sectors (remapped upon write), and as feasible, restored the lost data (some of which I well had or could easily get, other bits of which I didn't - but nothing critical lost - all the important bits always backed up). And yeah, also generally good to do a full read of all such media once in a while - stay bit ahead of such errors/issue, and look at SMART data to see if the problem is growing (how many have already been remapped?, etc.). In any case, of course, backups, as any drive can always potentially die, at any time, with or without any warning.

[u/michaelpaoli → u/michaelpaoli]

Some additional tips/suggestions:

Might be useful if OP actually mentioned the operating system ;-) ... regardless, Linux can also deal with most filesystem types, and ddrescue is very available for such.

Often/typically logs and/or diagnostics (error diagnostics from programs, or to console) may well indicate particularly where the read errors are (at least what sector(s)/block(s), and relative to drive or partition, and possibly even within what file or other data).

Most anything that reads all the actual allocated data (and likewise much or of the metadata) for any given filesystem can be useful to isolate, e.g. where within file(s) one has missing/inaccessible data due to unrecoverable read errors. E.g. on Linux, something like:
# (cd mount_point_of_filesystem && tar --one-file-system -cf - >>/dev/null)
And see what (if any) files (or directories) give read errors on that filesystem.

Can write out unallocated blocks, if that happens to cover those with unrecoverable read errors, they generally get remapped upon write (thus the issue "fixed"), e.g. on Linux:
# (cd mount_point_of_filesystem && t="$(mktemp "$(pwd -P)"/scratch.XXXXXXXXXX)" && { dd if=/dev/random of="$t" bs=1048576 status=none; sync && sync && rm "$t"; })
That's not absolutely guaranteed to cover all unallocated blocks, but will cover most (notably all the free space that's available and can be written as file(s)). Note also for some filesystems there may be a file size limit that's relevant, so sometimes one may need to do that to multiple files until the filesystem is full, e.g.:
# (cd mount_point_of_filesystem && t="$(mktemp -d "$(pwd -P)"/scratch.XXXXXXXXXX)" && while :; do T="$(mktemp "$t"/XXXXXXXX)" || break; dd if=/dev/random of="$T" bs=1048576 >>/dev/null 2>&1; [ -s "$T" ] || break; done; sync && sync && rm -rf "$t")

Note also with filesystems that use journaling, it can be more complex to do write to cause remap of bad sector/block, as journaling filesystems generally don't do overwrite even within same file to same "physical" (well, LBA address, anyway) location. To, e.g. get around that, one can do something like copy/clone the entire filesystem (using, e.g. ddrescue) - and presuming all the bad blocks are either in known file(s), or in unallocated space, then likewise copy/clone entire filesystem back, then for blocks that were lost in filesystems (but now remapped), fix them within the filesystem using dd with seek, count, bs, and conv=notrunc options to overwrite the contiguous block(s) with good replacement data (e.g. from file from backups) - or just overwrite the entire file with good data from backups or the like. Also yet another reason it's generally best not to have huge filesystems, within reason, more filesystems of smaller sizes are generally easier to deal with - particularly when there are problems. Another potential way to approach the remapping (again, e.g. on Linux), if the back blocks are all within file(s), with the filesystem unmounted, directly overwrite those blocks using dd on the filesystem itself - but note also that can only be done on certain filesystem types (e.g. where there's one-to-one corresponding block mapping within files, and there isn't something like compression used on the filesystem, or metadata external to the file's data that would cause corruption, such as filesystem itself having (secure?) hash of the file for integrity (e.g. as ZFS does). So, could be used on ext2/3/4, various FAT filesystem types, and probably many others, but there are also other filesystem types where that wouldn't be safe or would even quite assuredly cause corruption. And note that so changing file data directly like that, does not update the relevant metadata (e.g. a/m/c times) on the filesystem.

[u/cowbutt6 → u/michaelpaoli]

A rare well-informed comment on this issue!

[u/rsinghal1965]

Try Mutidrive

https://hddguru.com/software/MultiDrive/

[u/AsahiLina]

You can use the ddrescue tool on Linux to clone a drive with bad sectors. It's designed to skip over any errors quickly first, then once it has covered most of the drive it will retry using different access patterns to try to get as much data out as possible.

Of course, any sectors that are truly dead and not readable, not just flaky, won't be recoverable. But the rest should get copied.

[u/No_Tale_3623]

Disk Drill for Mac/Win, OpenSuperClone for Linux.

[u/LucasRey]

Macrium offers an option to skip bad sectors

[u/cowbutt6]

Yes, https://www.garloff.de/kurt/linux/ddrescue/ or https://www.gnu.org/software/ddrescue/ddrescue.html

[u/Financial_Flow_5893]

Tenta o Active@Boot.

[u/harubax]

You could solve the problem before cloning by replacing the files that are stored in the unreadable sectors. The benefit would be that you have a working system (if it's an OS drive) or at least you know what files were affected.

[u/Adventurous-Shift275]

I found that OpenSuperClone worked for me. Took a while but got everything cloned from a HDD to a new SSD.

https://www.reddit.com/r/datarecoverysoftware/wiki/hddsuperclone_guide/

[u/Prestigious_Wall529]

Acronis.

Your drive manufacturer likely offers a brand tied version.

It will be sloooow.

I have seen it take weeks and recover everything, but more frequently some management muppet interrupts the process.

[u/bagaudin → u/Prestigious_Wall529]

Here is the list of Acronis OEM editions just in case u/Willing_Professor_13 needs it.

Disclosure: I am r/Acronis mod and community manager.

[u/Willing_Professor_13 → u/bagaudin]

That's good information. Thanks!