Непреднамеренное повреждение заголовка жёсткого диска из-за неправильного применения dd

extundelete

testdisk

Тыц (wordpress.com)

Подскажите пожалуйста, как восстановить данные

Из бекапов.

Те 70 МБ ты потерял безвозвратно точно. Сколько файлов это затронуло - как повезёт.

А если ТС бы сделал бэкап таблицы разделов

dd if=/dev/sda of=/path/mbr-part-table bs=1 count=66 skip=446

ext4magic

Через testdisk не получилось. Нашёл разделы, но программа не увидела файлов. То ли я то неправильно понял/сделал, то ли ещё что. Пробую восстановить файлы через scalpel.

R-Linux прогони.

http://www.r-tt.com/ru/free_linux_recovery/

В пакете с testdisk есть утилитка photorec. Она должна помочь. А со скальпелем ты замучаешься, сразу говорю. Если данные фрагментированы, то толку от него — ноль.

к перезаписи начала данных

testdisk здесь уже не поможет.

Подойдет любая программа позволяющая сканировать и восстанавливать структуры каталогов: R-Studio, WinHex и пр.

photorec

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

Ты ничего не путаешь? Она, как бы, умеет использовать таблицу размещения файлов или её остатки. Скрин из гугла. Другое дело, что у ТС эта самая таблица инодов, скорее всего, затёрта, да и про тип файловой системы он ничего не сказал.

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

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

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

Нужную опцию смотри в 'man mkfs.ext4'.

Она, как бы, умеет использовать таблицу размещения файлов или её остатки

Не, не прокатит Photorec в данном случае. Там нужно уже именно сканить всё (это если надо найти в человеческом виде). R-Studio подойдет, потому что юзерфрендли и в конкретном случае, скорее всего, восстановит большую часть. А после пройти по сигнатурам, а вот здесь фоторек уже предпочтительнее, потому что в настройках по-умолчанию восстанавливает только «good» файлы (мусора практически не бывает), да и сигнатур в нее напихано до фига.

Там была обычная, незашифрованная, ext4.

про тип файловой системы он ничего не сказал

Н-да. Похоже, я таки перегрелся.

R-Studio подойдет

$80 же. Иначе она не восстанавливает файлы >256kB. Что?! Кто сказал «ру-боард»?

Не, не прокатит Photorec в данном случае

Ради интереса попробовал на копии своего /boot раздела (затер первые 20 метров образа из 512-ти). Ситуация удручающая. Имена похерены, а анализ действительно только сигнатурный. Судя по всему, имена показываются только в режиме «а ля undelete». В общем, был не прав — признаю.

Однако ж, странно это всё — при структуре ext4 должно вычитаться всё, кроме первой группы блоков, если я правильно понимаю. Похоже, что kostik87 дело говорит.

Я тут попробовал всякое.

Для начала, сразу ищи место, равное примерно двойному объему убитого раздела/винта: битовая (dd) копия на текущий момент + место для восстанавливаемых файлов. Можно чем-то вроде dcfldd или dc3dd воспользоваться. Дальше можно играться как с образом, так и с самим устройством (но только с чем-то одним).

Имея точку отката, я бы попробовал сделать так:

• mke2fs -n /dev/sdxN — узнаем где есть копии суперблока.

  Superblock backups stored on blocks: 
  	8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
  

• mount -t ext4 -o ro,sb=204801,norecovery /dev/sdxN /mnt — пробуем монтировать ФС: только чтение, без журнала, с вручную указанным суперблоком из тех, что ближе к хвосту. Если нифига не вышло (не помог ни гугл, ни man mount), то идем дальше.
• e2fsck -b 204801 /dev/sdxN — пробуем минимально починить ФС для монтирования, указав суперблок.

  Superblock has an invalid journal (inode 8).
  Clear<y>? yes
  *** ext3 journal has been deleted - filesystem is now ext2 only ***
  
  Resize inode not valid.  Recreate<y>? yes
  Pass 1: Checking inodes, blocks, and sizes
  Root inode is not a directory.  Clear<y>? yes
  Pass 2: Checking directory structure
  Entry '..' in <2>/<65537> (65537) has deleted/unused inode 2.  Clear<y>? yes
  Pass 3: Checking directory connectivity
  Root inode not allocated.  Allocate<y>? yes
  Unconnected directory inode 65537 (...)
  Connect to /lost+found<y>? yes
  /lost+found not found.  Create<y>? yes
  Pass 4: Checking reference counts
  Inode 65537 ref count is 6, should be 5.  Fix<y>? yes
  ...
  Recreate journal<y>? yes
  Creating journal (8192 blocks):  Done.
  
  *** journal has been re-created - filesystem is now ext3 again ***
  
  xxxxxxxxxxxx: ***** FILE SYSTEM WAS MODIFIED *****
  xxxxxxxxxxxx: 324/131072 files (0.3% non-contiguous), 36937/523712 blocks
  

• монтируем ФС (можно командой из позапрошлого пункта) и идём забирать спасённое барахло из lost+found.

  Как-то так.

Я тут попробовал всякое.

Вах. Я на чет подобное натыкался, но не пробовал. Сегодня вечером поэкспериментирую. В любом случае интересно.

Для начала, сразу ищи место, равное примерно двойному объему убитого раздела/винта:

И вот тут-то проблема. У меня винт объёмом в терабайт. Где я сейчас два терабайта возьму?

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

Но photorec неплох. Да, были обрезанные файлы, всё смешано в одну кучу, утрачены имена — но несколько файлов-таки смог восстановить (дальше я его просто прервал, потому что места не так много). Тот же scalpel при поиске картинок ничего не нашёл, а photorec некоторые картинки восстановил (опять же не все, т.к. не успел).

Я ж говорю - R-Studio. После сканирования - выборочно восстановишь. Тот же Photorec+сканирование можешь попробовать http://sleuthkit.org/autopsy/download.php

Тот же scalpel при поиске картинок ничего не нашёл

А ты всё просканировал? Scalpel с настройками по-умолчанию сканирует ну ооочеееньь долго. Попробуй как-нибудь, к примеру foremost: foremost -vq -t ole,jpeg -o OUTPUT_FOLDER /dev/sdX

Ну можно как-то так (при условии, что винт никогда не забивался полностью):

dd if=/dev/sdxN | pv -cN 'uncompressed' | pigz -9 | pv -cN '  compressed' > backup.bin.gz

Вместо многопоточного gzip'а можно использовать lzop без параметров. Скорость сжатия у него повыше, чем скорость чтения с винта, а пустое место, как бы, пофиг чем сжимать.

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

можешь попробовать http://sleuthkit.org/autopsy/download.php

Оно ж страшное, как моя жизнь (имею ввиду веб-морду) и немного не для того (мы же не криминалисты).

Я ж говорю - R-Studio.

Я бы еще UFS Explorer попробовал из проприетарщины. Интересно, как он в сравнении с R-Studio?

З.Ы. Вспомнилась милая хреновина для создания образа и упаковки его в squashfs: sfsimage.

Оно ж страшное, как моя жизнь (имею ввиду веб-морду) и немного не для того (мы же не криминалисты).

Это в версии 2 оно страшное и мало чего умеет. В версии 4 есть Photorec вдобавок ко всему (ну и венда нужна, конечно).

UFS Explorer

Ну да, я ж говорю - много чего есть под оффтоп. R-Studio, ИМХО не Царь горы, просто самая распространенная.

squashfs

Кстати, не видел раньше. Прикольный скрипт, спасибо.

Интересно, как он в сравнении с R-Studio?

Мне больше нравится UFS. По результатам не скажу, давно R-St. не пользовался.

(ну и венда нужна, конечно)

Вот только Windows у меня нету.