저는 두 대의 서로 다른 컴퓨터에서 사용하는 대용량 파일(2-3GB, 바이너리, 문서화되지 않은 형식)을 가지고 있습니다(보통 데스크탑 시스템에서 사용하지만 여행할 때는 노트북 위에 올려 놓습니다). rsync를 사용하여 파일을 앞뒤로 전송합니다.
나는 때때로 이 파일을 조금씩 업데이트하는데, 변경된 양은 100kB 미만입니다. 이는 두 시스템 모두에서 발생합니다.
내가 이해한 바로는 rsync의 문제점은 소스와 대상 사이에서 파일이 변경되었다고 생각되면 전체 파일을 전송한다는 것입니다. 내 경우에는 파일의 작은 부분이 변경되면 시간 낭비처럼 느껴졌습니다. 나는 원본과 대상의 전송 에이전트가 먼저 전체 파일을 체크섬한 다음 결과를 비교하는 프로토콜을 구상합니다. 그들은 전체 파일의 체크섬이 다르다는 것을 깨닫고 파일을 A와 B의 두 부분으로 분할하고 별도로 체크섬을 계산했습니다.
아하, B는 두 컴퓨터 모두 동일합니다. 그 절반은 무시합시다. 이제 A를 A1과 A2로 나눕니다. 그런데 A2만 바뀌었어요. A2를 A2I와 A2II로 분할하여 비교 등을 합니다. 예를 들어 원본과 대상이 서로 다른 세 개의 섹션(각각 1MB)을 찾을 때까지 이 작업을 반복적으로 수행한 다음 해당 섹션만 전송하고 대상 파일의 올바른 위치에 삽입합니다. 오늘날 빠른 SSD와 멀티 코어 CPU를 사용하면 이러한 병렬화는 매우 효율적입니다.
그래서 제 질문은, 오늘날 이와 같이 작동하는(또는 상상할 수 없지만 비슷한 결과를 제공하는 다른 방식으로) 사용할 수 있는 도구가 있습니까?입니다.
해명 요청이 발행되었습니다. 저는 주로 Mac을 사용하기 때문에 파일 시스템은 HFS+입니다. 일반적으로 나는 이렇게 rsync를 시작합니다.
rsync -av --delete --progress --stats- 이 경우 SSH를 사용할 때도 있고 rsyncd를 사용할 때도 있습니다. rsyncd를 사용할 때 다음과 같이 시작합니다 rsync --daemon --verbose --no-detach.
두 번째 설명: 작은 변경 사항이 있는 두 위치에 모두 존재하는 파일의 델타만 전송하거나 rsync가 실제로 이 기능을 제공하는 도구를 요청합니다. rsync에 대한 내 경험은 파일 전체를 전송한다는 것입니다(그러나 이제 이를 설명하는 답변은 다음과 같습니다. rsync는 델타만 전송하기 위해 rsync 서버가 필요합니다. 그렇지 않으면(예: ssh-shell 사용) 전체 파일을 전송하지만 많은 경우 변경되었습니다).
답변1
Rsync는 델타를 사용하지 않지만 단일 프로세스로서 소스 및 대상 파일을 담당하는 경우 전체 파일이 전송됩니다. 원본 및 대상 컴퓨터에서 별도의 클라이언트 및 서버 프로세스가 실행 중인 경우 델타를 전송할 수 있습니다.
rsync가 유일한 프로세스일 때 델타를 보내지 않는 이유는 델타를 보내야 하는지 여부를 결정하기 위해 소스 및 대상 파일을 읽어야 하기 때문입니다. 완료되면 파일을 직접 복사할 수 있습니다.
이 명령 형식을 사용하는 경우 rsync 프로세스는 하나만 있습니다.
rsync /path/to/local/file /network/path/to/remote/file
이 명령 형식을 사용하는 경우 두 개의 rsync 프로세스(로컬 호스트와 원격 호스트에 하나씩)가 있으며 증분을 사용할 수 있습니다.
rsync /path/to/local/file remote_host:/path/to/remote/file
답변2
설명 섹션에서 man rsync:
Rsync는 빠르고 다양한 파일 복사 도구입니다. 원격 셸을 통해 다른 호스트로/에서 로컬로 복사하거나 원격 rsync 데몬으로/에서 복사할 수 있습니다. 이는 동작의 다양한 측면을 제어할 수 있는 많은 옵션을 제공하고 복사할 파일 세트를 지정하는 데 있어 뛰어난 유연성을 허용합니다. 원본 파일과 대상에 있는 기존 파일의 차이만 전송하여 네트워크로 전송되는 데이터의 양을 줄이는 증분 전송 알고리즘으로 알려져 있습니다.
그래서 그것은 "아니요"입니다.
답변3
이를 최적화하려면 RAID-1(미러)을 사용할 수 있습니다. 양쪽이 바뀌어서 이상하기도 하지만 rsync사용하기도 이상하네요. 이 문제를 처리하는 방법을 설명해야 합니다.
dd if=/dev/zero of=/path/to/syncfile.img bs=1M count=3500가까운 장래에 동기화 파일이 증가할 크기보다 약간 더 큰 파일을 만들 수 있습니다 ( ).- 그런 다음 파일 상단에 루프 장치( )를 배치합니다
losetup /dev/loop5 /path/to/syncfile.img. - 두 시스템 모두에서 이 작업을 수행합니다.
- 변경 사항을 다른 시스템과 동기화해야 하는 시스템에서는
nbd네트워크 블록 장치( )를 통해 다른 시스템의 블록 장치를 사용할 수 있도록 설정할 수 있습니다. - 두 개의 블록 장치에 RAID-1 배열을 만듭니다.
mdadm create /dev/md5 --raid-devices=2 --level=raid1 --bitmap=/path/to/ext3volume/sync-bitmap --assume-clean /dev/loop5 --write-mostly /dev/path/to/nbd.--bitmap=/path/to/ext3volume/sync-bitmap나중에 배열을 조립할 때 필요합니다. - RAID에 파일 시스템을 생성
mke2fs -j /dev/md5하고 어딘가에 마운트합니다. - 파일을 볼륨에 복사합니다. 이 작업은 인터넷 연결이 양호한 상태에서 이루어져야 합니다. 어쩌면 파일 내용을 블록 장치에 직접 쓰는 더 똑똑한 방법이 있을 수도 있는데, 이는 로컬에서 수행할 수 있지만 파일 내용이 파일 시스템 메타데이터와 혼합되어 있기 때문에 어떻게 해야 할지 모르겠습니다.
이제 네트워크 블록 장치의 연결을 끊을 수 있습니다. 이로 인해 양쪽 모두 RAID-1 성능이 저하됩니다. 동기화하려면 다음을 수행해야 합니다. 1. 동기화 시스템에서 RAID를 마운트 해제하고 고정합니다. 2. nbd를 다시 설정합니다. 3. 동기화 소스 시스템의 RAID에 nbd를 핫 추가합니다.
그러면 두 블록 장치가 동기화됩니다. 그러나 비트맵 덕분에 소스 시스템은 상대방에서 읽지 않고도 어떤 데이터를 전송해야 하는지 알 수 있습니다.
질문
잡고 있다. 이제 모든 것을 적어 두었으므로 이것이 양쪽(다른 영역)의 변경 사항에는 적용되지 않는다는 것을 깨달았습니다(괜찮습니다). --build대신 사용하면 작동할 수 있습니다 --create(이를 통해 로컬 블록 장치가 두 호스트 모두의 마스터인 것처럼 가장할 수 있음).
양방향 변경 사항을 처리하려는 방법에 따라 비트맵 파일을 백업하고(두 RAID가 모두 중지된 동안) 양방향으로만 동기화를 실행할 수 있습니다. 또는 (변경 사항을 한 방향으로만 기록하려는 경우) 또는 더 나쁜 경우에는 동기화를 실행하고 RAID를 중지하고 로컬 비트맵을 원격 비트맵으로 바꾼 다음 다시 동기화합니다(그런 다음 비트맵 파일을 동기화합니다). 확실히 재미있을 거예요.
LVM 스냅샷
LVM 스냅샷은 유사한 작업을 수행할 수 있습니다.