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

Анамнез


Для кражебезопасного перемещения персональных данных, 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 с делами\поручениями.
Share post

Comments 14

  • UFO just landed and posted this here
      0
      С точки зрения решения проблемы — в принципе да. Тут, я считаю, чем проще — тем лучше.
      С точки зрения причины — проблема в «трансляции» сбойных кластеров с нижнего уровня — базовой файловой системы — на верхний — в файловую систему контейнера. Точнее, в её отсутствии.
      Если бы TrueCrypt «умел» бы определять сбойные кластеры на «родительской» файловой системе и переносить данные с них на другие, исправные… (Что в конце концов пришлось сделать вручную)
      Хоть TrueCrypt и open source, но слишком далеко от моей специализации, чтобы взяться и сделать самому.
    • UFO just landed and posted this here
        +1
        Я, возможно, спрошу очевидность, но если вы скриптами даже запускаете менеджер паролей, то могли бы озаботится и автоматическим резервированием. Хотя бы по шедулеру давать пинок сотруднику (я так понимаю, скорее всего, речь идет о рабочих данных). Есть бэкаперы, которые при подключении схемного накопителя делают бэкап.
          0
          «озаботиться»
            0
            Резервирование настроено. Вся критическая информация, которая, будучи потеряна, не сможет быть восстановлена или приведёт к неприемлемым задержкам в делах, копируется при любом удобном случае. Например, бакап базы паролей делается тем же скриптом, который запускает менеджер паролей, минимум дважды в сутки.
            В контейнере же хранится оперативная информация (типа кэша). То есть такая, которая где-то ещё разбросана по накопителям, там же, при необходимости, резервируется и т.п. Всю её можно, потратив какое-то время, собрать заново. Например, сканы паспортов, свидетельств о рождении, сохранённые веб-страницы. Ценность эта информация представляет только из-за того, что здесь и сейчас она — со мной и не надо совершать лишних телодвижений, чтобы её получить.
            В конце концов время, потраченное на восстановление, действительно оказалось гораздо меньше ориентировочного времени, которое я потратил бы на сбор всего этого заново.
            0
            В «итогах» не хватает пункта «Научился делать ежедневные бэкапы».
              0
              Приоритеты для себя я давно расставил и особо важные «активы» — выделил. Всё, что нужно, — бэкапится. В контейнере хранится только оперативная информация, которая хранится также и в других местах и потеря которой в данном месте не критична. Затраты на бэкап, как показал «инцидент», не окупились бы всё равно.
            • UFO just landed and posted this here
                0
                Может быть. Не знаю насчёт Dropbox'a, а git и svn будут воспринимать криптоконтейнер как бинарный файл. Причём так как он «крипто-», то различий между двумя его версиями будет очень много. Поэтому «версионировать» по сети малыми diff'ами для синхронизации 500 Мб криптоконтейнер, по моему мнению, не получится.
                Архивировать для хранения — тоже не вариант, опять же из-за того, что файл шифрованный и энтропия его велика.
                А гонять по сети туда-сюда каждый раз по 500Мб — удовольствие на любителя.
                  0
                  Дропбокс проверяет хеши не целиком по файлу, а кусками.
                  Трукрипт, на сколько я помню, шифрует посекторно.

                  Так что, должно работать довольно неплохо в связке.
                    0
                    Можно ещё поэкспериментировать со снапшотами NTFS.
                    Сделать снапшот, а потом кинуть в каталог, отслеживаемый клиентом DropBox, линк на файл-контейнер в этом снапшоте.
                    * пошёл делать тестовый контейнер и региться на DropBox'e
                +1
                Расскажи плз подробнее про автоматическое монтирование с вводом пароля.
                Я правильно понимаю, что когда вы втыкаете в юсб внешний винт автоматом запускается truecrypt с какими-то параметрами? есть какие то варианты как это можно сделать без авторана новых устройств?
                  +1
                  Правильно понимаете.
                  Вариант есть. Нужен установленный nnCron. У него есть семейство очень полезных ключевых слов Watch*. А конкретнее, в данном случае:

                  WatchDrive: "B"

                  При появлении диска с совпадающей буквой (т.е. «флешки» с криптоконтейнером на ней) срабатывает описанное ниже в скрипте правило:

                  \ Проверить, "флешка" ли это - есть ли файл "H:\KeePass Password Safe\KeePass.exe"
                  FILE-EXIST: "B:\KeePass Password Safe\KeePass.exe"
                  \ Если есть - запустить "B:\KeePass Password Safe\KeePass.exe"
                  IF
                  \ Если KeePass.exe ещё не запущен...
                  PROC-EXIST: "KeePass.exe" NOT
                  IF
                  \ ... запустить его.
                  StartIn: "B:\KeePass Password Safe"
                  ShowNormal NormalPriority
                  START-APP: "B:\KeePass Password Safe\KeePass.cmd"
                  THEN


                  При появлении в системе диска B: (интервал сканирования настраивается. По умолчанию — 1000 мс) проверяется его содержимое. На диске должен быть KeePass. Если он есть — он запускается. Но не непосредственно, а батником. Файл KeePass.cmd делает бэкап базы паролей, добавляя в имя файла штамп времени и сохраняя его в выделенные каталоги (рядом на флешке и в «Моих документах» текущего пользователя. База зашифрована, за содержимое можно не волноваться).

                  \ Запустить монтирование тома на "флешке"
                  FILE-EXIST: "B:\TrueCrypt\TrueCrypt.exe"
                  IF
                  \ Если файл криптоконтейнера существует на "флешке" ...
                  FILE-EXIST: "B:\MyDocs.tc"
                  IF
                  StartIn: "B:\TrueCrypt\"
                  ShowNormal NormalPriority
                  START-APPW: "B:\TrueCrypt\TrueCrypt.exe" /b /letter I /volume "B:\MyDocs.tc"
                  ...


                  Теперь с использованием интерфейса командной строки TrueCrypt монтируется контейнер на выделенную букву диска. Ну, и дальше — всё что нужно.

                  В принципе, можно запрограммировать любые действия в пределах компетенций языка Форт, встроенного в nnCron.

                Only users with full accounts can post comments. Log in, please.