Hello -- I have a 1TB   (boot) drive in my system ... I   want to replace it with a 500GB  SSD --   

The data on the 1TB  drive is  less than  200GB -- so can I shrink it to   do a restore on  the 500GB SSD? 

Yes; I've done it several times.  When you boot into the Rescue environment and choose to restore the image onto the disk (or if you have a SATA to USB adapter you can do it as a clone within Windows), the partition map of the source image/disk will appear in the source row.  Select the SSD as the destination, then drag each partition down to the destination row underneath. Finally, select the OS partition in the destination row, click "Cloned partition properties", and set an appropriate size. Reflect even handily includes a Max button if you just want to size it to fill all remaining available space on the destination.

Hello -- Thanks for  the  reply ... 
I used the SSD  example as one t the would be the most common ... I actually want  to restore the OS in a VM and I don't need a 1TB  vdisk ....  So
would I still be able to shrink the image?  

I don't see why not.  Resizing partitions works the same way whether it's an SSD or virtual disk.

Hello  --- This is something  I need to also need to do --  I want to restore a backup image into a vm --- I am not sure where I read this, but  it noted that I can map the virtual  drive to the host (hypervisor)  and have the  reflect in the host to the restore --- would that work the same way to to the shrink?  

In my case the source HD is  over 100g but  less than 20g  is being used ---

Thanks

That should probably be a new topic, but if you just need to run an image as a VM temporarily, then Reflect's viBoot feature is probably a better option if you have a Pro or better version of Windows and therefore have access to Hyper-V.  If you need to restore an image captured from one system into a VM that you will use going forward, there are two general ways to achieve this.  The choice between the two might depend on the capabilities of the hypervisor you're using.  Otherwise, whichever one works easiest for you:

Option #1: Create a virtual disk that you'll use for your VM, and mount it on your host system where you have Reflect installed.  If you're using Hyper-V as your hypervisor, you could just create a new VHDX file using the Disk Management tool.  Open Reflect on your host and restore the desired backup onto that virtual disk.  When that completes, detach the disk from your host and attach it to a VM that you'll need to create.  There's a good chance that the VM will NOT initially boot because it would be expecting to run on whatever system it was captured from, not the virtual hardware present in the VM environment.  In that case, you'd need to boot your VM from a Rescue Media ISO file and run ReDeploy.  Note that ReDeploy is only available as part of paid Reflect licenses, and according to my understanding of Macrium's licensing policy, that means you'd technically need to have either a paid Reflect license for the source PC -- which you can use with the VM only if you'll be permanently migrating from that source PC to this VM -- or else you'd need a paid Reflect license for the VM itself.

Option #2: Create a new VM from scratch, then set up virtual networking between the guest VM and the host PC and connect the guest VM's virtual network interface to the virtual network you've created for this purpose.  Then enable folder sharing for the folder containing the backup you'll be restoring.  Boot the VM from Rescue Media, browse to that network share inside the guest VM, and run the restore that way.  Then run ReDeploy if needed, as noted above.

+x

 

jphughan - 3 July 2019 6:38 PM

That should probably be a new topic, but if you just need to run an image as a VM temporarily, then Reflect's viBoot feature is probably a better option if you have a Pro or better version of Windows and therefore have access to Hyper-V.  If you need to restore an image captured from one system into a VM that you will use going forward, there are two general ways to achieve this.  The choice between the two might depend on the capabilities of the hypervisor you're using.  Otherwise, whichever one works easiest for you:

Option #1: Create a virtual disk that you'll use for your VM, and mount it on your host system where you have Reflect installed.  If you're using Hyper-V as your hypervisor, you could just create a new VHDX file using the Disk Management tool.  Open Reflect on your host and restore the desired backup onto that virtual disk.  When that completes, detach the disk from your host and attach it to a VM that you'll need to create.  There's a good chance that the VM will NOT initially boot because it would be expecting to run on whatever system it was captured from, not the virtual hardware present in the VM environment.  In that case, you'd need to boot your VM from a Rescue Media ISO file and run ReDeploy.  Note that ReDeploy is only available as part of paid Reflect licenses, and according to my understanding of Macrium's licensing policy, that means you'd technically need to have either a paid Reflect license for the source PC -- which you can use with the VM only if you'll be permanently migrating from that source PC to this VM -- or else you'd need a paid Reflect license for the VM itself.

Option #2: Create a new VM from scratch, then set up virtual networking between the guest VM and the host PC and connect the guest VM's virtual network interface to the virtual network you've created for this purpose.  Then enable folder sharing for the folder containing the backup you'll be restoring.  Boot the VM from Rescue Media, browse to that network share inside the guest VM, and run the restore that way.  Then run ReDeploy if needed, as noted above.

Thanks for the info --- I am not a big fan of  drag-n-drop -- I prefer just to use the keyboard ---  I think that the working within the vm makes sense ---  so  do  restore and the target disk 
is  smaller than the source (backup)  image will  reflect ask me if I want to shrink the source for the target?  Thanks

+x

 

Frank Esposito - 3 July 2019 8:56 PM

Thanks for the info --- I am not a big fan of  drag-n-drop -- I prefer just to use the keyboard ---  I think that the working within the vm makes sense ---  so  do  restore and the target disk 
is  smaller than the source (backup)  image will  reflect ask me if I want to shrink the source for the target?  Thanks

No.  If you try to do a restore and the destination is smaller than the source, Reflect will automatically shrink the last partition from the source as much as possible in order to make everything fit on the destination.  That will typically work if the C partition or some other partition with a lot of free space is the final partition on disk and you're ok with all of the necessary shrinkage being taken from the size of that last partition.  If that doesn't allow everything to fit -- which is especially likely if the last partition on disk is a small Recovery partition of some kind -- then you'll get an error that there's insufficient space on the destination.  In that case, dragging and dropping each partition from source to destination and resizing any partition(s) you want to resize before dragging down subsequent partitions is the only way I know of to perform the type of restore you want.

+x

 

jphughan - 3 July 2019 10:14 PM

+x

 

Frank Esposito - 3 July 2019 8:56 PM

Thanks for the info --- I am not a big fan of  drag-n-drop -- I prefer just to use the keyboard ---  I think that the working within the vm makes sense ---  so  do  restore and the target disk 
is  smaller than the source (backup)  image will  reflect ask me if I want to shrink the source for the target?  Thanks

No.  If you try to do a restore and the destination is smaller than the source, Reflect will automatically shrink the last partition from the source as much as possible in order to make everything fit on the destination.  That will typically work if the C partition or some other partition with a lot of free space is the final partition on disk and you're ok with all of the necessary shrinkage being taken from the size of that last partition.  If that doesn't allow everything to fit -- which is especially likely if the last partition on disk is a small Recovery partition of some kind -- then you'll get an error that there's insufficient space on the destination.  In that case, dragging and dropping each partition from source to destination and resizing any partition(s) you want to resize before dragging down subsequent partitions is the only way I know of to perform the type of restore you want.

thanks for the info --- now I  see how the drag-n-drop make sense --- so if the order of the partitions  change I guess that the bios will 
boot to the correct partition --- 

You shouldn’t have to change the sequence of the partitions just because you’re resizing them. If you want to for some reason, then the BIOS should be fine with that, but Windows Boot Manager might not be. In that case, you might need to run Fix Boot Problems. Note that for UEFI systems, there are sequence requirements. The EFI partition should always be immediately before the MSR partition, which should be immediately before the Windows partition. The WinRE (Windows Recovery) partition can be placed either before the EFI partition or immediately after the Windows partition. Then you’d have any additional partitions you might want to create and any recovery/support partitions that might have been created by your system manufacturer if you want to keep those.