restore data from broken hdd

сохранность данных

написать нижеследующую простыню меня побудило то, что в определенный момент времени я, благодаря проворству своего домашнего животного и большой стеклянной банке чая, потерял некоторое количество важной информации. но даже это не очень важно, потому как впоследствии, клюнув на рекламные объявления, провел довольно большое количество времени в попытках восстановить данные с помощью автоматических программ и потерпел фиаско.

восстановление данных

тут начинается самое интересное. в силу того, что мой диск получил ощутимые физические повреждения (вмятина шириной в 10 милиметров и глубиной в три прямо над блоком парковки головок), я не думал, что он вообще сможет работать. мне очень не хотелось его вскрывать самому для того, чтобы вмятина ничему не мешала при восстановлении данных. сильно помогло отверстие прямо рядом с вмятиной — при помощи отвертки былприподнят корпус и диск смог прочитаться.

дальше уже все было просто — подключаем в powermac, запускаемся, с трудом грузимся, монтирование диска происходит в течении десятка минут. на диске у меня два раздела и если второй смог показаться в finder и я спокойно смог начать копировать с него данные, то первый не мог ни подключиться, ни пройти верификацию в disk utility. тут я вспомнил, что были две программы, которые могли бы помочь мне скачать информацию даже с такого раздела. этими программи оказались TechTool Pro 4.6.2 и Data Rescue II.

кратко о том, каков у них принцип работы.

каждая из них пытается прочитать весь диск для того, чтобы найти на нем уцелевшие файлы. но не все так просто. после составления некотого индекса этих файлов, обе программы предлагают выбрать необходимые файлы и ваше веселье начинается заново. то есть вместо копирования с заведомо небыстрого и проблемного места файлов, предлагается пару раз попилить диск, чтоб уж наверняка файлы не восстановились. других объяснений именно такой работе я не вижу. и если уж у вас есть данные, ценность которых заведомо выше каждой из этим программ, то будет странно, если у вас не найдется денег на диск, куда вы будете восстанавливать восстановимое.

впроче, оставим это все на совести разработчиков этого софта, но кратко пройдемся по каждой программе. кстати, ни одна из них не поддерживает национальные символы. во всяком случае, я не смог разобраться, какое количество вопросиков соответствует нужному файлу.

TechTools Pro — это такой небольшой комбайн для тыканья ответкой в разные чувствительные части вашего мака. он вроде может определить неисправность основных узлов и сказать, что с вашим алюминием в порядке, а что — не совсем. заодно может создать специальный скрытый раздел на диске с собой любимым и как–бы восстанавливает данные.

программа проработала около 14 часов и прогресс остановился. я нажал кнопку отмена и она (о чудо!) и вывела список директорий, которые она думала, что могла бы восстановить. спустя три часа после копирования одного из файлов я решил прервать этот процесс, потому как у меня было ощущение, что это не закончится никогда. результат: около 20 часов работы, около 20 восстановленных файлов из нескольких каталогов в домашней директории. вернуться к списку директорий мне не позволили и это полностью определило дальнейшую судьбу программы — она отправилась в корзину. если остальные функции этой программы реализованы также хорошо, то она не стоит своих денег и … вообще ничего не стоит.

Data Rescue II «умеет» только восстанавливать файлы. но функциональность в целом схожа с восстановлением у TechTools Pro. то есть софт чрезвычайно долго мурыжит диск, потом выдает список «восстановимых» файлов и при выборе мучительно пытается их восстановить. завершения процедуры я не дождался, на часах уже были третьи сутки с момента падения диска.

эти программы дали мне довольно много информации о том, как вообще живет софт восстановления данных на mac os x. его просто нет. бэкапьтесь почаще!

как показал гугл, восстановление данных с диска формата hfs+ стоит от 250 евро. в моем случае нужно было бы еще и убирать гермоблок, то есть еще около 100 евро. данные, которые у меня были не сохранены, столько не стоили и я решил попробовать сам все скопировать.

закат солнца вручную.

эта часть повествования относится скорее к unix geek, чем к обычным пользователям. поэтому ее можно прочитать как руководство к действию, а можно вообще не читать, пока у вас ничего не случилось.

подготовка

сначала вам придется свыкнуться с мыслью, что чем больше вы возитесь, тем меньше у вас шансов. так происходит по разным причинам, начиная с того, что ваш диск разваливается физически и заканчивая тем, что магнитная структура у неисправного диска может меняться. поэтому, если у вас не сложилась любовь с терминалом и данные важны, попробуйте восстановить их за бабло.

также вам придется подумать о том, что стоит «спасать» в первую очередь. если ваш ответ — домашняя директория или вообще все, то вам стоит обратиться к специалистам. потому что в случае серьезных неполадок вам удастся скопировать только небольшую часть данных за ограниченное время. пофайловый план будет идеальным.

вам понадобится открытый внешний контейнер для диска. если у вас он закрытый, то важно будет его не закрывать. кроме того, нужно организовать принудительное охлаждение. его хорошо делать с помощью обычного компьютерного вентилятора размером 120х120х25мм. есть большая вероятность, что вы сможете спасти больше данных с охлаждением, нежели без. во всяком случае, у меня диск переставал отдавать данные вообще после получаса чтения с него без охлаждения.

внешний контейнер нужен затем, что вы можете загрузить систему без участия проблемного диска. у меня система с моим диском попросту не грузилась, если диск был подключен к sata контроллеру.

допустим, вам повезло

стоит понять, какая вероятность того, что ваши данные восстановимы. если диск монтируется и с него даже худо–бедно что–то копируется, то вам повезло. точно также вам повезло, если вы сможете подмонтировать диск с помощью команды mount_hfs -j (это значит, что вы просто проигнорировали журнал при монтировании). это и было степенью моего везения. после этого я с помощью команды cp в терминале (Finder перестает копировать файлы после первой ошибки) получил все важные данные (некоторые не скопировались, конечно, но основное я получил). при этом я скопировал всего 3 гигабайта из 45 в течении часа. это одна из причин, почему план спасения данных, расписанный вплоть до файлов с директориями — хорошая идея. при этом начало диска оказалось безнадежно испорчено — 200 мегабайт из начала копировались 4 часа. но тут уж как повезет.

возможно, не повезло

и диск не монтируется даже без журнала. это, предположительно, обозначает, что схемы расположения файлов на диске уже нет. теперь вам предстоит кропотливая работа по отделению мух от котлет. для начала лучше всего будет скопировать имеющиеся данные. это можно сделать с помощью следующей команды:

dd bs=4096 if=/dev/disk2s2 of=/Volumes/vert/tristane.dmg conv=noerror,sync

где 4096 — размер блока, /dev/disk2s2 — это ваше отвалившееся устройство, /Volumes/vert/tristane.dmg — место и файл, куда будут сбрасываться полученные данные. эта процедура может длиться очень долго. может даже недели. так что озаботьтесь доставкой пиццы и кока–колы для себя и бесперебойным питанием для компьютера, на котором вы будете переливать все из пустого (все непрочитанные блоки dd забивает нулями) в порожнее. кроме того, за этим компьютром вам будет сложно работать, потому что иногда система перестает отвечать. еще раз повторю, что, возможно, ждать придется долго.

допустим, у вас спустя время создался образ вашего диска. вот теперь вы можете напустить на него Data Rescue II. есть вероятность, что он даже найдет в образе несколько файлов.

ну и в последний раз повторюсь — не хотите производить эти все операции — делайте backup.

usability sucks

http://www.ibm.com/developerworks/ru/library/os-whistle/index.html

напоминает анекдот:

«В одной деревне жил старичок, который мог напердеть любую мелодию. И вот
узнали об этом телерепортеры. Приехало к нему телевидение, берут,
значит, интервью.
Журналист: А правда, что вы можете напердеть любую мелодию?
Старик: Да, конечно.
Журналист: А "Калинку-малинку" можете?
Старик: Могу.
И напердел мелодию.
Журналист: А " Во саду ли в огороде" слабо?
Старик: Нет.
И тоже напердел песенку.
Журналист: А что-нибудь из классики вы могли бы напердеть?
Старик: Например?
Журналист: Ну, например, Моцарта?
Старик: Не знаю, давайте ноты.
Ему дают ноты, он около 10 минут пристально смотрит на них.
Журналист: Ну так что, сможете?
Старик: Нет, не смогу.
Журналист: Почему же?
Старик: Да тут в 2 местах обосраться можно»

и это снова я про mysql

новыя знания — новыя печали

теперь я использую mysql таким образом:

"DBI:mysql:database=regru_auction;mysql_multi_statements=1;mysql_enable_utf8=1;mysql_auto_reconnect=1"

тогда есть надежда, что можно сразу несколько statements в do напихать, но я уже этим не пользуюсь. парсить sql оказалось проще, чем договориться с mysql.

причем, как показывает опыт, последний флаг не работает вообще. как был morning bug, так и остался. Apache::DBI отдыхает.

но это не все. после ошибки DBD::mysql становится нестабильным и может порождать ошибки типа таких:

DBD::mysql::st bind_columns failed: bind_columns called with 1 values but 10 are needed [for Statement "select count(*) from `auction` "]

для тех, кто в танке: иногда имеет смысл запустить возможно ошибочное sql выражение, чтобы не трясти базу лишний раз. а именно, вместо проверки, есть ли пользователь с таким username/password просто попытаться пользователя туда вставить. тогда, в случае ошибки, мы можем сказать: «э нет, чувак, такое как ты уже есть». ха. не в случае mysql. случай mysql:

eval {
$dbh->do (…);
};

if ($@) {
$dbh->disconnect;
Core::make_new_dbh ();
}

ну и сладкое напоследок.

есть вероятность не выйти из транзакции. то есть после commit или rollback есть вероятность остаться в транзакции со всеми вытекающими. в мануале предлагают дисконнектиться и соединяться заново. а, ну и autoreconnect в таком случае отключается -)

P.S.: совсем забыл. если создать mysql dbh и форкнуться, то есть вероятность чрезвычайно круто попасть впросак, потому что как–то оно очень хуево после этого работает.

мудаки.

migration postgresql => mysql

есть достаточно большое количество statements, которые после запуска не могут быть rollback. список: для 5.0, для 5.1, то есть mysql не является ACID compliant, хотя оно заявлено.

drop table if exists temp_test_one, temp_test_two;

begin;
create table temp_test_one (a int, b int);
rollback;

-- fail here, create table caused implicit commit
create table temp_test_one (a int);


begin;
alter table test1 drop b;
rollback;

-- fail here, because alter table also caused implicit commit
alter table test1 drop b;

по непонятным для меня причинам, второе поле типа timestamp не может принимать значение now() при вставке, что делает возможным создание поля created только с помощью триггера. зато первое поле такого типа по умолчанию апдейтится при каждом обновлении записи. вот такая долбаная магия.

-- fail here, error: Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause (WHY?)
create table temp_test_two (created timestamp default now(), updated timestamp default now());

-- fail here because first timestamp column have default now()
create table temp_test_two (updated timestamp, created timestamp default now());

create table temp_test_two (updated timestamp, created timestamp);

-- now updated column being updated on any update

триггеры может создавать только пользователь с правами super (вроде, в 5.1 они это поправили)

-- fail here if you don't have super privilege (5.0)
create trigger temp_test_two_bcreate before insert on temp_test_two for each row set new.created = now();

чюваки из mysql до сих пор не смогли написать нормального парсера, чтобы разграничивать внутренности процедур от остального sql кода.

-- fail because you don't set delimiter (stupid mysql parser can't recognize trigger end without separation delimiters inside trigger and outside)
create trigger contact_aupdate after update on contact
for each row begin
if new.contact_auth = 'ok' then
update domain set domain_authenticated = true, domain_state = 'auth' where auth_contact_id = new.contact_id;
end if;
end;

теперь про перл

mysql не может запускать сразу два statement в одном do; если сделать fork, то придется создавать новое соединение, так как старое привязано к process id.

my $dbh = DBI->connect;

my $pid = fork;
if ($pid) {
# failed because you can't launch two statements at same time
$dbh->do ('drop table if exists temp_test_one; drop table if exists temp_test_two; ');
} else {
# failed because cloned dbh doesn't work
$dbh->do ('drop table if exists temp_test_one, temp_test_two;');
}

короче, если нет возможности использовать что–то другое, то можно, иначе — нужно как можно быстрее избавляться от mysql в пользу postgresql и/или sqlite.

perl death is postponed

в последнее время начал работать с перлом серьезно (весь в кишках). и как–то так получилось, что уже в третий раз нахожу в нем ошибку. один товарищ сказал, что пора переключаться на java — там я буду дилетантом и не буду соваться во всякую мутную низкоуровневую поебень.

меня больше тянет к ruby, потому что по архитектуре java меньше подходит в качестве web языка. но, судя по последним данным, вряд ли я стану ruby или java специалистом.

давайте посмотрим на вот эту картинку:


по ней явно видно, что перл держится молодцом между enterprise level java и активно продвигаемым одной небезызвестной компанией ASP.NET.

как всем уже давно известно, perl не развивается. но не в том смысле, что не появляется чего–то нового. а скорее в том плане, что без большого объема общения сложно выяснить, что же стоит использовать и для каких целей. для тех же accessors в перле есть не один десяток модулей. то же касается web frameworks, ORM. короче, трендов нет, есть одна глобальная помойка под названием cpan. нет инструментов и удобных frameworks. но есть куча перлового кода, который был написан и будет написан и все это барахло нужно поддерживать.

волшебные слова типа Catalyst и Moose оставьте при себе. в реалиях сегодняшнего дня у них нет достаточного уровня производительности: http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/ . если охота более свежих тестов, то в компании, где я сейчас работаю, используется Catalyst и при потреблении памяти в 500 мегабайт он умеет обслуживать не более 10 простых запросов в секунду. Moose же работает в 10 раз медленнее моих самописных accessors, и это в самом простом случае, когда они не типизированы. простите, но это лажа.

memory organization and management in mac os x

только для 10.5

некоторые из указанных здесь данных справедливы только для 10.5. то есть я предполагаю, что, как минимум в 10.4 inactive память не могла быть помещена в swap.

чипы и диски

системе доступны кэш память процессора (cpu cache), физическая или оперативная память (ram) и память подкачки (swap). кэш память процессора — самая быстрая из имеющейся памяти. она напрямую отдает данные процессору, но за все приходится платить: она же самая дорогая и поэтому размер ее чрезвычайно мал. управление ею возможно, но при программировании под mac os x скрыто, можно лишь сравнивать насколько архитектура процессора соответствует размеру кэш памяти — что является темой для отдельной статьи. в обозримом будущем интел обещает сильное увеличение объемов процессорного кэша, так что посмотрим, может все сильно поменяется. физическая память - это микросхемы оперативной памяти, память подкачки же - это файлы на диске. также система может показывать виртуальную память, но она настолько виртуальна, что не имеет отображения ни в оперативной памяти, ни на диске. не стоит путать память подкачки и виртуальную память - они не имеют вообще ничего общего. суть виртуальной памяти в том, что она выделяется по запросу приложения. но отображаться в реальной памяти начинает только тогда, когда приложение начинает операции с выделенной памятью.

так получилось, что чем медленнее сама память, тем дешевле запихать побольше ее в компьютер. поэтому кэша у процессора в пределах нескольких мегабайт, оперативной памяти в макбук можно поставить 4 гигабайта, а более медленной дисковой — аж 300 гигабайт.

приложения потребляют память при запуске и своей работе. чем интенсивнее приложение работает с объектами и чем больше количество объектов используется, тем больше потребляет памяти данное приложение. когда активное приложение перестает помещаться в оперативную память, то часть данных неактивного приложения сбрасывается на диск, в файл подкачки. впоследствии, при переключении на такое неактивное приложение вы почувствуете, что оно совсем небыстро отвечает в течении небольшого промежутка времени - это данные, попавшие в файл подкачки, возвращаются в физическую память, а другое неактивное приложение помещается в swap. привет, пляжный мячик!

системная память

система различает в оперативной памяти несколько секций: wired, active, inactive и free. обычно, пользователь, замечая, что у него почти не осталось свободной (free) памяти, начинает выгружать приложения. количество свободной памяти после данной процедуры увеличивается, но несильно. система с двумя гигабайтами памяти, в которой запущен один только finder, может иметь свободной лишь 100 мегабайт. и это нормально.

wired память - это, зачастую, лишь память ядра системы (ну и WindowServer). wired память не имеет шансов попасть в swap. больше она ничем не интересна.

active память - это память всех приложений. то есть если приложение загрузилось, то оно «отъело» кусок active памяти. если приложение загрузило файл и держит содержимое в памяти, то оно отъест еще кусок. возможно, часть такой памяти превращается в inactive, но условия, при которых это происходит и что именно становится «неактивным» — мне неизвестно.

inactive память предположительно не имеет никакого отношения к приложениям. этой памятью управляет система, кэшируя обращения к файлам на диске. то есть если приложение прочитало файл на диске, то содержимое этого файла будет сохранено системой внутри inactive памяти. если приложение вторично пытается прочитать файл и файл не изменился, то с большой вероятностью он будет прочитан из памяти, без обращения к диску. эта память также не помещается в swap в силу бессмысленности данной операции (вообще–то так должно быть, но это не совсем так — читай далее).

free - это память, которую не использует ни одно приложение. количество свободной памяти не может опуститься ниже некоторого предела, поэтому вы вряд ли сможете увидеть значения типа 500 килобайт памяти свободно. но если значение опустилось менее 5 мегабайт, то скорее всего либо у вас уже все тормозит, или вы очень скоро это почувствуете.

сразу после загрузки у вас будет очень много свободной памяти, которая по мере работы будет активно превращаться в active и inactive. и если с active памятью мы ничего сделать не можем, система распорядится ею сама, то размер inactive памяти можно менять.

вообще–то есть довольно сильная зависимость от профиля вашей работы. если вы работаете с небольшим количеством файлов, но с приложениями, которые перелопачивают большое количество данных, то, с большой вероятностью, у вас будет больше занято active памяти. в случае копирования и чтения множества файлов — inactive память вырвется на первое место.

приоритеты

память подчиняется определенным приоритетам, которые выглядят как (у всех так нарисовано):

wired > active > inactive > swap

это не совсем верно. wired не имеет шансов попасть в swap. кроме того, я за много попыток не смог добиться (или не смог увидеть) попадания active памяти в inactive.

так что схема примерно такова:

inactive > swap, active > swap

то есть в случае нехватки памяти, active и inactive могут быть помещены в swap, причем сначала помещается inactive память, а потом active. если насчет active все понятно, то почему inactive, которая (фактически) является файловым кэшем, помещается в swap? этого я понять не могу, но результаты тестов показывают нам именно это.

волшебная inactive память

поработав за компьютером некоторое время я наблюдаю следующую картину:



для того, чтобы определиться с inactive памятью, я решил скопировать 1 гигабайт данных с помощью команды «cp» в терминале («Finder» не использует кэширование при копировании файлов):



все параметры в норме, полет нормальный, inactive память подросла на гиг. давайте посмотрим, что будет, если я попрошу у системы 2 гига памяти и запишу в них данных, а потом освобожу эту память. на первой картинке — процедура отъедания памяти, а на второй — после того, как я покликал по активным GUI приложениям и проверил, что они не залезли в swap:





вроде бы все в норме, только там есть волшебная строчка, на которую стоит обратить внимание: swap used. если сравнить с начальной картинкой, то в свопе оказалось полгига inactive памяти. фигасе, сказал я себе, когда это увидел. может, у меня скриншоты неправильно скриншотятся? я выгрузил все приложения и увидел следующую картину:



то есть в свопе находится inactive память, которая не была нужна ни одному из загруженных приложений. дальнейшие мои опыты не смогли вытащить эту память из swap. она осталась там до перезагрузки. естественно, после перезагрузки памяти у нас до фига:



еще одно наблюдение, которое я сделал по мере тестов — mach_kernel и WindowServer кушают память (wired память). причем, в случае выгрузки приложений, они ее не возвращают системе, а в силу того, что это wired память, то и в swap ее не отдают. а это значит, что в случае, если они выросли слишком сильно (у меня бывало и по полгига на каждого), никаким образом, кроме перезагрузки, нельзя вернуть память, сожранную этими двумя процессами, в систему.

inactive, active => free

в случае необходимости, вы можете освободить большую часть inactive и active памяти. как показывает вышеприведенный эксперимент, часть inactive памяти действительно освободится, часть же перейдет в swap. для этого вы можете воспользоваться программой ifreemem или волшебным скриптом, который просто нужно запустить в терминале или сделать action в automator:

perl -e 'my $a = []; $a[5*10**8] = 1;'

меняя циферки, вы можете управлять размером освобождаемой памяти. вышеприведенный пример освобождает почти два гига памяти. с помощью perl вам не удастся освободить больше, чем три с небольшим гигабайта. насчет ifreemem не знаю.

после запуска подобного скрипта в системе с небольшим количеством свободной (free) памяти, фотошоп начинает грузиться и работать быстрее, потому что ему не приходится биться за каждый килобайт оперативки с неактивной памятью. но за все нужно платить. в случае, когда у вас действительно немного неактивной памяти, а большая часть памяти активна, то активная память уйдет в своп и вы получите однозадачную операционную систему — переключение на другие приложения будет исключительно мучительным (конечно, если у вас не mac pro с raid 5 из 8–ми дисков).