마지막 업데이트: 2026-07-09
rsync가 1996년부터 폴더를 미러링해 온 데는 이유가 있습니다. 양방향 동기화, 롤링 체크섬으로 파일 내부에서 실제로 바뀐 바이트만 전송하는 델타 알고리즘, 그리고 온갖 예외 상황을 다루는 수십 년치 플래그입니다. 이미 SSH 접근 권한이 있고 rsync를 잘 안다면, 이를 능가하기는 매우 어렵습니다.
Relayium의 sync 명령은 더 좁은 범위——단방향 증분 미러——만 다루지만, rsync가 이미 되어 있다고 가정하는 한 단계, 즉 SSH 설정을 없애줍니다. 이미 SSH가 있다면 그 위에서 동작하고, 없다면 SSH 서버 없이 두 기기를 직접 연결합니다. 이 글은 둘을 정직하게 비교합니다. sync는 rsync의 완전한 대체품이 아니며, FAQ에서도 이를 분명히 밝힙니다.
rsync는 양방향입니다——어느 쪽이든 소스가 될 수 있습니다——그리고 델타 전송 알고리즘은 롤링 체크섬으로 파일의 블록을 비교하므로, 거대한 파일에 작은 수정을 가해도 바뀐 블록만 보내고 파일 전체를 다시 보내지 않습니다. 여기에 수십 년치 플래그(--exclude, 하드링크 스냅샷용 --link-dest, 압축, 대역폭 제한 등)가 더해져 많은 작업에 알맞은 도구가 됩니다.
또한 어디에나 있습니다. 대부분의 Linux와 macOS에 기본 포함되어 있고, 이미 설정해 두었을 SSH 연결 위에서 동작합니다. 이 중 어느 것도 Relayium sync가 대체하려는 것이 아닙니다.
relayium sync <소스...> <대상> [--delete] [--watch]는 단방향 증분 미러입니다. 각 파일의 크기와 수정 시각을 비교해 이미 일치하는 것은 건너뛰고 나머지만 보냅니다.
두 가지 전송 방식으로 동작합니다. user@host:/dest를 가리키면 SSH로 동작하지만——원격에 이미 relayium이 설치되어 있어야 합니다. push와 달리 sync에는 tar 폴백이 없습니다. 대신 relayium://host[:port]를 가리키면 SSH를 완전히 건너뜁니다. 고정된 TLS 1.3 연결로 상대 기기에서 실행 중인 relayium serve 리스너에 직접 연결되며, 그 기기의 핑거프린트로 인증됩니다(한 번 승인하면 이후로는 기억됩니다). 이 두 번째 경로가 진짜 편리한 부분입니다. sshd를 설정할 필요도, SSH 키를 관리할 필요도 없이, relayium이 설치된 두 기기와 그 사이의 열린 포트 하나만 있으면 됩니다.
relayium sync ./photos user@host:/backup/photos # over SSHrelayium sync ./photos relayium://203.0.113.9:9031 # daemon direct, no SSH기본적으로 sync는 추가와 갱신만 합니다——스스로 무언가를 삭제하는 일은 없습니다. 삭제까지 미러링하려면 --delete를 넘기되, 받는 쪽이 명시적으로 동의해야 합니다. relayium serve --allow-delete로 실행 중이어야 합니다. 그렇지 않으면 삭제 요청은 조용히 무시되는 대신 거부되고 보내는 쪽에 보고됩니다.
계속 바뀌는 폴더라면 --watch를 붙이세요. 첫 동기화 이후에도 sync가 계속 실행되며, 소스 아래 파일이 바뀔 때마다 다시 미러링합니다——이에 해당하는 기능이 rsync에는 내장되어 있지 않아, 보통 cron 작업이나 lsyncd 같은 래퍼를 써야 합니다.
relayium serve --dir /backup --port 9031 --allow-deleterelayium sync ./photos relayium://203.0.113.9:9031 --delete --watch모든 파일은 SHA-256 해시로 끝에서 끝까지 검증되며, 파일 전송 도중 끊긴 전송은 디스크에 이미 있는 바이트 오프셋부터 재개합니다——처음부터 다시 하지 않습니다. rsync의 재개와 같은 이유로 유용합니다.
다만 재개가 무엇이 아닌지는 분명히 해 둘 필요가 있습니다. rsync의 델타 알고리즘이 아닙니다. 파일이 이미 완전히 존재하더라도 크기나 타임스탬프가 다르면, sync는 내부의 바뀐 블록을 비교하는 대신 파일 전체를 다시 보냅니다. 자주 조금씩 바뀌는 거대한 파일 하나에 대해서는, rsync의 델타 전송이 실제로 더 적은 데이터를 옮깁니다. sync는 일반 파일만 다룹니다——심링크와 특수 파일은 건너뛰므로, 이를 필요로 하는 경우 별도로 처리해야 합니다.
양방향 동기화가 필요할 때, 이미 SSH가 설정되어 있어 또 다른 데몬을 돌리고 싶지 않을 때, 세밀한 제어(제외 규칙, 필터, 하드링크 스냅샷, 대역폭 제한, 압축)가 필요할 때, 또는 파일 하나가 자주 조금씩 바뀌어 델타 전송이 실제로 대역폭을 아껴줄 때는 rsync를 선택하세요. Relayium sync는 이 중 어느 것도 다루려 하지 않습니다.
아닙니다. 단방향 미러링만 하며, rsync 같은 블록 단위 델타 알고리즘도 없습니다——크기나 타임스탬프가 바뀐 파일은 통째로 다시 보내지고, 플래그 수도 rsync보다 훨씬 적습니다. 양방향 동기화나 세밀한 필터 제어가 필요하거나 rsync의 성숙한 생태계에 기대고 싶다면, rsync가 여전히 더 나은 도구입니다.
아니요. 데몬 다이렉트(relayium://host:port)는 SSH를 완전히 건너뜁니다. 고정된 TLS 연결로, 받는 쪽의 핑거프린트로 인증되며, 한 번 승인하면 이후로는 기억됩니다. SSH(user@host:path)를 통해서도 동작할 수 있지만 원격에 relayium이 설치되어 있어야 하며, push와 달리 sync에는 tar 폴백이 없습니다.
--delete를 넘기고, 받는 쪽의 serve가 --allow-delete로 실행 중일 때만 그렇습니다. 그렇지 않으면 삭제 요청은 거부되고 보내는 쪽에 보고되며, 조용히 무시되지 않습니다.
네, --watch를 붙이세요. 첫 미러링 이후에도 sync가 계속 실행되며, 소스 아래 파일이 바뀔 때마다(디바운스하며) 다시 미러링합니다.
네. Relayium CLI는 완전히 무료이며, sync를 포함한 어떤 모드도 계정이 필요 없습니다.
당신 소유의 두 기기 사이에서 폴더를 미러링하세요——SSH 서버가 필요 없습니다.
CLI 받기