Сказ о том, как не надо сохранять данные с полумертвого жесткого диска
Принесли недавно Samsung NP-N210 в плачевном состоянии. Играли им в футбол или вели военные действия – история умалчивает, но грузиться немецкая XP на нем отказывалась наотрез.
Требуемый результат – «хотя бы фоточки семейные выковырять из него».
Что ж, отработанным движением раскручиваем спинку ноутбука, вынимаем жесткий диск, подключаем к конвертору интерфейсов (на фото выше), ждем…
Диск опознался, разделы видны, данные – тоже, но… Диск покрыт плохими секторами, как собака – блохами. Разумеется, немало досталось системным файлам, поэтому операционную систему уже не спасти (граждане, пожалейте технику – уж если забиваете ею гвозди, то хоть выключайте сначала!).
Попытки простого переписывания большинства «фоточек семейных» на рабочий диск систематически не удаются и единственным результатом такого подхода оказывается мертвое зависание диска.
После отключения-подключения разделы на диске уже не видны — видимо, диск находится на последнем издыхании. Вынимаем из широких штанин интернетов Acronis True Image Home (Trial), натравливаем на диск в надежде прочитать по секторам в образ и потом поработать с образом.
Трудолюбивый True Image принимается за дело… Проходят сутки… Сектора все еще читаются… Вторые сутки… Третьи… И вот она – ошибка резидента вашего покорного слуги – ресурса диска не хватает для того, чтобы аккуратно и трудолюбиво, со многими повторными попытками (привет компании Acronis) прочитать каждый сбойный сектор. Диск намертво завешивает систему (и это – через USB!). После перезагрузки пациент окончательно прекращает подавать какие-либо признаки жизни.
Что ж, имеем на руках мертвый жесткий диск и кусок TIB образа – около 10 гигабайт. Просмотр в шестнадцатиричном редакторе внушает надежду:
К счастью, образ диска делался полный, посекторный и без сжатия, так что полученные данные, по-видимому, можно использовать (все-таки, оптимисты – счастливые люди).
Не будем подробно останавливаться на многочисленных попытках чем-либо смонтировать этот огрызок фрагмент файловой системы, чтобы прочитать из него хоть что-то стоящее. True Image Home уверенно сказал – «не мое», различные сторонние утилиты тоже не усмотрели в десятигигабайтном файле ничего полезного. Поиск описания формата TIB на просторах интернета результатов не принес.
Не пора ли вспомнить о полезной и толковой программе — R.Saver от R.LAB? Натравливаем ее на архив, и — НИ-ЧЕ-ГО… Так умирает надежда.
Прошло несколько дней. Однажды утром очередное просветление принесло свежую мысль – провести так называемый «следственный эксперимент». Расчехляем основное оружие – Windows XP Mode. Кто не знает – это виртуальная XP, тесно интегрированная с хостовой Windows 7.
Создаем на этой виртуалке маленький диск на 50 мегабайт (чтобы эксперимент не занял вечность), форматируем в NTFS, бросаем на него немножко файлов, чтобы хоть какие-то сектора не были сплошными нулями. Устанавливаем на ту же виртуалку True Image Home и Disk Editor. Первый из них создает для нас TIB файл, второй – полный посекторный образ без всяких заголовков и прочих излишеств. Затем устанавливаем Beyond Compare – первую попавшуюся софт-тварь, которая, как утверждают авторы, хорошо справляется со сравнением двоичных файлов. Что ж, проверим.
Сравнение тут же выявляет заголовок файла и какие-то регулярные блоки данных по 68 байт, которые есть в TIB и отсутствуют в посекторном образе. Вот оно, секретное оружие компании Acronis! Именно эти блоки ломают структуру архива и не дают R.Saver сосредоточиться на поиске остатков файлов. Предполагаю, что эти блоки – что-то вроде контрольной суммы или каких-то маркеров, т.к. они вставляются после каждых 256 килобайт (или 512 секторов). Вряд ли мы узнаем правду от создателей True Image, но если кто из уважаемых читателей может прояснить, что это за блоки данных и зачем они нужны – милости прошу комментировать.
Стало быть, есть смысл убрать эти блоки и заголовок, и предложить то, что останется, программе R.Saver – в надежде на лучшее.
Общеизвестно то, что нормальный человек будет просто делать, а программист сначала автоматизирует. В данном случае в автоматизации есть смысл, т.к. вырезать из десятигигабайтного архива блоки по 68 байт, расположенные через каждые 256 килобайт – занятие для ОЧЕНЬ терпеливых – на минуточку, около 40 тысяч операций получается.
Поскольку сама задача, хоть и весьма нудная, но очень простая – поиск чего-либо уже существующего займет гарантированно больше времени, чем написание своего скромного велосипедика.
Запасаемся кофе… В общем, кофе даже не успел остыть. Собственно, вот и весь листинг:
#include <stdio.h>
#include <stdlib.h>
#define BUFSIZE 262144
int main(int argc, char* argv[])
{
if(argc < 5) {
printf("tibclean <src> <trg> <protection record size> <header size>");
return 0;
}
printf("arg1==%starg2==%starg3==%s", argv[1], argv[2], argv[3]);
off64_t protectionRecSize = atoi(argv[3]);
off64_t headerSize = atoi(argv[4]);
FILE* sf = fopen64(argv[1], "rb");
if(NULL==sf) { return 1; }
FILE* df = fopen64(argv[2], "wb");
if(NULL==df) {
fclose(sf);
return 2;
}
off64_t offs = headerSize;
fseeko64(sf, offs, SEEK_SET);
char fbuf[BUFSIZE];
unsigned int readbytes;
unsigned int writtenbytes;
off64_t divbuff;
int lastmbytes = 0;
int mbytes = 0;
while(!feof(sf)) {
fseeko64(sf, protectionRecSize, SEEK_CUR);
readbytes = fread(fbuf, 1, BUFSIZE, sf);
if(0==readbytes) { break; }
writtenbytes = fwrite(fbuf, 1, readbytes, df);
if(writtenbytes!=BUFSIZE) { break; }
//reporting
divbuff = ftello64(sf);
divbuff = divbuff / 1048576;
mbytes = (int)divbuff;
if(mbytes!=lastmbytes) {
printf("%d mbytes readyn", mbytes);
lastmbytes = mbytes;
}
}
fclose(sf);
fclose(df);
return 0;
}
Длина заголовка и длина вырезаемого блока задается из командной строки, т.к. в тестовом TIB файле и в том, который остался в наследство от безвременно погибшего жесткого диска, размер вставляемого блока оказался разным – 68 байт в тестовом образе, и, на удивление, всего 12 байт – в «наследстве».
Что ж, запускаем нашу микроутилиту:
TIBClean.exe drive_c_full_b1_s1_v1.tib cleaned.img 12 28Попытка номер два — R.Saver жадно набрасывается на слегка похудевший файл, и – о, чудо – находит в нем файловую систему, хотя и поврежденную.
Дальше все просто – выделяем все интересующие файлы, и пытаемся их сохранить. К сожалению, 10 гигабайт – это не все просторы бывшего раздела с данными, поэтому восстанавливается не очень большая часть семейного фотоархива, увы.
Выводы
Не используйте Acronis True Image с дисками, на которых ОЧЕНЬ МНОГО битых секторов – эта прекрасная утилита предназначена для других задач! Битые сектора погружают ее в задумчивость, что не способствует улучшению здоровья умирающего жесткого диска.
Для таких случаев используйте R.Saver – лучшую из бесплатных программ, предназначенную именно для аварийного спасения нажитого непосильным трудом ваших данных в случае, если остаток жизни диска исчисляется часами.
Для недопущения таких случаев не играйте ноутбуками в футбол и теннис, а также не используйте их как личное оружие.
Делайте резервные копии ваших данных.
Disclaimer
Я не являюсь сотрудником компании R.LAB и не имею к ней никакого отношения. Также, я не являюсь злопыхателем или конкурентом компании Acronis, и в том, что ее продукт не помог в данном конкретном случае, не обвиняю никого, кроме себя.
Happy End
Через пару недель отдыха в ящике стола «труп» частично ожил – с жуткими тормозами, но определялся в системе, хотя разделы на нем по-прежнему не были видны. Наученный предыдущим горьким опытом, автор сего опуса незамедлительно использовал R.Saver и спасительную силу молитвы. Удалось спасти более 80 процентов «семейного фотоархива» моих друзей, увлекающихся забиванием гвоздей при помощи ноутбука.
Автор: dMac
