모든 데이터를 저장한 두 하드 드라이브 모두에 오류가 발생했습니다. 내 시스템이 디스크 로드 및 파티션 마운트를 계속 거부합니다. 인식 문제가 덜한 다른 컴퓨터로 하드 드라이브를 옮겼지만 파티션에 오류가 많고 해당 드라이브의 dmesg에서 여전히 E/S 오류가 발생합니다.
부팅에 사용된 파티션에 잘못된 슈퍼블록이 있었지만 다른 슈퍼블록으로 읽을 수 있었고 더 많은 오류가 표시되었기 때문에 먼저 외장 하드 드라이브에 파티션의 마스터 백업을 만들었습니다. 이런 이유로 ddrescue에 두 번 패스했는데 로그에 따르면 512바이트 오류만 나와 종료되었는데 이는 유망하다고 생각합니다.
lsblk를 사용하여 백업을 나열하는 것이 더 유망해 보입니다.
손상된 파티션의 lsblk에는 다음이 표시됩니다.
$lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
...
sda
└─sda1
...
이제 마스터가 보여주는 곳은 다음과 같습니다.
sdc
├─sdc1 ext4 new 8cab6f75-1ea7-4451-9f48-2bbcce167184
이제 이 기본 파티션에서 동일한 드라이브 끝까지 또 다른 백업이 있으므로 lsblk의 실제 출력은 다음과 같습니다.
lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
fd0
loop0 squashfs /snap/anbox-installer/25
loop2 squashfs /snap/core/9669
loop3 squashfs /snap/core/10911
sda
└─sda1
sdb
├─sdb1 ext4 Debian_copia ce2c8e8f-f3ef-4005-9cb1-0bb9d5870f43 /
└─sdb2 swap d60a8ad0-5528-4bbc-af5e-092b96282df4 [SWAP]
sdc
├─sdc1 ext4 new 8cab6f75-1ea7-4451-9f48-2bbcce167184
└─sdc2 ext4 new 8cab6f75-1ea7-4451-9f48-2bbcce167184
sr0
여기서 제가 놓친 부분이 있습니다. fsck의 옵션 p를 옵션 f로 착각해서 그렇게 했습니다.
fsck -fy /dev/sdc2
이로 인해 몇 가지 문제가 발생하고 일부 노드가 삭제되었으며 설치 후 파일의 절반이 예상대로 나열되었지만 다행히 이것은 손상된 하드 드라이브의 복사본이므로 이번에는 더 조심하겠습니다.
좋은 사례를 알려주실 수 있나요? 내 데이터는 이제 모두 도박이므로 정확하게 입력해 주세요.
lsblk가 파티션을 변경합니까? 파티션을 변경하지 않고 파티션을 마운트할 수 있나요? 그런데 다음 링크가 있습니다.https://www.sans.org/blog/how-to-mount-dirty-ext4-file-systems/
여기서 시간을 벌 수 있도록 fsck를 안전하게 수행하려면 어떻게 해야 합니까? fsck -n이 여전히 파티션을 변경합니까? 디스크에서 파티션 복사본이 있는 위치에 차이가 있습니까?
파일 시스템을 다루지 않고 파일을 복구할 수 있는 방법이 있습니까? photorec에 대해 읽었지만 인식하지 못하는 굵은 파일이 많이 있습니다. 좀 더 일반적인 것은 없나요?
답변1
디스크가물리적실패하면 더 이상 쓰기를 수행하면(예: fsck 사용) 상황이 더 악화될 뿐입니다. 이 디스크에서 데이터를 복구할 가능성을 높이려면 즉시 디스크 사용을 중지해야 합니다. 지금 제거하세요. 새 디스크를 주문하고 새 디스크가 도착하면 일반 Linux 배포판을 명령 프롬프트로 부팅하고 ddrescue아래 설명에 따라 기존 디스크를 새 디스크에 설치합니다.여기. 기억하십시오: 추가 손상을 방지하려면 이전 디스크에서 파일 시스템을 마운트하지 마십시오.
답변2
당황하지 말 것
더러운 ext4 파일 시스템이 있는 하드 드라이브의 문제를 해결하려는 것 같습니다.
백업이 있나요? 백업이 있는 경우 백업에서 복원하세요. 백업이 없다면 여기서 매우 조심해야 합니다. 가장 먼저 해야 할 일은 키보드에서 손을 떼고 게임 계획을 세우는 것입니다. 실행하려는 모든 명령, 특히 하드 드라이브에 직접 닿는 도구를 시작 info하거나 실행 하십시오 .man
손상된 미디어에 대한 액세스 제한
하드 드라이브에 오류가 발생하면 디스크에서 직접 파일에 액세스하려는 모든 시도를 중지해야 합니다. 탈출 시도를 중단해야 합니다 fsck. 하드 드라이브를 더 많이 사용할수록 잠재적으로 고장이 날 수 있는 드라이브에 더 많은 마모가 발생합니다. 이러한 디스크 중 하나에서 운영 체제를 부팅하는 경우 이 작업도 중지하십시오. 라이브 미디어에서 실행하세요.GRML 리눅스.
대신 오류가 발생한 하드 드라이브의 이미지를 생성해야 합니다. 여기에는 하드 드라이브를 다른 저장 장치의 파일에 비트 단위로 복사하는 작업이 포함됩니다. 이상적으로는 이미지의 여러 복사본을 저장할 수 있도록 다른 저장 장치가 상당히 커야 합니다. 복구 도구가 최대한 많은 데이터 복구를 완료하면,이 이미지를 읽기 전용으로 표시. 이것이 될 것이다마스터 카피. 이 이미지를 만지지 마십시오. 대신에 사본을 만드십시오.마스터 카피fsck그리고 달리고 mount이 안에작업 사본. 실수를 해도 별 문제가 되지 않습니다. 그냥 새로 만들기만 하면 됩니다.작업 사본~에서마스터 카피.
마스터 사본 만들기
GNU 주소 구조하드 드라이브에서 데이터를 복구하는 데 이상적입니다. 다음과 같이 실행합니다:
ddrescue --idirect /dev/sdX /mnt/big-storage-filesystem/sdX.img /mnt/big-storage-filesystem/sdX.mapfile
(이렇게 하면 --idirectddrescue가 디스크 액세스를 더 효과적으로 제어할 수 있습니다.)
완료되면 ddrescue를 실행하는 것이 좋습니다 chmod a-w sdX.img sdX.mapfile. 나중에 수정하면 안 됩니다.
작업 복사본에서 복원을 시도합니다.
먼저 작업 복사본을 만드세요.
cp /mnt/big-storage-filesystem/sdX.img /mnt/big-storage-filesystem/work/work-sdX.img
그런 다음 losstup을 사용하여 이미지를 블록 장치 파일에 매핑합니다.
losetup -a /mnt/big-storage-filesystem/work/work-sdX.img
루프백 장치의 위치가 출력에 표시되므로 위 명령을 실행할 수 있습니다 kpartx -a /dev/loopN./dev/loopN
이제 다른 하드 드라이브처럼 이미지에 액세스할 수 있습니다.
그것을 확인 하면 그런 일을 lsblk할 수 있어야합니다 .fsck -y /dev/loop0p1
운이 좋으면 mount /dev/loop0p1 /mnt/recovery거기에서 시작할 수 있습니다.
운이 좋지 않다면 손상된 파일 시스템에서 데이터를 얻기 위해 포렌식 도구를 사용해야 할 수도 있습니다. 바라보다이것유닉스 SE 게시물이 그 예입니다.
이 경험을 통해 배워보세요
백업을 만들고 백업을 확인하세요. Unix SE에서 이 질문을 하지 않고 대체할 수 없는 데이터를 복구하기 위해 많은 노력을 기울이지 않았다면 무엇을 할 것인지 상상해 보십시오. 기술은 항상 변화하고 기술은 결코 유행을 따르지 않으므로 데이터 손실을 예상하는 것이 좋습니다.
답변3
이제 해결되었습니다. 저와 같은 문제가 발생하면 다른 디스크에 파티션의 이미지 파일 복사본을 만든 다음 cp를 사용하여 이미지를 적어도 한 번 복사하고 모두 읽기 전용으로 표시한 다음 루프로 마운트하세요. 내 파일이 모두 돌아왔어요! ! ! 내가 많이 아끼는 통나무 더미를 제외하고.
모두들 행운을 빌며 파일을 백업하는 것을 잊지 마세요! DVD 구조선이라도 없는 것보다는 낫습니다! 중요한 파일은 여러번 복사하여 가능하다면 인터넷에 업로드해 보세요! 당신은 끔찍한 Firefox 다운로드에 대해 매우 걱정하고 있을 것입니다.