스트림 rdiff - 델타 차이점?

Question

rdiff를 사용하여 온라인 백업을 수행하는 제품이 있습니다.

1. 복사 준비 영역에 파일 (우리가 작업하는 동안 그래서 파일이 사라지지 않습니다하거나 수정할 수)

2. 해시 원본 파일 및 rdiff는을 계산 : 어떤 일이 발생하는 것입니다 서명 (델타 차이점 사용) 는

3. 를 압축 &는 결과 델타 차이를 암호화 (우리가 더 이전 버전이없는 경우,이 단계를 스킵)이 rdiff는 델타 차이를 계산

현재 이러한 단계는 서로 명확하게 수행됩니다. 최종 결과는 파일을 여러 번 반복하는 것입니다. 작은 파일의 경우 이것은 (특히 디스크 캐싱과 관련하여) 큰 문제는 아니지만 대용량 파일 (10 또는 심지어 100GB)의 경우 이는 실제 성능 저하 요인입니다.

모든 단계를 하나의 읽기/쓰기 단계로 통합하고자합니다.

이렇게하려면 모든 "출력"(파일 해시, rdiff 서명, 압축 된 & 암호화 된 델타 차이 파일)을 보존하면서 스트리밍 방식으로 위의 모든 단계를 수행 할 수 있어야합니다. 이렇게하면 소스 파일 (예 : 100k?)에서 데이터 블록을 읽은 다음 해시, rdiff 서명을 업데이트하고 델타 차이를 계산 한 다음 압축/암호화 출력 스트림에 출력을 쓰도록 메모리의 파일을 반복합니다 . 목표는 디스크 스 래싱의 양을 크게 최소화하는 것입니다.

현재 서명을 계산하고 2 진 델타를 생성하기 위해 rdiff.exe (기본 librsync 라이브러리의 맨 위에있는 얇은 층)를 사용합니다. 즉, 이러한 과정은 별도의 프로세스로 수행되며 스트리밍 방식 대신 원샷 방식으로 수행됩니다.

librsync 라이브러리를 사용하여 필요한 작업을 수행하려면 어떻게해야합니까?

Answer 1

아마도 1 단계를 건너 뛸 수 있습니다. 파일이 열려있는 동안 파일을 삭제할 수 없으며 파일을 열 때 적절한 잠금 플래그를 선택하면 파일이 수정되지 않을 수 있습니다. 예를 들어 CreateFile 함수는 dwShareMode 인수를 사용합니다.

rdiff 델타를 만들기 전에 전체 rdiff 서명을 계산해야합니다. 서명을 계산하고 한 번에 파일의 각 블록 (예 : 100MB 블록)에 대한 델타를 사용하여 전체 파일을 읽지 않아도됩니다. 이 방법으로 압축 효율을 잃을 수 있습니다 *. 또한 rdiff에서 xdelta으로 전환하는 것을 고려해 볼 수 있습니다. 입력을 통해 단일 패스에서 델타 파일을 만들 수 있습니다.

압축 및 암호화는 델타 계산과 함께 병렬로 수행 할 수 있습니다. 별도의 프로그램에서 압축 및 암호화를 수행하는 경우 표준 입력에서 읽거나 표준 출력에 쓰는 것이 허용됩니다. 이것은 예를 들어, 배치 파일에 파이프가 가장 쉽게 사용할 수 있습니다

rdiff signature oldfile oldfile.sig 
rdiff delta oldfile.sig newfile | gzip -c | gpg -e -r ... > compressed_encrypted_delta 

당신이 당신의 프로그램에서 압축/암호화 라이브러리를 사용하는 경우 작업을 스트리밍을 지원하는 라이브러리를 선택해야합니다.

* 또는 데이터가 파일에서 움직이면 많은 효율성을 잃게됩니다. 누군가가 100MB를 10GB 파일 앞에 추가하면 rdiff는 약 100MB의 델타 파일을 생성합니다.rdiff는 한 번에 100MB 이하의 블록으로 수행하여 약 10GB의 델타를 생성합니다. 200MB의 블록은 각 블록의 데이터의 절반 만이 파일의 이전 버전의 해당 블록에 있으므로 약 5GB의 델타를 생성합니다.