이것은 확장입니다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는 크기와 타임스탬프를 기준으로 파일을 비교하지만 장치에는 크기가 없으므로 이 섹션에서 설명하는 차이를 계산하려면 델타 알고리즘을 사용해야 합니다.기술 보고서. 대략적으로 원격 파일은 선택한 크기의 청크로 나누어지고 이러한 청크의 체크섬이 다시 전송됩니다. 로컬 파일도 블록 단위로 체크섬되어 목록과 비교됩니다. 그런 다음 원격 장치는 파일을 다시 만들기 위해 청크를 재조립하고 일치하지 않는 청크에 대한 데이터를 보내는 방법을 알려줍니다.
options 을 사용하여 델타섬 알고리즘에 대해서만 레벨 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개 블록 항목을 저장할 때 매우 null입니다. 이렇게 많은 잘못된 긍정은 정상적인 현상이며 무엇보다 효율성을 나타냅니다.
답변2
rsync --partial --inplace다른 옵션과 함께 사용을 고려해야 합니다. 그렇지 않으면 작동하는 동안 대상에 디스크 이미지의 전체 복사본이 만들어지기 때문입니다. 나는 또한 -B 4096장치의 자연스러운 섹터 크기이고 rsync 기본 블록 크기가 이러한 유형의 작업에 비해 너무 작기 때문에 그것을 사용해 왔습니다 .
이미지가 모두 올바르게 복사되었는지 다시 확인하려면 sha1sum소스 측과 대상 측 모두에서 별도의 작업을 수행하는 것이 좋습니다. 꼭 필요한 것은 아니지만 확실하게 알고 싶다면 간단하고 신뢰할 수 있습니다. 나는 귀하의 소스 디스크가 라이브 마운트 또는 이와 유사한 것이 아니라고 가정합니다. 그렇지 않으면 모든 베팅이 중단되고 이를 보낼 수 있는 안정적인 방법이 없습니다.