Восстановить внешний HDD

Какие там были разделы и файловые системы?

человек не уверен, но говорит что было 2 раздела, один пустой на чуть больше 100Гб., и один раздел с данными чуть боьше 850 Гб.. 4 раздела образовались в новой винде. но что то мне слабо верится, пока исхожу из того что человек может и ошибаться и у него было 2 рабочих раздела на 200 и 400 Гб.

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

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

Какие там были файловые системы?

Про образ уже написали, далее тем же самым testdisk найти удаленные разделы и восстановить их, либо photorec`ом восстановить инфу и пере разметить диск.

Не знаю, вроде как FAT32, но допускаю и NTFS.

Тогда отключай диск, бери в руки программу GetDataBack for FAT и отдельно GetDataBack for NTFS, ставь её можешь сканировать диск.

Testdisk хуже найдёт файлы с повреждённой файловой системы.

Программы для Windows. Можно попробовать запустить в wine, но нужно снимать образ с диска.

Так что лучше использовать виртуальное окружение с Windows и пробросить туда диск.

После сканирования файлы нужно будет куда-нибудь сохранить.

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

Удачи.

блинство, прервал работу testdisk'a :(

sudo e2fsck -f /dev/sdg2
e2fsck 1.43.3 (04-Sep-2016)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdg2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

sudo mke2fs -n /dev/sdg2
mke2fs 1.43.3 (04-Sep-2016)
Creating filesystem with 68103341 4k blocks and 17031168 inodes
Filesystem UUID: c64687bd-ca92-4b2c-8b91-602cc710a036
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872

Если там был FAT или NTFS, то зачем ты запускаешь утилиты для ext*? Если данные нужно то отложи диск в сторону.

это самый крайний случай, хотелось бы быстрый и сразу результативный способ. когда то давно консольная утилита восстановила разделы буквально за несколько минут, но это было ОЧЕНЬ давно....

Если там FAT или NTFS, то как минимум запускать утилиту проверки файловой системы для ext* странно, а фактически глупо.

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

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

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

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

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

Если ты этого не понимаешь и тем более не хочешь понять, то данным конец.

Удачи.

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

mke2fs -n /dev/sdg2

НАХРЕНА???

Вместо лечения решил пристрелить что ли?

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

И в том случае, если на этом разделе была бы ext* файловая система, то можно было бы запустить e2fsck с указанием сектора с копией суперблока для восстановления файловой системы.

А, ну да. Но после e2fsck БЕЗ -n я уже на ключи mkfs не смотрел, ожидая худшего.

Дорогой топикстартер!

Во-первых строках моего письма спешу сообщить тебе, что через шнурок USB2.0 (особенно через хреновый и/или длинный) терабайтный диск будет _очень_ долго читаться. Я прозреваю, что у тебя на руках не нормальный диск, а сиранэ WD My passport, поэтому через SATA ты его не подключишь, поэтому хотя бы найди USB3.0 (шнур и порт).

Во-вторых, конечно, надо снимать образ и играться уже с ним. Я клал образ на lvm, делал снапшоты и экспериментировал с ними, но и просто образ в файле сойдёт. Можно образ сжать pbzip2 и по мере надобности его накатывать обратно на диск, если места на штатных дисках недостаточно.

В-третьих, утилиты, работающие в режиме чтения fdisk -l, fsck -n, testdisk во время поиска, dd if=/dev/sdg и прочие прекрасно работают одновременно (из разных консолей, например).

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

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

mount: wrong fs type, bad option, bad superblock on /dev/sdg, missing codepage or helper program, or other error

ты чертовски прав, но для винды у меня только виртуальная машина на редкий случай, USB 3.0 не поддерживается, да и не надо оно мне. пусть сканируется проприетарщиной, вытащу фото, а потом поиграюсь малость уже родными утилитами линукса, от владельца разрешение получил.
fsck -n во время работы testdisk'a говорил что диск занят.

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

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

Можно было бы поискать (например утилитой ht(hte)) в образе диска сектора, заканчивающиеся на 0x55, 0xAA. В начале сектора есть сигнатуры файловых систем, поля с указанием размера раздела. По ним реконструировать записи MBR . Или проще вытащить куски из образа командой dd if=image.bin of=partiton.bin skip=offset_in_sectors bs=512 count=partition_size и монтировать их потом.

Инфа по NTFS (размер раздела 8 байт по 0x28), ExFAT и его VBR (размер раздела - 8 байт по 0x48). По FAT32 сейчас ссылки нет, там размер раздела - 4 байта по 0x20, по 0x52 строка «FAT32 ».

Достаточно просто на сях утилиту набросать для автоматизации процесса поиска.

поискать ... в образе диска сектора, заканчивающиеся на 0x55, 0xAA.

Чего его искать эта сигнатура записывается в конце нулевого сектора диска после блока с таблицей разделов. Это последние символы первого (нулевого) 512 сектора.

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

В нулевом секторе в последних 66 байтах находится 4-е 16-и байтных записи о параметрах разделов, номер начального, конечного сектора, тип файловой системы. Это в случае MBR разметки.

Но т.к. уже созданы другие разделы, то таблица разделов в нулевом секторе уже перезаписана.

у testdisk можно выбрать раздел и попробовать просмотреть файлы на этом разделе.

go to (your disk) > Intel > Analyse > (your dynamic partition) highlight your partition press P to list files

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

В 0-м секторе находится MBR (Master Boot Record), я даже ссылку на нее дал. И да, она уже повреждена. Остается надеяться, что виндовская прогармма разметки не попортила сильно старые разделы.

В 0-м секторе каждого виндовского раздела находится VBR (Volume Boot Record), которая также заканчивается 0x55, 0xAA, на их структуру я тоже ссылки дал. В ext2/3/4 по другому, там первый 1КБ пробит нулями. Из VBR-ов MS-разделов можно вытащить размеры разделов.

Вот пример. Реальная загрузочная флешка с FAT32 разделом. По LBA=0x8000 находится сектор VBR для FAT32. Этот LBA и должна будет найти утилита.

0000 eb 58 90 53 59 53 4c 49-4e 55 58 00 02 40 40 00 |?X?SYSLINUX ?@@ 
0010 02 00 00 00 00 f8 00 00-20 00 40 00 00 08 00 00 |?    ?    @  ?  
0020 00 f8 37 07 c0 39 00 00-00 00 00 00 02 00 00 00 | ?7??9      ?   
0030 01 00 06 00 00 00 00 00-00 00 00 00 00 00 00 00 |? ?             
0040 80 01 29 1d 05 29 4c 4b-4e 4f 50 50 49 58 20 20 |??)??)LKNOPPIX  
0050 20 20 46 41 54 33 32 20-20 20 fa fc 31 c9 8e d1 |  FAT32   ??1???
0060 bc 76 7b 52 06 57 1e 56-8e c1 b1 26 bf 78 7b f3 |?v{R?W?V???&?x{?
0070 a5 8e d9 bb 78 00 0f b4-37 0f a0 56 20 d2 78 1b |????x ??7??V ?x?

01a0 2f 00 66 61 72 01 c3 e2-c9 31 f6 8e d6 bc 68 7b |/ far????1????h{
01b0 8e de 66 8f 06 78 00 be-da 7d ac 20 c0 74 09 b4 |??f??x ??}? ?t??
01c0 0e bb 07 00 cd 10 eb f2-31 c0 cd 16 cd 19 f4 eb |??? ????1???????
01d0 fd 8a 16 74 7b 06 cd 13-07 c3 42 6f 6f 74 20 65 |???t{?????Boot e
01e0 72 72 6f 72 0d 0a 00 00-00 00 00 00 00 00 00 00 |rror??          
01f0 00 00 00 00 00 00 00 00-fe 02 b2 3e 18 37 55 aa |        ???>?7U?

Вот она сигнатура VBR - 0x55, 0xAA по смещению 0x1FE, тип файловой системы «FAT32 » в 0x52. В 0x20 находим размер раздела в секторах - 0x737f800, это 62ГБ если помножить на размер сектора 512, что похоже на правду.

Итого, команда вытаскивания раздела будет.

dd if=image.bin of=part.bin skip=$((0x8000)) bs=512 count=$((0x737f800))

Про $((...)) вычитал тут

И вот накропал в помощь утилю

findvbr.c

#include <stdlib.h>
#include <stdio.h>
#include <linux/types.h>

#define BUF_BLOCKS	256
#define SECT_SIZE	512
#define BUF_SIZE	(BUF_BLOCKS*SECT_SIZE)

__u8		buf[BUF_SIZE];

int main(int argc, char **argv)
{
    FILE		*himg = 0;
    __u32		offs, size, img_size, obuf;
    __u8		*vbr;
    __u8		*fstype;
    int			found;

    if(argc<2)
    {
	printf("Use\r\n\tfindvbr phys_drive_or_dump\r\n");
	return -1;
    }

    himg = fopen(argv[1],"rb");
    if(!himg)
    {
	printf("Cannot open device/image \"%s\"",argv[1]);
	return -1;
    }

    fseek(himg,0,SEEK_END);
    img_size = ftell(himg);

    for(offs=0; offs<img_size; offs+=BUF_SIZE)
    {
	fseek(himg,offs,SEEK_SET);
	fread(buf,BUF_SIZE,1,himg);

	for(obuf=0; obuf<BUF_SIZE; obuf+=SECT_SIZE)
	{
	    vbr = buf+obuf;
	    if(0xAA55==*((__u16*)(vbr+0x1FE)))
	    {
		found = 0;

		if(!strncmp(vbr+0x52,"FAT32",5))
		{
		    found = 1;
		    fstype = "FAT32";
		    size = *((__u32*)(vbr+0x20));
		}
		else if(!strncmp(vbr+0x03,"NTFS",4))
		{
		    found = 1;
		    fstype = "NTFS ";
		    size = *((__u64*)(vbr+0x28));
		}
		else if(!strncmp(vbr+0x03,"EXFAT",5))
		{
		    found = 1;
		    fstype = "ExFAT";
		    size = *((__u64*)(vbr+0x48));
		}

		if(found)
		{
		    printf("@LBA=0x%8.8X  fstype=%s  size=0x%8.8X[sect]",(offs+obuf)/SECT_SIZE,fstype,size);
		    printf("\r\n");
		}
	    }
	}

    }

    fclose(himg);
    return 0;
}

Конпеляем gcc findvbr.c -o findvbr

Запускаем

root@LIN:/home/user/PROJECTS/findvbr# ./findvbr /dev/sdd
@LBA=0x00000800  fstype=FAT32  size=0x0737F800[sect]
@LBA=0x00000806  fstype=FAT32  size=0x0737F800[sect]

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

Ты тут в треде щас testdisk изобретёшь, остановись!