Partition Resize during Restore

[ronk]

Terabyte 3.37 Suite,boot to USB IFW. Window 10 build 19041, Thinkpad T530 with SSD internal, SSD in Caddy.

1)Wondering why IFW failed on restore from smaller to larger partition. Always use 'Manual' restore option.

Recently converted caddy HDD to SSD. Had several partitions all backed up with IFW earlier to USB external drive, which were to be expanded with SSD. Used Windows to created Basic Disc on SSD,with the desired larger sizes with Windows, then booted to USB IFW, and began restoring, with resizing occurring at the end of the restore. I had entered a 'new size' slightly less than the target partition. Worked fine for the first smaller (~100gb)partitions, and a couple of the extended partitions. But the last, largest 250gb partition failed during the resizing with File System error, red progress bar, and warning to check file system. Upon booting Windows, found that all earlier extended partitions were back to 'unallocated' as if the restore never happened. So had to redo those, and that last partition, gave up, and 'copied' all files (in batches, since memory exceeded otherwise) from HDD (sata to usb-b cable) to the SSD recreated extended partition that failed with IFW.There were no errors during the Restore itself.

Did I use the wrong parameters or procedure to accomplish this? The experience has slipped my confidence in restores of differing size partitions. Also,particularly worrisome is the loss of earlier successfully restored extended partitions after the failed on. I usually do restores to partition sizes identical on image and target which has never failed me in nearly a decade with Terabyte.

Global parameters attached, as well as the

2)Can on resize down or 'shrink' a partition, or is that illogical since it is an 'image'? That is, can I restore from an IFW image to a smaller partition when the partition imaged has a lot of 'freespace, or must this be done within the Windows environment?

[TeraByte Support]

The error code would give a reason, and most likely because something in the file system is dirty so it will refuse to resize to prevent any potential data loss. chkdsk /f it, then resize again separately.

[ronk]

Thanks for the response,

I believe I used the term 'partition' incorrectly in my OP; I should be referring to 'volumes' or 'logical drives' within the 'extended partition.

Your response didn't answer fully my question. Why did the failed IFW (USB boot) from external USB restore wipe out 2 previously restored volumes in the extended partition which had just been restored earlier (not the same IFW session). Terabyte software has never done that to me before. I recovered those 2 volumes by re-restoring them again, and then doing file copies within Windows10 to create the 3rd large volume.

As to system integrity and the file system error, both Windows 10 (chkdsk /scan) and Samsung Magician quick scan, found no errors on the target SSD. I didn't do the chkdsk /f because it would run hours, I think. Regrettably, I didn't see the error code, if one appeared. Coincidently or not, the failed restore was the largest I have ever attempted; 170gb min and limit of 250gb.

I suspect the answer is yes, but my second question which wasn't answered was if one can 'shrink' volumes as long as the new volume is larger than the 'min' size specified. How is the 'min' determined for a 'image', is there an end of data marker?

Ron

[CyberSimian]

ronk wrote:
> I didn't do the chkdsk /f because it would run hours, I think.

I routinely perform a "chkdsk /f /v" on a 100GB partition on a slow and nearly full laptop disk, and it takes only 10-15 minutes.

The action which takes a long time is "chkdsk /r", which (I think) reads and writes every single block on the disk in order to locate faulty blocks. The /r action implies moving existing data to a different location on the disk, as well as writing and reading blocks that are currently unused.

-- from CyberSimian in the UK

[ronk]

Thank you CyberSimian for the information. Yes, I did read that chkdsk /r isn't even recommended on an SSD because it could cause unnecessary wear on the device. Supposedly SSD's are self correcting. This is a 2TB SSD, but would likely run chkdsk /f only on a 300gb logical drive. Will post the results and time to do so.

Edit:update
Couldn't run chkdsk /f, seemed instead to merely run a /scan in seconds. Had dismounted the drive in diskmgmt before hand, but still indicated drive in use. Found no errors in the scan. But couldn't get chkdsk /f to run.

Windows has scanned the file system and found no problems.
No further action is required.

313343999 KB total disk space.
154939604 KB in 7143 files.
2036 KB in 144 indexes.
0 KB in bad sectors.
87035 KB in use by the system.
65536 KB occupied by the log file.
158315324 KB available on disk.

4096 bytes in each allocation unit.
78335999 total allocation units on disk.
39578831 allocation units available on disk.
Total duration: 254.44 milliseconds (254 ms).

Ron

[Brian K]

Ron,

Does this work....

chkdsk /scan

Or is that what you did?

[TeraByte Support]

you would only need to chkdsk /f the source or restore without resizing the target and then afterwards resize. The resize error code would mean something as well.

[ronk]

Brian K wrote:
> Ron,
>
> Does this work....
>
> chkdsk /scan
>
> Or is that what you did?

I entered chkdsk /f, but essentially, it would only do the chkdsk /scan, per the results, because within Windows 10, at the admin command prompt, the dismount was perhaps not complete,....not sure on that. However, I am now running live with the SSD, and no issues found. My only concern with IFW for future usage, is not knowing why all other volumes on the extended volume became unallocated space after running into the resize issue. I will have to leave this rest for now, because, as noted earlier, I instead copied (with usb to sata cable) all 150gb or so data in to the target SSD 300gb target volume from the HDD. I then used IFW to image that 300gb volume w/o any issue.

Next time this situation arises, will be sure to capture any errors. I believe this was my first failure encountered during a restore. Is there a log produced anywhere?

Happy and Prosperous New Year to Terabyte Support.

Ron