ddrescue 복구 시도를 통해 어떤 파일이 손실되었는지 어떻게 알 수 있나요?

Question 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개(및 512바이트 장치 블록 200개)가 있습니다. 구출하세요:

$ 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.

Answer

발견된 모든 불량 블록의 블록 번호가 필요합니다( 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개(및 512바이트 장치 블록 200개)가 있습니다. 구출하세요:

$ 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.

Question 2

NTFS, ext3, ext4

를 사용하여 오류가 발생한 드라이브에서 데이터를 복사한 후 다음을 ddrescue사용하세요.ddrutility영향을 받은 파일 이름을 찾으려면

ddrescue20초 이내에 맵 파일이 제공된 1TB 파티션의 영향을 받은 NTFS 파일 목록을 성공적으로 얻었습니다 .

현재 디렉터리에 로그 파일을 기록합니다.

링크된 페이지에는 NTFS, ext3 및 ext4에 대한 지원이 언급되어 있습니다.

btrfs, zfs

이러한 파일 시스템에는 자체 내장 scrub기능이 있습니다.

Answer

NTFS, ext3, ext4

를 사용하여 오류가 발생한 드라이브에서 데이터를 복사한 후 다음을 ddrescue사용하세요.ddrutility영향을 받은 파일 이름을 찾으려면

ddrescue20초 이내에 맵 파일이 제공된 1TB 파티션의 영향을 받은 NTFS 파일 목록을 성공적으로 얻었습니다 .

현재 디렉터리에 로그 파일을 기록합니다.

링크된 페이지에는 NTFS, ext3 및 ext4에 대한 지원이 언급되어 있습니다.

btrfs, zfs

이러한 파일 시스템에는 자체 내장 scrub기능이 있습니다.

Question 3

나는 이미 구현된 이라는 유틸리티를 추천하고 싶습니다 ddrutility. 그러면 수동으로 지루한 계산이 필요 없게 됩니다.

복제된 컴퓨터에서 실행해야 합니다.복사(원본이 아님) 드라이브 장치는 다음과 같습니다.

ddru_findbad /dev/sdb /ddrescue-disk-copy.map

여기서는 맵 파일(두 번째 인수)을 사용해야 합니다.

ddrescue이 유틸리티는 매우 똑똑하고 다양한 파일 시스템(NTFS 포함)을 지원하며 아직 분할되지 않은 잘못된 섹터(불량 임시 섹터로 표시)를 테스트하는 기능도 있으므로 전체 절차가 필요한지 예측할 수 있어야 합니다. 완료됩니다. 또한 전체 디스크가 원래 복제되었으므로 /dev/sdb여기서는 전체 디스크( 와 같은 일부 파티션이 아님)로 사용됩니다 ./dev/sdb1

이 유틸리티는 Debian 저장소에서 사용할 수 있으며 다음과 같이 설치할 수 있습니다.

sudo apt install ddrutility

프로젝트 위키:https://sourceforge.net/p/ddrutility/wiki/Home

Answer

나는 이미 구현된 이라는 유틸리티를 추천하고 싶습니다 ddrutility. 그러면 수동으로 지루한 계산이 필요 없게 됩니다.

복제된 컴퓨터에서 실행해야 합니다.복사(원본이 아님) 드라이브 장치는 다음과 같습니다.

ddru_findbad /dev/sdb /ddrescue-disk-copy.map

여기서는 맵 파일(두 번째 인수)을 사용해야 합니다.

ddrescue이 유틸리티는 매우 똑똑하고 다양한 파일 시스템(NTFS 포함)을 지원하며 아직 분할되지 않은 잘못된 섹터(불량 임시 섹터로 표시)를 테스트하는 기능도 있으므로 전체 절차가 필요한지 예측할 수 있어야 합니다. 완료됩니다. 또한 전체 디스크가 원래 복제되었으므로 /dev/sdb여기서는 전체 디스크( 와 같은 일부 파티션이 아님)로 사용됩니다 ./dev/sdb1

이 유틸리티는 Debian 저장소에서 사용할 수 있으며 다음과 같이 설치할 수 있습니다.

sudo apt install ddrutility

프로젝트 위키:https://sourceforge.net/p/ddrutility/wiki/Home

Question 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-invocation.html"장애가 있는 디스크의 경우" 부분을 검색하세요.

dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock

시간이 좀 걸렸어요. 각 불량 블록에는 결함이 있는 드라이브를 두드리는 듯한 소리가 들렸습니다. 블록별로 복사하고 모든 불량 블록을 통해 동일한 소음이 발생했습니다. 소음이 발생한 횟수는 또 다른 불량 블록을 발견하고 디스플레이 오류 메시지에 대해 알려주기 때문입니다. 무슨'conv=오류 없음,동기화'NUL을 사용하여 잘못된 읽기를 채우는 것입니다.'iflag=풀블록'짧은 읽기에 적합하지만 끝까지 데이터 동기화를 유지합니다. 전혀 손상되지 않으며, 단지 결함이 있는 블록을 복사하지 않고 빈 NUL로 채웁니다.

DD를 사용한 복사가 완료된 후 이전 백업에서 Filezilla를 되돌리는 잘못된 파일을 교체하면 모든 것이 제대로 작동했습니다. 결함이 있는 드라이브를 백업하려는 다른 사람들에게 이것이 유용할 수 있기를 바랍니다.

참고: 내 불량 블록은 서로 거의 가깝습니다. 불량이 감지된 그룹은 한 번에 약 4개의 블록입니다. 블록이 디스크 전체에 있으면 여러 파일이 영향을 받을 수 있습니다. 다행히 제 경우에는 큰 데이터베이스 4GB 파일만 영향을 받았습니다.

Answer

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-invocation.html"장애가 있는 디스크의 경우" 부분을 검색하세요.

dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock

시간이 좀 걸렸어요. 각 불량 블록에는 결함이 있는 드라이브를 두드리는 듯한 소리가 들렸습니다. 블록별로 복사하고 모든 불량 블록을 통해 동일한 소음이 발생했습니다. 소음이 발생한 횟수는 또 다른 불량 블록을 발견하고 디스플레이 오류 메시지에 대해 알려주기 때문입니다. 무슨'conv=오류 없음,동기화'NUL을 사용하여 잘못된 읽기를 채우는 것입니다.'iflag=풀블록'짧은 읽기에 적합하지만 끝까지 데이터 동기화를 유지합니다. 전혀 손상되지 않으며, 단지 결함이 있는 블록을 복사하지 않고 빈 NUL로 채웁니다.

DD를 사용한 복사가 완료된 후 이전 백업에서 Filezilla를 되돌리는 잘못된 파일을 교체하면 모든 것이 제대로 작동했습니다. 결함이 있는 드라이브를 백업하려는 다른 사람들에게 이것이 유용할 수 있기를 바랍니다.

참고: 내 불량 블록은 서로 거의 가깝습니다. 불량이 감지된 그룹은 한 번에 약 4개의 블록입니다. 블록이 디스크 전체에 있으면 여러 파일이 영향을 받을 수 있습니다. 다행히 제 경우에는 큰 데이터베이스 4GB 파일만 영향을 받았습니다.

ddrescue 복구 시도를 통해 어떤 파일이 손실되었는지 어떻게 알 수 있나요?

답변1

답변2

NTFS, ext3, ext4

btrfs, zfs

답변3

답변4

관련 정보