Pull to refresh

Спасение «битого» переносного винчестера с TrueCrypt-контейнером

Information Security *
Sandbox

Анамнез


Для кражебезопасного перемещения персональных данных, portable-приложений, базы ScrapBook и индексов Архивариуса 3000 между двумя стационарными точками присутствия по примеру Брюса Шнайера была создана СуперФлешка – переносной 2.5’’ винчестер Toshiba MK2552GSX в корпусе ViPowER VP-352518 с USB и SATA-интерфейсами с криптоконтейнером внутри. Однако, "пришла беда, откуда не ждали!".

В открытом виде в корне раздела лежали дистрибутив TrueCrypt 7.0a и portable-инсталляция KeePass Password Safe свежайшей версии с базой паролей. Всё остальное место отдано под крипто-контейнер в виде файла. Пароль к контейнеру хранится в базе KeePass.

Подмонтирование в точках присутствия – скриптами nnCron по времени или по подключению соответствующего USB-диска с автозаполнением диалога ввода паролей с помощью связки nnCron+KeePass.

В один непрекрасный день винчестер приказал начал отдавать приказ на долгую жизнь. Ошибки чтения, зависания, леденящие душу звуки стрёкота головок винчестера и прочие «прелести». После отмонтирования криптоконтейнера диск как USB-привод не захотел отмонтироваться добровольно. Тут бы проявить уважение к мнению железки, смирить гордыню и перезагрузиться, но… Все мы крепки задним умом… Диск был извлечён «на горячую». И зря.

Диагностика


Сначала теплилась надежда справиться штатными средствами.
При следующем подключении и монтировании криптоконтейнера неприятности обнаружил сначала TrueCrypt:
image

Даже если благоразумно выбрать «Нет», Windows всё-равно вставит свои 5 коп.:
image

Сразу скажу, что сканирование подключенного криптоконтейнера при наличии сбойных кластеров на физическом диске не несёт никакой пользы. Неудачные эксперименты с исправлением ошибок средствами Windows и тома криптоконтейнера(T), и базового жёсткого диска не устранили проблем: проверки зависали на высоком проценте или вообще «слетали».

Неудачная попытка скопировать отмонтированный криптоконтейнер показала, что проблема глубже – или разрушена NTFS, или посыпались «кластеры».

Симптоматическое лечение


Попытки скопировать информацию штатными средствами Winsows (xcopy в режиме подавления сообщений об ошибках) и Total Commander’a (с созданием скрипта nnCron для автонажатия «Ок» в диалоге нескрываемого сообщения о невозможности прочитать файл, выдаваемого для каждого случая и не имеющего кнопки «Пропустить все») сильно затянулись. Очень много файлов не было скопировано. Значит, наверняка bad-блоки.

Лечение


По здравом размышлении был придуман ещё один вариант спасения, который возможен подручными средствами (и который в итоге привёл к успешному завершению миссии):
  1. Скопировать файл-контейнер как «битый» файл в новое надёжное место.
  2. Подключить скопированный контейнер.
  3. «Вылечить» его и вытянуть с него инфу.

Для выполнения первого этапа выбран плагин к Total Commander’у «Bad Copy» и входящая в его состав nscopy.exe (Non-Stop Copy v1.04) Дмитрия Сергеева. Точнее, это плагин сделан на её основе. Несмотря на 2006-й год выпуска и прекращение развития, улучшать там уже кажется нечего, программа и так прекрасно справляется со своими задачами.
Внимание: контейнер не должен быть подмонтирован! Иначе nscopy не сможет получить к нему доступ.

Итак, на одной панели – нужный диск с криптоконтейнером (MyDocs.tc), открытый через плагин Bad Copy, на другой – надёжное место нового хранения криптоконтейнера. F5, Ok – загружаем файл плагином (запускаем процесс восстановления):
image

Появляется диалог загрузки, но прогресс-бар не растёт:
image

Так и надо, потому что параллельно и незаметно запустилось основное окно nscopy:
image

В процессе сканирования были созданы 2 файла: одноимённый с криптоконтейнером и <с_таким_же_именем>.nsc. «Спасённый» контейнер с самого начала операции имеет такой же размер, как и оригинальный файл – резервируется место на диске. Так сказать, «во избежание».

NSCopy имеет в дистрибутиве неплохой howto.txt, где описано, например, как:
  1. пакетно копировать каталоги;
  2. интегрировать в контекстное меню Проводника.

В файле readme.txt подробно описаны варианты применения программы. В моём случае пригодилось следующее:
«Детализация. Каждый плохой участок копируется по секторам до первого плохого сектора, сперва двигаясь от начала плохого участка, затем от конца плохого участка в обратном направлении. В результате при малых затратах времени получается более точная картина локализации групп плохих секторов.
Точная детализация. Программа пытается скопировать каждый сектор во всех плохих участках. По окончанию этого этапа получается реальная картина плохих секторов.
Копирование плохих секторов. Программа пытается скопировать каждый плохой сектор, при этом делает подряд несколько попыток чтения. Количество попыток определяется опцией «Попыток скопировать плохой сектор». Именно на этом основана способность программы копировать информацию из плохо читаемых секторов, так как в некоторых случаях (например, старый или плохо записанный CD-R диск) есть вероятность, что сектор все-таки прочитается.»


NSCopy, кроме всего прочего, умеет управляться из командной строки.

Сразу объясню, почему так подробно описываю именно эту программу и не привожу альтернатив.
  1. Шок от случившегося. Все мысли – на восстановление. Сразу по происшествии – не до перфекционизма было как-то.
  2. NSCopy уже стояла в Тотале. Как наследие времён DVD.
  3. Альтернативы не понадобилось – метод сработал и всё получилось.
  4. Гугление постмортем не дало результатов – как-то негусто на рынке программ восстановления битых файлов с носителей. Ни одна из найденных программ не прошла этапа критического осмысления названия и оценки номера версии и даты выхода последней крайней версии. Не впечатлили, короче.

(«А тем временем на яхте «Беда»…») На 99% восстановления картина повреждений, в принципе, видна уже практически полностью. Несколько одиночных сбойных кластеров и несколько плотных групп. Вот откуда при копировании леденящие душу любого IT-шника звуки «Хщ-щ-щ-дзынь!!!».

Несколько часов ожидания и — финиш. Причём в моём случае (м.б. это исключение) до 100% так и не дошло. Долго ждал и на свой страх и риск всё-таки нажал «Стоп». Ни к чему фатальному это не привело, так как NSCopy написана достаточно надёжно и устойчиво – как-никак, а она как раз и заточена под такую ненадёжную вещь, как сбойные диски. Автор в readme.txt сам говорит – алгоритмы восстановления работают последовательно. Чем дальше – тем больше информации восстановится, но и времени это займёт больше. Сами решайте – когда остановиться.

image

После остановки на 99% Non-Stop Copy восстановленный криптоконтейнер был скопирован для надёжности в неизменном виде ещё один раз, а затем подмонтирован обычным способом. TrueCrypt опять обнаружил некорректное отключение. Теперь уже можно смело идти на эксперименты.

image

Ещё одно предупреждение:
image

И ещё одно:
image

И, наконец, проверка стартует:
image

Запуск восстановления штатными средствами Windows (включая проверку на сбойные кластеры) прошёл успешно и закончился быстро.
Как ни странно, при копировании файлов из восстановленного криптоконтейнера в свежесозданный все файлы прочитались без проблем. То есть необратимо потерянных файлов нет, хотя не исключена частичная порча содержимого.

Профилактика (итоги)


Кажется, в этот раз отделался лёгким испугом. Из положительного:
  1. Обновил железо «суперфлешки» – теперь 500 Гб вместо 250-ти. Теперь буду делать регулярно. По-любому мои нервы стоят дороже ~1600р. за новый винт раз в 1-1.5 года.
  2. Отработал методику восстановления покоцанных криптоконтейнеров.
  3. Отработал процедуру миграции с одной СуперФЛЕШКИ на другую и работы во временном режиме ограниченной мобильности.
  4. Выявил «узкие» места своего рабочего процесса, где нужно обязательное дублирование portable-софта для того, чтобы не выпасть из онлайна и из жизни\работы. Например, IM-клиент с настроенными аккаунтами, ScrapBook с материалами по работе, база MyLifeOrganized с делами\поручениями.
Tags:
Hubs:
Total votes 27: ↑22 and ↓5 +17
Views 11K
Comments Comments 14