VPN을 통한 rsync: 어느 쪽이 진실의 원천인가?

서버 두 대, 하나의 VPN, 양쪽에 반드시 있어야 하는 디렉터리 하나, 그리고 실행은 쉽지만 되돌리기는 어려운 명령 하나. 입력하기 전에 어느 사본이 권위 있는지 결정하세요, 이후의 모든 rsync 질문이 그 답에 달려 있기 때문입니다. 단방향 복제본, 공유 작업 폴더, 버전이 있는 아카이브는 변경과 삭제에 서로 다른 규칙이 필요합니다. 터널은 경로를 제공할 뿐 그중 어느 것에도 의견이 없습니다.

명령을 입력하기 전에 어느 사본이 이기는지 결정하세요

방향을 한 문장으로 적고, 양쪽의 호스트 이름과 경로를 포함하고, 데이터 소유자의 동의를 받으세요. 이 안내에서 원본은 /srv/publish/이고 대상은 fileserver.example의 계정이며 /srv/mirror/에만 쓸 수 있습니다.

복사 전에 SSH 호스트 키가 검증되었는지, 대상 계정은 복제 영역에만 쓸 수 있는지, 두 호스트 모두 호환되는 rsync 버전을 가지고 있는지 확인하세요. 이런 전제 조건은 작은 계획 실수가 권한 사고가 되는 것을 막습니다. 또한 문제가 생겼을 때 대상의 로그에 어느 계정이 나타날지도 알려 줍니다.

복사를 미리 보고 상세 목록을 읽으세요

먼저 미리보기 플래그로 복사를 실행하고 출력을 보관하세요. 상세 변경은 각 경로에 무슨 일이 일어날지 알려 주며, 이는 나중에 얻는 완료 요약보다 훨씬 유용합니다. 출력을 변경 기록에 남겨 두면 다음 실행이 비교할 대상이 생깁니다.

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

끝의 슬래시가 중요합니다. 원본 쪽에서는 그 디렉터리의 내용을 뜻하고, 생략하면 원본 이름을 딴 디렉터리 계층이 하나 더 붙습니다. rsync 설명서는 두 형식을 메타데이터 보존 플래그와 함께 기록하며, 필요한 옵션 집합은 습관이 아니라 데이터에 달려 있습니다.

각 줄을 의도한 대상과 비교해 읽으세요. 미리보기 플래그를 빼면 복사가 수행되고 파일을 덮어쓸 수 있으며, 삭제 옵션이 없으면 대상에 이미 있는 여분 파일은 그대로 남습니다. 이것이 안전한 기본값인 경우는 남겨진 오래된 파일을 받아들일 수 있다고 정말로 결정했을 때뿐입니다. 답이 아니라면 이 명령에 여분 플래그를 뿌리는 것이 아니라 아래의 삭제 결정을 내려야 합니다.

다음으로 삭제가 함께 이동하는지 결정하세요

대상을 거울로 만드는 것은 두 번째 결정이며 첫 번째의 개선이 아닙니다. 삭제 플래그를 더하고 다른 것은 바꾸지 않은 채 따로 미리 보고, 목록의 차이가 전적으로 그 결정에 속하게 하세요.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

삭제는 동기화 범위 안에서 받는 쪽의 여분 파일을 제거하기 때문에 잘못된 원본 경로, 마운트되지 않은 디렉터리, 의도보다 많이 제외하는 필터가 파괴적인 실행을 깨끗한 거울처럼 보이게 할 수 있습니다. 미리보기 목록은 그 차이가 비싸지기 전에 보이는 유일한 곳입니다. 데이터가 정당화하는 곳에서는 독립적인 복구 사본을 두고, 거울은 이력을 보존하는 대신 우발적 삭제를 충실히 재현한다는 점을 기억하세요.

미리보기는 무엇도 잠그지 않습니다. 사람들은 시험과 실제 실행 사이에 파일을 편집하고 파일 시스템은 나름의 사정이 있어서, 승인한 실행과 실제로 실행되는 것은 두 트리가 조용하지 않으면 같은 작업이 아닙니다.

단방향 작업 두 개는 양방향 동기화가 되지 않습니다

같은 명령을 양방향으로 실행하는 것은 이 시나리오에서 데이터를 잃는 가장 흔한 방법입니다. 각 방향은 상대를 대상으로 보고 더 새로운 내용을 기꺼이 덮어쓰며, 삭제는 일정이 발동하는 순서대로 거울처럼 반영됩니다.

사용자가 두 사본을 모두 편집해야 한다면 충돌 처리, 삭제 추적, 그리고 그 모델을 위해 설계된 도구가 필요한 다른 제품 결정입니다. 일정 순서로 근사하는 것은 공유 폴더가 아무도 조정할 수 없는 문서마다 두 가지 버전을 갖게 되는 길입니다. cron 항목 두 개와 희망으로 근사하는 대신 명시적으로 결정하세요.

정책을 쓴 뒤에만 자동화하세요

예약된 작업은 방향, 경로, 메타데이터 정책, 승인된 삭제 결정을 함께 담아야 합니다. 그 다섯 가지 사실을 다음 관리자가 결코 읽지 않을 수도 있는 위키 페이지가 아니라 작업 파일 자체에 넣으세요. 겹치는 실행을 막으세요, 같은 트리에 동시에 쓰는 두 사본은 어느 쪽도 의도하지 않은 상태를 만들기 때문입니다.

원본이 살아 있는 데이터베이스이거나 다른 여러 파일 데이터 세트라면 먼저 애플리케이션과 일관된 내보내기나 조정된 스냅숏을 만드세요. 재귀적 파일 순회는 트랜잭션이 아니며, 변하는 데이터 세트의 사본은 일관되지 않습니다.

완료와 실패를 기록하고 종료 코드만이 아니라 대상의 데이터 세트를 확인하세요. 장애 후 VPN을 복구하면 연결만 돌아올 뿐, 마지막 복사가 끝났는지 또는 충돌하는 편집이 해결되었는지는 말해 주지 않습니다.