Не так давно, около месяца назад (ну или двух, смотря когда я допишу пост), мой SSD умер во время рабочего звонка. Сначала я подумал, что просто система лагнула, но после перезагрузки системы увидел зловещее сообщение "Drive failure imminent".
После небольшого изучения вопроса, выяснилось, что ресурс на запись у диска внезапно кончился. Впрочем, спустя чуть большее количество времени я узнал, что виной всему было обновление KB5063878 для Windows 11, которое судя по всему убивало SSD: иногда сразу же, иногда медленно и мучительно двигая их к ранней кончине. Мой диск был относительно новым, да и пользовался я им меньше года, так что кончившийся ресурс мне показался странным.
Впрочем, если быть откровенным, я не до конца уверен, что всему виной было именно это обновление (но с другой стороны, этот диск прожил меньше всех остальных моих SSD, использовался меньше прочих в сравнении, да и тайминг совпадает идеально), однако в любом случае, это повело меня в кроличью нору аосстановления данных. Хоть большая часть важных данных либо имела бэкапы, либо была откуда-то загружена, были и штуки, которые не успели быть зарезервированы: например рабочие файлы, дамп RAW-ок фотографий (с разнычными изменениями в них для большого поста про УФ/ИК фотографию). Так что восстановление данных с него стало приоритетной задачей.
И всё это может в целом казаться достаточно лёгкой в решении проблемой для умудрённых опытом в таких вещах, но я сам в процессе столкнулся с рядом любопытных техник и инструментов, чтобы восстановить убитые разделы умирающего диска. Так что оставляю этот пост как заметку для будущего себя и для тех, кто столкнётся с теми же проблемами, что и я.
Хороший, или странная ситуация с клонированием на меньший диск
- Мёртвый SSD с установленной Windows 11 и прорвой данных
- Внешний кейс m.2 SSD на USB-C
- Другой SSD десятилетней давности с установленной Windows 10, также установленный в мой десктоп
- Свежий SSD, который я прикупил неделей ранее
Моя первая мысль – использовать что-нибудь типа HDClone или софта от Acronis, чтобы перенести данные.
И первая проблема не заставила себя долго ждать. Хоть оба диска – и сломанный, и новый, ставший заменой – были технически 2 ТБ, на самом деле это были диски на 2048 и 2000 ГБ соответственно. То есть на деле это были 2 ТиБ и 2 ТБ.
Так что план становится чуть сложнее. Мне надо ещё клонировать данные, попутно меняя разметку разделов на лету. Не должно быть сильно сложнее, правда?
Правда же?..
Ну, было и правда несколько сложнее. И это вообще была несколько дурацкая идея с самого начала (и дальше станет понятно, почему). Но я всё равно решил попробовать.
И HDClone, и Acronis вроде как имеют поддержку такого изменения разметки при клонировании, но вместо одного захода мне пришлось сделать аж три разных: в первый раз Windows решила, что этот процесс недостаточно важны и запустила обновление Win10, во второй раз возникли ошибки чтения, так что хоть клонирование и завершилось успешно, прочитать диск было невозможно.
Третья попытка даже не особо случилась, потому что где-то между прошлыми попытками диск начал умирать, а вместе с этим росло количество ошибок чтения. К третьей попытке (первые две были с HDClone, третья с Acronis), таблица разделов уже была нечитаема.
Плохой, или странная ситуация с разделами
Ну, как понятно из заголовка, ситуация стала грустной. Настало время для тяжёлых орудий.
Хоть много полезных инструментов для восстановления данных и доступны на Windows, я как-то был больше знаком с linux-way решениями. Так что я достал свой старый-добрый Thinkpad x280 с Arch (btw), внешний 5 TB HDD и набрался терпения. Всё это в неудачный момент, когда все остальные мои Linux машины были недоступны, а этот внешний диск был единственным доступным, на котором было достаточно пространства, чтобы можно было сделать полное клонирование диска.
В общем план был простой:
- Подключить умерший диск в USB кейсе к Thinkpad'у, пока Win10 машина переходит на позицию "временной рабочей" на время
- Попробовать запустить TestDisk на оригинальном диске, чтобы попробовать обнаружить разделы и может сделать что-нибудь с ними
- Если ничего хорошего не выйдет на прошлом этапе — клонировать диск с помощью
dd, пока ещё больше секторов диска не умрут, а дальше уже работать с дампом диска
Ну короче TestDisk ни хрена не нашёл.
И после этого я попробовал воспользоваться обычным dd, но процесс быстро встал из-за мёртвых секторов. Неудачная ситуация.
Я думал воспользоваться чем-то вроде Clonezilla, но пришёл к выводу, что это не очень поможет в моём конкретном случае.
Злой, или GNU спешит на помощь
Немного гугления привело меня к такой штуке как ddrescue. По сути это инструмент GNU (по крайней мере как я понимаю?), который делает несколько обходов дисков в разных направлениях, в итоге создавая его dd образ. При первом проходе он помечает проблемные сектора и пропускает их, а на последующих — пытается восстановить данные с них. Вес прогресс записывается в лог, который можно потом использовать, чтобы продолжить с того же места в любой момент.
В итоге простого ddrescue -d -r3 /dev/sdc restore.img rescue.log оказалось достаточно для создания образа.
Ещё оказалось вот эти ссылки оказались полезными в процессе:
- Краткий гайд по восстановлению с ddrescue
- как возобновить процесс ddrescue? – Я в итоге всё сделал одним заходом, но вообще может быть полезно
- (по сути просто передать лог в качестве параметра, прогресс будет подхвачен автоматически)
- Пояснение легенды в логфайле
- (впрочем эту же информацию можно найти в GNU мануале)
И что круто с этим логом — это простой текстовый документ с достаточно простой структурой. Так что (1) естественно нашёлся инструмент визуализации ddrescue, (2) можно использовать этот лог для поиска повреждённых файлов. К тому же (3) можно примонтировать диск как loopback устройство при необходимости и что-нибудь с ним делать (через sudo losetup -Pf --show restore.img).
Ну и вот что мы имеем после прогона ddrescue. Таблица разделов всё ещё повреждена, но по крайней мере мы знаем, сколько на момент создания образа было плохих секторов, и что их количество было достаточно маленьким, значит есть высокий шанс, что ничего не утеряно.
Но к сожалению найти сами разделы пока никак не получалось, так что я остался с образом повреждённого диска. Но как найти и по возможности восстановить разделы на диске?
В поисках решения этой проблемы я и наткнулся на SleuthKit.
Спаситель, или лапа помощи
Короче говоря SleuthKit — набор инструментов для криминалистов, используемый для поиска данных на сломанных или повреждённых устройствах. Эти инструменты полностью свободные, с открытым кодом, и они творят чудеса: и удалённые файлы найдут, и по содержимому поищут, и разделы найдут, даже если всё уже давно пропало.
В моём случае всё было не настолько плохо, если сравнивать с тем, для чего SleuthKit обычно используют. Так что когда я сделал простой запуск fls -r -o restore.img, к моему удивлению на выходе был полный список всех файлов, даже удалённых, с этого диска, прямо в терминале. И это было отличной новостью: значит раздел он видит! А дальше-то что?
Ну наверное можно было бы как-нибудь восстановить раздел целиком? Но я пошёл немного иным путём: сначала я сделал небольшой скрипт для анализа списка файлов и лога ddrescue, чтобы найти "битые" файлы. А для восстановления данных я решил найти сначала какой-нибудь UI для SleuthKit...
...и так я нашёл Autopsy.
 |
| (скриншот не мой, но хорошо подойдёт как демонстрация, что этот инструмент из себя представляет) |
По сути надо просто "создать дело" и начать анализ того же образа диска, что был создан с ddrescue. После этого он обнаруживает, основываясь на известных паттернах, разделы и файлы на них, даже удалённые. И после этого можно экспортировать даныне целыми папками, правда вместе с удалёнными данными в том числе.
В моём случае это дало возможности распознать разделы, найти на них файлы и восстановить их без каких-либо проблем.
Единственной ощутимой проблемой была разве что установка: по сути самым удобным способом установки на арче оказалась установка snapd из AUR, с последующей установкой snap пакета autopsy. Ну или можно попытаться всё это собрать самому, но это займёт прилично так времени.
Но вообще к тому моменту я снова поменял машины назначениями, и Windows 10 ПК уже занимался восстановлением, с установленным Autopsy и подключенным новым диском.
Что же касается повреждённых файлов, я использовал свой скрипт, чтобы сопоставить повреждённые блоки из лога ddrescue с файлами из результата fls, отыскивая файлы по istat. Скрипт запускает несколько инстансов параллельно и старается найти соответствия этим повреждённым блокам в файлах из fls на файловой системе NTFS, сопоставляя файлы с пересечениями блоков из списка повреждённых.
Скрипт далёк от идеала (я ещё и не эксперт в питоне, так что немного собирал его по кускам, не без помощи), но в целом отработал достаточно хорошо для моих нужд. Код можно найти в этом gist'е.
У меня ещё был дополнительный скрипт, чтобы пробежаться по всем восстановленным файлам, их состояниям и найти ошибочно восстановленные удалённые файлы, чтобы удалить их повторно (но этот скрипт уже потерялся в истории).
Что было дальше
Нашлось около 20 повреждённых файлов, в основном они и так были удалёнными. Большая часть урона пришлась на таблицу разделов и загрузочный раздел. Позднее я подключил диск снова, любопытства ради, и обнаружил, что уже около 30% секторов были повреждены.
Все файлы были восстановлены как есть на свежем NTFS разделе. Я решил восстановить диск практически целиком, вместе с установленной Windows.
Сначала надо было восстановить загрузчик, примонтировав загрузочный раздел оригинальной системы на новом диске, а потом "восстановив" EFI загрузчик.
diskpart
Как оказалось, это была не самая лучшая идея, так как Windows требует особых настроек разрешений на системных и программных файлах. Так что пока я пытался загрузиться, даже поменять владельца всех файлов на "правильного", даже пробовал "восстановить" корректные системные файлы.
takeown /F D:\ /R /D Y
И потом даже
sfc /scannow
Но в какой-то момент это стало слишком большим гемором, да и ничего не помогало, так что я сдался и просто сделал установку "начисто".
А уже после установки начисто я скопировал на новую систему содержимое большей части AppData, настроек и установленных программ, дойдя до примерно того же состояния системы, в котором она у меня и была.
Несколько занятных моментов, что я обнаружил по пути:
Если после переноса всех пользовательских файлов, включая образ диска WSL, вылезает ошибка "WslRegisterDistribution failed with error: 0x80370114", то можно просто переустановить дистрибутив, заменить новый диск старым и перезапуститься. Это должно решить все проблемы с правами доступа, а система должна распознать WSL дистрибутив.
Для восстановления загрузки, помимо EFI раздела, нужно также пустое (неразмеченное) пространство после него ровно в 16 МБ (для некоторых системных операций и данных)
Пытаться "зачистить" реестр Windows, чтобы исправить ошибки доступов или зафорсить систему "починить" себя — не самая лучшая идея, всё может поломаться до точки невозврата
По непонятным причинам винда после переустановки выставила мне случайное имя учётной записи. Чтобы поменять имя пользователя и домашней папки мне понадобилось запустить
netplwizи после этого отредактировать ключи реестра вHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Что дальше?
С тех пор Microsoft заявили, что SSD умирали не из-за их обновления. И позднее выпустили исправление проблемы.
Система себя чувствует отлично на новом диске. Но в ходе всей этой эпопеи я начал задумываться о том, чтобы уйти с винды на Linux окончательно. Я и так большую часть жизни использую Linux как основную систему на своих ПК, а во время этого путешествия в мир восстановления данных я как-то притёрся к своему Thinkpad'у в качестве основной повседневной машины (до этого, хоть всё и было настроено под меня, я им пользовался в основном только в поездках до сих пор).
Другой ноут, очень производительный, был в ремонте после больших повреждений (SSD, с которого всё началось, изначально стоял вообще в этом ноуте) и вернулся ко мне после 9 месяцев. И за это время я себе пообещал, что накачу на него Linux, если его таки получится оживить. И таки получилось, так что я сделал небольшую пачку скриптов для переноса конфигурации и установленного софта из разных источников, и развернул там новую систему
В итоге этот ноут после недавней поездки в другой город стал моей основной машиной. И, по иронии судьбы, я не очень-то много пользуюсь той системой, оторую я так старался восстановить. Опять же, работает-то всё отлично, но мне просто как-то больше нравится с этого ноута работать.
Да и в любом случае, все основные файлы были восстановлены и забэкаплены, так что всё хорошо, что хорошо кончается, да?
В качестве заключения
Какие я выводы сделал для себя из этой истории
- Лучше сразу же делать бэкапы всей своей текущей работы, даже если планируешь быстро закончить (делать мы этого конечно же не будем)
- Хоть многие данные конечно кажутся важными, и вроде бы много места чем-то полезным занято, на деле это в большинстве своём хлам, который можно перезакачать, либо который просто занимает место (а ещё винда создаёт такого хлама в огромных количествах)
- Нельзя полагаться на Windows/Microsoft в деле оставления твоего железа в живых или отсутствия саботажа твоих попыток его спасти
- Open Source в очередной раз спасает день своими офигенными инструментами, вроде Autopsy и ddrescue (впрочем, на машине без винды такой проблемы скорее всего бы и не возникло)