실수로 dd외장디스크의 첫 208MB를 사용해서 썼습니다. 나는 그것을 자체 파티션(Debian Nestinstaller)에 작성했으므로 이전(지금은 손상된) ext4 파티션 대신에 다른 작은 파티션을 보고 있습니다. 이로 인해 제가 따를 수 있는 도구와 조언이 제한됩니다.
내 계획은 파티션 테이블을 다시 생성한 testdisk다음 아래 설명된 대로 백업 슈퍼블록을 사용하여 모든 것을 수정하는 것입니다.여기. 처음 208MB는 손실되지만, 그 안에 들어 있는 다른 300GB의 데이터와 비교하면 나쁘지 않습니다. 이와 같이:
mke2fs -n /dev/sdb1 # doesn't work because sdb1 is the 208MB new partition
testdisk ... # used this to create new correct partition table
mke2fs -n /dev/sdb1 # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y
그러나 아무것도 구하기 위해 할 수 있는 일은 아무것도 없었습니다. testdisk이전에 분할된 테이블과 일치하는 새로운 분할된 테이블을 작성한 적이 있습니다 . e2fsck를 실행하면 다양한 오류가 발생합니다. 나중에 파일 시스템을 얻었지만 파일 없이 완전히 비어 있었습니다.
Lost+Found 디렉터리는 파일(복구된 파일이라고 가정)로 가득 차 있지만 파일뿐만 아니라 디렉터리 트리도 복구해야 합니다. 파일이 무엇인지(현미경 이미지, 질량 분석 데이터 등) 알기 위해서는 파일 이름과 이전 디렉터리가 필요합니다. 이름과 파일이 있는 디렉터리가 없으면 아무 의미도 없습니다.
나는 또 다른 동일한 하드 드라이브를 구해 전체 드라이브의 복사본을 만들어 dd아무것도 잃지 않고 복구를 시도할 수 있었습니다. 어떤 제안이 있으십니까?
답변1
마침내 이 문제를 해결할 수 있었습니다. 참고로 제가 하는 방법은 이렇습니다. 내가 찾은 솔루션의 일부여기여기에는 파일 시스템을 생성하는 데 사용된 설정을 이해하는 것이 포함됩니다(기본값을 변경하지 않았다고 확신합니다).
기본적으로 먼저 실제로 가지고 있는 파티션 테이블을 반영하기 위해 파티션 테이블을 수정해야 했습니다( testdisk이를 위해 사용했지만 parted제대로 작동 cfdisk해야 함 fdisk). 방금 잘못된 파티션을 삭제하고 올바른 CHS 값으로 전체 디스크를 포함하는 단일 ext4 유형 파티션으로 교체했습니다.
나머지는 대부분 처음에 있는 링크에서 따왔지만(자세한 내용은 계속 읽어보세요), 기본적으로 mke2fs -n /dev/xxx슈퍼블록 백업이 어디에 있는지 찾기 위해 달려갔습니다. 그런 다음 디스크 끝에 가장 가까운 마지막 백업을 사용하여 fsck를 실행합니다(디스크 시작 부분의 백업만 dd로 덮어씁니다). 이로 인해 많은 오류가 발생하지만 fsck에는 -y옵션이 있습니다( fsck 와 다름 -a).
$ sudo e2fsck -a -b backup_block_number /dev/xxx
파일을 볼 수 없기 때문에 이것이 작동하지 않는 것 같지만 실제로는 모두 해당 lost+found디렉토리에 저장되어 있습니다.
그래서 결국 파일 이름과 디렉터리 구조를 유지하면서 대부분의 파일을 저장했습니다. 이것이 앞으로 다른 사람들에게 도움이 되기를 바랍니다.
답변2
좋습니다. MegaRAID 어레이에서 예기치 않게 부팅된 드라이브를 복구하는 데 효과적입니다. 내 RAID 컨트롤러는 재구축 중인 RAID6 어레이의 드라이브뿐만 아니라 RAID의 모든 드라이브를 초기화했습니다. 아야! 적어도 느린 초기화 대신 빠른 초기화를 수행했습니다. 느린 초기화로 인해 드라이브가 0으로 지워졌습니다.
빠른 초기화는 드라이브의 처음과 마지막 10M를 지웁니다. 따라서 전체 드라이브(Linux의 경우)에 ext4 파티션이 있고 드라이브 RAID0이 있습니다. 드라이브가 6TB 드라이브이고 거의 5TB가 있기 때문에 땀이 납니다. 제가 재구성하고 있는 RAID6 어레이의 백업입니다!
그런데 저는 실수를 하지 않았습니다. LSI MegaRAID가 다른 드라이브 그룹의 드라이브를 초기화하면 안 되었지만 그렇게 되었습니다. 내가 해야 할 일은 인클로저에서 드라이브를 제거하고 새로 배열된 RAID6 드라이브 그룹이 있으면 다시 가져오는 것입니다. 바보 같은 나. 나는 정말 바보 야...
운 좋게도 LSI MegaRaid는 RAID0 드라이브에 대해 특별한 기능을 수행하지 않습니다(혹은 하나 이상이 있는지 확실하지 않습니다). 내가 해결한 방법은 다음과 같습니다. OS=페도라 F22. 드라이브 = 큰 ext4 파티션, parted로 완료되었습니다. 먼저, 두 개의 예비 베이 슬롯이 있는 예비 서버에 있는 정확한 새 모델에 드라이브의 스냅샷을 찍습니다. :10시간 후에 작업이 완료되었습니다...
$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s
그게 내 황금 뒷받침이야.
노트 -내 드라이브는 /dev/sdb- 복구하려는 드라이브로 드라이브를 설정해야 합니다. 드라이브를 망치지 마십시오. 그렇지 않으면 더 큰 혼란에 빠지게 될 것입니다...
그런 다음 다음을 수행했습니다.
(1) 머신에서 스냅샷을 삭제합니다. (그것은 바보 같은 짓이 아닙니다. 장담합니다. 실패하면 지역 응급실에 체크인하는 동안 사람이 디스크 복구 병원으로 보내질 것입니다!)
(2) 드라이버로 FC22 기기를 다시 시작합니다. parted를 실행하고 파티션을 다시 실행하세요(제 경우에는 손상된 파티션을 삭제하고 새로운 0%~100% ext4 파티션을 작성하세요). 원시 파티션이 어디에 있는지, 정확한 유형이 무엇인지 정확히 알아야 합니다. 다음 단계는 이에 따라 다릅니다. 그렇지 않은 경우 여기서 중지하세요. 당신은 성공하지 못할 것입니다. testdisk및 /또는 유사한 방법을 사용 photorec하거나 정말 중요한 대형 드라이브의 경우 전송하십시오.
(3) 달리다 mke2fs -n /dev/sdb1(잊지 마세요 -n. 그렇지 않으면 걸어갈 수 있습니다...)
나에게 결과는 다음과 같습니다.
$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
그게 다입니다. 모든 예비 슈퍼블록이 있는 곳입니다. 첫 번째와 마지막 슈퍼블록은 쓰레기라는 것을 알지만 중간 슈퍼블록은 괜찮을 것입니다. (매우 조심하면 mkfs.ext4 -n /dev/sdb1동일한 결과를 얻을 수 있습니다.)
(4) 실행합니다 e2fsck -y -b 102400000 /dev/sdb1. -y누락된 디스크 전면으로 인한 혼란을 해결하려면 많은 "예"가 필요하므로... 중간에 원하는 슈퍼블록을 선택하고... 제 경우에는 약 30분 후에 침묵 ( 다른 터미널과 "top"을 사용하여 진행 상황을 확인하거나 깜박이는 디스크 표시등), 마운트 가능한 파티션 및 디렉터리의 거의 모든 것을 그대로 유지합니다 /lost+found.
어쨌든, 이것이 도움이 되기를 바랍니다. 그리고 이 글을 주의 깊게 읽으셨다면 행운이 있기를 바랍니다. 위에 글을 써주신 분께 감사드립니다. 정말 역겨운 결말에서 나를 구해주셨네요...