VPN을 통한 클라우드 백업이 느린 이유: 진짜 단계 찾기

VPN을 통해 기어가는 백업은 터널을 끊고 다시 측정하는 뻔한 실험을 유도합니다. 그러나 그 실험은 다른 질문에 답하는 경우가 많습니다. 작업이 바이트를 옮기는 대신 파일을 해시하고 있었거나 재시도를 기다리고 있었을 수 있기 때문입니다. 먼저 단계를 분리하면 불만은 구체적인 기대 결과가 있는 구체적인 테스트로 바뀝니다. 라우트가 후보가 되는 것은 전송 단계가 실제로 느릴 때뿐입니다.

느리게 느껴질 때 작업은 어느 단계에 있는가

백업 도구는 단계를 거칩니다. 파일 검색, 읽기와 해시 계산, 압축, 암호화, 업로드, 그리고 검증입니다. 각 단계에는 고유한 병목이 있고, 그중 일부만 네트워크를 건드립니다. 아직 아무 단계도 보고하지 않는 도구는 스캔을 끝내지 않았다고 말하는 것입니다.

백만 개의 작은 파일을 준비하는 데 이십 분을 쓰는 작업은 터널이 빨라져도 빨라지지 않습니다. 업링크를 포화시키는 작업은 해결책이 다른 용량 문제입니다. 지연이 발생하는 동안 진행 출력을 읽고 단계를 기록하고 시각을 적어 두세요. 불만 시점의 단계만이 중요합니다. 작은 파일은 큰 객체와 다르게 동작하는데, 파일마다 오가는 왕복이 지배적이어서 전송이 안정된 속도에 도달하지 못합니다. 터널에 대한 결론을 내리기 전에 같은 것끼리 비교하세요.

공용 엔드포인트와 사설 NAS는 다르게 실패한다

공용 백업 서비스는 자체 인증된 애플리케이션 연결을 사용하며, 터널은 더 긴 경로의 한 구간일 뿐입니다. 사설 NAS는 보통 네트워크에 대한 기본 접근성을 그 터널에 의존합니다. 이 차이가 연결 해제가 유효한 기준선인지, 아무것도 아닌 테스트인지를 결정합니다.

공용의 경우 정책이 허용한다면 다른 라우트로 같은 작업을 수행하는 것이 공정한 비교가 될 수 있습니다. 사설의 경우 터널을 제거하면 서버로 가는 경로가 전혀 남지 않으므로, 결과는 사용하는 경로가 아니라 삭제한 경로를 설명합니다.

멈춤은 느린 전송과 다른 실패다

그 표의 세 번째 열은 안정성 테스트를 아예 수행할 수 있는지를 결정합니다. 터널을 제거하는 기준선은 다른 경로가 존재하는 곳에서만 의미가 있기 때문입니다. 쓸 만한 기준선이 있다면 평균 속도가 아니라 실패의 모양을 보세요. 낮지만 꾸준한 업로드는 용량을 가리키고, 멈췄다 다시 시작하는 작업은 중단, 인증, 또는 문제 있는 파일 하나를 가리킵니다. 이 둘은 거의 같은 불만을 만들면서 전혀 다른 수리를 요구합니다.

재시도는 모든 측정을 왜곡합니다. 회선 위의 바이트가 실제로 바뀐 양보다 많을 수 있기 때문입니다. 다시 작업을 중단해 무슨 일이 일어나는지 보기 전에 재개 동작을 읽어 보세요. 분할 재개 업로드는 저렴하게 복구되지만 파일 전체를 다시 시작하는 것은 그렇지 않습니다. 몇 분마다 다시 연결되는 터널도 실제로는 안정성 문제인데 대역폭 문제처럼 보입니다. 경로 MTU가 이를 악화시키는데, 사용 가능한 페이로드를 줄이는 터널은 큰 세그먼트를 멈추고 작은 것만 통과시키기 때문입니다.

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

업로드 하나가 다른 모든 흐름을 굶길 수 있다

업링크를 채우는 업로드는 통화와 브라우징을 응답 없게 만들고, 백업이 그 대역을 두고 경쟁하는 유일한 대상인 경우는 드뭅니다. 두 번째 동기화 클라이언트만으로도 같은 증상이 나타납니다. 터널을 탓하기 전에 다른 무엇이 업로드 중인지 보세요.

최고 처리량을 다투는 대신 도구가 문서화한 일정이나 대역폭 제한을 사용하세요. 대화형 작업을 위한 여유를 남기는 것이 보통 마지막 몇 퍼센트보다 값집니다. 그다음 제한이 실제로 무엇에 적용되는지 확인하세요. 파일마다 제한하는 도구도 있고, 실행 전체를 제한하는 도구도 있으며, 작은 파일의 오버헤드를 완전히 무시하는 도구도 있습니다. 작업 부하와 맞지 않는 제한은 아무것도 바꾸지 않습니다. 분할 터널링도 여기서 의심할 만한데, 런처를 터널에서 제외해도 업로드를 수행하는 도우미 서비스는 제외되지 않습니다. 예를 들어 Rclone은 전송 제한과 재시도 동작을 모두 문서에 공개하므로, 제한이 무엇을 제어해야 하는지 참고하기 좋습니다.

속도 테스트가 아니라 복원으로 마무리하라

완료된 업로드는 그로부터 무언가 복원되기 전까지 백업이 아닙니다. 기대하는 버전이 있는지 확인한 다음, 도구가 문서화한 절차로 대표 파일을 복원하세요. 복구 정보는 잃어버릴 수 있는 기계나 프로필이 아닌 다른 곳에 보관하고, 실험을 정돈하기 위해 작동하는 백업을 버리는 일은 없어야 합니다.

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

네트워크 변경 후 전송과 복원을 모두 반복해, 개선이 데이터를 더 빨리 옮기는 데 그치지 않고 백업에 기여함을 보여 주세요. 그 두 번째 실행이 티켓을 닫습니다. 복원을 시험하지 않은 더 빠른 전송은 보호 없이 지내는 더 느린 방법입니다.