Cloning to a smaller destination drive fails in Windows 10 version 2004


Author
Message
Bree
Bree
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 9, Visits: 148
I have seen reports that cloning from a source drive to a destination drive that is smaller, but has sufficient space for the used space of the source drive will fail in 2004, while it works in 1909. I do not have a destination drive available to test this on my 2004 machine with Reflect Home installed, but I can reproduce this in a VM with the current Reflect Free v7.2.4971. A 1909 VM will work while a 2004 VM will fail.

In 2004 if the destination drive is smaller, the clone fails with the error 'Not all copied. Insufficient space'.



The resizing calculations in 2004 seem to be the problem, as manually resizing the destination partition(s) will allow the clone to proceed successfully, as will cloning to a destination drive that is the same size or larger than the source drive.

As I said, this problem only occurs in W10 version 2004, it works successfully in 1909 without any manual intervention.

.



Edited 23 June 2020 9:38 AM by Bree
Nick
Nick
Macrium Representative
Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)Macrium Representative (3.6K reputation)
Group: Administrators
Posts: 2.1K, Visits: 13K
Bree - 23 June 2020 9:35 AM
I have seen reports that cloning from a source drive to a destination drive that is smaller, but has sufficient space for the used space of the source drive will fail in 2004, while it works in 1909. I do not have a destination drive available to test this on my 2004 machine with Reflect Home installed, but I can reproduce this in a VM with the current Reflect Free v7.2.4971. A 1909 VM will work while a 2004 VM will fail.

In 2004 if the destination drive is smaller, the clone fails with the error 'Not all copied. Insufficient space'.



The resizing calculations in 2004 seem to be the problem, as manually resizing the destination partition(s) will allow the clone to proceed successfully, as will cloning to a destination drive that is the same size or larger than the source drive.

As I said, this problem only occurs in W10 version 2004, it works successfully in 1909 without any manual intervention.

.



Thanks for posting. When clicking the 'Copied selected partitions' link, only the last partition is automatically shrunk when copied to the target. The preceding partitions are copied with the same starting and ending offset. If the last partition begins after the end of the target disk or if its resultant location leaves insufficient space to shrink then you'll receive the error you have seen. 

https://knowledgebase.macrium.com/display/KNOW72/Message+Not+all+partitions+copied.+Insufficient+space

Does this explain your situation?

Kind Regards

Nick - Macrium Support

Next Webinar


Bree
Bree
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 9, Visits: 148
Nick - 23 June 2020 12:48 PM
Bree - 23 June 2020 9:35 AM
I have seen reports that cloning from a source drive to a destination drive that is smaller, but has sufficient space for the used space of the source drive will fail in 2004, while it works in 1909. I do not have a destination drive available to test this on my 2004 machine with Reflect Home installed, but I can reproduce this in a VM with the current Reflect Free v7.2.4971. A 1909 VM will work while a 2004 VM will fail.

In 2004 if the destination drive is smaller, the clone fails with the error 'Not all copied. Insufficient space'.



The resizing calculations in 2004 seem to be the problem, as manually resizing the destination partition(s) will allow the clone to proceed successfully, as will cloning to a destination drive that is the same size or larger than the source drive.

As I said, this problem only occurs in W10 version 2004, it works successfully in 1909 without any manual intervention.

.



Thanks for posting. When clicking the 'Copied selected partitions' link, only the last partition is automatically shrunk when copied to the target. The preceding partitions are copied with the same starting and ending offset. If the last partition begins after the end of the target disk or if its resultant location leaves insufficient space to shrink then you'll receive the error you have seen. 

https://knowledgebase.macrium.com/display/KNOW72/Message+Not+all+partitions+copied.+Insufficient+space

Does this explain your situation?
Yes, it does. Thank you.
Armed with that information I can now explain why it worked in a clean install of 909 but failed in clean install of 2004. For 2004 Microsoft have moved the Recovery Partition to be the last partition on the drive, in 1909 the C: partition was the last one.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
Bree - 23 June 2020 2:16 PM
Yes, it does. Thank you.
Armed with that information I can now explain why it worked in a clean install of 909 but failed in clean install of 2004. For 2004 Microsoft have moved the Recovery Partition to be the last partition on the drive, in 1909 the C: partition was the last one.

Yes, that would account for this behavior.  Ever since Windows 7 (or maybe Vista?) where the Recovery partition was introduced, the default position had been for it to be the first partition on disk.  And that did simply cloning to larger or small disks because you would simply shrink/expand the last partition as needed.  And that placement remained the default even on Windows 10.  The problem that arose in Win10 is that newer releases sometimes needed larger Recovery partition sizes, and when the Recovery partition is the first on disk, you can't simply extend it.  So what Microsoft ended up doing is that if you install a Win10 feature update that requires a larger Recovery partition than you have, it will shrink your C partition by the amount needed to create a new, larger Recovery partition.  At that point, your original Recovery partition becomes dead weight.  And going forward, additional expansions can be achieved by just incrementally shrinking your C partition in order to allow the following Recovery partition to expand.  And now finally with Win10 2004, Windows Setup was updated to create the Recovery partition after the C partition in the first place, thereby avoiding the "dead weight" problem.

alQamar
alQamar
Junior Member
Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)
Group: Forum Members
Posts: 39, Visits: 81
@Nick I'Ve encountered the exact same issue when trying to "clone" a HDD to an SSD for the first time using Macrium (latest build) using a Recovery USB stick.
even manually shrinking the C drive so leaving enough space for the system partitions behind, Macrium will not accept this.
There was 5 GB free space after C and 2 partitions after C with a total of ~1,5 GB,

How can we improve this so Macrium can effectively migrate from HDD based backup to restore on a smaller SSD with still sufficient disk space left.
I am aware that competitor products do this easily.
Is it a wrong use or something else?

p.s. did what said in the docs. But missed to drag and drop. Not very intuitive. The wizard should then continue to notice that there is enough space for the 2 partitions after C.
Edited 23 June 2020 7:16 PM by alQamar
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
alQamar - 23 June 2020 7:12 PM
@Nick I'Ve encountered the exact same issue when trying to "clone" a HDD to an SSD for the first time using Macrium (latest build) using a Recovery USB stick.
even manually shrinking the C drive so leaving enough space for the system partitions behind, Macrium will not accept this.
There was 5 GB free space after C and 2 partitions after C with a total of ~1,5 GB,

How can we improve this so Macrium can effectively migrate from HDD based backup to restore on a smaller SSD with still sufficient disk space left.
I am aware that competitor products do this easily.
Is it a wrong use or something else?

p.s. did what said in the docs. But missed to drag and drop. Not very intuitive. The wizard should then continue to notice that there is enough space for the 2 partitions after C.

A while back I created this Wish List thread, which is an aggregation of some of my own requests and those submitted by others throughout the forum (or ideas stemming from issues that others stumbled on).  One of the items in that list, which is an idea of my own is:
  • When cloning/restoring to a smaller destination, if the source contains only the standard BIOS or UEFI Windows partitions, make the default "Copy selected partitions" behavior shrink the OS partition as needed to fit all selected partitions on the destination, even if a Recovery partition exists after the OS partition. This will immediately give users a viable restore/clone setup that is likely to be their desired outcome in this scenario anyway.
For more complex disk setups such as those that might include a user-created Data partition, I don't know if doing this automatically would be feasible, since when cloning to a smaller disk, Reflect has no way of knowing how much capacity you want to trim from each of your partitions.  Same goes for how to allocate capacity when cloning to a larger disk, I guess.  But given that most people's disks will only have the standard set of Windows partitions, I think this would cover a lot of people's use cases.

Edited 23 June 2020 7:33 PM by jphughan
alQamar
alQamar
Junior Member
Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)
Group: Forum Members
Posts: 39, Visits: 81
I can only reinforce that other products sufficiently do this. They give the user a similar view of what were the sizes and what will be the future sizes and graphically (by numbers) adjust the size. In a standard scenario with Windows default partitions this request you named should be sufficient.
Edited 23 June 2020 7:57 PM by alQamar
Bree
Bree
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 9, Visits: 148
@Nick with Windows 10 version 2004 now defaulting to placing the recovery partition after the C: partition this problem is likely to be seen more often. Would it be possible for Macrium to check for the presence of a recovery partition after C: then (if required) shrink C: that little bit more to make room for it?

Edited 26 June 2020 7:27 PM by Bree
alQamar
alQamar
Junior Member
Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)Junior Member (79 reputation)
Group: Forum Members
Posts: 39, Visits: 81
it is also more logical for MS to place the recovery at the end as diskpart / powershell as of today cannot move partitions Smile and yes it would take ages for people with HDDs, which already suffer from slow upgrades anyway. 
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
I'm glad Windows Setup finally defaults to putting the Recovery partition at the end of the disk. Starting with a Recovery partition at the beginning of the disk and later having to create a new one when you installed a feature update that required a larger Recovery partition was nonsense.  And strangely, Microsoft's guidance for manual builds recommended putting the Recovery partition after the Windows partition long before they finally updated Windows Setup to do that for Win10 2004.  But yes, I expect this will increase the frequency of people being caught out by this issue.  (Or maybe it will be somewhat offset by the fact that more and more PCs are moving to SSDs at least for the OS, so there will be fewer HDD to SSD migrations that are likely responsible for most of these migrations from larger source disks to smaller destination disks today.  But even so, it would be nice if Reflect handled this more gracefully. )

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search