1.5TB 데이터 파티션이 있는데 다음 오타로 인해 실수로 처음에 일부 바이트를 덮어썼습니다.
ssh somewhere command | dd of=/dev/sda3 // should have used quotes here, dd was executed locally by mistake!
/dev/sda3에는 중요한 데이터가 포함된 1.5TB ext4 파티션용 LUKS 컨테이너가 포함되어 있습니다.
문제를 발견했을 때 dd를 일시 중지하고 종료했습니다. 4K 미만이어야 합니다.
데이터를 복구할 수 있는 방법이 있나요? 그 이후로 컴퓨터가 다시 시작되지 않았는데 손실된 데이터가 아직 RAM에 남아 있는 것일까요? LUKS 컨테이너의 첫 번째(예:) 4k에는 무엇이 포함되어 있나요?
파티션이 여전히 마운트되어 있지만 다음과 같은 오류가 표시됩니다.
[1157706.786897] EXT4-fs error (device dm-4): htree_dirblock_to_tree:896: inode #2: block 9249: comm ls: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2791782547, rec_len=44529, name_len=90
액세스하려고 할 때.
도와주세요!
감사해요!
추신: 더 많은 테스트를 했는데 4K뿐만 아니라 더 많은 데이터가 포함된 것 같습니다. :-( 하지만 1.5TB의 데이터는 여전히 매우 작은 비율입니다! 오염되지 않은 영역에서 데이터를 계속 덤프할 수 있습니까? 아마도 ext4 복구를 사용할 수 있습니다. /dev/mapper/cr_sda3 덤프에서 검색하는 도구(좋은 도구가 있는 경우) - 이것이 여전히 유효합니까?
답변1
첫 번째 실행 dmsetup table --showkeys. 출력을 안전한 곳에 저장하십시오. 표시되는 크고 긴 16진수 문자열은 다음과 같습니다.실제암호화 키(마스터 키)는 귀하의 데이터를 보호하는 데 사용됩니다. LUKS는 해당 키를 비밀번호로 암호화하여(여기서는 단순화) 작동하므로 해당 키가 유출되면 게임이 종료된다는 점을 명심하세요. 비밀번호를 변경해도 도움이 되지 않습니다. LUKS 파티션을 지우고 다시 생성해야 합니다. 그러나 동일한 속성은 LUKS 헤더가 완전히 손상된 경우에도 해당 "테이블"(키 포함)을 사용하여 데이터를 읽을 수 있음을 의미합니다.
찾고 있는 라인(라인이 많을 수 있음, LVM도 Device Mapper를 사용함)은 다음과 같습니다. 0 대신에 임의의 16진수 숫자를 갖게 됩니다(0은 --showkey 없이 얻을 수 있습니다).
Zia-swap_crypt: 0 11714560 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 253:1 0
(위의 작업은 빠르기 때문에 먼저 수행하십시오. 정전, 기계 충돌 등이 발생하는 경우 데이터를 복구하는 데 사용할 수 있습니다. 이 작업이 없으면 데이터를 복구할 수 없습니다.)
전체 라인을 유지하고 싶습니다. 더 좋은 점은 전체 출력입니다. dmsetup행을 반환하여 테이블을 복원하면 LUKS 헤더 없이도 데이터에 대한 액세스를 복원할 수 있습니다 .
다음으로 이미지를 복사하세요.해독된어딘가에 장치. 해독된 장치는 위 dmsetup의 출력에서 볼 수 있는 이름입니다 /dev/mapper/Zia-swap_crypt. 에 넣거나 /etc/fstab전달한 것과 동일합니다 mount.
이제 실행 중인 시스템에서 데이터를 복사할 수 있습니다(예: 사용 tar). 복사가 실패할 경우 fsck파일 시스템 복구를 시도할 수 있습니다. (그런 다음 데이터를 복사합니다).
해당 키를 사용하여 작동하는 새 LUKS 헤더를 생성하거나 다시 초기화하고 다시 시작할 수 있습니다.
앞으로도 많은 이용 부탁드립니다 cryptsetup luksHeaderBackup.