Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1007 сообщений
Cообщения с меткой

hdd - Самое интересное в блогах

Следующие 30  »
ferderfre

Погоня за лихачом в Дзержинске закончилась столкновением с машиной ДПС

Вторник, 15 Августа 2017 г. 18:51 (ссылка)

­­­­­­­­­­­­­­­­­

Водитель, устpоивший погоню с двyмя экипажами ДПС в Дзержинске в Нижегоpодской облaсти, столкнулся с автомобилем полиции. Об этом сообщает телеканал «Звезда».

Инцидeнт пpоизошел pанним утpом 13 августа. На видeозапиcи с рeгистpатоpа видно, что сначалa полицейские пытаются остановить лиxача в гоpодe, но он, манeврируя между жилыми домами, избегает поимки. Погоня пpодолжилaсь на загоpодной тpассе. Там к коллегам присоединился втоpой экипаж ДПС.

В какой-то момент нарушитель пошел на сближение с машиной полиции. Автомобили столкнулись и упали в кювет.

Лиxача задeржали, им оказался 28-летний житель Тверской облaсти. В отношении нeго составлено более 10 пpотоколов об администpативных пpавoнарушениях.

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Грех администратора или восстановление данных из стучащего HDD Western Digital WD5000AAKX

Пятница, 23 Июня 2017 г. 23:30 (ссылка)

В одной маленькой софтверной компании хранение данных было организовано следующим образом: сервер, в котором обыкновенные SATA накопители средствами linux (mdamd) организованы в несколько массивов RAID 1, каждый из которых являлся хранилищем для одного из направлений разработки. Данный вариант при минимальных затратах относительно надежен, если за ним подобающим образом присматривать. Но системный администратор решил, что нет нужды регулярно проверять состояние массивов, и занимался иными делами. В июне 2017, получив жалобы о невозможности прочитать данные от пользователей одного из массивов, обнаружил, что собственно массива уже давно нет, и что на один из накопителей запись прекратилась в августе 2015, а второй с актуальными данными при попытке монтирования подвешивает ОС. Резервная копия за пределы сервера последний раз была сделана в ноябре 2016 года.





рис. 1



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



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



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



12 июня утром, сразу же после открытия, на пороге офиса нашей компании появляется человек, который сообщает, что ему срочно необходимо получить услугу бесплатной диагностики накопителя WD5000AAKX-221CA1, который подвешивает систему и не позволяет скопировать файлы. Накопитель без следов вскрытия.



Проводим стандартные диагностические мероприятия: визуальный осмотр, проверка цепей питания на печатной плате, сопротивления обмоток двигателя. Не обнаружив ничего крамольного, подключаем к порту PC3000 и подаем питание. Слышен нормальный звук раскрутки вала, прохождения калибровочного теста. По регистрам накопитель демонстрирует готовность к обмену данными. На запрос паспорта получаем от жесткого диска корректный ответ со всеми данными. Проверяем читабельность модулей микропрограммы и оцениваем их контрольные суммы. При анализе relo-list обнаруживаем, что он не пустой, что свидетельствует о том, что микропрограмма накопителя обнаружила некоторые проблемы на поверхности. Просматривая атрибуты SMART, замечаем, что 197 атрибут (текущее количество нестабильных секторов) весьма далек от нулевого значения, что подтверждает наличие проблем. Модифицируем в ОЗУ накопителя настройки: отключаем процедуры переназначения и добавления дефектов в relo-list, очищаем сам relo-list, запрещаем обновление журналов SMART. После такой модификации накопитель не будет выполнять процедуры оффлайн сканирования и обновлять журналы SMART. На этом этапе производим оценку качества чтения каждой из головок в зонах разной плотности записи. Тест подтверждает пригодность оригинального БМГ для вычитывания данных. Читаем 0 сектор.





рис. 2



Обнаруживаем, что в нем содержатся записи для трех разделов.



По смещению 0x00000800 (2048) секторов располагается первый раздел Linux RAID (0xFD), размер раздела 0x00064000 (409 600) секторов.



По смещению 0x00064800 (411 648) секторов располагается второй раздел Linux RAID (0xFD), размер раздела 0x39DC8000 (970 752 000) секторов.



По смещению 0x39E2C800 (971 163 648) секторов располагается третий раздел linux swap (0x82), размер раздела 0x00400000 (4 194 304) секторов.



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



На этом первичные диагностические мероприятия завершены, и их результат сообщается клиенту, также сообщается ценовая ниша услуги от 250 до 350 белорусских рублей и срок выполнения около 2-3 рабочих дней (исключительно в дневное время, так как накопитель требует постоянного наблюдения). Если необходимо выполнять работы во внеурочное время для сокращения сроков, то это возможно, но это прямо отразится на стоимости. План работ: модификация микрокода накопителя, локализация дефектных зон, чтение стабильных зон, анализ метаданных файловых систем на копии, вычитывание недостающих метаданных из проблемных зон, повторный анализ и построение цепочек нужных файлов для вычитывания из проблемных зон, при необходимости мероприятия по анализу регулярных выражений в областях, не занятых файлами, и возможные реконструкции поврежденной файловой системы.



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



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



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



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



15 июня в середине рабочего дня снова появляется данный клиент (он же системный администратор), но уже не один, а в сопровождении своего прямого руководителя. Сходу была озвучена претензия, что после наших диагностик накопителю стало намного хуже, что он теперь стучит и не определяется в BIOS. На этом моменте останавливаем монолог системного администратора и говорим, что мы готовы принять письменную претензию и дать на нее ответ в установленный законом срок, но прежде, чем переходить к ведению диалога в подобном русле, давайте проведем визуальный осмотр накопителя при Вас и также сравним отличается ли его внешний вид от того, что был, а также при необходимости просмотрим видеозапись вчерашнего дня и установим было ли что-либо в наших действиях, что могло серьезным образом усугубить ситуацию. Системный администратор хотел было начать перечить, но в диалог вмешался его руководитель, который велел системному администратору выложить жесткий диск на стойку.



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



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



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



По результатам анализа второго накопителя установлено, что имеют место небольшие дефектообразования (именно из-за них накопитель был исключен из массива), и согласно метаданным файловой системы пользовательских данных после августа 2015 года нет. Таким образом вскрылся факт, что отказ дисков не был одновременным.



В условиях ламинарного бокса было произведено вскрытие накопителя. Повреждения БМГ были заметны визуально и даже не требовали снятия для осмотра под микроскопом. Но фотофиксация была сделана.





рис. 3



В данном БМГ обе подвески были деформированы подобным образом. Такие деформации обычно являются следствием неумелого вывода головок с поверхности на парковочную рампу. Попытки старта этого накопителя приводили к появлению дополнительных царапин на поверхности пластин. К счастью, попыток старта было немного, и окончательного убийства данных не состоялось, но характер царапин таков, что возможно перерождение в запилы.



Таким образом, вместо заурядной задачи с вычитыванием накопителя с дефектами, из-за особого усердия системного администратора имеем задачу, где необходимо выполнить пересадку БМГ и перспективы весьма туманны, так как имеются радиальные царапины в начале диска. Служебная зона данного накопителя находится в самом начале пластины т.е. в зоне с царапинами.





рис. 4



Обратим внимание, как изувечен край пластины оборванными слайдерами (зона повреждений примерно 0,1-0,3мм, из-за увеличения кусок окружности вырождается почти в прямую). Благо, что в этом месте при сходе с рампы у исправного БМГ слайдеры находятся еще достаточно высоко, поэтому эти самые сильные повреждения пластины угрозы не представляют.



Данная информация доводится до Заказчика, также информируем о том, что стоимость существенно выросла по причине возникновения необходимости пересадки БМГ от аналогичного донора (Tahoe LT), дополнительных работ по пересадке, а также велика вероятность, что вряд ли хватит одного донора при вычитывании проблемных зон, так как деградационные процессы будут прогрессировать. Заказчик без колебаний соглашается.



Приступая к работе, производим подбор нескольких комплектов БМГ от накопителей-доноров с учетом близости адаптивных параметров, чтобы получить максимально устойчивое чтение. Обеспыливаем гермоблок пациента и производим процедуры перестановки БМГ от накопителя донора с помощью специализированного инструмента.





рис. 5



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





рис. 6



Запрашиваем паспорт накопителя и получаем пустышку, что свидетельствует о том, что накопитель не смог загрузить из служебной зоны все модули, которые необходимы для старта. Анализируем версию кода в ПЗУ накопителя и подбираем подходящий оверлей из нашей базы данных микропрограмм скопированных из накопителей. После загрузки его в память накопителя получили возможность полноценно читать и анализировать содержимое служебной зоны. По результатам проверки целостности служебной зоны нечитабельными оказались 0x11 (основной оверлей), 0x31 – транслятор, 0x32 – relo-list, 0x33 – P-list, 0x34 – G-list, 0x43 – адаптивные параметры, а также модули, ответственные за работу SMART.



Производим посекторную вычитку наиболее критичных модулей. P-list прочитался с небольшим количеством дефектов, расположение которых достаточно далеко от начала модуля. Аналогичная картина с модулем адаптивных параметров. Модули транслятора, G-list, relo-list оказались нечитабельными на 100%. Подобные повреждения модулей случаются при работе накопителя с не совсем исправными головками при попытке переписать модуль микропрограммой накопителя.



Для восстановления модуля транслятора записываем все необходимое, полученное из служебной зоны пациента, в накопитель-донор, в том числе и реконструированные 0x33 и 0x43. Выполнив пересчет транслятора с учетом P-list получим оригинальный 0x31 модуль за счет работы самой микропрограммы накопителя. Информация о скрытых дефектах в модуле 0x34 безвозвратно потеряна, поэтому создадим модуль пустышку без записей. Аналогичное действие выполним и с модулем 0x32.



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



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



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





рис. 7



Есть проблемы с чтением в границах swap раздела, но их мы игнорируем, так как раздел представляет весьма малую ценность. В границах основного второго радела чтение идет без нареканий до 57 89х ххх сектора, затем начинают появляться первые нестабильности.



Изменим чтение с UDMA режима на PIO для лучшего контроля процесса чтения и провизведем вычитку метаданных файловой системы (Ext4) второго раздела. Завершив этут операцию на 99,99% перейдем к чтению мини зон с коротким таймаутом и прыжком 10 000 секторов в случае нестабильности. Данная мера позволила нам дочитать более 85% от непрочитанного объема.



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



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



В процессе проведения работ Заказчику пересылались отчеты о поврежденных файлах после каждой деградации донорского БМГ и согласовывалось использование каждого дополнительного донора. При использовании третьего динамика чтения была малозаметной, по этой причине было принято решение о прекращении дальнейших попыток получить оставшиеся данные из дефектных зон. Удалось получить более 95% всех файлов (и более 99,5% согласно основному техническому заданию). Данный результат удовлетворил Заказчика.



В заключение подведем итоги. Налицо халатное отношение системного администратора к своим обязанностям. Также бросается в глаза неуместная эмоциональность руководства, которая вредит рабочему процессу. Ведь именно из-за прессинга со стороны руководства системный администратор пытался минимизировать свои расходы и совершил множество необдуманных поступков, усугубивших состояние накопителя, чем поставил под угрозу окончательного уничтожения пользовательские данные, которые для компании представляли ценность во много раз больше, чем стоимость услуги восстановления данных. Хочется обратить внимание руководящего состава, что в подобных ситуациях срываться на эмоции – непозволительная роскошь. Куда более разумным решением будет анализ проблемы и оценка собственных возможностей для ее устранения и, если необходимо, поиска исполнителей. И лишь после решения основной проблемы разбираться в степени вины системного администратора и говорить о каких-либо взысканиях за нанесенный своим бездействием ущерб. Также руководству стоит разделить бремя вины со своим подчиненным, так как именно недоработка должностных инструкций или полное их отсутствие создало условия для развития подобной ситуации.



Предыдущая публикация: Неглубокое погружение или восстановление данных с жесткого диска после затопления офиса
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331512/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Неглубокое погружение или восстановление данных с жесткого диска после затопления офиса

Пятница, 16 Июня 2017 г. 23:30 (ссылка)

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



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



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





рис. 1



Проанализировав резервные копии данных, которые находились вне офиса, было принято решение о необходимости восстановления данных с некоторых накопителей. Одним их них был накопитель Samsung HD753LJ.



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





рис. 2



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





рис. 3



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





рис. 4



Снимаем блок магнитных головок (БМГ) и обследуем отверстие с резьбой в корпусе накопителя и его окрестности, а также сам БМГ под микроскопом. В результате осмотра обнаружены небольшие разводы у самого резьбового соединения, что говорит о том, что жидкости попало достаточно мало и на момент поступления накопителя к нам она уже вся успела испариться. Деформаций подвесок и слайдеров не обнаружено, коммутатор-предусилитель визуально без повреждений. Проводим операцию удаления солей, содержавшихся в жидкости, во избежание разлета пыли по гермоблоку, как на корпусе, так и на самом БМГ. Также замеряем сопротивление всех выводов на колодке от коммутатора-предусилителя и сравниваем его с сопротивлением аналогичного накопителя. Результат проверок позволяет предположить исправность коммутатора-предусилителя. Исходя из того, что серьезных загрязнений не обнаружено, отсутствуют деформации подвесок и слайдеров, а также есть основание предполагать, что коммутатор-предусилитель исправен, приходим к выводу, что нет необходимости производить пересадку пакета дисков в другой корпус и также нет необходимости использовать БМГ от накопителя-донора. Собираем накопитель обратно.



Исходя из результатов первичного визуального осмотра очевидно, что печатная плата «контроллера» данного накопителя деградировала в результате электрохимической коррозии и не может быть использована. В данном семействе (F1_3D) ПЗУ располагается в MCU Marvell 88i8826E. Учитывая, что неизвестно «жив» ли данный MCU, а также сложность пайки BGA микросхем, варианты с получением оригинального содержимого ПЗУ исключим.



В случае накопителей Samsung данного семейства применима методика Hot swap. Прочитав модули микропрограммы, можно установить версию оригинальной микропрограммы, а также понять, помещался ли код микропрограммы целиком в ПЗУ микроконтроллера или для его хранения использовались оверлеи в служебной зоне.





рис. 5



Проведя анализ модуля FSI, мы установили версию микропрограммы 1AG08ugB.d35. Оценивая содержимое модулей 73_MOVLY, 19_BOVLY, обнаруживаем, что они целиком заполнены нулями. Данное наблюдение позволяет сделать вывод, что для восстановления данных можно использовать практически любое ПЗУ с совместимым идентификатором платформы, которое не использует модули 19 и 73 для хранения исполняемого кода.



Используем плату донора, в которую запишем ближайшее совместимое ПЗУ Ближайшая версия в наличии оказалась 1AA18HuM.d35.



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





рис. 6



По регистрам накопитель также сообщил о готовности к обмену данными.





рис. 7



В ОЗУ жесткого диска модифицируем количество аппаратных повторов со 100 попыток чтения до 2, чтобы не провоцировать долгие задержки на нечитабельных участках, а также частично отключаем процедуры оффлайн-сканирования.



Создаем задачу посекторной копии на другой накопитель и первым делом строим карту зонного распределения.





рис. 8



Начинаем чтение в UDMA режиме с таймаутом ожидания готовности 300 миллисекунд, с прерыванием операции при обнаружении нестабильности, подачей программного сброса и прыжком на 100 000 секторов вперед.



Обнаруживаются UNC ошибки на секторах 6 24х ххх и 89 36х ххх. Остальные участки читаются без затруднений.



Отправляем накопитель в спящий режим и на копии производим анализ нулевого сектора.





рис. 9



На рис. 9 видно, что присутствуют записи о двух разделах. Первый раздел начинается с сектора 0x0000003F (63) и его длина 0x061A7927 (102 398 247) секторов. Второй раздел начинается с сектора 0x061A7966 (102 398 310), и его длина составляет 0x446AF55B (1 147 860 315) секторов. По смещению 0x1BE находится значение 0x80 – признак активности раздела (раздел является загрузочным). Согласно локализации дефектов очевидно, что они приходятся на первый раздел.



В секторе 63 располагается загрузочный сектор первого раздела, в котором кроме кода загрузчика, передающего управление NTLDR, находятся параметры файловой системы.





рис. 10



Из параметров файловой системы отметим: сектор 512 байт, 8 секторов в кластере, размер раздела в загрузочном секторе соответствует размеру, описанному в таблице разделов.

Первый сектор MFT рассчитывается по формуле: X*Y+Z, где X номер первого кластера расположения MFT, Y – количество секторов в кластере, Z – смещение до начала раздела.



0x00000000000C0000*0x08+0x3F=0x000000000060003F (6 291 519)



Так как по этому смещению у нас недочитанный фрагмент, то рассчитываем позицию MFT Mirror



0x000000000061A792*0x08+0x3F=0x00000000030D3CCF (51 199 183)



По этому смещению нет непрочитанных фрагментов. Определив позицию MFT и проведя анализ ее расположения, строим карту.





рис. 11



Производим чтение частично непрочитанного первого фрагмента MFT. Операция проходит без затруднений.



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





рис. 12



Первый является служебной структурой NTFS, которая некритична.



Второй является файлом виртуальной памяти в Windows и тоже не представляет ценности для Заказчика.



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



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



Предыдущая публикация: Всегда ли надежно шифрование или восстановление данных с внешнего жесткого диска Prestigio Data Safe II
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331090/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

В чем особенности работы дисков в NAS: экспресс-тест HDD WD Red

Среда, 14 Июня 2017 г. 11:09 (ссылка)

Это одна из историй о технологиях, которые отличают серию WD Red от обычных дисков. Они помогают повысить отклик системы, не дают выпасть диску из массива и позволят ему беспроблемно работать в круглосуточном режиме. Плюс мы сделали базовые тесты производительности самих дисков и их работы в WD MY CLOUD DL2100. Читать далее

https://habrahabr.ru/post/330804/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Всегда ли надежно шифрование или восстановление данных с внешнего жесткого диска Prestigio Data Safe II

Суббота, 10 Июня 2017 г. 12:42 (ссылка)

Владелец небольшого предприятия вечером в понедельник решил заняться финансовым анализом текущих дел. Придя вечером домой, он расположился в домашнем кабинете, подключил к ноутбуку внешний накопитель Prestigio Data Safe II 500ГБ и погрузился в цифры. Внезапно его мысли прервал донесшийся шум, а следом в помещение с пронзительным мяуканьем влетел домашний любимец, который, игнорируя все препятствия, запрыгнул на стол, пулей промчался по нему, совершил прыжок на шторы и взобрался на карниз, где в итоге замер и лишь подозрительно косился на окружающих, шипя при любой попытке приближения.



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





рис. 1



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



Администратор, убедившись в тщетности попыток работать с накопителем через USB, разобрал бокс, извлек него HDD Toshiba MK5059GSXP и подключил к SATA порту компьютера. Загрузив Windows, в оснастке управления дисками обнаружил, что с точки зрения ОС накопитель не содержит ни одного раздела. Была осуществлена попытка запуска программы автоматического восстановления, но сканирование, едва начавшись, подвесило компьютер, и из накопителя послышались щелчки. На этом этапе было принято решение, что пора остановиться.



С такой предысторией накопитель поступил в нашу лабораторию восстановления данных. Исходя из того, что накопитель был после удара и при попытке сканирования начал издавать стучащие звуки, то первой операцией будет его очистка от пыли и проведение обследования в условиях ламинарного бокса. Тщательному обследованию подлежат подвески и слайдеры БМГ, рециркуляционный воздушный фильтр, а также верхняя поверхность в пакете дисков.





рис. 2



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



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





рис. 3



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



Попытка записи на неиспользуемый трек служебной зоны приводит к тому, что жесткий диск начинает издавать стучащие звуки, что явно говорит о проблемах с записью. Так как возможности переписать нечитаемый модуль у нас нет, то не будем пытаться записать чистый модуль G-list.



Для накопителей Toshiba, у которых не работают или некорректно работают записывающие головки, либо имеются серьезные повреждения в служебной зоне, которые не позволяют корректно функционировать, можно использовать особенности технологического режима. После включения технологического режима, накопитель меняет логику работы: не осуществляется запись в SMART логи, отключено оффлайн сканирование, а также система трансляции работает без учета записей в P-list и G-list.



Перед вычитыванием в технологическом режиме необходимо проанализировать P-list жесткого диска, чтобы учесть все исключенные области из PBA диапазона и при вычитывании получить данные пользователя, которые записывались в рамках LBA диапазона (в котором учтены исключения из P-list), без сдвигов.



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





рис. 4



В данном случае без особых затруднений было прочитано до 15 998 ххх секторов. Потом обнаружились затруднения в чтении.





рис. 5



Попытка перестроить цепочки в порядке возрастания с дальнейшим чтением показало наличие дефектов от самого начала логического диапазона.





рис. 6



Исключаем чтение по головке №0 и пытаемся читать далее, следом обнаруживаются проблемы с 249 xxx сектора, также исключаем чтение по головке №2. Выполняем чтение зон головками №1 и №3 на интервале от 0 до 15 998 975 сектора.



Для дальнейшего вычитывания проблемных зон будем использовать PIO режим для более точного контроля состояния накопителя. Выполнив некоторое число попыток чтения с разным таймаутом ожидания готовности и разным размером прыжков при обнаружении нестабильностей, переходим к этапу многопроходного чтения дефектов. В результате всех попыток чтения непрочитанными остались менее 3000 секторов из всего множества 976 773 168 секторов.



Выполняем заполнение непрочитанных секторов на копии паттерном 0xDE 0xAD. Проводим анализ регулярных выражений для различных популярных типов файлов и обнаруживаем отсутствие пользовательских данных на диске, но в тоже время можно сказать, что диск заполнен некими данными более чем на 95% (согласно того, какое количество секторов заполнено ненулевыми значениями).



На этом этапе отложим посекторную копию и проведем анализ особенностей USB-SATA моста, используемого в боксе.





рис. 7



Данный USB-SATA адаптер основан на MCU J-Micron 20339. Возьмем накопитель, все сектора которого заполнены 0x00, присоединим к данному адаптеру и подключим к ПК.





рис. 8



ОС обнаружила 2 накопителя по 20Мб. При анализе выяснилось, что первый раздел доступен только для чтения. На втором запись доступна.





рис. 9



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



При открытии в дисковом редакторе в каждом секторе любого из устройств видим заполнение неким паттерном.





рис. 10



Отключим диск от данного адаптера и проанализируем, располагает ли контроллер некие метаданные на самом накопителе, так как диск изначально был полностью заполнен нулями. В секторе 0x18FBF (102 335) и секторе 0x18FCF (102 351) обнаруживается заполнение неким хаотичным содержимым.



Начиная с сектора 102 352 выполним запись номера сектора в первые 4 байта на протяжении 40 960 секторов. Вновь подключив диск к адаптеру проанализируем заполнение первого двадцати мегабайтного раздела. Увидим, что на протяжении всего раздела остался прежний паттерн, как на рис. 10, но с изменениями в первых байтах. Выполнив XOR операции между и первоначальным паттерном и текущими значениями, получим сектора, содержимым которых будут нули с номером сектора в первых 4 байтах.



На основании этого, мы можем утверждать, что данный контроллер шифрует данные посредством XOR операции, размер ключа 512 байт. Недостаток данного «шифрования» в том, что в секторах, заполненных нулями, но прочитанных через данный USB-SATA адаптер, будут находиться все 512 байт ключа в оригинальном виде. Также обратим внимание, что в накопителях, где в секторах 102 335 и 102 351 содержится некорректное содержимое с точки зрения микропрограммы JM20339, то произойдет формирование новых ключей случайным образом.



Вернемся к копии проблемного накопителя и проанализируем карту прочитанного. Удостоверимся, что ключевые сектора 102 335 и 102 351 прочитаны и дополнительные методы анализа для нахождения ключа не потребуются. Перенесем содержимое ключевых секторов на чистый накопитель и подсмотрим, какой XOR паттерн сформирует микропрограмма контроллера JM20339.



Создадим резервную копию накопителя, на который была записана посекторная копия пациента, и выполним XOR операцию над каждым сектором, начиная с сектора 102352 с полученным ключом.



Начав анализ регулярных выражений, обратим внимание, что обнаруживается множество признаков наличия популярных типов файлов (jpg, doc, xls и т.п.). Это обстоятельство подтверждает корректность расшифровывания данных.



Для удобства анализа в 0 секторе напишем классическую таблицу разделов, в которой опишем 3 раздела, имеющихся на данном накопителе. В нашу первоначальную задачу подставим накопитель с расшифрованными данными.



Так как в задании клиентом было поставлено восстановление данных из скрытого раздела, то проведем оценку целостности файловой системы на нем посредством анализа расположения метаданных и проверим, нет ли непрочитанных участков. Анализ выявляет, что 16 секторов в MFT прочитать не удалось, что говорит о потере не более 8 файловых записей. Дальнейшее сопоставление файлов с картой прочитанного позволяет выявить еще 73 файла, пострадавших в результате контакта слайдеров с поверхностями пластин.



99, 9% восстановленных файлов – это конечный результат, который удовлетворил клиента.

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



Предыдущая публикация: Восстановление данных с внешнего жесткого диска Seagate FreeAgent Go
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330642/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Восстановление данных с внешнего жесткого диска Seagate FreeAgent Go

Суббота, 03 Июня 2017 г. 11:01 (ссылка)

Внешний жесткий диск Seagate FreeAgent Go 500Gb верой и правдой служил своей владелице, но в один из не самых лучших для него дней стал жертвой человеческих эмоций, когда владелица в пылу семейной драмы швырнула устройство в объект, вызывающий у нее сильное раздражение – в своего мужа. Муж серьезно не пострадал, а вот с накопителем дела обстояли хуже. При подключении в USB порт компьютера накопитель издавал тихие жужжащие звуки и не начинал вращение вала.





рис. 1



В таком состоянии внешний жесткий диск поступил в нашу лабораторию восстановления данных. Визуальный осмотр не выявляет каких-либо деформаций самого бокса. Учитывая, что в предыстории значится удар, такой накопитель подлежит обязательному вскрытию в условиях ламинарного бокса без каких-либо попыток включения во избежание дальнейших разрушений. Из бокса извлекается жесткий диск Seagate ST9500325AS (Momentus 5400.6), представитель семейства Wyatt. Корпус винчестера без деформаций и вмятин на крышке. Проводим мероприятия по удалению пыли из всех возможных мест и отправляемся в ламинарный бокс. Сняв крышку, обнаруживаем, что блок магнитных головок находится вне парковочной рампы.





рис. 2



С использованием съемников осуществляем вывод БМГ на рампу. Далее извлекаем БМГ и тщательно осматриваем все 4 слайдера и подвески под микроскопом на предмет деформаций и наличия посторонних частиц. Также осматриваем рециркуляционный фильтр и поверхность верхней пластины в месте залипания БМГ. В нашем случае установлено, что деформаций подвесок нет, загрязнения слайдеров отсутствуют. На поверхности пластины присутствует «пятно» с повреждением, которое невозможно увидеть невооруженным глазом. На рециркуляционном фильтре отсутствуют металлические частицы. Повреждений пластиковой парковочной рампы нет, перекоса пакета дисков нет.



По результатам данного осмотра установлено, что допустимо осуществить попытку чтения оригинальным блоком магнитных головок, но необходимо учитывать наличие повреждений у внешнего края пластин. Устанавливаем блок магнитных головок обратно в накопитель и производим сбор. Зная, что накопитель подвергся ударной нагрузке, выполним замену оригинальной печатной платы 100536286 Rev E, на заведомо исправную плату накопителя-донора с переносом ПЗУ. Данная мера рекомендуема, чтобы не получить неприятных сюрпризов из-за потенциально возможных микротрещин.



Подключаем накопитель к SATA порту и терминалу и подаем питание. В нашем случае накопитель начал вращение вала без какого-либо биения. Послышался нормальный звук калибровочного теста и через несколько секунд накопитель сообщил о своей готовности к обмену данными в регистрах.





рис. 3



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



Rst 0x08M

(P) SATA Reset



Сразу же в ОЗУ накопителя необходимо найти модуль конфигурации HDD (ID=0x2A) и убрать оттуда все ключи, которые ответственны за запуск процедур оффлайн сканирования, автономного и отложенного скрытия дефектов, а также отключить процедуры автореаллокации при чтении и записи. Эта мера необходима, чтобы накопитель при обнаружении проблем не пытался запускать процедуры обслуживания дефектов, так как они приведут к длительной задержке БМГ над проблемным участком, что может спровоцировать лавинообразное разрушение (запиливание пластины). Структура модуля 0x2А (system file FC36608F) достаточно проста (порядок записи параметров достаточно очевиден). При исследовании (исследования проводились и продолжают проводиться для всех накопителей F3 архитектуры) главной сложностью было установление назначения каждого из параметров и допустимые значения. Использование современных версий комплекса PC3000 существенно упрощает процедуру правки значений.



Резервируем микропрограмму накопителя (ПЗУ, модули, “system files”). Проверяем на тестовых модулях, которые не важны для функционирования накопителя, способность записи и чтения записанного каждой из головок. Удостоверившись в корректной работе всех головок, перейдем к оценке качества их чтения в пользовательской зоне. Для этого построим карту зонного распределения в границах всего логического пространства (от 0 до 976 773 167 сектора LBA диапазона). Оценив размер мини-зон, можно сделать вывод, что для оценки читабельности головок в данном экземпляре достаточно непрерывно прочесть около 300 000 секторов в конце логического пространства, около 450 000 секторов в середине и около 600 000 в начале диска (зная о наличии повреждения пластин, начало диска не тестируем).

Удостоверившись в возможности чтения всеми головками, настроим параметры чтения: UDMA режим, таймаут операции чтения не более 500 миллисекунд, при отсутствии готовности программный сброс и пропуск мини-зоны. Построив список мини-зон в обратном порядке, приступим к последовательному чтению мини-зон (созданию посекторной копии).





рис. 4



99% логического пространства были прочитаны без каких-либо затруднений. Начиная с LBA 6 541 ххх по головке №1, обнаружилась первая задержка. Чтение было немедленно прервано и накопитель отправлен в sleep режим (парковка головок на рампу, остановка вала, но микропрограмма остается загруженной в ОЗУ жесткого диска. Перестроим список зон в прямой порядок и приступим к последовательному чтению.





рис. 5



С LBA 2 518 ххх также обнаружилась задержка чтения по головке №1. Также быстро отправляем накопитель в спящий режим. Проводим грубую оценку границ дефектной зоны и размер 6 541 000 – 2 518 000= 4 023 000, что примерно равно 2 GB.

Дальнейший анализ проводим исключительно копии на исправном накопителе. Оценим содержимое LBA 0.





рис. 6



Значение 0x07 по смещению 0x1C2 сообщает нам о том, что тип раздела NTFS (или ExFAT).



Значение 0x00000800 по смещению 0x1C6 информирует о том, что раздел начинается с сектора 2 048.



Значение 0x3A384800 по смещению 0x1CA говорит, что длина раздела 976 766 976 секторов.

Перейдем к сектору 2 048





рис. 7



Из параметров NTFS видим, что сектор 512 байт, секторов в кластере 8, размер кластера 512*8=4096 байт. MFT располагается с кластера 0x00000000000C0000 (786 432) или с сектора 6 293 504 (786 432*8+2048). MFT Mirror находится в кластере 0x0000000000000002 (2) или берет начало с сектора 2 064 (2*8+2048).



Зная границы дефектообразования, можем заметить, что с высокой вероятностью на область с MFT придутся дефекты. Для этого оценим первую запись MFT (в MFT Mirror, которая дублирует первые 4 записи MFT так как она прочитана). В нашем случае этот файл расположен в виде одного фрагмента, начиная с сектора 6 293 504 и протяженностью 277 092 сектора.





рис. 8



Обратим внимание, что основные затруднения в чтении были зафиксированы по головке №1, поэтому начнем чтение с зоны по головке №0. Пробудим накопитель из спящего режима и прочитаем фрагмент MFT по нулевой головке. В данном случае это не вызвало затруднений и позволило получить более 75% важнейшей структуры. Далее используем PIO режим для лучшего контроля операций чтения и попытаемся прочесть оставшиеся 68 400 секторов из проблемной зоны. Манипулируя размерами прыжков, таймаутами ожидания готовности, размером блока при чтении в несколько проходов, производим чтение проблемного участка. В области MFT остается 18 непрочитанных секторов, которые по расположению повторяются (цикличность соответствует SPT для этих зон), что свидетельствует о царапине на этой пластине.



Снова отправив накопитель в спящий режим, произведем анализ записей в MFT на копии и оценим расположение файлов, чтобы понимать, какие из них попадают в дефектную зону. Обнаруживается порядка 50 пострадавших файлов. Сверяемся с техническим заданием и выясняем, что можно отбросить из сценария вычитывания более 35 файлов. Для остальных построим цепочки их расположения и отсортируем в порядке следования.



При чтении заметим, что кроме проблем на поверхности, читаемой первой головкой, обнаруживаются проблемы по поверхности, читаемой головкой №3. Исключим чтение цепочек по проблемным поверхностям и прочитаем участки по поверхностям 0 и 2.



Далее попытаемся возобновить чтение проблемных цепочек головками №1 и №3, и менее, чем через 30 секунд из накопителя раздается достаточно громкий стук. Пытаемся подать сброс, но накопитель не реагирует и продолжает стучать. Принимаем решение об отключении питания. Повторное включение питание начинается со стука из накопителя. Отключаем питание и делаем вывод о развитии деградационных процессов вследствие чтения поврежденной зоны.



Отправляемся в ламинарный бокс и осматриваем произошедшее. Верхняя поверхность выглядит идеально, но под микроскопом обнаруживается начавшийся лавинообразный процесс разрушения пластины (запил). Наличие металлических частиц на слайдерах №1 и №3 уточняет диагноз.

Из посекторной копии создаем файловую копию с переносом файлов, имеющих недочитанные фрагменты, в отдельную папку (с оригинальной иерархией). Также уточненно проводим анализ MFT, чтобы понимать, к чему привела потеря 18 секторов. Из анализа повреждений можно однозначно установить, что утеряно не более 7 файлов. К сожалению, Bitmap также находится в дефектной зоне, и его содержимое не может быть использовано для анализа.



При приемке результата владелица диска осталась довольна результатом (более 99,9% нужных данных) и посчитала, что нет нужды проводить дополнительный анализ регулярных выражений для поиска пропавших файлов из-за повреждений MFT.



В качестве заключения хочу обратить внимание многих пользователей, что не все так просто в случае накопителей у которых «головки» залипли вне парковочной рампы. И насколько порой опасны предложения людей, далеких от понимания принципов работы накопителя на жестких магнитных дисках, самостоятельно вскрыть устройство и вывести головки, а далее используя dd из Linux или WinHex под Windows выполнить «безопасную» посекторную копию. Если бы к накопителю, описанному в публикации, были бы применены подобные меры, то он бы превратился в труп без возможности восстановления данных при чтении второго гигабайта.



Предыдущая публикация: Немного реверс-инжиниринга USB flash на контроллере SK6211

Публикация вне habrahabr: Восстановление данных с неисправного HDD WD4000FYYZ-01UL1B1
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330120/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
vzglyad

Преимущества и недостатки SSD дисков

Четверг, 11 Мая 2017 г. 19:03 (ссылка)


5766557_16 (700x468, 63Kb)



Далеко не каждый сейчас может позволить себе иметь в компьютере SSD диск. Его стоимость может достигать стоимости современной игровой видеокарты.



 



Но действительно ли он так важен в наших компьютерах?



Давайте попытаемся разобраться что такое SSD диск, чем он так хорош или плох и нужно ли отправлять на свалку жесткий диск HDD.



Более подробно читайте и смотрите на сайте : https://www.ru24.top/hi-tech/obzory/preimushhestva-i-nedostatki-ssd-diskov.htm

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Konduktor

Как восстановить файлы с внешнего жесткого диска.

Четверг, 16 Марта 2017 г. 20:35 (ссылка)

Это цитата сообщения Владимир_Шильников Оригинальное сообщение

Как восстановить файлы с внешнего жесткого диска.


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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
vadimka_mt

Жесткий диск с функцией самоуничтожения данных

Среда, 15 Февраля 2017 г. 16:19 (ссылка)


Был у меня недавно такой замечательный случай, когда жесткий диск toshiba на 500 гиг сам по себе удалял информацию. Приведу пример - закидываю на него инфу и всё нормально. После перезагрузки компьютера, вместо жестого диска стоит только значек, при нажатии на который всплывает сообщение - "Жесткий диск не отформатирован. Отформатировать?"



Продолжение: http://dgz.livejournal.com/283203.html

-------

dgz.livejournal.com

vk.com/xulliganchik

facebook.com/VadimYatsenko

plus.google.com/u/0/+VadimYatsenko4

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
vadimka_mt

Впечатления о Samsung 850 EVO

Пятница, 10 Февраля 2017 г. 22:15 (ссылка)


Странно получается, что новое не всегда лучше старого. Был как-то у меня жесткий диск на 80 гигабайт, работал безупречно, за все время ни одного сбойного сектора, уж и не помню сколько ему лет было. А тут на днях посыпался жесткий диск Toshiba на 500 гиг. в ноутбуке, которому 3 года от роду.



Samsung 850 Evo/3914366_0_138e8f_55961e3b_orig (700x466, 37Kb)





Работаешь себе и ни с того ни с сего выскакивает синий экран. Пару раз прокатило, пока ОС перестала грузиться вообще. Переустановил заново - на месяц помогло. Опять стали появляться ошибки и после смены ОС 2 раза за неделю, решил все-таки пересесть на SSD. Новые технологии и всё такое.



Подробности: http://dgz.livejournal.com/280000.html



#SSD #samsung #evo850 #hdd #toshiba #Intel

-------

dgz.livejournal.com

vk.com/xulliganchik

facebook.com/VadimYatsenko

plus.google.com/u/0/+VadimYatsenko4

youtube.com/channel/UCT-cGyGyKwDKD1xSLBJ8v6w

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
masiania1

А что же скрывается за аббревиатурами HDD и SSD?

Пятница, 09 Декабря 2016 г. 19:30 (ссылка)
lapplebi.com/aksessuary/303...speta.html

Ещё совсем недавно с вероятностью 99,9 % можно было говорить о накопителях на жёстких магнитных дисках HDD (Hard Disk Drive), но сейчас их позиции уже не так сильны, и главная причина этому
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
masiania1

Установка Windows 7 на внешний USB-HDD для Макбук

Пятница, 09 Декабря 2016 г. 16:12 (ссылка)
lapplebi.com/news/3035-usta...k-air.html

Места мало для установки Windows 7 через Boot Camp да и не хочется ставить винду на макбук, поэтому я решил поставить Windows 7 на внешний USB-HDD.
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<hdd - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda