In some rare cases, i have experienced SSDs getting slower, right before it started giving out read errors and corrupt data. When it can't read the NAND properly, it tries to re-read it again few times, which result in what looks like slow downs.
So my only chance is to do a sector-level clone of the drive? Do I really need the same SSD (SanDisk U100 256GB) or is a SSD with the same storage but from another brand fine too? After cloning the disk, how may I try to retrieve my files from the encrypted and damaged C: volume ? I've never done this before.
Do you see the label: Embedded Backup Header: Yes Your keys should still be intact... Sadly, the Data written since mount means you might have screwed it up more. You should ALWAYS tick the read only option if you are attempting to mount it to recover data... Finally, have you changed your password at any point ... If so try mounting with older passwords. The password is used to secure the encrypted keys.
Well i'm glad you got there. Now learn some lessons about mixing encryption with data recovery and find a balance. If full encryption is needed ensure you have a good backup plan.
So what to learn from this thread? I've learned that veracrypt is not reliable (anyway it is still unclear to me why the disk did not its job)....a rescue disk should be there to recover (here just to restore the original bootdata) and there should be no backup data on the drive itself for security reasons....(but here it was the only way to get it back)... I mean OP has written a new bootloader and fixmbr does not overwrite the partitions and the drive might have got some errors due to 'tuneup' crap. A potential attacker who could get hands on the drive could have been also able to recover the data...the one would just have to reverse the PW call anything else had been on the drive... Anyway glad that you have got back your data.
I referred to the 'feature' mentioned by Threat: I mean why a separate rescue disk that should hold already what is needed to restore AND a backup of the header (keys etc.) at the end of the drive? A separate disk is safer than 'at the end of the drive'. When the method you have used is the way like the veracrypt software decrypted the data 'at the end of the drive' by entering your PW then it is a security vulnerability to store them there additionally. It is actually the job of the original bootloader, not the software. IMHO the drive should contain NOTHING backup'ed that can be used to restore, it's the job of a separate disk one should take care and keep at another place. Btw: Is the SSD physically damaged or not? I am curious about what really was the reason for your misery and why the disk did not work......you did nothing wrong and if ..then the use of tuning utilities..perhaps Modern SSDs have hardware support for encryption and when I setup'ed Linux I had the choice to encrypt, but I have chosen 'no' this time...
Two retired blocks could mean the SSD is on its way out. Closely monitor that value and, if it increases, get a new drive. Usually, after all reserved spare blocks are used up, the SSD goes into Read-only mode.
After all you have been through and the way you have been treated over there, and even if they say they fixed the problem, Would you really want to use it again
Well I would not have a problem to post over there. If I am more tech savvy I don't know. But what’s fact is that you know more details about the entire process than me and the dev asked you for reply. I can summarize what should be posted there in order to make veracrypt better (not to be ungrateful when posting such things). Fact is that there has been a way to get back your data no matter what has been the reason for the trouble. The rescue disk hasn't offered to you a possibility to restore the original bootloader. It tried to read it three times and could not read it. That is nothing special, though. Your commands you have applied deleted the bootloader. The rescue disk then should have shown ALL possibilities a user still would have. The dev could try to reproduce the issue by applying the same 2 commands bootrec /fixmbr and bootrec /fixboot to a test system and try the rescue disk. I do not think the issue has been due to your two bad blocks, but we do not know if the rescue disk itself has an issue. So the dev could think about a verification of it during creation maybe? And for security reason the drive itself should not contain the data needed to restore on the drive. Instead of the rescue disk should try to restore the original bootloader and if not able because of damaged block there it could append the data ONLY then and point on mounting options. The entire trouble has been because the rescue disk was not made to show what options the user still has to recover. In your case you needed people like Threat who pointed on other possibilities. Short: veracrypt appeared unreliable because the rescue disk did not offer the info needed to restore your data. And it has been possible, though. You could have saved a lot of efforts. Why it could not restore the original bootloader is still strange. People there meant you did not boot from the disk, which was not true. Feel free to use what I have posted over there (if it matches exactly what has happened to you)...if you want to reply there at all. It is clear that you should have made a backup, but to say that "However even the most idiotic computer user knows they should always backup to a separate physical disk, in case of hardware failures. " is not nice. The dev appeared reasonable with his replies, though. Either way what you want to do, I am glad that you were able to get your data back.
The backup of the key vault was implemented in TrueCrypt because they found some other software (Adobe) installed some copy-protection data over the same sector, trashing the key vault. The boot loader was updated to be intelligent enough to detect this, and automatically revert to the backup copy (both encrypted). Just a theory if you store 2 copies, the chances of both been overwritten is low. I don't think VeraCrypt have changed anything in the logic of this area. In the case of the backup rescue CD, there should be no reason it cannot restore the whole boot loader. Not much of a rescue CD if it can't. I think the VeraCrypt developers should spend more time improving this. I guess it depends on the original boot loader still been there (the 3 x read errors are because it's not). It should not depend or assume anything to do with the boot loader or Key Vault is still intact, i.e. worst case scenario. That's what they should take away from this. I don't think your hard drive is faulty, bad blocks happen due to the IC having a fixed number of read/write cycles. When a block fails, it can be remapped to a number of spare blocks - this is designed to allow you time to arrange a replacement. There is only a limited number of spare blocks.
Yes, the SSDs have spare blocks that get remapped by the firmware if an original one is found unreliable and retired. However, due to wear leveling a large percentage of blocks on that disk will be of averagely the same condition. So if the first blocks start to fail, more will possibly follow soon. That's why I recommend to keep an eye on the count. That being said, of course spontaneous failures (power surge/loss) or false positives (firmware glitches) are possible. Thus, YMWV.