I was wrong! On step 3 at 10% it got stuck once more. This time it passed through steps 1 and 2 very quickly and started step 3 so I thought the free space factor was crucial and that with 458 free Gb it would be enough to successfully recover. Then powerd off Ubuntu live booted Macrium rescue media and start recovery process again. this was quite important) to the 2nd partition of the same disk which had 458 Gb free. Using an Ubuntu live distro I boot up and moved the back up file from 1st partition of secondary data disk (by the way, datas were all safe!) which had only 98 Gb free (to recover a 85 Gb image.

I might clone the source disk before I tried using chkdsk.įollowing the clue of 'insufficient space on disk' where backup image was store I tried the following:

You could run chkdsk on the source disk but this could really cause issues. Then attempt the verify and restore on that device. Might suggest using another machine to get data to safe place.ĭo you have another machine and the resources to move both drives to. If not, can you browse this image and see your data? I think it is time to step back and think through possible paths.įirst do you have your data on a separate backup that can be used to restore the personal data? If you can't verify the backup then to me it does not matter the condition of the target. So the disk where you have the image, how much free space is on this drive. As the member made more free space available the faster the task ran. Wasn't on verify but creating differentials. We had a thread last week and one issue was insufficient disk space. In my opinion it should be on an then let the user say I don't need that.Īnd confirming when it hangs you give it time to complete or at least add to progress meter. I'm not sure why Macrium has Verify off in defaults. So if I read posting correctly you cannot verify your image.

Macrium reflect 7 universal restore