Saving a “broken” portable hard drive with a TrueCrypt container
For the theft-safe transfer of personal data, portable applications, ScrapBook database and Archivarius 3000 indices between two stationary points of presence based on the example of Bruce Schneier, SuperFleshka was created - a portable 2.5 '' Toshiba MK2552GSX hard drive in ViPowER VP-352518 case with USB and SATA interfaces with a cryptocontainer inside. However, " trouble came, from where they did not wait! ".
In the clear, at the root of the section lay the TrueCrypt 7.0a distribution and the KeePass Password Safe portable installation of the latest version with a password database. The rest of the space is given under the crypto container in the form of a file. The password for the container is stored in the KeePass database.
Mounts in points of presence - nnCron scriptsby time or by connecting the appropriate USB-drive with autocomplete password entry dialog using nnCron + KeePas s.
One fine day, the Winchester
At first, there was a hope of coping with regular means.
The next time I connected and mounted the cryptocontainer, TrueCrypt first found troubles :
Even if it is prudent to select “No”, Windows will still insert its 5 kopecks:
I must say that scanning the connected cryptocontainer in the presence of bad clusters on the physical disk does not do any good. Unsuccessful experiments with error correction using Windows and the cryptocontainer volume (T) and the underlying hard disk did not fix the problems: the checks hung at a high percentage or even “flied”.
An unsuccessful attempt to copy the unmounted cryptocontainer showed that the problem is deeper - either NTFS is destroyed, or "clusters" fell.
Attempts to copy information using standard tools Winsows ( xcopy in the mode of suppressing error messages) and Total Commander 'a (with the creation of the nnCron script for auto-clicking "OK" in the dialog of an undisclosed message about the inability to read the file issued for each case and not having the "Skip all ») Dragged on. A lot of files were not copied. So, probably bad blocks.
According to common sense, another option of salvation was invented, which is possible with improvised means (and which ultimately led to the successful completion of the mission):
- Copy the file container as a “broken" file to a new safe place.
- Connect the copied container.
- "Cure" him and pull out from him.
To complete the first stage, the plugin for Total Commander ' at "Bad Copy" and Dmitry Sergeev nscopy.exe (Non-Stop Copy v1.04) included in it was selected . More precisely, this plugin is made on its basis. Despite the 2006 year of release and the cessation of development, there seems to be nothing to improve there, the program copes with its tasks very well.
Caution : the container must not be mounted! Otherwise, nscopy will not be able to access it.
So, on one panel - the desired disk with a cryptocontainer ( MyDocs.tc ), opened through the Bad Copy plugin , on the other - a safe place for new storage of the cryptocontainer. F5, Ok- load the file with the plugin (we start the recovery process):
The download dialog appears, but the progress bar does not grow:
It is necessary, because the main nscopy window was launched in parallel and imperceptibly :
2 files were created during the scan: the same file with the cryptocontainer and <with_ same_name> .nsc. The "saved" container from the very beginning of the operation has the same size as the original file - disk space is reserved. So to speak, "to avoid."
NSCopy has a good howto.txt in the distribution, which describes, for example, how:
- batch copy directories;
- integrate into the Explorer context menu.
The readme.txt file details application options. In my case, the following came in handy:
“ Detailing . Each bad section is copied across sectors to the first bad sector, first moving from the beginning of the bad section, then from the end of the bad section in the opposite direction. As a result, at low time, a more accurate picture of the localization of groups of bad sectors is obtained.
Exact detail. The program tries to copy every sector in all bad areas. At the end of this stage, we get a real picture of bad sectors.
Copying bad sectors.The program tries to copy every bad sector, while making several attempts to read in a row. The number of attempts is determined by the option “Attempts to copy a bad sector”. It is on this basis that the program’s ability to copy information from poorly readable sectors is based, since in some cases (for example, an old or poorly recorded CD-R disc) there is a chance that the sector can still be read. ”
NSCopy, among other things, can be controlled from command line
I’ll explain right away why I describe this program in such detail and don’t bring any alternatives.
- The shock of what happened. All thoughts are on recovery. Immediately after the incident - there was no time for perfectionism.
- NSCopy already stood in Total. Like the legacy of the times of the DVD.
- No alternatives were needed - the method worked and everything worked out.
- Googling with post-mortem did not produce results - it was somehow sparse in the market for programs for recovering beaten files from storage media. None of the programs found have passed the stage of critical understanding of the name and evaluation of the version number and release date of the latest extreme version. Not impressed, in short.
("Meanwhile, on the yacht" Trouble "...") At 99% recovery, the picture of damage, in principle, is already almost completely visible. Several single failed clusters and several dense groups. That's when copying the chilling sounds of any IT-shnik when copying the sounds of "Hmm-shch-shch-dzyn !!!".
A few hours of waiting and - finish. And in my case (maybe this is an exception) up to 100% did not reach. I waited a long time and at my own risk I still clicked “Stop”. It didn’t lead to anything fatal, since NSCopy was written quite reliably and steadily - after all, and it’s just sharpened for such an unreliable thing as bad disks. The author in readme.txt himself says - recovery algorithms work sequentially. The farther - the more information will be restored, but it will take more time. Decide for yourself when to stop.
After stopping at 99% Non-Stop Copy, the restored cryptocontainer was copied for reliability unchanged one more time, and then mounted in the usual way. TrueCrypt again detected an invalid shutdown. Now you can safely go to the experiments.
And one more:
And, finally, the check starts:
Restoring by regular means of Windows (including checking for failed clusters) was successful and ended quickly.
Oddly enough, when copying files from a restored cryptocontainer to a freshly created one, all files were read without problems. That is, there are no permanently lost files, although partial damage to the contents is not ruled out.
It seems that this time he got off with a slight fright. From the positive:
- Updated iron "super flash" - now 500 GB instead of 250. Now I will do it regularly. In any case, my nerves are more expensive ~ 1600r. for a new screw every 1-1.5 years.
- He worked out the method of restoring the cryptocontainers pokotsennyh.
- He worked out the migration procedure from one SuperFLASH to another and works in a temporary mode of limited mobility.
- He revealed the “bottlenecks” of his workflow, where mandatory duplication of portable software is needed in order not to fall out of online and out of life / work. For example, an IM client with configured accounts, ScrapBook with work materials, MyLifeOrganized database with tasks / assignments.