Aller au contenu principal

[Resolved] OS recovery fails with resize / formatting error.

Thread needs solution

I completed a disk level save of a SATA 256GB SSD using Simple boot media (Windows based - UEFI) in ATI 2018. This drive was my C: drive and holds Win 10 OS to the machine. This backup was successful.

I am trying to restore to a SATA 512GB SSD using same boot media. I've tried restoring whole disk at once and also doing one partition at a time. The system reserved and recovery partition restore fine but the data part fails with "formatting // resizing" error, then says archive is corrupt and then the whole recovery fails.

I already formatted my old drive (needed it for another machine).

I'm working on creating win10 media to get into diskpart to try and create partitions manually. If that fails, I've also got some older backups on my NAS I can try. If none of that works I may see if I can just reinstall windows and then just restore the files over that. If all else fails I guess I will be reinstalling Windows from scratch.

I appreciate any suggestions in the meantime. 

0 Users found this helpful

Chris, welcome to these User Forums.

Please see KB 60131: Acronis True Image 2018: how to restore your computer with WinPE-based or WinRE-based media for an overview of the process required here to perform a successful recovery.

Pay particular attention to step 2. in the above document where it says:

Arrange the boot order in BIOS so as to make your rescue media device (CD, DVD or USB stick) the first boot device. See Arranging boot order in BIOS or UEFI BIOS.
If you use an UEFI computer, please pay attention to the boot mode of the bootable media in UEFI BIOS. It is recommended that the boot mode matches the type of the system in the backup. If the backup contains a BIOS system, then boot the bootable media in BIOS mode; if the system is UEFI, then ensure that UEFI mode is set.

You wrote: 'The system reserved and recovery partition restore fine' but also wrote: 'Windows based - UEFI) in ATI 2018' for the context where your backup image was created.

If your computer boots to Windows 10 using UEFI where the BIOS Boot setting is for the 'Windows Boot Manager', then you should have an EFI partition instead of having a Microsoft System Reserved partition, where the latter is used by older, non-UEFI systems booting in Legacy mode and using MBR drives.  If your drive is GPT partitioned then UEFI is required to support this.

En réponse à par truwrikodrorow…

I was thinking it was UEFI based but the backup has the option to restore MBR track 0. 

The partitions in the backup show as:

NTFS (System Reserved) - 500MB

NTFS (unlabeled) - 237.5 GB

Recovery Partition - 476 MB

MBR and Track 0

 

Does that indicate the old drive was actually MBR? On thinking about it I can't recall why I was so set on thinking it was already GPT. Probably a bad assumption based on working on other machines.(oops)

I'll try booting the directions for BIOS mode and see how that goes. 

Well I booted in BIOS mode and tried again. But this time I went into options and selected to validate the archive before doing the restore. 

The validation failed with "Error while checking the metadata integrity of points in time (PITS) in the archive". Then it says "The backup is corrupted, but you can still try to recover data from it".

Does this mean the backup is no good? When I looked through file recovery mode it looked like everything was there.

I have a weekly on my NAS from 8-13-18 I'm going to try. Unfortunately it will take about 8 hours to copy it to my usb drive as the .TIB has my other drive in it as well.

I think during this time I will just reload windows 10 and see how far I get reinstalling things. Not real happy about this, but it is what it is.

Chris, it does sound like you have a Legacy boot system from the partitions information and thus need to boot the rescue media in that mode, not as UEFI.  Hope your further actions are successful.

Chris, I've only seen very few mentions of "Error while checking the metadata integrity of points in time (PITS) in the archive" here in the forums so am not sure of the implications of this?

I would suggest trying to do the recovery at a disk level from that archive and see whether it gives you the same error as for validation?  It seems strange if you can browse through the archive contents without issue.

Just tried recovery in BIOS mode (did not validate this time) and it failed that same as it did originally.

I'm going to try to reinstall windows using windows media and then do file level recovery onto the new partition. If that fails as well, then I will try my week old nas archive. It will take 7 hours to copy to usb drive so I may have to do it over night. Funny enough I started the copy earlier and Acronis Ransomware protection killed the transfer after a while.

If all that fails then I'll just go with fresh windows install.

Thanks for all your help. Absolute worst case at least I learned a lot.

Update! I eventually tried to just reload windows 10 and discovered many errors with that too. Eventually I ended up running Memtest86 (more to rule RAM out to discover anything), but it was hitting thousands of errors. So now after too many hours of chasing rabbits, it's time to do a complete rewind and try and resolve the ram issue.

This machine has been running fine for years, so I am hoping something just came a little loose while I was swapping disks around. So I'll begin procedure to swap / reseat memory tonight. After I get RAM issue resolved I'll start over and post results.

So maybe faulty RAM messed up backup. Or hopefully it was just messing up restore. Murphy's Law at its finest

Chris, thanks for the update.  Hopefully removing and reseating your RAM modules will do the trick but if not, then try just removing a single module and testing.  It is rare for all modules to fail at the same time unless you've suffered a power surge or similar.

I was able to narrow down memtest errors to a single DIMM. (by running test with only 1 stick installed at a time).

The other DIMM tested fine. I retried my first plain-jane, normal disk recovery using the single good DIMM and the recovery completed successfully.

The faulty DIMM also explains all the other inconsistent issues I was experiencing.

So in summary, a stick of RAM failed roughly the same time I installed the new SSD. After removing the faulty RAM, I was able to recover with no problems.

I Murphy'd the hell out of this one. I wanted to blame Acronis so bad for this issue, but after resolving the hardware error, it worked flawlessly. So good job Acronis!

Also, Thanks so much for your assistance Steve!

 

Thanks for the posting of your resolution to the issue you experienced.  It may well help others facing similar issues.