☰

메인 드라이브의 잘못된 dd 명령 - 데이터를 복구하는 방법은 무엇입니까?

tag-icon • tag-icon linux partitioning data-recovery dd
메인 드라이브의 잘못된 dd 명령 - 데이터를 복구하는 방법은 무엇입니까?

좋아, 짜증나고 멍청한 일이 일어났어. Arch Linux ISO 파일을 USB 썸 드라이브에 복사하고 싶었지만 서두르다가 실수로 메인 드라이브를 매개변수로 입력했습니다 of.

자세한 내용은 다음과 같습니다.

$ sudo dd bs=4MB if=archlinux-2017.08.01-x86_64.iso of=/dev/nvme1n1

/dev/nvme1n1였어야 했어 /dev/sdb.

내 기본 드라이브에는 /dev/nvme1n1두 개의 파티션이 포함되어 있습니다.

  • 512MB EFI 부팅 파티션 1개
  • 나머지 1TB 드라이브에 걸쳐 있는 하나의 ext4 파티션

파일 크기는 archlinux-2017.08.01-x86_64.iso541065216바이트입니다.516MB

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 파일 크기(516MB)로 인해 루트 파티션의 처음 4MB도 덮어썼습니다.

다음과 약간 다른 출력 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

내가 찾은 몇 가지 관련 질문은 다음과 같습니다.

유망해 보이는 유틸리티를 이미 설치했지만 testdisk올바른 단계를 수행했는지 확인하고 싶습니다.컴퓨터가 계속 실행되는 동안. 지금 종료하면 더 이상 부팅되지 않으므로 질문은 다음과 같습니다.

  • 이 상황에서 회복하는 가장 좋은 방법은 무엇입니까?
  • 파티션 테이블을 이전 형식으로 복원하려면 어떻게 해야 하며, /boot 파티션을 다시 생성하려면 어떻게 해야 합니까? 저는 최신 커널로 Arch Linux를 실행하고 있습니다.
  • 내 루트 파티션의 처음 4MB에 무엇이 포함되어 있고 파괴되었는지 알 수 있는 방법이 있습니까?

편집: 명령 실행에 대한 @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

답변1

파티션 테이블과 부팅 파티션은 쉽게 다시 생성할 수 있다고 가정하므로 ext4 파티션에 중점을 두겠습니다.

파일 시스템의 레이아웃은 파일 시스템을 생성할 때 사용된 옵션에 따라 다소 달라집니다. 일반적인 경우를 설명하겠습니다. 장치에서 실행하여 이것이 일치하는지 확인할 수 있습니다 dumpe2fs(디스크에서 읽는 대신 캐시에서 모든 최상위 메타데이터를 찾을 수 있기를 바랍니다).

ext4 파일 시스템의 일반적인 블록 크기는 4096바이트이므로 1024개의 블록이 손실됩니다.

가장 먼저 덮어쓴 것은 기본 슈퍼블록인 블록 0이었습니다. 백업 슈퍼블록이 있기 때문에 이 자체로는 문제가 되지 않습니다. 그 다음에는 파일 시스템 내에 백업이 있는 그룹 설명자 테이블이 있습니다.

그 다음에는 블록 비트맵과 inode 비트맵이 있습니다. 이것은 뉴스가 약간 더 나빠지기 시작하는 곳입니다. 이들 중 하나라도 블록 1024 아래에 있으면(아마도 그럴 것임) 어떤 inode와 블록이 사용 중인지에 대한 정보를 잃어버린 것입니다. 이 정보는 중복되며, 모든 디렉터리와 inode가 손상되지 않은 경우 이를 탐색하여 찾은 내용을 기반으로 fsck에 의해 재구성됩니다.

그러나 다음은 inode 테이블입니다. 여기에서 루트 디렉터리, 저널 및 기타 특수 inode를 포함하여 많은 inode가 손실되었을 수 있습니다. 그것들을 다시 가지고 있으면 좋을 것입니다. 분명히 루트 디렉토리는 여전히 작동하고 있거나 실행하려는 거의 모든 명령이 이미 실패했을 것입니다.

지금 실행하면 dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024현재 캐시에 있는 모든 항목의 백업 복사본을 얻을 수 있으며, 캐시되지 않은 블록에 대한 잘못된 데이터도 혼합되어 있습니다. 그런 다음 복구 디스크를 부팅한 후 동일한 작업을 dd반대로 수행하여 부분적으로 양호한 데이터를 디스크에 다시 넣고 현재 존재하는 모든 불량 데이터를 덮어쓸 수 있습니다.

그 후에는 자동 복구 도구( fsck, testdisk)가 충분히 작동할 수 있습니다. 그렇지 않은 경우 수동 복구에 도움이 되는 맵이 있습니다. 의 "사용 가능 블록" 목록을 사용하면 dumpe2fs무시할 블록을 알 수 있습니다.

잃어버린 것의 대부분은 아마도 inode일 것입니다. 실제로 파일이 없을 가능성이 높습니다.내용물디스크의 처음 4MB에. (1TB 이미지 파일에 대해 옵션 없이 실행했는데 mkfs.ext4, 첫 번째 비메타데이터 블록은 블록 9249로 밝혀졌습니다)

복구를 위해 관리하는 모든 inode는 전체 파일의 데이터 블록을 식별합니다. 그리고 이러한 데이터 블록은 반드시 근처에 있을 필요는 없지만 디스크 전체에 위치할 수 있습니다.

2일차

Pastebin에 게시된 덤프에는 다음과 같은 좋은 소식이 있습니다.

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

파일 시스템 시작 부분에서 4MB만 덮어썼다고 생각하므로 블록 0-1023만 걱정하면 됩니다. 그리고 예약된 GDT 블록은 블록 1141까지 계속됩니다! 이는 간단한 e2fsck -b $backup_superblock_number방법(재부팅 후) 으로 복구해야 하는 종류의 손상입니다 . 적어도 -n그것이 어떻게 생각하는지 확인하기 위해 시도해 볼 수 있습니다.

답변2

디스크가 GPT를 사용한 경우 디스크 끝 부분에 백업된 GPT 데이터를 사용하여 파티션 테이블을 복구할 수 있어야 합니다. 다음을 사용하여 이를 수행할 수 있습니다 gdisk. 보다gdisk데이터 복구에 관한 문서자세한 내용은. 간단히 말해서: gdisk디스크에서 실행하면아마손상을 확인하고 백업된 GPT 데이터를 사용할지, 아니면 MBR 데이터를 사용할지 물어보세요. GPT 옵션을 선택한 다음 변경 사항을 기록하면 파티션 테이블이 수정됩니다. 어떤 파티션 테이블을 사용할 것인지 묻지 않더라도 복구 및 변환 메뉴의 옵션을 gdisk사용하여 백업 테이블을 로드할 수 있습니다 .c

/sys/block/nvme1n1/nvme1n1p1/start이것이 실패하더라도 및 /sys/block/nvme1n1/nvme1n1p1/size파일 의 데이터를 사용하여(및 유사하게) 파티션 테이블(또는 최소한 파티션의 시작 및 끝 지점)을 다시 만들 수 있습니다 /dev/nvme1n1p2. 하지만 이 데이터를 활용한다면 반드시 필요한 사항입니다.아니다hek2mgl이 조언한 것과는 반대로 컴퓨터를 종료합니다. 즉, 현재 상태로 디스크를 계속 사용하면 상황이 더 악화될 위험이 있다는 hek2mgl의 말은 틀린 것이 아닙니다. 전반적으로 가장 좋은 절충안은 파티션 테이블 문제를 최대한 빨리 해결한 다음 시스템을 종료하고 응급 디스크에서 파일 시스템 문제를 해결하는 것입니다.

불행히도 귀하의 ESP는 토스트입니다. 디스크 레이아웃을 고려하면 ESP를 마운트 /boot하고 거기에 커널을 저장한 것 같습니다 . 따라서, chroot또는 다른 방법을 사용하여 커널 패키지를 다시 설치해야 합니다 . 부트 로더나 부트 관리자도 마찬가지입니다.

답변3

  1. 컴퓨터 종료(즉시)
  2. 구조 시스템으로 부팅하십시오.
  3. 실행 testdisk하여 데이터를 복구해 보세요. (공간이 충분하다면, 사용 중인 기기에서 이미지를 가져와 해당 이미지에서 dd실행하세요 .)testdisk

컴퓨터를 즉시 종료해야 하는 이유는 무엇입니까? 새 파일이 생성되거나(/run probaly에 뭔가) 추가되는 경우(/var/log/...) 파일 시스템은 데이터를 저장할 위치를 결정하기 위해 기존(잘못된!) 정보를 확인해야 합니다. 잘못된 정보를 바탕으로 이러한 결정이 내려지면 기존 데이터 블록을 덮어쓸 위험이 높습니다. 그것은 그들을 영원히 길을 잃게 만듭니다. testdisk및 와 같은 도구의 경우에도 마찬가지입니다 photorec.

관련 정보