고장난 1TB 드라이브에서 데이터를 복구하고 있습니다(하드 드라이브를 교체하는 단계는 무엇입니까?). 시스템 복구 USB에서 이 작업을 수행 ddrescue한 결과 오류 크기는 557568B이고 191개의 오류가 있는 것으로 나타났습니다. 아마도 모두 오류일 것 /home입니다. (소위 "오류"는 불량 섹터가 아니라 일련의 불량 섹터라고 가정합니다. ).
이제 내가 본 몇 가지 가이드에서는 e2fsck새 디스크에서 이 작업을 수행할 것을 제안했습니다. 일부 파일이 "빈 섹터/블록"에 할당되어 있음을 발견하여 적어도 어떤 파일이 해당 파일을 모두 보유하지 않는지 알 수 있기를 바랍니다. . 하지만 전혀 오류가 발견되지 않았습니다( -y아무것도 놓치지 않았는지 확인하지 않고 실행했습니다). 이제 지금까지 95% 오류가 발견되지 않은 상태로 다시 실행하고 있습니다 -c. 언젠가는 해당 파일을 사용할 때까지 0이 아닌 임의의 조각이 있는 정상적으로 보이는 파일이 있는 것 같습니다. 소프트웨어가 파일을 열 때 감지됩니다. , 또는 Linux Mint가 요구할 때.
잠재적으로 손상된 파일 목록을 얻기 위해 기존/새 드라이브에 수행할 수 있는 작업이 있습니까? 191개가 파일에 걸쳐 있을 수 있기 때문에 그 수가 얼마나 되는지 모르지만 적어도 제가 가장 걱정하는 것은 오래된 가족 사진과 비디오(각각 1MB 이상)입니다. , 나머지는 관련이 없거나 최근에 백업된 것일 수 있습니다.
업데이트: e2fsck의 새 채널은 내가 전혀 몰랐던 몇 가지 새로운 기능을 제공합니다.
Block bitmap differences: +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes
답변1
발견한 모든 불량 블록의 블록 번호가 필요하며( ddrescue목록이 제공되어야 하며 저장해 두시기 바랍니다) 그런 다음 이러한 블록을 사용하는 파일을 찾아야 합니다(예:여기). 불량 블록이 많으면 이 스크립트를 작성해야 할 수도 있습니다.
e2fsck도움이 되지 않습니다. 파일 시스템 자체의 일관성만 확인하므로 "관리" 파일 시스템 정보가 포함된 잘못된 블록에서만 작동합니다.
파일의 불량 블록은 비어 있습니다.
편집하다
좋아요, 블록 크기를 알아봅시다. 512바이트 장치 블록을 사용하여 평가판 파일 시스템을 만들어 보겠습니다.
$ dd if=/dev/zero of=fs bs=512 count=200
$ /sbin/mke2fs fs
$ ll fs
-rw-r--r-- 1 dirk dirk 102400 Apr 27 10:03 fs
$ /sbin/tune2fs -l fs
...
Block count: 100
...
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
따라서 파일 시스템 블록 크기는 1024이고 100개의 파일 시스템 블록(및 200개의 512바이트 장치 블록)이 있습니다. 저장해:
$ ddrescue -b512 fs fs.new fs.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued: 102400 B, errsize: 0 B, current rate: 102 kB/s
ipos: 65536 B, errors: 0, average rate: 102 kB/s
opos: 65536 B, run time: 1 s, successful read: 0 s ago
Finished
$ cat fs.log
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue fs fs.new fs.log
# Start time: 2017-04-27 10:04:03
# Current time: 2017-04-27 10:04:03
# Finished
# current_pos current_status
0x00010000 +
# pos size status
0x00000000 0x00019000 +
$ printf "%i\n" 0x00019000
102400
따라서 16진수 ddrescue단위는 블록이 아니라 바이트입니다. 마지막으로 무엇이 유용한지 살펴보겠습니다 debugfs. 먼저 파일을 만들고 해당 내용을 찾습니다.
$ sudo mount -o loop fs /mnt/tmp
$ sudo chmod go+rwx /mnt/tmp/
$ echo 'abcdefghijk' > /mnt/tmp/foo
$ sudo umount /mnt/tmp
$ hexdump -C fs
...
00005400 61 62 63 64 65 66 67 68 69 6a 6b 0a 00 00 00 00 |abcdefghijk.....|
00005410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
따라서 데이터의 바이트 주소는 0x5400. 이를 1024바이트 파일 시스템 블록으로 변환합니다.
$ printf "%i\n" 0x5400
21504
$ expr 21504 / 1024
21
블록 범위도 시도해 보겠습니다.
$ /sbin/debugfs fs
debugfs 1.43.3 (04-Sep-2016)
debugfs: testb 0
testb: Invalid block number 0
debugfs: testb 1
Block 1 marked in use
debugfs: testb 99
Block 99 not in use
debugfs: testb 100
Illegal block number passed to ext2fs_test_block_bitmap #100 for block bitmap for fs
Block 100 not in use
debugfs: testb 21
Block 21 marked in use
debugfs: icheck 21
Block Inode number
21 12
debugfs: ncheck 12
Inode Pathname
12 //foo
따라서 결과는 예상한 대로이지만 블록 0은 유효하지 않습니다. 아마도 파일 시스템 메타데이터가 있기 때문일 것입니다. 따라서 0x30F8A71000의 바이트 주소 에 대해 ddrescue파티션이 아닌 전체 디스크에서 작업한다고 가정하면 파티션이 시작되는 바이트 주소를 뺍니다.
210330128384 - 7815168 * 512 = 206328762368
이를 tune2fs블록 크기로 나누어 파일 시스템 블록을 얻습니다. (손상된 여러 물리적 블록이 파일 시스템 블록을 구성하므로 숫자가 정확한 배수일 필요는 없습니다.)
206328762368 / 4096 = 50373233.0
이것이 테스트해야 할 블록입니다 debugfs.
답변2
NTFS, ext3, ext4
실패한 드라이브의 데이터를 복사한 후 ddrescue다음을 사용하십시오.ddrutility영향을 받은 파일 이름을 찾으십시오.
ddrescue20초 이내에 지정된 매핑 파일에 대해 1TB 파티션에 영향을 받는 NTFS 파일을 나열하는 데 성공했습니다 .
현재 디렉터리에 로그 파일을 씁니다.
링크된 페이지에는 NTFS, ext3 및 ext4에 대한 지원이 언급되어 있습니다.
btrfs, zfs
이러한 파일 시스템에는 자체 내장 scrub기능이 있습니다.
답변3
나는 지루한 수동 계산을 없애기 위해 이미 구현된 유틸리티를 추천합니다 ddrutility.
클론에서 이것을 실행해야합니다복사(원래가 아닌) 드라이버 장비는 다음과 같습니다:
ddru_findbad /dev/sdb /ddrescue-disk-copy.map
여기서는 맵 파일(두 번째 매개변수)을 사용해야 합니다.
이 유틸리티는 매우 똑똑하고 다양한 파일 시스템(NTFS 포함)을 지원하며 아직 분할되지 않은 불량 섹터를 테스트하는 기능도 갖추고 있으므로(임시 불량 섹터로 표시) 필요한지 여부를 예측할 수 있어야 합니다. 전체 ddrescue프로세스가 완료됩니다. 또한 전체 디스크가 원래 복제되었으므로 /dev/sdb여기서는 전체 디스크( 와 같은 일부 파티션이 아님)가 사용되었습니다 ./dev/sdb1
이 유틸리티는 Debian 저장소에서 사용할 수 있으며 다음을 통해 설치할 수 있습니다.
sudo apt install ddrutility
프로젝트에 대한 위키피디아:https://sourceforge.net/p/ddrutility/wiki/Home
답변4
Filezilla를 간단하게 사용하고 문제를 해결했습니다. 일반 Filezilla를 사용하여 모든 좋은 데이터를 백업하세요. 대용량 파일이 제대로 복사되지 않은 것을 발견했습니다(전송이 중지되었다가 도중에 다시 시작되었습니다). 다행히 같은 파일의 이전 백업이 있었습니다. 디스크를 복사하려면 다음 프로세스를 사용하여 디스크에서 불량 블록을 찾아야 했습니다.
먼저 문제의 디스크를 찾고 식별 HD 정보를 사용하십시오.fdisk -l
두 번째는 디스크가 다음과 같다고 가정하는 경우입니다./dev/sdb그런 다음 명령을 실행해야합니다 불량 블록 -v /dev/sdb드라이브의 모든 불량 블록이 나열됩니다. 다행히도 일부 있을 것입니다. 불량 블록이 발견되지 않으면 드라이브 블록에 문제가 없으며 해결해야 할 다른 문제가 있습니다. 내 블록 크기는 512이므로 해당 기본 숫자를 사용하여 DD를 실행합니다.
세 번째 청크의 크기는 512이므로 bs=512로 설정했습니다.
평소처럼 정기적으로 DD를 실행할 때마다 오류가 발생하여 데이터가 손상됩니다. 따라서 페이지에 명시된 매개변수를 사용합니다.https://www.gnu.org/software/coreutils/manual/html_node/dd-inspiration.html"실패한 디스크" 섹션을 검색하세요.
dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock
시간이 좀 걸렸어요. 각각의 불량 블록은 고장난 드라이브의 충돌 소리와 유사한 소리를 냅니다. 블록별로 복사하고 모든 불량 블록에서 동일한 소음을 발생시킵니다. 소음이 나는 횟수는 또 다른 불량 블록을 발견하고 오류 메시지 표시를 알려주기 때문입니다. 무엇인가요'변환=오류 없음, 동기화'잘못된 읽기를 NUL로 채우는 것입니다.'iflag=전체 블록'짧은 읽기에 적합하지만 항상 데이터 동기화를 유지합니다. 전혀 손상이 없으며 잘못된 블록을 복사하지 않고 빈 NUL로 채웁니다.
DD를 사용하여 복사를 마친 후 불량 파일을 교체하고 이전 백업에서 Filezilla를 복원했는데 모든 것이 잘 작동했습니다. 실패한 드라이브를 백업하려는 다른 사람에게 이 내용이 도움이 되기를 바랍니다.
참고: 내 불량 블록은 서로 매우 가깝습니다. 4개의 블록을 그룹화하면 불량 상태가 한 번 정도 감지됩니다. 블록이 디스크 전체에 분산되어 있으면 여러 파일이 영향을 받을 수 있습니다. 다행히 제 경우에는 4GB의 대용량 데이터베이스 파일만 영향을 받았습니다.