VPN을 거치는 rsync: 끊긴 전송을 재사용하는 재시도

업로드가 열두 기가바이트짜리 아카이브의 네 기가바이트 지점에서 멈추고, 다운로드 관리자에게서 배운 습관은 재개를 누르라고 말한다. rsync는 TCP 스트림을 재개하지 않는다. 그 스트림은 터널의 마지막 재전송과 함께 사라졌기 때문이다. 대신 할 수 있는 일은 이미 받은 바이트를 보관하고 다음 시도의 기반으로 쓰는 것이며, 이것은 다른 규칙을 가진 다른 메커니즘이다. 어떤 플래그를 고르느냐가 그 재사용이 아예 일어날지를 결정한다.

재시도는 상태를 다시 만들 뿐, 스트림을 재개하지 않는다

SSH 세션이 끊기면 원격 쪽에는 디스크에 기록한 것만 남고 그 밖에는 아무것도 없다. 다시 붙을 세션 토큰도, 재생할 시퀀스 번호도 없다. 다음 실행은 새 연결을 열고 소스를 다시 읽고 수신자에게 무엇을 이미 가지고 있는지 묻는다.

그 마지막 질문이 부분 파일을 남길 가치가 있는 이유다. 수신자의 사본은 rsync에게 비교할 재료를 주고, 알고리즘은 식별할 수 있는 차이만 보낸다. 그래도 메타데이터의 새 전송과 소스에 대한 새 통과는 필요하므로, 절약되는 시간은 파일이 얼마나 일치하는지에 비례하고 이전 연결이 얼마나 진행했는지에는 비례하지 않는다. 수신자가 아무것도 남기지 않았다면, 첫 시도가 몇 기가바이트를 옮겼든 다음 시도는 전체 사본이다.

재사용 가능한 조각이 어디에 살지 정한다

기본 동작은 부분 파일을 대상 경로에 쓰기 때문에, 반쯤 기록된 아카이브가 최종 이름으로 보이게 된다. --partial-dir 는 그것을 원하는 디렉터리로 옮기며, 설명서는 그 디렉터리를 이후 전송이 데이터로 사용하도록 보관된다고 설명한다. 상대 이름은 대상 디렉터리 아래에서 해석되며, 두 끝의 배치가 다를 수 있을 때 원하는 것이 바로 그것이다.

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

대상에서도 순서가 중요하다. 부분 디렉터리에는 조각을 위한 충분한 공간이 필요하고, 볼륨에는 완성된 파일을 위한 공간도 필요하다. 전송 도중 대상 볼륨을 채우면 네트워크 문제처럼 보이지만 아닌 실패가 생기고, 보관된 조각이 잘린 채 남을 수 있다. 실행이 시작되기 전에 수신 호스트의 여유 공간을 확인하고, 실패한 뒤에 확인하지 않는다. 같은 SSH 경로로 df -h 를 몇 초 실행하는 것이 계획의 가장 저렴한 시험이다.

권한은 더 작지만 실제 걱정거리다. 관계없는 계정이 쓸 수 있는 부분 디렉터리는 다음 실행이 이미 받은 것으로 취급할 내용을 다른 사람이 바꿔치기할 수 있게 한다. 전송 계정 소유로 두고, 다른 서비스가 게시하는 곳에 두지 않는다.

같은 사본을 실행한다. 더 영리한 사본이 아니라

재사용은 소스와 대상이 여전히 같은 객체를 가리킬 때만 적용된다. 같은 경로, 같은 이름, 같은 파일이다. 소스 이름을 바꾸거나 다른 대상 디렉터리를 가리키면 쓸모없는 것과의 새 비교가 시작된다.

델타 동작을 기대하면서 --whole-file 를 추가하지 않는다. 그 옵션은 롤링 체크섬 비교 없이 파일 전체를 복사하라고 rsync에 지시하며, 빠른 로컬 링크에서는 합리적이고 실패한 장거리 업로드 뒤에는 정확히 틀린 선택이다. --inplace 도 이야기를 바꾼다. 대상 파일에 직접 쓰기 때문에, 중단되면 옛 내용과 새 내용이 섞인 파일이 남고 되돌아갈 별도 조각이 없다.

진행 줄은 전송의 집계 진행을 보고한다. 완료 신호가 아니다. 연결이 아직 열려 있는데 숫자가 백 퍼센트에 이르는 것은 데이터가 밀려 들어갔다는 뜻이지, 수신자가 이름을 바꾸거나 동기화하거나 받아들였다는 뜻이 아니다.

일치한 뒤에만 객체를 받아들인다

먼저 종료 상태를 확인하고, 오류가 없다는 것을 믿는 대신 결과를 비교한다. 크기 검사는 잘린 전송의 대부분을 잡고, 체크섬 비교는 나머지를 잡으며, 둘 다 업로드를 다시 실행하는 것보다 저렴하다.

아카이브를 하위 프로세스가 게시한다면 그 프로세스가 승인된 파일을 기다리게 한다. 최종 이름으로 감시 디렉터리에 떨어진 보관 조각은 다음 스캔에 걸리고, 소비자의 오류는 끝나지 않은 전송이 아니라 손상된 입력에 대한 것이 된다.

수신자가 확인할 때까지 소스를 건드리지 않는다. 시도 사이에 아카이브를 다시 만들면 비교 기준이 바뀌고, 다음 실행은 거의 전부를 옮기거나 옛 소스에도 새 소스에도 맞지 않는 파일을 만든다.

한계가 플래그가 아니라 링크일 때

헤더와 프로토콜 오버헤드는 전송의 한 비용이며, 큰 파일이 얼마나 걸리는지를 결정하는 것은 좀처럼 그것이 아니다. 재시작 동작이 더 중요하다. 수작업 없이 끊김을 견디는 방법은 다시 시작해야 하는 더 빠른 방법보다 빨리 쓸 수 있는 파일을 준다. 양 끝의 저장소와 인증 경로도 같은 비교에 속한다.

허용된 대체 경로를 같은 파일과 같은 대상으로 비교하고, 중단 뒤에 각각이 어디서 다시 시작하는지 적어 둔다. 그 한 열은 VPN을 통한 열두 기가바이트 업로드에 대해 짧은 시험에서 잰 어떤 최고 속도보다 많은 것을 알려 준다.