[Resolved] OS recovery fails with resize / formatting error.
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.


- Log in to post comments
In reply to Chris, welcome to these User… by 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.
- Log in to post comments

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.
- Log in to post comments

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.
- Log in to post comments

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.
- Log in to post comments

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.
- Log in to post comments

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
- Log in to post comments

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.
- Log in to post comments

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!
- Log in to post comments

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