Hi
I have been making backups of a 32 Gig SSD for months. I was able to restore them any time I wished. I installed a new distro onto the 32 Gig unit and now I cannot restore any of the prior Disk Images. It errors out with the following error:Destination disk size is too small. Destination disk size is 62511710 sectors (32.0 GB). Source disk size from the image: 62533296 (32.0 GB).
The original images used GPT and the latest one I installed did not (MBR I assume). How can I restore the 32 Gig SSD to be able to restore the images, of which I have many. I really want to know how to fix this. I know I can restore to a bigger drive but that is not what I want to do. Can I use 'dd' or something to get back the original number of sectors?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which version of Clonezilla live did you use?
In the newer version, Clonezilla will wipe both MBR and GPT table before restoring an image, and it might solve your problem.
So, if you can, give Clonezilla live 1.2.12-51 a try.
//NOTE// Back up important data before you use Clonezilla. Just in case.
Steven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven
I tried clonezilla-live-1.2.12-51-i686-pae.iso . Unfortunately it gave me exactly the same error. Keep in mind the drive I am trying to restore to is an SSD. The issue of the drive having lost some 21,586 sectors has concerned me and I am trying to get someone who can explain it to me. The management of SSD's being essentially NAND Memory and not an actual Spinning Platter seems to have some issues when it comes to Total Sector count. They have made some 'Virtual Abstraction' to get the SSD's to mimic Spinning Platter Drives.
When I restored the Disk Image to a 500 Gig Spinning Disk it puts the GPT Duplicate Table info at the very end. Even though the Partitions are shrunk to a smaller overall size it sees the Image as having 976,773,168 sectors (a full 500.1 GB). This means that no matter how much I shrink the partitions, it will not restore to the 32 GB SSD unit.
As such, I believe because of the GPT being used as the Partition Table type (instead of MBR) by my original Distro I will not be able to recover that image or any of the other ones I have made, to the 32 GB SSD drive.
I will Email you directly and forward two photos of the two error situations I have encountered. Thanks…
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven
Well I have solved my problem, as stated herein. I bought a new SSD Drive and it has exactly the same 'total sectors' as the Image that I was having trouble restoring. This is a serious problem, in my opinion, with the restoring capability of Clonezilla to SSDs. I will explain what I mean. Once an SSD starts to reach end of life on some of its NAND memory locations, it will reduce the Total Available Sectors that can be used! This means, at least it did for me, in unrestorable CZ Images.
No one, that I have communicated with, has actually agreed with my hypothesis; but I know it has happened to me. This means, possibly unlike Rotating Spindle Drives, that one cannot count on always having a Fixed Number of Sectors Available over the entire Life Cycle of SSD drives.
Total Disk backups will Refuse to restore and essentially force one to get New Hardware or Larger Capacity units. My original SSD was purchased in February 2010 and has been used extensively. GPT may well be also a factor as it puts a duplicate header entry at the Last Address location, and backwards from that.
I Recommend that some comments might be added to CZ such that users are made aware of this issue. Gauranteed that it will bite others as the stock of SSDs gets more prolific and given there Expected Life Span.
Please Email me if you want more details but I believe this problem is real. Cheers…
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Robert,
Thanks.
"Once an SSD starts to reach end of life on some of its NAND memory locations, it will reduce the Total Available Sectors that can be used! " -> So you are very sure about this?
Actually I have no idea about that…
Steven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven
I have created a bit of a buzz with this one. I posted on the OCZ Forums, as it was an OCZ 32 GB unit and they were shocked, not OCZ staff but forum responders. I have no idea how it happened or why, but it did. I have done a Secure Erase (using hdparm) on it and its total Available Sectors is 62,511,710, new it was 62,533,296. I purchased a new unit (not OCZ but Kingston) and it had exactly 62,533,296 sectors in total. How this occurred and what may have contributed to it is beyond me.
I was able to restore a CZ Image to the new drive without incident. I could not restore to the old one, no matter what I tried. (And I tried everything I could to restore it to factory, without success.) I had to get back my image, so I purchased another one. I cannot say with certainty what exactly went wrong; but some mention of write cycles being exceeded was mentioned on the OCZ forum.
I may never find out the true reason but I have a perfectly working 32 GB OCZ SSD with 0.0345% less Availablle Sectors than it did when it was new. As a usable drive it is still working fine. As a Fixed Sector drive unit it is totally borked. One less sector and CZ freaks, so it was extremely diconcerting to me. If I ever get a better intelligence on what happened I will personally let you know. Thanks for everything Steven…
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven
Update: I was in communication with a Technician at OCZ and was able, with some serious learning curve, to get the Total Available Sectors back to Original Factory Levels. I am pleased to say that I have been able to restore the image that was created previously to the restored 32 GB SSD. :)
It was referred to as a "Firmware Upgrade". I am still trying to get more info on whether it can be done again or if it is a one time fix. If I learn more about this issue I will let you know.
The loss of Sectors was confirmed as valid, given where I was initially. I assume that the algorithm that was being used to limit the number of writes to 'NAND Blocks' must have kicked in. The Firmware upgrade must have convinced it that it could be written to a few more times. They appear reluctant to provide serious details, but I am glad that it has some more life in it.
I must say that I do not have the same confidence I had in SSDs. I do however think that the key problem was the GPT partitioning and its need to put a secondary Header at the very last Sector on the Physical Drive. From my perspective this will, at sometime in the future, come back and bite its designers! Possibly an MBR Partition type may not have manifested as a problem. What do you think about this point?
Have a great day and CZ still rules…
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Robert,
"Possibly an MBR Partition type may not have manifested as a problem. What do you think about this point?" -> Maybe… Actually here I do not have too many experience about SSD.
So did you try MBR type?
Same issue? Or it only exists for GPT on SSD?
Thanks.
Steven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven
I will update you with what has happened. I was able to restore the SSD back to the factory "Available Sectors". I had to contact a Tech at OCZ and obtain the procedure. It was referred to as a Firmware Update but I have since learned that it can be run as any times as needed. I will not go into the actual procedure but it is not for casual users.
Anyway, on the OCZ forums, I was told that it was the first such problem that they had ever heard of. I would not have discovered it if I was not backing and restoring images as often as I do. Something about my specific usage triggered the problem.
In answer to your question, I am not sure if the issue would have occurred if I had been using an MBR Partition Table. Based on what I now believe, it would have happened either way. If CZ will NOT RESTORE to a smaller drive than it was created from then it probably makes no difference. I am unable to replicate this for an MBR because it may never happen again, even if I restore a thousand times.
So in summary if any of your users ever encounter this problem they should consult the SSD drive manufacturer and get the procedure to Restore the Firmware to factory. It could be called something else but it seems that it is Firmware on the SSD that needs resetting.
I am thrilled to have had this experience, now that I know the solution. Hope this is helpful to you in some way and you have a great day…
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Came here from drbl.org/faq "119 When I restored an image to the same, original SSD disk, Clonezilla complained the destination disk is too small. What's wrong?")
Seems there is another, popular reason for this error message:
In disc to local disc beginner mode, I backupped a new 256 GB SSD to an old 500 GB HDD. When I wanted to restore it the same way, Clonezilla complained the destination disc is too small. Looking into GParted, the partition sizes are actually the same, but followed by 250 GB free space on the HDD.
I tried several options in expert mode then, but especially proportional restore lead to wired partition sizes on the SSD. Since 2 partitions are Windows 10 bitlocker in TPM mode, they can't stand resizing.
Hope anyone has an idea to restore this disc as it was before? I know I'm stupid, but there is important data on one of the bitlocker partitions and I have none of the keys, except the TPM.
(I dare to post it here because this is the place the FAQ to this question directs. Feel free to move it or something.)
Last edit: Rasko 2021-12-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you, Steven.
Yes, I did: Option 2 is not possible because of bitlocker. Even when I create identical partitions with GParted and Clonezilla restores "into" these partitions, the Windows Boot Manager says "no mountable partition". Maybe I missed a detail and my partitions aren't 100% identical - but that's too hard for me to find out. Option 1 (-icds + -k1) leads to partitions that only have half of the original size. Seems Clonezilla wants to restore the 250 GB unused space from the backup HDD, although this space never was on the original SSD. But! I now tried Option 1 with only the -icds (without the -k1) parameter, and this worked! So problem solved for me.
👍
1
Last edit: Rasko 2021-12-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I have been making backups of a 32 Gig SSD for months. I was able to restore them any time I wished. I installed a new distro onto the 32 Gig unit and now I cannot restore any of the prior Disk Images. It errors out with the following error:Destination disk size is too small. Destination disk size is 62511710 sectors (32.0 GB). Source disk size from the image: 62533296 (32.0 GB).
The original images used GPT and the latest one I installed did not (MBR I assume). How can I restore the 32 Gig SSD to be able to restore the images, of which I have many. I really want to know how to fix this. I know I can restore to a bigger drive but that is not what I want to do. Can I use 'dd' or something to get back the original number of sectors?
Which version of Clonezilla live did you use?
In the newer version, Clonezilla will wipe both MBR and GPT table before restoring an image, and it might solve your problem.
So, if you can, give Clonezilla live 1.2.12-51 a try.
//NOTE// Back up important data before you use Clonezilla. Just in case.
Steven.
Hi Steven
I tried clonezilla-live-1.2.12-51-i686-pae.iso . Unfortunately it gave me exactly the same error. Keep in mind the drive I am trying to restore to is an SSD. The issue of the drive having lost some 21,586 sectors has concerned me and I am trying to get someone who can explain it to me. The management of SSD's being essentially NAND Memory and not an actual Spinning Platter seems to have some issues when it comes to Total Sector count. They have made some 'Virtual Abstraction' to get the SSD's to mimic Spinning Platter Drives.
When I restored the Disk Image to a 500 Gig Spinning Disk it puts the GPT Duplicate Table info at the very end. Even though the Partitions are shrunk to a smaller overall size it sees the Image as having 976,773,168 sectors (a full 500.1 GB). This means that no matter how much I shrink the partitions, it will not restore to the 32 GB SSD unit.
As such, I believe because of the GPT being used as the Partition Table type (instead of MBR) by my original Distro I will not be able to recover that image or any of the other ones I have made, to the 32 GB SSD drive.
I will Email you directly and forward two photos of the two error situations I have encountered. Thanks…
Robert
Hi Steven
Well I have solved my problem, as stated herein. I bought a new SSD Drive and it has exactly the same 'total sectors' as the Image that I was having trouble restoring. This is a serious problem, in my opinion, with the restoring capability of Clonezilla to SSDs. I will explain what I mean. Once an SSD starts to reach end of life on some of its NAND memory locations, it will reduce the Total Available Sectors that can be used! This means, at least it did for me, in unrestorable CZ Images.
No one, that I have communicated with, has actually agreed with my hypothesis; but I know it has happened to me. This means, possibly unlike Rotating Spindle Drives, that one cannot count on always having a Fixed Number of Sectors Available over the entire Life Cycle of SSD drives.
Total Disk backups will Refuse to restore and essentially force one to get New Hardware or Larger Capacity units. My original SSD was purchased in February 2010 and has been used extensively. GPT may well be also a factor as it puts a duplicate header entry at the Last Address location, and backwards from that.
I Recommend that some comments might be added to CZ such that users are made aware of this issue. Gauranteed that it will bite others as the stock of SSDs gets more prolific and given there Expected Life Span.
Please Email me if you want more details but I believe this problem is real. Cheers…
Robert
Robert,
Thanks.
"Once an SSD starts to reach end of life on some of its NAND memory locations, it will reduce the Total Available Sectors that can be used! " -> So you are very sure about this?
Actually I have no idea about that…
Steven.
Hi Steven
I have created a bit of a buzz with this one. I posted on the OCZ Forums, as it was an OCZ 32 GB unit and they were shocked, not OCZ staff but forum responders. I have no idea how it happened or why, but it did. I have done a Secure Erase (using hdparm) on it and its total Available Sectors is 62,511,710, new it was 62,533,296. I purchased a new unit (not OCZ but Kingston) and it had exactly 62,533,296 sectors in total. How this occurred and what may have contributed to it is beyond me.
I was able to restore a CZ Image to the new drive without incident. I could not restore to the old one, no matter what I tried. (And I tried everything I could to restore it to factory, without success.) I had to get back my image, so I purchased another one. I cannot say with certainty what exactly went wrong; but some mention of write cycles being exceeded was mentioned on the OCZ forum.
I may never find out the true reason but I have a perfectly working 32 GB OCZ SSD with 0.0345% less Availablle Sectors than it did when it was new. As a usable drive it is still working fine. As a Fixed Sector drive unit it is totally borked. One less sector and CZ freaks, so it was extremely diconcerting to me. If I ever get a better intelligence on what happened I will personally let you know. Thanks for everything Steven…
Robert
Robert,
Thanks. Please keep me posted when you find anything new.
Steven.
Hi Steven
Update: I was in communication with a Technician at OCZ and was able, with some serious learning curve, to get the Total Available Sectors back to Original Factory Levels. I am pleased to say that I have been able to restore the image that was created previously to the restored 32 GB SSD. :)
It was referred to as a "Firmware Upgrade". I am still trying to get more info on whether it can be done again or if it is a one time fix. If I learn more about this issue I will let you know.
The loss of Sectors was confirmed as valid, given where I was initially. I assume that the algorithm that was being used to limit the number of writes to 'NAND Blocks' must have kicked in. The Firmware upgrade must have convinced it that it could be written to a few more times. They appear reluctant to provide serious details, but I am glad that it has some more life in it.
I must say that I do not have the same confidence I had in SSDs. I do however think that the key problem was the GPT partitioning and its need to put a secondary Header at the very last Sector on the Physical Drive. From my perspective this will, at sometime in the future, come back and bite its designers! Possibly an MBR Partition type may not have manifested as a problem. What do you think about this point?
Have a great day and CZ still rules…
Robert
Hi Robert,
"Possibly an MBR Partition type may not have manifested as a problem. What do you think about this point?" -> Maybe… Actually here I do not have too many experience about SSD.
So did you try MBR type?
Same issue? Or it only exists for GPT on SSD?
Thanks.
Steven.
Hi Steven
I will update you with what has happened. I was able to restore the SSD back to the factory "Available Sectors". I had to contact a Tech at OCZ and obtain the procedure. It was referred to as a Firmware Update but I have since learned that it can be run as any times as needed. I will not go into the actual procedure but it is not for casual users.
Anyway, on the OCZ forums, I was told that it was the first such problem that they had ever heard of. I would not have discovered it if I was not backing and restoring images as often as I do. Something about my specific usage triggered the problem.
In answer to your question, I am not sure if the issue would have occurred if I had been using an MBR Partition Table. Based on what I now believe, it would have happened either way. If CZ will NOT RESTORE to a smaller drive than it was created from then it probably makes no difference. I am unable to replicate this for an MBR because it may never happen again, even if I restore a thousand times.
So in summary if any of your users ever encounter this problem they should consult the SSD drive manufacturer and get the procedure to Restore the Firmware to factory. It could be called something else but it seems that it is Firmware on the SSD that needs resetting.
I am thrilled to have had this experience, now that I know the solution. Hope this is helpful to you in some way and you have a great day…
Robert
Hi Robert,
Got it. Thanks for sharing the important info.
Steven.
Steven
You are very welcome:)
Cheers…
Robert
(Came here from drbl.org/faq "119 When I restored an image to the same, original SSD disk, Clonezilla complained the destination disk is too small. What's wrong?")
Seems there is another, popular reason for this error message:
In disc to local disc beginner mode, I backupped a new 256 GB SSD to an old 500 GB HDD. When I wanted to restore it the same way, Clonezilla complained the destination disc is too small. Looking into GParted, the partition sizes are actually the same, but followed by 250 GB free space on the HDD.
I tried several options in expert mode then, but especially proportional restore lead to wired partition sizes on the SSD. Since 2 partitions are Windows 10 bitlocker in TPM mode, they can't stand resizing.
Hope anyone has an idea to restore this disc as it was before? I know I'm stupid, but there is important data on one of the bitlocker partitions and I have none of the keys, except the TPM.
(I dare to post it here because this is the place the FAQ to this question directs. Feel free to move it or something.)
Last edit: Rasko 2021-12-04
So you have tried the methods mentioned here?
https://drbl.org/faq/fine-print.php?path=./2_System/119_larger_to_smaller_disk_restore_clone.faq#119_larger_to_smaller_disk_restore_clone.faq
Steven
Thank you, Steven.
Yes, I did:
Option 2 is not possible because of bitlocker. Even when I create identical partitions with GParted and Clonezilla restores "into" these partitions, the Windows Boot Manager says "no mountable partition". Maybe I missed a detail and my partitions aren't 100% identical - but that's too hard for me to find out.
Option 1 (-icds + -k1) leads to partitions that only have half of the original size. Seems Clonezilla wants to restore the 250 GB unused space from the backup HDD, although this space never was on the original SSD.
But! I now tried Option 1 with only the -icds (without the -k1) parameter, and this worked! So problem solved for me.
Last edit: Rasko 2021-12-05