Anamnesis
For the theft of personal data, portable-applications, ScrapBook database and Archivarius 3000 indexes between two fixed points of presence, the SuperFlash was created, a portable 2.5 "Toshiba MK2552GSX hard drive in the ViPowER VP-352518 with USB and SATA interfaces with cryptocontainer inside. However, "
trouble came, from where it was not expected! ".
In open form, in the root of the section were the distribution kit
TrueCrypt 7.0a and the portable installation
KeePass Password Safe of the latest version with a password database. All the rest of the place is given under the
crypto-container in the form of a file. The container password is stored in the KeePass database.
Submounting at the points of presence - by
nnCron scripts by time or by connecting the corresponding USB-drive with auto-
filling of the password input dialog using the
nnCron + KeePas s
connection .
')
In one non-red day, the hard drive
ordered began to give the order for a long life. Reading errors, freezes, chilling sounds of the heads of the hard drive and other "charms". After the crypto-container was unmounted, the disk as a USB drive did not want to be unmounted voluntarily. There would be to show respect for the opinion of the piece of iron, to subdue pride and reboot, but ... We are all strong in our back mind ... The disk was removed "on hot." And in vain.
Diagnostics
At first, there was a hope to cope with regular means.
The next time you connect and mount the cryptocontainer,
TrueCrypt first discovered the trouble:

Even if it is prudent to choose "No", Windows will still insert its 5 kopecks:

At once I will say that scanning a connected cryptocontainer in the presence of failed clusters on a physical disk does not bear any benefit. Unsuccessful experiments with error correction by means of Windows and the cryptocontainer volume (T), and the basic hard disk did not eliminate the problems: the checks were stuck at a high percentage or even “flew off”.
An unsuccessful attempt to copy an unmounted cryptocontainer showed that the problem was deeper - either NTFS was destroyed, or “clusters” fell down.
Symptomatic treatment
Attempts to copy information using Winsows 'regular tools (
xcopy in error message suppression mode) and
Total Commander ' a (with creating an
nnCron script for
auto-pressing “Ok” in the dialog of an undisguised message about the inability to read the file issued for each case and not having the “Skip all ") Strongly tightened. A lot of files were not copied. So, probably bad-blocks.
Treatment
On second thought, another version of salvation was invented, which is possible by improvised means (and which eventually led to the successful completion of the mission):
- Copy the container file as a “broken” file to a new safe place.
- Connect the copied container.
- "Cure" him and pull him out info.
For the first stage, the plugin for
Total Commander is selected from
Bad Copy and Dmitry Sergeev’s
nscopy.exe (Non-Stop Copy v1.04) . More precisely, this plugin is made on its basis. Despite the year 2006 and the cessation of development, there seems to be nothing to improve there, the program copes so well with its tasks.
Attention : 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 a new storage of the cryptocontainer.
F5, Ok - load the file with a plugin (we start the recovery process):

The download dialog appears, but the progress bar does not grow:

This is necessary, because parallel and imperceptibly, the main
nscopy window was
launched :

In the process of scanning, 2 files were created: of the same name with a cryptocontainer and <s_ takim_zhe_name> .nsc. The “saved” container from the very beginning of the operation is the same size as the original file - disk space is reserved. So to say, "to avoid."
NSCopy has a good howto.txt in the distribution, which is described, for example, as:
- batch copy directories;
- integrate into Explorer context menu.
The readme.txt file describes in detail the options for using the program. In my case, the following came in handy:
“ Detailing . Each bad segment is copied by sector 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, with a small investment of time, a more accurate picture of the localization of groups of bad sectors is obtained.
Precise detail. The program tries to copy every sector in all bad sites. At the end of this stage, you get a real picture of bad sectors.
Copy bad sectors. The program tries to copy every bad sector, while making several consecutive attempts at reading. The number of attempts is determined by the option “Attempts to copy a bad sector”. The ability of a program to copy information from poorly readable sectors is based on this, since in some cases (for example, an old or badly recorded CD-R disc) there is a possibility that the sector will still be read. ”NSCopy, among other things, can be controlled from the command line.
I will explain at once why I describe this program in such detail and do not provide alternatives.
- Shock from what happened. All thoughts - to restore. Immediately after the incident - there was no time for perfectionism.
- NSCopy already stood in Total. Like a legacy of DVD times.
- There was no need for an alternative - the method worked and everything worked out.
- Post-mortem googling did not produce any results - somehow it was not very large in the market for recovering broken files from storage media. None of the programs found has passed the stage of critical thinking about the name and evaluation of the version number and the release date of the latest latest version. Not impressed, in short.
(“In the meantime, on the yacht“ Trouble ”...”) For 99% of the recovery, the damage picture is, in principle, almost completely visible. Several single failed clusters and several dense groups. That's where, when copying, the chilling soul of any IT-person sounds like “Hsch-shch shch-tshin !!!”.
A few hours of waiting and - finish. And in my case (mb. This exception) up to 100% never came. I waited a long time and, at my own risk and risk, I still pressed “Stop”. It didn’t lead to anything fatal, since NSCopy is written quite reliably and steadily - after all, but it’s just sharpened for such an unreliable thing as bad drives. The author in readme.txt himself says - recovery algorithms work consistently. The further - the more information is restored, but it will take more time.
Decide for yourself when to stop.
After stopping at 99% Non-Stop Copy, the recovered cryptocontainer was copied unchanged once more for reliability, and then mounted in the usual way. TrueCrypt again found an incorrect shutdown. Now you can safely go on experiments.

Another warning:

One more thing:

And finally, the check starts:

Starting the recovery using regular Windows tools (including checking for failed clusters) was successful and ended quickly.
Oddly enough, when copying files from the restored cryptocontainer to the newly created one,
all the files were read without any problems. That is, there are no irreversibly lost files, although partial corruption of the contents is not excluded.
Prevention (results)
It seems that this time I got off with a slight fright. From the positive:
- Updated superflesh hardware - 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 broken cryptocontainers.
- Worked out the migration procedure from one SuperFLASH to another and work in a temporary mode of limited mobility.
- He revealed the “narrow” places of his workflow, where obligatory duplication of portable-software is necessary in order not to fall out of online and out of life / work. For example, an IM client with customized accounts, a ScrapBook with work materials, a MyLifeOrganized database with tasks / tasks.