Цель заметки — обратить внимание на эти особенности и предостеречь пользователей устройств Apple с технологией Fusion Drive от действий, ведущих к уничтожению информации при замене жесткого диска.
Кратко
Правильная последовательность действий:
- Сохранение всей важной информации. Если жесткий диск вышел из строя и самостоятельно сделать это не получается — обращение к специалистам.
- Замена диска в компьютере или ноутбуке с последующим возвращением в эксплуатацию.
Последовательность, приводящая к потере данных:
- Замена диска и возвращение устройства в эксплуатацию.
- Попытка копирования нужных файлов с извлечённого из устройства жесткого диска.
Подробнее
Судя по всему, в настоящий момент жизненный цикл жестких дисков в большом количестве устройств Apple с технологией Fusion Drive (далее FD) подходит к концу. И пользователи массово обращаются в соответствующие сервис-центры, где жесткие диски заменяют на исправные.
Затем многие из них самостоятельно, либо с помощью специалистов, пытаются извлечь данные из старого диска. И в этот момент сталкиваются с «обратной стороной» FD, делающей полное восстановление информации уже невозможным.
В целом, практика показывает, что сотрудники сервис-центров далеко не всегда стремятся вникать в особенности, которые надо учитывать для сохранения данных заказчика. Поэтому, если вы держите на FD хранилище важную информацию, полезно в общих чертах понимать, как оно работает.
FD представляет собой объединение двух накопителей, один из которых твердотельный SSD небольшого объема, а второй — обычный жесткий диск (либо, в случае с ноутбуками — ноутбучный). При этом, пользователь видит в системе такое устройство как один логический том общей емкости, равной сумме емкостей SSD и HDD.
Как уже можно догадаться из суммарного объёма, SSD используется непосредственно для хранения информации, а не в качестве кэша. Для того, чтобы уменьшить среднее время доступа, операционная система размещает на нём наиболее востребованную часть данных. Таким образом, в числе прочего, там оказывается служебная информация файловых систем и часто используемые пользовательские файлы.
Часть данных размещается на SSD сразу, другая часть перемещается туда постепенно, в автоматическом режиме, по мере накопления информации о пользовательской активности. В результате на более медленном жестком диске оказывается содержимое наименее востребованных файлов.
Когда после замены HDD выполняется инициализация, форматирование и переустановка операционной системы, на SSD уничтожаются не только наиболее актуальные данные пользователя, но и служебная информация файловой системы, являющаяся ключём к целостности файлов, оставшихся на старом HDD.
В итоге, без информации, содержавшейся на SSD, с заменённого жестого диска в большинстве случаев удаётся восстановить лишь отдельные куски мало значимых файлов.
Варианты действий, которые помогут сохранить данные
- Резервное копирование.
- Если жесткий диск исправен, но вы по какой-то причине хотите его заменить — предварительно сохранить на другой накопитель все важные файлы.
- При выходе из строя жесткого диска и отсутствии актуальной резервной копии, принести устройство на восстановление целиком, не предпринимая попыток замены жесткого диска и переустановки системы.
- Если всё-таки необходимо срочно вернуть ноутбук или компьютер в эксплуатацию, сохраните посекторную копию SSD перед заменой жесткого диска.
Комментарии (30)
tvr
17.05.2018 18:18Срочно нужен качественный перевод этой статьи на английский — Reddit & Medium тут же потеряют львиную долю аудитории.
dmitrodem
17.05.2018 18:20Ждем похожих историй про интеловский оптан и прочие "технологии".
dartraiden
17.05.2018 19:02У Optane, вроде бы, этот момент продуман: если надо заменить кеширующий накопитель, либо основной, то можно отключить в биосе кеширование, после чего накопители становятся «независимыми».
lll000lll Автор
17.05.2018 18:48Эта статья не про Apple Fusion Drive, в начале об этом написано. Она про то, что множество людей сейчас несёт на восстановление данных жесткие диски из ноутбуков, которые им заменили в сервис-центрах. А восстанавливать оттуда нечего. И статья написана в попытке как-то повлиять на этот тренд.
Stan_1
17.05.2018 21:32Полгода назад реанимровал старый Мак 2009 года. Думал убрать CD-диск и поставить SSD, объединив в Fusion. Мастер, который делал отговорил, сказав, что во Fusion пропиертарный протокол объединения двух дисков. И чтобы я не выпендривался, а просто разметил два диска (HDD, SSD) как отдельные. «Целее будут», завершил он спич :)
MAXXL
17.05.2018 22:30Есть Мак 2010 года. Добавил в него SSD, не удаляя CD. Собрал Fusion, года 4 уже работает, правда после перехода на HS уже не хватает производительности когда запускаешь виртуалку в Parallels. В остальном все нормально.
silverjoe
17.05.2018 22:35«пропиертарный протокол» — это такой себе LVM в исполнении Apple.
Ничего там страшного нет.Raidman
18.05.2018 00:15С таким себе своеобразным thin provisioning, в котором все данные о размещении данных лежат именно на ссд.
alexyr
18.05.2018 13:19Весь смысл статьи в одной ветке комментариев…
P.S. lll000lll за статью всё равно спасибо!lll000lll Автор
18.05.2018 13:44Да, вы правы. Возможно, я поступил не совсем верно, просто вариант с оформлением в таком виде представился лучшим.
Можно было в один-два абзаца всё уместить, но тогда это не соответствовало бы правилам Гиктаймс, а обратить внимание сообщества на возникшую ситуацию для уменьшения случаев потерь данных счёл важным.
Поэтому и разделил текст на две части, вся суть в начале статьи, под катом — детали.
BitHint
18.05.2018 11:22У меня собствено было подтверждение данной истории Макбук Прошка 11го года. Вытащил привод, поставил ssd, объединил все в fusion.
Прошло 4 месяца и в один прекрасный вечер система не стартует, данных нет. Ладно, все важное в облаке, переставляю, делаю всю процедуру по объединению заново. Проходит какое-то время и снова система падает.
В итоге остановился на ssd для системы, папка пользователя на hdd. Год все стабильно.lll000lll Автор
18.05.2018 14:04За много лет работы в области восстановления данных, у меня лично сложилось мнение, что если есть какая-то возможность обойтись без объёдинения накопителей (не важно с помощью какой технологии, RAID какой-то, или что-то совсем проприетарное) лучше так и сделать. Чтобы накопители работали независимо.
И при эксплуатации в итоге надёжнее получается, и данные достать, если что, проще.
Я помимо прочего сисадминю немного, внутри компании, и раньше втыкал рэйды повсюду просто потому что мог — были контроллеры и корзины, ничего покупать не надо было. А в последние годы, не смотря на то, что есть из чего их собирать, есть кому следить за ними, и если что, данные можем восстановить — предпочитаю везде где можно без них обходится, и по большей части это удаётся. В итоге инфраструктура проще и надёжнее получается. И моё время экономится.isden
18.05.2018 15:27А вот насчет RAID 1+ — это вы зря. Там избыточность, при деградации можно спокойно вытащить и заменить сломанный.
lll000lll Автор
18.05.2018 20:56Ага, и в момент ребилда массив рассыпется из-за того, что обнаружится бэд, не хватит чётности для восстановления и прошивка не сможет корректно эту ситуацию обработать. Или в течении короткого времени несколько дисков выпадут. Или просто контроллер из строя выйдет. Регулярно с результатами подобных происшествий работаем.
И да, действительно можно спокойно вытащить. Но для того, чтобы такая возможность была, надо подобную ситуацию вовремя обнаружить. Для этого надо внимательно следить за состоянием массива и оперативно реагировать на любые неполадки. Регулярно проверять состояние hotspare дисков, если они есть и т.п.
В общем время на это на всё нужно, и на настройку и на наблюдение за состоянием. И резервного копирования всё равно это не отменяет. Если это основная рабочая обязанность — нет проблем. Но если и без этого задач хватает — хочется оптимизировать время затраты.
Я же не говорю, что рейды, это плохо. Во многих случаях они необходимы. Но считаю, что без необходимости к лишним усложнениям при хранении данных лучше не прибегать.isden
18.05.2018 21:06> Ага, и в момент ребилда
Упадет метеорит на сервер, прилетят пришельцы и начнется зомби-апокалипсис.
> Для этого надо внимательно следить за состоянием массива и оперативно реагировать на любые неполадки.
Например тот же mdadm много чего умеет из коробки. А ведь есть еще куча всяких систем мониторинга.
> В общем время на это на всё нужно, и на настройку и на наблюдение за состоянием.
По-моему, лучше один раз потратить время на изучение/настройку, и иметь хоть какую-то избыточность и устойчивость к сбоям, чем не иметь их совсем. Конечно, бэкапы никто не отменял. Но подъем и разворачивание из бэкапов — процедура достаточно долгая, и не всегда уместная.
> Но считаю, что без необходимости к лишним усложнениям при хранении данных лучше не прибегать.
Ну да, нет смысла городить на десктопе массив из 10 дисков (на самом деле иногда есть).lll000lll Автор
18.05.2018 21:36>Ага, и в момент ребилда
Упадет метеорит на сервер, прилетят пришельцы и начнется зомби-апокалипсис.
Последствия ситуаций, когда из-за обнаружения бэдов в процессе ребилда массив разваливается, наблюдаем постоянно. Это не теоретические рассуждения, мы регулярно восстанавливаем данные после подобного.
Если не ошибаюсь, RAID 6 и всевозможные проприетарные аналоги, создавались в первую очередь по этой причине. Ёмкости дисков растут, количество секторов растёт, а средняя вероятность ошибки чтения для каждого конкретного сектора, как минимум, не уменьшается. На хабре даже статья или перевод были на тему того, что скоро и шестых рейдов хватать перестанет для надёжной страховки от одновременного возникновения бэдов на нескольких дисках массива.
Например тот же mdadm много чего умеет из коробки.
Так он для программных рейдов, нет?
А ведь есть еще куча всяких систем мониторинга.
Которые надо настроить и поддерживать. Если вы думаете, что можно настроить массив и системы мониторинга, а потом не проверять регулярно их корректную работу — вы потенциальный клиент компаний, восстанавливающих данные.
Конечно, бэкапы никто не отменял. Но подъем и разворачивание из бэкапов — процедура достаточно долгая, и не всегда уместная.
Да, полно ситуаций, когда рейд — лучший вариант. Но, например, если задача позволяет собрать два сервера подешевле, без массивов, и настроить репликацию данных, плюс бакапы, само собой, это может оказаться более удобной избыточностью.isden
18.05.2018 21:52> Это не теоретические рассуждения, мы регулярно восстанавливаем данные после подобного.
А можно примеры конфигураций, когда бэд на диске убивал raid? Сдается мне, избыточностью там и не пахло.
Ну и все более-менее современные диски умеют на уровне прошивки обрабатывать бэды, и писать гневные отчеты в смарт.
> скоро и шестых рейдов хватать перестанет для надёжной страховки от одновременного возникновения бэдов на нескольких дисках массива.
По-моему, это чушь какая-то. Извините. Начнем с вероятности возникновения бэдов одновременно на нескольких дисках в массиве. RAID 6 — это RAID 5 с доп. проверкой четности, и насколько помню допускает выход из строя 2 дисков из минимальных 4. И это если еще не копать во всякую экзотику, вроде 1+6.
> Так он для программных рейдов, нет?
Я лично перестал доверять аппаратным контроллерам после того, как наблюдал такую ситуацию — все диски в массиве ок, но внезапно вылетает контроллер и все превращается в тыкву, т.к. диски в живой массив на другом контроллере уже не собрать.
Вероятно есть более правильные контроллеры, которые хранят всю метадату на дисках (а не в своих внутренностях), но я за темой уже давно не слежу.
> Если вы думаете, что можно настроить массив и системы мониторинга, а потом не проверять регулярно их корректную работу
А зачем все это делать вручную? Есть же отличные средства автоматизации и тестирования.
> если задача позволяет
> подешевле
Ну тут конечно без вопросов. Задачи и бюджеты бывают разные.lll000lll Автор
18.05.2018 23:15А можно примеры конфигураций, когда бэд на диске убивал raid? Сдается мне, избыточностью там и не пахло.
Верно. Я ведь и писал про обнаружение бэда в процессе ребилда. В такой момент избыточности нет. Например, после замены вышедшего из строя диска.
Ну и все более-менее современные диски умеют на уровне прошивки обрабатывать бэды, и писать гневные отчеты в смарт.
Ага, выполняется ремап и сектор заменяется на резервный. Но данных то в резервном секторе нет, а из заменённого сектора они не читаются. Таким образом, данные в секторе теряются, и контроллеру надо их откуда-то взять.
Я лично перестал доверять аппаратным контроллерам после того, как наблюдал такую ситуацию — все диски в массиве ок, но внезапно вылетает контроллер и все превращается в тыкву,
Так об этом и речь. И контроллер может физически остаться исправным — прошивки случается сбоят. Причём в тех ситуациях, ради обработки которых они и создавались. У программных решений свои проблемы.
А зачем все это делать вручную? Есть же отличные средства автоматизации и тестирования.
Корректную работу которых тоже надо регулярно проверять. Повторюсь, к нам регулярно обращаются люди, которые полностью положились на автоматические средства и устранились от ручного контроля за их работой.
Настроите автоматическую проверку автоматической проверки автоматической проверки — ок, но её работу тоже надо будет проверять.isden
18.05.2018 23:46> Таким образом, данные в секторе теряются, и контроллеру надо их откуда-то взять.
Так у нас raid же? Ну т.е. контроллер диска обнаруживает бэд, ремапит, а контроллер raid делает ресинк. Ситуацию когда бэд возникает одновременно на всех дисках в одном и том же месте и данные тупо пропадают я отношу к упомянутому ранее нападению пришельцев.
Если половина дисков в массиве вдруг резко осыпается — то это надо гнать админа ссаными тряпками, т.к. за много дней до этого момента смарт начинает орать.
> Повторюсь, к нам регулярно обращаются люди, которые полностью положились на автоматические средства и устранились от ручного контроля за их работой.
По моему личному мнению, это значит, что они что-то делают не так. Например, raid0 и настраивали мониторинг методом копипаста с SO.
> Настроите автоматическую проверку автоматической проверки автоматической проверки — ок, но её работу тоже надо будет проверять.
Это уже какая-то паранойя lvl80, даже я до такого не доходил)
lll000lll Автор
18.05.2018 23:25По-моему, это чушь какая-то. Извините. Начнем с вероятности возникновения бэдов одновременно на нескольких дисках в массиве.
Если посчитаете вероятность, там не так уж и мало окажется. Секторов очень много на современных дисках, и их количество растёт дальше, а стабильность чтения наоборот падает. К сожалению, сейчас не могу найти статью с хабра, в которой приводились расчёты.
Да, с тем, что шестых совсем скоро перестанет хватать — ещё можно поспорить, у меня это тоже сомнения вызвало, возможно имеет смысл самому посчитать. Но вот для массивов с одним блоком чётности или зеркал — это уже так. Там вероятность одновременного возникновения бэдов вполне себе ощутимая. Маленькая, но рельная. Я так понимаю примерно как в лотерею выиграть, цифры не помню уже.isden
18.05.2018 23:51> Если посчитаете вероятность, там не так уж и мало окажется.
Одновременно. На половине дисков массива. Да еще и так, чтобы повредить одни и те же данные. И при этом чтобы мониторинг не поднял тревогу, когда начали появляться первые бэды на одном из дисков? Верится с трудом.
> Вот, к примеру, ещё аж 2009 года:
> geektimes.com/post/78311
1. Там про 5, 2. Там как раз таки рекомендуют 6.
И, кстати, можете немного раскрыть мысль на тему «перестанет хватать»?
isden
19.05.2018 00:03> И, кстати, можете немного раскрыть мысль на тему «перестанет хватать»?
Я к тому, что немного непонятно. Надежность у 6 очень неплохая, а если скомбинировать с другими типами — то можно еще чуть повысить.
Про другие типы, да, там надежность меньше. Но это таки лучше чем голые диски as-is.
lll000lll Автор
18.05.2018 23:36Cтатью, на которую хотел сослаться, не нашел, но оказалось, что есть и другие на ту же тему. Вот, к примеру, ещё аж 2009 года:
geektimes.com/post/78311
xacker
18.05.2018 06:21+1Всю статью можно уместить в:
"Что делать, чтобы сохранить данные
- Резервное копирование."
lll000lll Автор
18.05.2018 13:47Если резервное копирование не было выполнено своевременно, перед заменой диска, если он не исправен, оно уже не всегда возможно.
Сейчас понял, что не совсем чётко выразил мысль. Список в конце статьи — не последовательность действий, а их варианты.
x67
18.05.2018 10:21Забавляют инструкции для техники apple:
- Копируйте
- Замените
Невероятно сложная последовательность действий, спасибо)
lll000lll Автор
18.05.2018 13:48Прошу извинить, не совсем понял.
Да, в целом всё просто, но множество людей сначала меняют диск, а потом, когда данные на SSD перезаписаны, пытаются извлекать информацию с HDD.
igruh
Детский сад какой-то.