Порятунок "битого" переносного вінчестера з TrueCrypt-контейнером

Для крадіжки безпечного переміщення персональних даних, portable-додатків, бази ScrapBook та індексів Архіваріуса 3000 між двома стаціонарними точками присутності за прикладом Брюса Шнайєра була створена СуперФлешка – переносний 2.5'' вінчестер Toshiba MK2552GSX в корпусі ViPower ом всередині. Проте, "прийшла біда, звідки не чекали!".

У відкритому вигляді в корені розділу лежали дистрибутив TrueCrypt 7.0a і portable-інсталяція KeePass Password Safe свіжої версії з базою паролів. Решта місця віддано підкрипто-контейнеру вигляді файлу. Пароль до контейнера зберігається у базі KeePass.

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

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

Діагностика

Спочатку теплилася надія впоратися штатними коштами. При наступному підключенні та монтуванні криптоконтейнера неприємності виявив спочаткуTrueCrypt:

Навіть якщо розсудливо вибрати «Ні», Windows все одно вставить свої 5 коп.:

Відразу скажу, що сканування підключеного криптоконтейнера за наявності збійних кластерів на фізичному диску не має ніякої користі. Невдалі експерименти з виправленням помилокзасобами Windows та томи криптоконтейнера (T), і базового жорсткого диска не усунули проблем: перевірки зависали на високому відсотку або взагалі злітали.

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

Симптоматичне лікування

Отже, однією панелі – потрібний диск із криптоконтейнером (MyDocs.tc), відкритий через плагінBad Copy, іншою – надійне місце нового зберігання криптоконтейнера.F5, Ok– завантажуємо файл плагіном (запускаємо процес відновлення):

З'являється діалог завантаження, але прогрес-бар не зростає:

У процесі сканування було створено 2 файли: однойменний з криптоконтейнером та .nsc. «Врятований» контейнер із початку операції має такий самий розмір, як і оригінальний файл – резервується місце на диску. Так би мовити, «щоб уникнути».

NSCopy має у дистрибутиві непоганий howto.txt, де описано, наприклад, як:

пакетно копіювати каталоги;
інтегрувати у контекстне меню Провідника.

У файлі readme.txt докладно описані варіанти застосування програми. У моєму випадку знадобилося таке:«Деталізація. Кожна погана ділянка копіюється по секторах до першого поганого сектора, спочатку рухаючись від початку поганої ділянки, потім від кінця поганої ділянки у зворотному напрямку. У результаті за малих витрат часу виходить точніша картина локалізації груп поганих секторів.Точна деталізація.Програма намагається скопіювати кожен сектор у всіх поганих ділянках. Після закінчення цього етапу виходить реальна картина поганих секторів.Копіювання поганих секторів.Програма намагається скопіювати кожен поганий сектор, при цьому робитьпоспіль кілька спроб читання. Кількість спроб визначається опцією "Спроб скопіювати поганий сектор". Саме на цьому заснована здатність програми копіювати інформацію з секторів, що погано читаються, оскільки в деяких випадках (наприклад, старий або погано записаний CD-R диск) є ймовірність, що сектор все-таки прочитається.»

NSCopy, крім іншого, вміє керуватися з командного рядка.

Відразу поясню, чому так докладно описую саме цю програму і не наводжу альтернатив.

Шок від того, що сталося. Усі думки – на відновлення. Відразу після події – не до перфекціонізму було якось.
NSCopy вже стояла у Тоталі. Як спадщина часів DVD.
Альтернативи не знадобилося – метод спрацював, і все вийшло.
Гуглення постмортем не дало результатів - якось негусто на ринку програм відновлення битих файлів з носіїв. Жодна із знайдених програм не пройшла етапу критичного осмислення назви та оцінки номера версії та дати виходу останньої крайньої версії. Не вразили, коротше.

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

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

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

Ще одне попередження:

І ще одне:

І, нарешті, перевірка стартує:

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

Профілактика (підсумки)

Хардкорна конфа за С++. Ми запрошуємо лише профі.