☰

4TB ext4 파일 시스템의 처음 32GB를 덮어씁니다. 회복하는 방법?

tag-icon • tag-icon linux partition ext4 data-recovery
4TB ext4 파일 시스템의 처음 32GB를 덮어씁니다. 회복하는 방법?

지정된 블록 장치의 사고로 인해 SATA 디스크에 있는 4TB ext4 파일 시스템의 첫 번째 32GB가 dd 명령에 의해 USB 플래시 드라이브의 내용으로 덮어쓰여졌습니다.

fdisk -l /dev/sda는 다음을 보고합니다.

Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xeaad24fe

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1          2048  8388607  8386560    4G  6 FAT16
/dev/sda2       8388608 73924607 65536000 31.3G 83 Linux

다음을 별도로 표시합니다.

GNU Parted 3.5
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: ATA ST4000NM0165 (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  4295MB  4294MB  primary  ext4
 2      4295MB  37.8GB  33.6GB  primary

참고 사항: fdisk에서는 FAT16으로 표시하는 반면 parted에서는 파일 시스템이 ext4라고 생각하는 이유가 무엇인지 잘 모르겠습니다. 그러나 무슨 일이 일어나고 있는지 파악하기 전에 실행하려고 시도한 fsck와 관련이 있을 수 있습니다. "e2fsck /dev/sda1"을 실행해 보았고 다음 질문에 "예"라고 대답했습니다.

Superblock has an invalid journal (inode 8).
Clear<y>? yes

그런 다음 파티션 크기가 물리적 크기와 일치하지 않는다는 설명을 반환했고 그 때 더 이상 진행하지 않고 중지했습니다. (죄송합니다. 실패한 fsck 시도에 대한 전체 텍스트가 없습니다. 위의 내용을 메모리에서 다시 입력하고 "예"라고 한 번만 대답했습니다.)

이전에 디스크에 있던 내용은 다음과 같습니다.

디스크는 원래 Ubuntu 18.04 설치 프로그램에 의해 자동으로 파티션이 지정되고 포맷되었습니다. 전체 드라이브를 차지하는 하나의 파티션 sda1만 있는 ext4 파일 시스템입니다. 시스템 파티션인 별도의 NVME 드라이브가 있으며 해당 디스크는 보조 데이터 디스크로 구성됩니다. 이 경우 해당 매개변수는 Ubuntu 18.04 설치 프로그램에서 선택한 기본값이 됩니다.

내가 아는 한, 해당 디스크의 처음 32GB에 있는 모든 데이터는 복구 불가능하게 손실됩니다. 하지만 해당 디스크의 데이터는 매우 중요합니다. 드라이브의 나머지 99%를 복구할 수 있는 방법이 있습니까?

원래 파일 시스템을 다시 만들 수 있는 단계를 추천할 수 있는 사람이 있습니까?

편집: gdisk -l /dev/sda는 다음을 보여줍니다.

GPT fdisk (gdisk) version 1.0.5

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

답변1

문제가 발생할 경우를 대비해 안전하게 보관하기 위해 파티션의 전체 "dd" 복사본을 다른 장치에 만들어야 합니다.

일반적으로 e2fsck이러한 문제를 복구하는 것은 가능하지만 덮어쓴 메타데이터는 손실됩니다. 슈퍼블록, 루트 디렉터리, 로그 및 기타 메타데이터가 손실됩니다. 그러나 슈퍼블록 및 기타 중요한 메타데이터는 나중에 파티션에 여러 백업이 있으므로 대부분의 데이터는 그대로 유지되어야 합니다.

너가능한예를 들어 백업 슈퍼 블록 위치를 지정해야 합니다 e2fsck -fy -B 4096 -b 11239424 /dev/sda2. 백업은 3^n, 5^n, 7^n 번호의 그룹에 저장되고 그룹 크기는 128MiB이므로 최대 32GiB(예: 256개 그룹)가 손상되었습니다. 그룹 번호가 가장 높으면 7x7x7 = 343백업 슈퍼블록이 차단됩니다 343x32768 = 11239424.

lost+found모든 것을 디렉터리에 넣기 때문에 콘텐츠, 기간 등을 기준으로 파일/디렉터리를 식별해야 합니다.

관련 정보