이는 다음의 확장입니다.rsync가 이미 최신 파일을 복사하려고 시도하는 이유는 무엇입니까?
--copy-devices패치를 사용하여 rsync전체 디스크 드라이브를 복사하고 다른 컴퓨터에 이미지로 저장하려고 합니다 .
복사본이 올바르게 실행된 것처럼 보이지만 rsync동일한 값으로 다시 실행하면 매번 일부 데이터가 다시 복사되는 것처럼 보입니다.
나는 rsync자세한 내용을 표시하여 실행하여 다음을 얻었습니다.
$ sudo rsync -vvz --partial --progress --copy-devices /dev/sdb me@otherserver:/backupdisks/mydisk.img
opening connection using: ssh -l me otherserver rsync --server -vvze.Lsfx --partial --copy-devices . /backupdisks/mydisk.img (11 args)
me@otherserver's password:
delta-transmission enabled
sdb
320,071,851,520 100% 63.47MB/s 1:20:09 (xfr#1, to-chk=0/1)
total: matches=2441955 hash_hits=2441955 false_alarms=204015955 data=0
sent 188 bytes received 21,979,001 bytes 2,837.31 bytes/sec
total size is 0 speedup is 0.00
rsync가 시간에 따라 변경 사항을 결정하지만 디스크는 rsync 사이에 변경되지 않았다는 것을 알고 있습니다(그리고 어쨌든 디스크의 수정된 시간을 어떻게 결정합니까?). 그러나 원격 이미지의 시간은 매번 업데이트됩니다. 그래서 이것이 문제가 될 수 있습니다.
또 다른 가능성은 디스크에 매번 다른 값을 반환하고 사용 중인 모든 체크섬을 무효화하는 불량 섹터가 있다는 것입니다.
내 질문은 두 가지입니다.
내 이미지가 성공적으로 전송되었습니다. 그렇다면 다시 실행하면 디스크의 상당 부분이 재전송되는 것처럼 보이는 이유는 무엇입니까? (이것은 또한 내 당연한 질문의 일부로 부분적으로 답변될 수도 있습니다.rsync 출력의 "matches", "hash_hits" 및 "false_alarms"는 무엇이며 "data=0"은 성공을 의미합니까?)
이 작업을 제대로 수행하는 데 필요한 스위치가 없습니까? (어쩌면
--checksum?) rsync 알고리즘에서 사용되는 블록 수준 오류를 나열하는 것이 가능합니까?
답변1
기본적으로 rsync는 크기와 타임스탬프를 기준으로 파일을 비교하지만 장치에는 크기가 없으므로 여기에 설명된 델타 알고리즘을 사용하여 차이를 계산해야 합니다.기술 보고서. 대략적으로 원격 파일은 선택한 크기의 블록으로 나누어지고 이들의 체크섬이 다시 전송됩니다. 로컬 파일도 마찬가지로 블록 단위로 체크섬이 계산되어 목록과 비교됩니다. 그런 다음 리모컨은 파일을 다시 만들기 위해 블록을 재조립하는 방법을 지시받고 일치하지 않는 블록에 대한 데이터가 전송됩니다.
옵션을 사용하여 델타섬 알고리즘에 대해서만 레벨 3에서 디버그 출력을 요청하면 이를 확인할 수 있습니다 --debug=deltasum3. -B숫자를 단순화하기 위해 블록 크기를 지정할 수 있습니다 . 예를 들어, 이미 한 번 복사된 파일의 경우 두 번째 실행은
rsync -B 100000 --copy-devices -avv --debug=deltasum3 --no-W /dev/sdd /tmp/mysdd
각 블록의 체크섬을 보여주는 다음과 같은 출력을 생성합니다.
count=164 rem=84000 blength=100000 s2length=2 flength=16384000
chunk[0] offset=0 len=100000 sum1=61f6893e
chunk[1] offset=100000 len=100000 sum1=32f30ba3
chunk[2] offset=200000 len=100000 sum1=45b1f9e5
...
그러면 차이가 없기 때문에 다른 장치의 체크섬과 매우 사소하게 일치하는 것을 볼 수 있습니다.
potential match at 0 i=0 sum=61f6893e
match at 0 last_match=0 j=0 len=100000 n=0
potential match at 100000 i=1 sum=32f30ba3
match at 100000 last_match=100000 j=1 len=100000 n=0
potential match at 200000 i=2 sum=45b1f9e5
match at 200000 last_match=200000 j=2 len=100000 n=0
...
마지막에는 data=필드가 0이 되어 새 데이터가 전송되지 않았음을 나타냅니다.
total: matches=164 hash_hits=164 false_alarms=0 data=0
이제 파일 중간을 덮어써 복사본을 손상시킨 경우:
echo test | dd conv=block,notrunc seek=80 bs=100000 of=/tmp/mysdd
touch -r /dev/sdd /tmp/mysdd
그런 다음 rsync 디버그는 블록 80에 대한 새로운 체크섬을 표시하지만 일치하는 항목이 없습니다. 79번 매치에서 81번 매치로 이동합니다.
chunk[80] offset=8000000 len=100000 sum1=a73cccfe
...
potential match at 7900000 i=79 sum=58eabec6
match at 7900000 last_match=7900000 j=79 len=100000 n=0
potential match at 8100000 i=81 sum=eba488ba
match at 8100000 last_match=8000000 j=81 len=100000 n=100000
마지막에는 data=100000완전히 새로운 데이터 블록을 전송해야 함을 보여줍니다.
total: matches=163 hash_hits=385 false_alarms=0 data=100000
일치에 실패한 손상된 블록 체크섬에 대해 일치 횟수가 1개 감소했습니다. 아마도 순차 매칭을 잃기 때문에 해시 히트가 증가했을 것입니다.
우리가 보면더 나아가동일한 기술 보고서에는 일부 테스트 결과가 표시되며허위 경보 "32비트 롤링 체크섬은 일치했지만 강력한 체크섬은 일치하지 않은 횟수"로 설명됩니다. 각 블록에는 간단한 체크섬과 만들어진 md5 체크섬(이전 버전에서는 md4)이 있습니다. 단순 체크섬은 32비트 정수이므로 해시 테이블을 사용하여 검색하기 쉽습니다. 항목과 일치하면 더 긴 16바이트 md5 체크섬도 비교되고, 일치하지 않으면 잘못된 경보가 되어 검색이 계속됩니다.
내 예에서는 16MB의 매우 작은(그리고 오래된) USB 키 장치를 사용하고 최소 해시 테이블 크기는 2**16, 즉 65536개의 항목이므로 내가 가지고 있는 164개의 청크 항목을 보유할 때 꽤 비어 있습니다. 잘못된 경보가 너무 많이 발생하는 것은 정상이며 다른 어떤 것보다 효율성을 나타내는 지표입니다.
답변2
다른 옵션과 마찬가지로 사용을 고려하는 것이 좋습니다 rsync --partial --inplace. 그렇지 않으면 작동하는 동안 대상 측에 디스크 이미지의 전체 복사본이 만들어지기 때문입니다. -B 4096장치의 자연스러운 섹터 크기이고 rsync 기본 블록 크기가 이러한 유형의 작업에 비해 너무 작기 때문에 저도 사용하고 있습니다 .
이미지가 모두 올바르게 복사되었는지 다시 확인하려면 sha1sum원본과 대상 측 모두에서 독립적인 작업을 수행하는 것이 좋습니다. 반드시 그럴 필요는 없지만 확실하게 알고 싶다면 간단하고 신뢰할 수 있습니다. 나는 귀하의 소스 디스크가 라이브 마운트나 이와 유사한 것이 아니라고 가정합니다. 그렇지 않으면 모든 베팅이 취소되고 이를 보낼 수 있는 신뢰할 수 있는 방법이 없습니다.