немного посмеявшись над ребятами, которые пытались определить, сколько же «приложений» выдержит мак, мне самому пришлось столкнуться с некоторой ограниченностью системных лимитов.
оказывается, что в mac os x 10.5 по умолчанию одним пользователем можно открыть не более 266 приложений. при этом часть из них — системные сервисы, поэтому реально запущеных приложений будет меньше. если такого количества не хватает, то можно увеличить лимит и об этом пойдет речь ниже.
но, к сожалению, эти лимиты тоже не бесконечны и довольно невелики. это значит то, что если вам вдруг понадобится производительный сервер, то mac os x вам этого просто не позволит сделать, несмотря на всю юникс начинку внутри.
как известно, у макоси есть две версии, клиентская и серверная. сейчас я буду говорить за первую, потому как второй в доступности нет.
как показывает команда «sysctl -a | grep maxproc», операционная система ограничила себя до 532 процессов в целом и не более 266 на одного пользователя. не очень–то пожируешь. ну что ж, на то нам дадены руки.
sysctl -w kern.maxproc=4096
sysctl: kern.maxproc: Invalid argument
опа, а это что такое?
это оказалось, что в ядре операционной системы записан жесткий лимит в 2500 соединений. превысить его можно только после пересборки ядра. то есть запустить под mac os x client более 2500 процессов невозможно.
в server 10.4.11 тоже есть подобный лимит, только он чуть ниже — 2068
для увеличения лимита можно добавить информацию в два файла:
/etc/sysctl.conf и /etc/launchd.conf
первый управляет ограничениями в ядре, а второй — в запускаемых приложениях операционной системы.
/etc/sysctl.conf
kern.maxprocperuid=1024
kern.maxproc=2048
/etc/launchd.conf
limit maxproc 512 1024
Thursday, April 9, 2009
Wednesday, March 25, 2009
postfix: no spam without antispam
борьба со спамом без антиспама.
примерно с месяц назад на своей работе я начал переносить почту со старого и неуправляемого CommunigatePro на более стандартный (в рамках почтового сервера под управлением Mac OS X) postfix. и после переноса аккаунтов обнаружил, что /var/log/mail.log растет не по дням, а по часам, причем на пару сотен мегабайт в час. к концу суток у меня был шестигигабайтный лог файл и около гигабайта новых писем. я довольно сильно испугался, что так будет и дальше.
сервер по умолчанию был настроен на прием корреспонденции только для известных адресов, других проверок не делалось.
это вынудило меня начать разбираться со встроенными механизмами фильтрации спама в postfix и возможности применить особенности протокола smtp для отсеивания всей этой корреспонденции. можно было бы попробовать поставить spamassassin или другие решения с открытыми исходниками и натюнинговать их, но гигабайт принятой почты меня совсем не радовал. платные варианты сразу же были исключены, так как спам в основном приходит на русском языке, а kaspersky antispam и спамоборона не имеют сборок под Mac OS X.
немного теории
любая машина, подключенная к интернет, может получить mx dns запись для любого из доменов и отправить туда почту. при этом, можно отправить почту не напрямую, а через специальный relay сервер, который уже сам займется доставкой почты до получателя. обычно relay сервера требуют авторизации отправителя для дальнейшей пересылки почты. те, которые не требуют авторизации, называются open relay. проблема, которая связана с ними — это то, что любая машина сможет послать письмо, которое будет выглядеть, как письмо, полученное от этого relay.
в итоге доставка почты выглядит примерно так:
машина пользователя => relay => … => relay => сервер назначения
отсылка почты напрямую используется сейчас не очень часто и, в основном, всякими сервисами и гиками, которые сподобились настроить local delivery. в том случае, когда пользователь отправляет почту через почтовую программу с указанием mail сервера и данных аутентификации или через web–интерфейс, то почта уходит напрямую с сервера почтового сервиса. при этом отсылка почты напрямую в большинстве случаев сразу же дает знать о себе: скорее всего у такого хоста не будет reverse dns записи или будет что–то выделяющееся, например ppp85-140-10-222.pppoe.mtu-net.ru; в случае серьезного сервиса его владельцы обычно заботятся о reverse dns записи.
reverse dns — это когда по ip адресу можно получить имя связанного с ним домена.
тут есть одна тонкость: спамер может зарегистрировать кучу доменов, купить кучу ip адресов, но ему придется все время покупать новые домены и ip адреса (потому что его будут блокировать — адрес–то известен), что не слишком выгодно. поэтому зачастую спамеры используют зараженные вирусами машины, чтобы ответственность легла на пользователя такой машины. большинство таких зараженных машин находится дома у пользователей, а самый распространненый тип домашнего подключения — это доступ с динамическим ip адресом.
поэтому, отказывая в получении почты с динамических адресов, мы ограничиваем неправильно настроенные интернет–сервисы, гиков с local delivery и сети машин домашних пользователей, зараженные вирусами и рассылающие спам.
для отсеивания спама также иногда применяется технология DNSBL, которая заключается в том, что система с DNSBL получает отчеты об ip адресах машин, которые рассылают спам и делают списки этих адресов доступными всем или подписчикам. сама система по задумке неплохая, но имеет порядочное количество нареканий. например, в некоторых системах DNSBL заблокированы целые подсети адресов и для администратора почтового сервера нет никакой возможности исключить из блокировки свою машину. или кто–то получил пароль для авторизованного аккаунта и начал рассылать с этого аккаунта спам. ip адрес попал в DNSBL и нужно тратить время, чтобы эта ошибка пользователя не отключила полностью отсылку почты с этого сервера. поэтому я не использую эту технологию и другим не рекомендую, так как моя практикапоказывает, что вреда от нее больше, чем пользы.
после отсеивания всех неугодных нам машин, мы беремся за то, как спамеры общаются с нашим почтовым сервером по SMTP протоколу. большинство доковылявших спам–ботов отваливается на простой проверке — в команде HELO должно быть полное доменное имя отправителя. дальше вставляем несколько простых проверок — на наличие указанного адресата, на количество адресатов в минуту, почту для которых мы готовы принять. дальше просто принимаем почту и надеемся, что тупых бот сетей больше, чем разумных.
практика
я сразу же принялся за анализ логов. сразу же стало видно, что есть достаточно большое количество спама исходит от машин, которые тупо перебирают адреса по словарю на домене. postfix не предоставляет встроенных инструментов для отрезания таких деятелей, посему эта проблема была отложена в долгий ящик, но к сведению были приняты некоторые настройки, которые ограничивают количество соединений, писем и получателей в одном письме.
различные «строгие» опции:
лимитирование слишком быстрых:
вторая проблема, которая стала сразу же видна — это соединения с динамических адресов различных интернет провайдеров (через dialup, adsl или подобные соединения) или тех адресов, которые вообще не имеют reverse dns записи. копания в поисках способа определения этих самых динамических пользователей привели меня к статье http://www.yekt.info/postfix_antyspam.html. там я и почерпнул необходимую информацию, но, к сожалению, действия, приводимые там мне не очень понравились, поэтому я расскажу, что сделал я, а те, кому интересно, смогут сравнить и сделать свои собственные выводы.
отклоняем желание клиента прогнать команды «по–быстрому»; разрешаем тех, кто ввел логин/пароль; разрешаем соединения из доверенных сетей; отклоняем тех у кого не совпадают сочетания ip адрес 1=>домен, домен=>ip адрес 2 и ip адрес 1 == ip адрес 2; проверяем клиента на отсутствие в известных dialup и dsl сетях.
ниже добавились:
проверка на известные проблемные helo, отказ от обслуживания клиентам, доменное имя которых вызывает подозрения
две оставшиеся проверки — на наличие домена у отправителя письма и правильное указание получателя.
результат
оказался хорош. например, за 24 марта было 433 158 попыток соединения с почтовым сервером, чтобы отправить почту и почта была доставлена лишь в 1 068 случаях.
как говорят пользователи, им кажется, что вся почта доходит, полезная почта не теряется. вместо гигабайта в день принимается около 4 мегабайт почты.
в следующей заметке я расскажу, как сделать так, чтобы имеющаяся система не проседала со временем.
примерно с месяц назад на своей работе я начал переносить почту со старого и неуправляемого CommunigatePro на более стандартный (в рамках почтового сервера под управлением Mac OS X) postfix. и после переноса аккаунтов обнаружил, что /var/log/mail.log растет не по дням, а по часам, причем на пару сотен мегабайт в час. к концу суток у меня был шестигигабайтный лог файл и около гигабайта новых писем. я довольно сильно испугался, что так будет и дальше.
сервер по умолчанию был настроен на прием корреспонденции только для известных адресов, других проверок не делалось.
это вынудило меня начать разбираться со встроенными механизмами фильтрации спама в postfix и возможности применить особенности протокола smtp для отсеивания всей этой корреспонденции. можно было бы попробовать поставить spamassassin или другие решения с открытыми исходниками и натюнинговать их, но гигабайт принятой почты меня совсем не радовал. платные варианты сразу же были исключены, так как спам в основном приходит на русском языке, а kaspersky antispam и спамоборона не имеют сборок под Mac OS X.
немного теории
любая машина, подключенная к интернет, может получить mx dns запись для любого из доменов и отправить туда почту. при этом, можно отправить почту не напрямую, а через специальный relay сервер, который уже сам займется доставкой почты до получателя. обычно relay сервера требуют авторизации отправителя для дальнейшей пересылки почты. те, которые не требуют авторизации, называются open relay. проблема, которая связана с ними — это то, что любая машина сможет послать письмо, которое будет выглядеть, как письмо, полученное от этого relay.
в итоге доставка почты выглядит примерно так:
машина пользователя => relay => … => relay => сервер назначения
отсылка почты напрямую используется сейчас не очень часто и, в основном, всякими сервисами и гиками, которые сподобились настроить local delivery. в том случае, когда пользователь отправляет почту через почтовую программу с указанием mail сервера и данных аутентификации или через web–интерфейс, то почта уходит напрямую с сервера почтового сервиса. при этом отсылка почты напрямую в большинстве случаев сразу же дает знать о себе: скорее всего у такого хоста не будет reverse dns записи или будет что–то выделяющееся, например ppp85-140-10-222.pppoe.mtu-net.ru; в случае серьезного сервиса его владельцы обычно заботятся о reverse dns записи.
reverse dns — это когда по ip адресу можно получить имя связанного с ним домена.
тут есть одна тонкость: спамер может зарегистрировать кучу доменов, купить кучу ip адресов, но ему придется все время покупать новые домены и ip адреса (потому что его будут блокировать — адрес–то известен), что не слишком выгодно. поэтому зачастую спамеры используют зараженные вирусами машины, чтобы ответственность легла на пользователя такой машины. большинство таких зараженных машин находится дома у пользователей, а самый распространненый тип домашнего подключения — это доступ с динамическим ip адресом.
поэтому, отказывая в получении почты с динамических адресов, мы ограничиваем неправильно настроенные интернет–сервисы, гиков с local delivery и сети машин домашних пользователей, зараженные вирусами и рассылающие спам.
для отсеивания спама также иногда применяется технология DNSBL, которая заключается в том, что система с DNSBL получает отчеты об ip адресах машин, которые рассылают спам и делают списки этих адресов доступными всем или подписчикам. сама система по задумке неплохая, но имеет порядочное количество нареканий. например, в некоторых системах DNSBL заблокированы целые подсети адресов и для администратора почтового сервера нет никакой возможности исключить из блокировки свою машину. или кто–то получил пароль для авторизованного аккаунта и начал рассылать с этого аккаунта спам. ip адрес попал в DNSBL и нужно тратить время, чтобы эта ошибка пользователя не отключила полностью отсылку почты с этого сервера. поэтому я не использую эту технологию и другим не рекомендую, так как моя практикапоказывает, что вреда от нее больше, чем пользы.
после отсеивания всех неугодных нам машин, мы беремся за то, как спамеры общаются с нашим почтовым сервером по SMTP протоколу. большинство доковылявших спам–ботов отваливается на простой проверке — в команде HELO должно быть полное доменное имя отправителя. дальше вставляем несколько простых проверок — на наличие указанного адресата, на количество адресатов в минуту, почту для которых мы готовы принять. дальше просто принимаем почту и надеемся, что тупых бот сетей больше, чем разумных.
практика
я сразу же принялся за анализ логов. сразу же стало видно, что есть достаточно большое количество спама исходит от машин, которые тупо перебирают адреса по словарю на домене. postfix не предоставляет встроенных инструментов для отрезания таких деятелей, посему эта проблема была отложена в долгий ящик, но к сведению были приняты некоторые настройки, которые ограничивают количество соединений, писем и получателей в одном письме.
различные «строгие» опции:
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
лимитирование слишком быстрых:
anvil_rate_time_unit = 60s
smtpd_client_connection_count_limit = 5
smtpd_client_connection_rate_limit = 6
smtpd_client_message_rate_limit = 6
smtpd_client_recipient_rate_limit = 10
вторая проблема, которая стала сразу же видна — это соединения с динамических адресов различных интернет провайдеров (через dialup, adsl или подобные соединения) или тех адресов, которые вообще не имеют reverse dns записи. копания в поисках способа определения этих самых динамических пользователей привели меня к статье http://www.yekt.info/postfix_antyspam.html. там я и почерпнул необходимую информацию, но, к сожалению, действия, приводимые там мне не очень понравились, поэтому я расскажу, что сделал я, а те, кому интересно, смогут сравнить и сделать свои собственные выводы.
отклоняем желание клиента прогнать команды «по–быстрому»; разрешаем тех, кто ввел логин/пароль; разрешаем соединения из доверенных сетей; отклоняем тех у кого не совпадают сочетания ip адрес 1=>домен, домен=>ip адрес 2 и ip адрес 1 == ip адрес 2; проверяем клиента на отсутствие в известных dialup и dsl сетях.
smtpd_client_restrictions =
reject_unauth_pipelining,
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_client_hostname,
check_client_access regexp:/etc/postfix/dul_checks,
permit
ниже добавились:
проверка на известные проблемные helo, отказ от обслуживания клиентам, доменное имя которых вызывает подозрения
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_helo_access regexp:/etc/postfix/helo_regexp,
check_helo_access regexp:/etc/postfix/dul_checks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
permit
две оставшиеся проверки — на наличие домена у отправителя письма и правильное указание получателя.
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
smtpd_recipient_restrictions =
reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit
результат
оказался хорош. например, за 24 марта было 433 158 попыток соединения с почтовым сервером, чтобы отправить почту и почта была доставлена лишь в 1 068 случаях.
как говорят пользователи, им кажется, что вся почта доходит, полезная почта не теряется. вместо гигабайта в день принимается около 4 мегабайт почты.
в следующей заметке я расскажу, как сделать так, чтобы имеющаяся система не проседала со временем.
Friday, March 20, 2009
Thursday, March 5, 2009
mysql grants dump
меня тут на собеседовании спросили: «а почему вы не любите mysql»?
я вам отвечу.
когда делается «grant privileges on … to 'user'@'hostname' … », то при наличии двух записей, указывающих на один и тот же ip адрес (например 'user'@'host.example.com' и 'user'@'10.0.2.1'), то выбирается всегда запись с ip адресом, а вот сообщение в логе выводится по reverse dns имени хоста. разработчики mysql, вот вам от меня гнилой помидор!
допустим, вы сдампили все базы mysql и хотите теперь восстановить базу к прежнему состоянию в другом месте.
и вуаля — не работают указанные вами гранты. хотите узнать почему? потому что разработчики mysql не умеют без костыликов и вам придется запустить этот костылик самому:
получите–ка, дорогие мои, в лицо собачьей какашкой.
я вам отвечу.
когда делается «grant privileges on … to 'user'@'hostname' … », то при наличии двух записей, указывающих на один и тот же ip адрес (например 'user'@'host.example.com' и 'user'@'10.0.2.1'), то выбирается всегда запись с ip адресом, а вот сообщение в логе выводится по reverse dns имени хоста. разработчики mysql, вот вам от меня гнилой помидор!
допустим, вы сдампили все базы mysql и хотите теперь восстановить базу к прежнему состоянию в другом месте.
mysql -u super -p <mysql_dump
и вуаля — не работают указанные вами гранты. хотите узнать почему? потому что разработчики mysql не умеют без костыликов и вам придется запустить этот костылик самому:
flush privileges
получите–ка, дорогие мои, в лицо собачьей какашкой.
Friday, January 9, 2009
beware perl
как ни странно, скрипт ниже по тексту письма работает без ошибок.
#!/usr/bin/perl
use strict;
print asdfagertghswdfgasdfgsdfgasdf;
# то же самое, когда перл не может определить контекст bareword, он рассматривает его как FILEHANDLE
{
no strict 'refs';
*{a} = sub {return "hello!!!";};
}
print a; # does nothing
print a (); # nothing
print "-=-=-=-=-=-=-=-";
print a(); # ok
print &a; # ok
#beware!
Wednesday, December 31, 2008
the beatles
некоторое время назад, благодаря постоянным «новостям» о том, что битлы наконец проложат свой путь в itunes music store, я решил таки послушать что и как они поют. и это оказалось для меня потрясением — большинство песен с точки зрения звука оказались беспомощным говном. я был в шоке от этого феномена и решил не обращаться к этой теме больше. но недавно услышал как fiona apple поет их песню и понял, в чем дело.
как оказалось, все просто. у битлов хорошая музыка и тексты. но пение и оранжировки портят все. если даже небольшая часть песен спета неплохо, то все остальные спеты и сыграны так, что просто уши вянут.
например — битлы:
и fiona apple:
второй по звуку для меня на порядок приятнее.
как оказалось, все просто. у битлов хорошая музыка и тексты. но пение и оранжировки портят все. если даже небольшая часть песен спета неплохо, то все остальные спеты и сыграны так, что просто уши вянут.
например — битлы:
и fiona apple:
второй по звуку для меня на порядок приятнее.
Tuesday, December 23, 2008
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.
написать нижеследующую простыню меня побудило то, что в определенный момент времени я, благодаря проворству своего домашнего животного и большой стеклянной банке чая, потерял некоторое количество важной информации. но даже это не очень важно, потому как впоследствии, клюнув на рекламные объявления, провел довольно большое количество времени в попытках восстановить данные с помощью автоматических программ и потерпел фиаско.
восстановление данных
тут начинается самое интересное. в силу того, что мой диск получил ощутимые физические повреждения (вмятина шириной в 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.
Subscribe to:
Posts (Atom)