Windows 10: inconsistant restults cloning / migrating Windows10 system HD

My machine is a somewhat dated but reliable Dell T5400, having two quad core intel processors, 8 gig of RAM, and is running Windows-10, 64 bit, and I like to CLONE my system drive for my primary means of backup.

I'm aware of other options, but this is what i prefer to do. Having an externally accessible drive "bay" connected to my SATA-1 and my main HD mounted internally as SATA-0 allows me to fairly easily make clones and remove them from the machine, for storage in a safe place. This way if a HD failure happens I can simply shut down, plug in a clone, turn of SATA-0 in the bios, reboot and be back in business. I've been doing this with all versions of windows since the dawn of 32 bit OS. With windows 10 however, I've had very inconsistent results, with multiple clone programs. I always "test" when the program reports a completion with no problems, by re-booting, turning off SATA-0 in the setup/bios and then restarting. Well sometimes it works, but quite often the boot will result in a black screen with nothing but a lower case "j" appearing, and nothing else. This weird behavior, when it happens, is exactly the same regardless of what I use for the clone process. These include.

1. An old version (2008) of CD based Acronis "Home" using the "Clone Disk" option
2. A much more recent version (12.5) of Acronis Disk Director (also CD based) also using the Clone Disk option
3. The "migrate OS" options of "Minitool partition wizard" (which completes the clone after re-booting
4. Same "Migrate OS" option from the PAID CD-version of Minitool Partition Wizard"

I know there are other tools, but the fact that the problem happens exactly the same (black screen boot, "j") tells me the tools are likely not at fault. Plus, all the above tools allow you to clone from larger to smaller capacity disks or vise-versa, as long as it can verify the target disk has sufficient space. In all but the 3rd item, I am making my clone "offline", meaning I'm booting into a CD, so there's no chance of a "disk in use" issue. (That's why the free version of minitool" needs a re-boot to complete the actual clone work.)

The disks that "fail" to boot as expected always show the "expected" "reserved" partition (usually no letter assigned, just * ). along with the actual system disk. I can verify this by wiping the disk before attempting a clone. Same result. Further checking with various tools show no disk read errors. Where the options exist (such as in "Minitool" versions) I have tried both the option to force partitions to begin on 1Megabyte boundaries (apparently helpful with SSDs) and I've also tried without adding these "unassigned" gaps.

I do know the old version of acronis (1st item) does not let me clone to a 2-terabyte disk, but I'll grant that it is an old tool. The newer acronis (disk director) has no such problem, and yet can produce the same crazy result. Besides, most of my system clones are in the 1-terabyte or 500gig range where there's never been a problem. The only really mysterious clue I have so far is that the last time I cloned and ran into this problem, after about 4 different attempts with different tools and the same result, I tried putting the failed clone on SATA-1 over to SATA-0, and it booted fine. Ah-ha! I thought! So... problem with SATA-1? I don't think so because (a) if the put the former (source) disk on SATA-1 and disable SATA-0 in the bios and boot, no problem there either!!! OK, so bad SATA cable? Nope... the whole process has failed similarly with different cables on different SATA ports. And the most confusing kicker of all is that when I then switch the so-called "failed" clone (the one that booted to a back scree with a "j") back to SATA1, turn off SATA-0 in the bios and boot, NOW IT WORKS!!

You would think something like this would be easy enough to "narrow down", but after having happen (and waste 1/2 a day each time) whenever I decide its "clone" time, I have not figured out any rhyme or sensible reason for what is going one here. I'm thinking whatever is going on here has SOMETHING to do with the need for win-10 to have separate "reserved" and "system" partitions, because this NEVER happened with win-XP clones I've tried on this same machine. And obviously the clone/test process is very time consuming, so its difficult to try 50 variations to try to pinpoint the problematic step, or mysterious resolution after a few swaps of SATA position.

So has ANYONE else had a similar experience and discovered the reason? Anyone else boot into a mysterious "j" on a black screen when testing a clone? Could it be that my Dell BIOS is "remembering" something about a drive that has just been cloned to, and is mistakenly mis-directing the boot process to a wrong area? Maybe multiple power-ups after switching the drives around is causing the BIOS to properly "clear' and re-map the drive layout? Just grasping at straws here!

:)

 

inconsistant restults cloning / migrating Windows10 system HD

My machine is a somewhat dated but reliable Dell T5400, having two quad core intel processors, 8 gig of RAM, and is running Windows-10, 64 bit, and I like to CLONE my system drive for my primary means of backup.

I'm aware of other options, but this is what i prefer to do. Having an externally accessible drive "bay" connected to my SATA-1 and my main HD mounted internally as SATA-0 allows me to fairly easily make clones and remove them from the machine, for storage in a safe place. This way if a HD failure happens I can simply shut down, plug in a clone, turn of SATA-0 in the bios, reboot and be back in business. I've been doing this with all versions of windows since the dawn of 32 bit OS. With windows 10 however, I've had very inconsistent results, with multiple clone programs. I always "test" when the program reports a completion with no problems, by re-booting, turning off SATA-0 in the setup/bios and then restarting. Well sometimes it works, but quite often the boot will result in a black screen with nothing but a lower case "j" appearing, and nothing else. This weird behavior, when it happens, is exactly the same regardless of what I use for the clone process. These include.

1. An old version (2008) of CD based Acronis "Home" using the "Clone Disk" option
2. A much more recent version (12.5) of Acronis Disk Director (also CD based) also using the Clone Disk option
3. The "migrate OS" options of "Minitool partition wizard" (which completes the clone after re-booting
4. Same "Migrate OS" option from the PAID CD-version of Minitool Partition Wizard"

I know there are other tools, but the fact that the problem happens exactly the same (black screen boot, "j") tells me the tools are likely not at fault. Plus, all the above tools allow you to clone from larger to smaller capacity disks or vise-versa, as long as it can verify the target disk has sufficient space. In all but the 3rd item, I am making my clone "offline", meaning I'm booting into a CD, so there's no chance of a "disk in use" issue. (That's why the free version of minitool" needs a re-boot to complete the actual clone work.)

The disks that "fail" to boot as expected always show the "expected" "reserved" partition (usually no letter assigned, just * ). along with the actual system disk. I can verify this by wiping the disk before attempting a clone. Same result. Further checking with various tools show no disk read errors. Where the options exist (such as in "Minitool" versions) I have tried both the option to force partitions to begin on 1Megabyte boundaries (apparently helpful with SSDs) and I've also tried without adding these "unassigned" gaps.

I do know the old version of acronis (1st item) does not let me clone to a 2-terabyte disk, but I'll grant that it is an old tool. The newer acronis (disk director) has no such problem, and yet can produce the same crazy result. Besides, most of my system clones are in the 1-terabyte or 500gig range where there's never been a problem. The only really mysterious clue I have so far is that the last time I cloned and ran into this problem, after about 4 different attempts with different tools and the same result, I tried putting the failed clone on SATA-1 over to SATA-0, and it booted fine. Ah-ha! I thought! So... problem with SATA-1? I don't think so because (a) if the put the former (source) disk on SATA-1 and disable SATA-0 in the bios and boot, no problem there either!!! OK, so bad SATA cable? Nope... the whole process has failed similarly with different cables on different SATA ports. And the most confusing kicker of all is that when I then switch the so-called "failed" clone (the one that booted to a back scree with a "j") back to SATA1, turn off SATA-0 in the bios and boot, NOW IT WORKS!!

You would think something like this would be easy enough to "narrow down", but after having happen (and waste 1/2 a day each time) whenever I decide its "clone" time, I have not figured out any rhyme or sensible reason for what is going one here. I'm thinking whatever is going on here has SOMETHING to do with the need for win-10 to have separate "reserved" and "system" partitions, because this NEVER happened with win-XP clones I've tried on this same machine. And obviously the clone/test process is very time consuming, so its difficult to try 50 variations to try to pinpoint the problematic step, or mysterious resolution after a few swaps of SATA position.

So has ANYONE else had a similar experience and discovered the reason? Anyone else boot into a mysterious "j" on a black screen when testing a clone? Could it be that my Dell BIOS is "remembering" something about a drive that has just been cloned to, and is mistakenly mis-directing the boot process to a wrong area? Maybe multiple power-ups after switching the drives around is causing the BIOS to properly "clear' and re-map the drive layout? Just grasping at straws here!

 

inconsistant restults cloning / migrating Windows10 system HD

Acronis backup software is poorly engineered and supported. I suggest you use Macrium Reflect Free which is much admired by most on this forum. Cloning can result in two disks having the same Disk ID which can cause boot problems if both disks are connected to the PC. For recovery, you are better off imaging your PC to another drive then recovering that image should you have problems.

 

inconsistant restults cloning / migrating Windows10 system HD

OK, being unfamiliar with the "Macrium" product, and hearing that it was used for disk image, I wasn't aware it could also clone. I'll look into it, try it under the same conditions I mentioned, and see what difference there may be. However, the fact that after several times getting the strange failed boot behavior, followed by finding that the clone DID boot properly after re-arranging the physical SATA config told me something else was going on. Was kind of interested in seeing if anyone else had a similar "spooky story" issue with clones.

But regarding "practicality", come on now... that's a matter of opinion. Stick shift cars aren't super practical some would say, but its a reasonable preference that has some advantages.. If I have a suspected total disk failure, booting from a known (meaning VERIFIED) clone has to be faster than rebuilding from an image onto a new HD. And fully verifying a disk image amounts to making clone in the end. Sometimes practicality means treating the machine as a tool. What I mean is, a tool is what I use to do work. If a tool fails while I'm working, I prefer the fastest way to be productive again and continue what i was doing. Sure I backup data regularly with a variety of simpler utilities (including old fashioned batch files!), and with high capacity drives available now I'm not opposed to disk images as well. But for system recovery I prefer the redundancy of a ready to go HD clone. And (call me super paranoid) a similar enough spare machine that windows will let me run my clone in it without complaining about "significantly different hardware" (which at least up to Win-7 was possible.

Anyway I'll look into Macrium, and give it a try!

Question: when you clone with Macrium, does it allow you to clone proportionally when you're cloning between HDs with different capacity? (as long as the target has sufficient storage of course)