tar.gz웹 호스팅을 아카이브로 압축하여 이라는 백업을 생성한다고 가정해 보겠습니다 backup.tar.gz.
한 달 후에 이 과정을 반복하고 싶습니다. 제가 적극적으로 사이트를 개발 중이어서 마지막 백업 이후 일부 변경 사항이 발생했다고 가정해 보겠습니다.
나(또는 내 크론 작업)는 한 달 후에 이 프로세스를 반복하고씌우다backup.tar.gz업데이트된 백업 아카이브가 포함된 원본 파일입니다.
rsync이를 사용하여 원격 백업 대상(예: SFTP를 통해)과 동기화 하는 경우 backup.tar.gz두 파일 간의 델타만 동기화할 수 있습니까?
파일을 덮어쓰면 새 타임스탬프가 생성되어 동작에 영향을 미치나요?
아니면 어떤 경우에도 rsync가 아카이브를 보고 대부분의 아카이브가 대상에 보존되어 있음을 인식하고 변경 사항만 동기화할 수 있습니까?
감사합니다!
답변1
압축(gzipped) 파일은 소스에 1바이트를 추가하여 전체적으로 변환됩니다. rsync아주 작은 변경이라도 전체 파일을 전송해야 하기 때문에 효율적인 복사에는 전혀 적합하지 않습니다 .
gzip다행히도 효율적인 전송을 위해 일부 압축 구현을 조정할 수 있습니다 rsync.
--rsyncable[...] 이 옵션을 사용하면 rsync는 변경된 파일과 변경된 영역의 아카이브 구조를 업데이트하는 데 필요한 소량의 메타데이터만 전송할 수 있습니다.
이 플래그에 직접 액세스할 수 없으므로 직접 압축하는 tar대신 파이프를 사용해야 합니다.tar
tar cf - files and folders | gzip --rsyncable > output.tgz
GZIP( 모든 호출에 대해 이 값을 설정하는 데 사용할 수 있는 환경 변수가 있지만 gzip문서에는 더 이상 사용되지 않는 것으로 표시되어 있으므로 함부로 사용하지 않는 것이 좋습니다.)
답변2
기본적으로 Rsync는 수정된 블록과 바이트만 동기화합니다. 따라서 이전에 텍스트 파일을 동기화한 후 나중에 동기화하는 동안 소스 파일에 일부 텍스트를 추가한 경우 삽입된 텍스트만 복사됩니다.
압축되지 않은 tar 파일을 사용하고 여기에 파일을 추가하는 경우
tar -rf archive.tar 파일3.txt
그러면 rsync는 tar 파일 끝의 새로운 차이점만 전송할 수 있습니다.
그러나 처음부터 tar 파일을 생성하는 경우 tar가 아카이브에 파일과 디렉터리를 추가하는 방식이 경우에 따라 정의되지 않을 수 있습니다.
매우 유사한 파일 시스템에서 두 개의 tar 작업을 수행하면 완전히 다른 기본 구조를 가진 tar 파일이 생성될 가능성이 높습니다.
그러나 이 비결정적 동작의 심각도에 따라 rsync 델타 알고리즘이 어느 정도 승리할 수 있습니다.
출력을 .gz로 압축하면 상황이 더욱 악화됩니다. 데이터를 압축하는 것은 변환 작업이며 tar 파일에 몇 바이트를 추가한 다음 압축하면 전체 구조가 근본적으로 바뀔 수 있습니다. 이는 rsync에 의해 구현된 롤링 해시 알고리즘을 무효화합니다.
tar 파일을 직접 압축하지 않는 것이 가장 좋지만, rsync가 rsync, --compress 또는 -z를 사용하여 보내는 데이터를 압축하도록 허용하는 것이 가장 좋습니다.
Tar는 패딩을 추가하고 특정 순서 없이 파일을 정렬하며 타임스탬프 등을 추가하기 때문에 결정적이지 않습니다.
일부 시스템(예: Nix/Nixos)은 NAR이라는 결정적 아카이브 형식을 사용합니다. NAR은 Knicks Archives입니다.
아카이버의 비결정적 동작과 이를 극복하는 방법에 대해 더 알고 싶다면 Dolstra의 박사 논문에서 더 많은 정보를 찾을 수 있습니다.