Ладно, случилось что-то досадно глупое. Я хотел скопировать ISO-файл Arch Linux на флэш-накопитель USB, но находился в спешке и случайно ввел свой основной диск в качестве параметра of .
Вот подробности:
$ sudo dd bs=4MB if=archlinux-2017.08.01-x86_64.iso of=/dev/nvme1n1
/dev/nvme1n1 должен был быть /dev/sdb .
Мой основной диск /dev/nvme1n1 содержал два раздела:
- Один загрузочный раздел EFI объемом 512 МБ
- Один раздел ext4, охватывающий оставшуюся часть диска объемом 1 ТБ
Размер файла archlinux-2017.08.01-x86_64.iso составляет 541065216 байт или 516 МБ
Компьютер все еще работает и, кажется, работает нормально, и у меня есть вывод lsblk и df -h перед выполнением команды dd . Вывод точно такой же, как когда я запускаю команды сейчас. Я предполагаю, потому что данные кэшируются:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:5 0 931.5G 0 disk
├─nvme1n1p1 259:6 0 512M 0 part /boot
└─nvme1n1p2 259:7 0 931G 0 part /
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1p2 916G 22G 848G 3% /
/dev/nvme1n1p1 511M 36M 476M 7% /boot
ls /boot прежнему печатает содержимое каталога (возможно, кэшированную информацию), но содержимое файла повреждено, и при запуске ls /boot/EFI или ls /boot/loader экран заполняется случайными символами, в том числе множеством Input/output error .
Вот еще немного информации:
$ cat /proc/partitions
major minor #blocks name
259 5 976762584 nvme1n1
259 6 524288 nvme1n1p1
259 7 976237255 nvme1n1p2
$ sudo fdisk -l /dev/nvme1n1
Disk /dev/nvme1n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x282bad86
Device Boot Start End Sectors Size Id Type
/dev/nvme1n1p1 * 0 1056767 1056768 516M 0 Empty
/dev/nvme1n1p2 164 131235 131072 64M ef EFI (FAT-12/16/32)
Если посмотреть на вывод fdisk , то становится ясно, что таблица разделов (и, вероятно, все данные в загрузочном разделе) была уничтожена. Это должен быть тип метки диска gpt , а размеры / типы разделов неверны. К сожалению, из-за размера файла ISO (516 МБ) он также перезаписал первые 4 МБ моего корневого раздела.
Немного другой вывод из gdisk:
$ sudo gdisk /dev/nvme1n1
# selected GPT when asked "Found valid MBR and GPT. Which do you want to use?"
Command (? for help): p
Disk /dev/nvme1n1: 1953525168 sectors, 931.5 GiB
Model: Samsung SSD 960 EVO 1TB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): <guid>
Partition table holds up to 248 entries
Main partition table begins at sector 2 and ends at sector 63
First usable sector is 64, last usable sector is 1056704
Partitions will be aligned on 8-sector boundaries
Total free space is 1 sectors (512 bytes)
Number Start (sector) End (sector) Size Code Name
2 164 131235 64.0 MiB 0700 ISOHybrid1
Я нашел пару связанных вопросов:
- https://askubuntu.com/questions/94421/is-there-a-way-to-recover-files-from-a-storage-device-partially-overwritten-with
- Случайно переписал не тот диск с дд, как восстановить?
Я уже установил утилиту testdisk , которая выглядит многообещающе, но я хочу убедиться, что я выполняю правильные шаги, пока компьютер еще работает. Если я выключу его сейчас, он больше не загрузится, поэтому вот вопросы:
- Как лучше всего оправиться от этой ситуации?
- Как восстановить таблицу разделов в предыдущей форме и как воссоздать раздел /boot? Я использую Arch Linux с последним ядром.
- Есть ли способ узнать, что содержалось (и уничтожалось)? в первые 4 МБ моего корневого раздела?
РЕДАКТИРОВАТЬ: Добавление дополнительной информации и деталей здесь на основе предложения @ WumpusQ.Wumbley запустить команду dumpe2fs .
Основной вывод (первые 50 строк) dumpe2fs: https://pastebin.com/fBuFRQfE
Для меня это выглядит довольно нормально, даже магическое число файловой системы (0xEF53) является правильным.
Далее следует Group 0:
Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
Primary superblock at 0, Group descriptors at 1-117
Reserved GDT blocks at 118-1141
Block bitmap at 1142 (+1142)
Inode bitmap at 1158 (+1158)
Inode table at 1174-1685 (+1174)
21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
Free blocks: 11419-32767
Free inodes: 16-8192
За этим следует множество групп, которые говорят [...]8192 free inodes, 0 directories, 8192 unused inodes [...] Первая группа, которая на самом деле сообщает о некоторых каталогах, - не до Group 3648 , или примерно через 25 000 строк:
Group 3648: (Blocks 119537664-119570431) csum 0xa9ea [ITABLE_ZEROED]
Block bitmap at 119537664 (+0)
Inode bitmap at 119537680 (+16)
Inode table at 119537696-119538207 (+32)
23930 free blocks, 1670 free inodes, 614 directories, 1670 unused inodes
Free blocks: 119546502-119570431
Free inodes: 29890939-29892608
В файловой системе много резервных суперблоков:
$ sudo dumpe2fs /dev/nvme1n1p2 | grep -i superblock | wc -l
dumpe2fs 1.43.5 (04-Aug-2017)
19