восстановление ext4 раздел после dd'ing запускается HD
Используя старый ПК для низкой вычислительной мощности приложение часто является ложной экономикой. Вам придется, вероятно, сделать большое обслуживание как сбой части (и прямые затраты для замены этих частей, если Вы не можете найти запчасти). Вы будете также использовать ~100W питания, где одноплатный компьютер мог бы использовать ~10W.
Если у Вас уже есть постоянный современный ПК, и Ваше приложение не должно быть физически отдельным, выполнение его в виртуальной машине является самым дешевым решением. Сбой этого, пойдите для основанного на ARM устройства (обычно заканчивается более дешевый, чем Intel, особенно если электричество является дорогим в Вашей локали).
Мне наконец удалось зафиксировать это. Только для справки вот то, как я сделал это. Часть решения, которое я нашел здесь и это включает знание настроек, используемых для создания файловой системы (я был вполне уверен, я не изменил значения по умолчанию).
В основном я сначала должен был исправить таблицу разделов для отражения то, что я на самом деле имел там (я использовал testdisk для этого, но parted, cfdisk или fdisk должен хорошо работать также). Я просто удалил неправильные разделы и заменил единственным разделом типа ext4, покрывающим целый диск корректными значениями CHS.
Остальное главным образом из ссылки в запуске (считайте его для деталей), но в основном я работал mke2fs -n /dev/xxx найти положения для резервного копирования суперблоков. Затем используемый последнее резервное копирование, самое близкое в конец диска (только те в начале диска были перезаписаны с dd) выполнять fsck. Это генерировало много ошибок, но fsck имеет a -y опция (не то же как -a).
$ sudo e2fsck -a -b backup_block_number /dev/xxx
Я думал, что это не работало, потому что я не мог видеть файлы, но на самом деле они были все сохранены к lost+found каталог.
Таким образом в конце я действительно спасал большинство своих файлов при хранении их имен файлов и структуры каталогов. Надежда это может помочь другим в будущем.
Хорошо, это работает для восстановления со случайно включенного диска в массиве MegaRAID. Мой RAID-контроллер настроил ВСЕ диски в RAID, а не только для массива RAID6, который я переделывал. Ой! По крайней мере, я сделал быструю инициализацию, а не медленную - медленная инициализация стирает диск до нуля.
Быстрая инициализация стирает 10 МБ в начале и в конце дисков. Итак, у меня с разделом ext4 на всем диске (под Linux) и одним диском, RAID0, были некоторые шансы. С накопителем на 6 ТБ и почти 5 ТБ на нем я вспотел - это была моя резервная копия массива RAID6, который я реформировал!
Между прочим, я не ошибся - LSI MegaRAID НЕ должен был иметь инициализированные диски в другой моей группе дисков - но это было. В качестве примечания, что мне следовало сделать, так это УДАЛИТЬ ДИСК ИЗ КОРПУСА и повторно импортировать его ПОСЛЕ того, как у меня была недавно организованная группа дисков RAID6. Дурак я. ДЕЙСТВИТЕЛЬНО глупый я ....
Хорошо, к счастью, LSI MegaRaid не делает ничего особенного с дисками RAID0 (если есть один, я не уверен, что несколько). Вот что я сделал, чтобы это исправить. ОС = Fedora F22. Диск = один большой раздел ext4, созданный с помощью parted. Сначала я сделал снимок диска на совершенно новый диск той же модели, на запасном сервере с парой слотов для запасных отсеков. Десять часов спустя все закончилось ...
$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s
Это была моя золотая резервная копия.
ПРИМЕЧАНИЕ. - Мой диск был / dev / sdb - вам нужно установить любой диск, который вы пытаетесь восстановить. Не лажайте с приводами, иначе вы попадете в еще больший беспорядок ....
После этого я сделал следующее.
(1) удалить снимок с машины (опять же, не глупо, могу вас заверить - в случае неудачи один из них будет отправлен в больницу восстановления дисков, пока я проверил себя в местном отделении скорой помощи!)
(2) перезагрузите компьютер FC22 с приводом. Запустите parted, переделайте раздел (в моем случае удалите поврежденный, запишите новый раздел ext4 от 0% до 100%). Вы ДОЛЖНЫ точно знать, где были исходные разделы и их точный тип - от этого зависит следующий шаг - если нет, ОСТАНОВИТЕСЬ ЗДЕСЬ. Вы этого не сделаете. используйте testdisk и photorec или аналогичные, или для большого диска, где это действительно важно, отправьте его.
(3) запустите mke2fs -n / dev / sdb1 (не забудьте -n , иначе вы можете просто уйти ...)
Для мне результат выглядел так:
$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
Вот и все запасные суперблоки ... Мы знаем, что первый и последний - мусор, но те, что посередине, должны быть в порядке. (Обратите внимание: вы можете использовать mkfs.ext4 -n / dev / sdb1 , чтобы быть очень осторожным и получить тот же результат).
(4) Запустите e2fsck -y -b 102400000 / dev / sdb1 . Вам понадобится -y , так как потребуется много «да», чтобы исправить беспорядок, создаваемый отсутствующим внешним интерфейсом диска ... и выберите любой суперблок посередине, который вам нравится ... и примерно через 30 минут тишины (используйте другой терминал и "верх", чтобы наблюдать за прогрессом, или мигающий индикатор диска) в моем случае presto, монтируемый раздел и почти все нетронутые в / lost + нашел каталог.
В любом случае, я надеюсь, что это поможет - если вы внимательно читаете это, я желаю вам удачи. И спасибо ребятам, написавшим выше. Вы спасли меня от ужасного конца .....