cron 작업으로 암호화된 서버 백업 자동화하기

마지막 업데이트: 2026-08-06

직접 기억해서 실행해야 하는 백업은 결국 실행되지 않습니다. cron은 기억해 주며, Relayium CLI는 바로 그 목적을 위해 만들어졌습니다: 디렉터리를 다른 머신으로 복사(또는 미러링)하고, 모든 파일을 검증하며, 네트워크가 끊기면 중단된 지점부터 이어가는 단일 비대화형 명령입니다.

이 가이드는 cron에서 relayium push와 증분 방식의 relayium sync를 예약하는 방법, 둘 다에 사용할 수 있는 두 가지 전송 방식, 그리고 그대로 복사해 쓸 수 있는 crontab 줄을 다룹니다.

push와 sync: 전체 복사냐 증분 미러링이냐

push와 sync는 둘 다 디렉터리를 다른 머신으로 옮기고, 둘 다 반복 실행해도 안전하지만, 해결하는 백업 문제는 조금 다릅니다.

push는 실행할 때마다 SSH 또는 daemon-direct로 매번 전체 복사본을 보냅니다 — 단순하며, relayium이 설치되지 않은 순수한 서버에도 tar 대체 방식으로 동작합니다. 반면 sync는 대상을 소스의 증분 단방향 미러로 유지합니다. 변경된 파일만 다시 전송하므로, 큰 디렉터리라도 첫 실행 이후의 야간 동기화는 빠릅니다. sync는 항상 양쪽 모두에서 relayium의 네이티브 프로토콜이 필요합니다 — tar 대체 방식이 없습니다.

relayium이 설치되어 있지 않을 수도 있는 서버로의 단순한 예약 복사에는 push를 사용하세요.
크거나 자주 변하는 디렉터리에서 매일 밤 전체를 다시 보내는 것이 낭비라면 sync를 사용하세요.
둘 다 파일별로 SHA-256 검증을 하며, 중단되어도 재개할 수 있습니다.

시작하기 전에

아래는 모두 relayium CLI이므로, 설치하지 않았다면 먼저 설치하세요. macOS나 Linux에서는 명령어 하나로 사전 빌드된 바이너리가 PATH에 등록됩니다:

curl -fsSL https://relayium.com/install.sh | sh

직접 파일을 고르고 싶거나 Windows인가요? 릴리스 페이지에서 바이너리를 받으세요 — relayium.com/cli 에 모든 설치 방법이 있습니다(Go가 있으면 go build -o relayium ./cmd/relayium 도 가능).
relayium --version 으로 설치를 확인할 수 있습니다. 이 단계를 건너뛰면 아래 명령은 “command not found”만 출력합니다.

두 가지 전송 방식: SSH 또는 daemon-direct

두 명령 모두 SSH 대상(scp 형식, 기존 ~/.ssh/config 사용)을 지정할 수도 있고, 상대 머신에서 relayium serve가 실행 중이라면 SSH 없이 daemon-direct 프로토콜로 곧장 연결할 수도 있습니다.

# SSH 대상: 기존 SSH 키와 설정을 그대로 사용합니다
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct: 대상에서 "relayium serve"가 실행 중이면 SSH가 필요 없습니다
relayium push ./data relayium://backup-server:9031

daemon-direct 연결은 고정된(pinned) TLS 1.3을 사용하며, 처음 연결할 때 신뢰(trust-on-first-use)하고 이후 실행부터는 같은 지문(fingerprint)에 대해 검증합니다.
sync는 push와 동일한 두 가지 대상 표기법을 받아들입니다.

cron으로 예약 실행하기

1단계 전에 필요한 것

이 기기의 CLI. sync를 쓸 생각이라면 목적지에도 필요합니다. sync에는 tar 대체 경로가 없습니다.
암호가 없는 SSH 키, 또는 relayium serve를 돌리는 목적지. cron에는 에이전트도 터미널도 없어 암호 입력에 답할 수 없습니다.
cron이 실행되는 시점에 실제로 존재하는 원본 디렉터리. 로그인해 있을 때만 붙는 네트워크 마운트는 곤란합니다.
로그를 남길 곳. 출력이 아무 데도 가지 않는 cron 작업은, 정작 필요할 때에야 문제를 알게 되는 백업입니다.

push와 sync는 둘 다 단일 비대화형 명령이므로, 그대로 crontab에 넣을 수 있습니다. 암호 없는 키(또는 agent)를 지정하고, 출력을 로그로 남겨 실패를 확인할 수 있게 하세요:

# 매일 밤 2시 전체 복사: crontab에 추가하세요 (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-backup.log 2>&1

# 대신 15분마다 증분 미러링
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

relayium이 실제로 어디에 있는지 확인하세요. cron은 셸의 PATH를 쓰지 않고, install.sh는 /usr/local/bin에 쓸 수 없으면 ~/.local/bin에 둡니다 — 바로 cron이 보지 못하는 자리입니다.
```
command -v relayium
```
아무도 키보드 앞에 없어도 키가 동작하는지 확인하세요. BatchMode=yes는 묻지 않고 실패하므로 cron과 같은 조건입니다.
```
ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
```
먼저 손으로 한 번, cron이 실행할 것과 똑같은 형태로 절대 경로까지 포함해 통째로 실행해 보세요.
```
/usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/
```
그다음에야 스케줄을 추가합니다. 절대 경로와 리다이렉트는 그대로 두세요.
```
crontab -e
```
첫 예약 실행 뒤에는 넘겨짚지 말고 로그를 읽으세요. 사람들이 건너뛰는 단계이자, 문제를 미리 알려 주었을 단계입니다.
```
tail -n 20 ~/relayium-backup.log
```

제대로 설정된 백업의 모습

relayium이 crontab에 그대로 붙여 넣을 수 있는 절대 경로로 확인되고, BatchMode를 붙인 ssh 검사가 아무것도 출력하지 않고 아무것도 묻지 않은 채 0으로 끝납니다. 대화형 셸에서만 되는 백업은 아직 예약된 것이 아닙니다.

$ command -v relayium
/usr/local/bin/relayium
$ ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
$ echo $?
0

무결성 검사에 실패한 파일이 하나라도 있으면 명령이 0이 아닌 상태로 종료되므로, cron의 실패 시 메일 알림으로 문제를 발견할 수 있습니다.
중단된 실행은 다음 예약된 실행에서 자동으로 재개되거나 따라잡습니다.

삭제 미러링과 실시간 동기화

기본적으로 sync는 대상 쪽에서 파일을 추가하거나 갱신하기만 합니다. --delete를 추가하면 진짜 미러가 되어 소스에 더 이상 없는 파일도 삭제합니다 — 수신 측이 명시적으로 serve --allow-delete로 대기 중이어야 하며, 그렇지 않으면 삭제는 조용히 건너뛰어지고 결과에 거부됨으로 보고됩니다. 소스 디렉터리가 파일을 하나도 찾지 못하면 sync는 --delete 실행 자체를 거부하므로, 소스 경로 오타로 대상이 지워지는 일은 없습니다.

cron의 다음 실행 시각을 기다리고 싶지 않다면, --watch를 사용해 relayium sync를 계속 실행 상태로 두면 소스 아래의 파일이 변경된 직후 자동으로 다시 동기화됩니다 — 예약된 폴링을 대신하는 가벼운 방법입니다.

relayium sync ./data user@backup-server:/srv/backups/ --delete는 삭제도 미러링합니다(수신 측에 serve --allow-delete 필요).
relayium sync ./data user@backup-server:/srv/backups/ --watch는 계속 실행되며 변경 시마다 동기화합니다. cron의 단발 실행 대신 사용할 수 있습니다.

잘 안 될 때

여기 있는 것들은 로그를 보기 전까지 전부 보이지 않습니다. 로그 리다이렉트가 선택이 아니라 crontab 줄에 처음부터 들어 있는 이유입니다. 다섯 번째는 보이지 않는 것보다 나쁩니다 — 성공처럼 보입니다.

증상, 확인, 해결

로그에 relayium: command not found가 찍히는데 같은 명령이 셸에서는 됩니다.

tail -n 5 ~/relayium-backup.log
# /bin/sh: relayium: command not found

cron은 최소한의 PATH, 보통 /usr/bin:/bin만으로 돕니다. install.sh가 /usr/local/bin에 쓰지 못했다면 바이너리는 ~/.local/bin에 있고, cron은 그곳을 결코 찾지 않습니다. command -v가 알려 준 절대 경로를 crontab 줄에 쓰거나, crontab 맨 위에 PATH= 줄을 넣으세요.

로그에 ssh 연결이 거부되었다고 나오거나, 첫 실행 이후로 아무것도 없습니다.

ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
# Permission denied (publickey).

cron에는 ssh-agent도 터미널도 없어서 암호가 걸린 키는 멈추거나 실패할 수밖에 없습니다. -i로 백업 전용의 암호 없는 키를 지정하고 BatchMode=yes로 확인하세요. 그 옵션은 거기 없는 사람을 기다리는 대신 아예 묻기를 거부합니다.

sync는 깔끔하게 도는데 원본에서 지운 파일이 목적지에 그대로 있습니다.

grep -i deni ~/relayium-sync.log

삭제는 수신 측이 켜야 하는 옵션입니다. 상대편에 serve --allow-delete가 없으면 삭제는 건너뛰어지고 denied로 보고됩니다. 답이 종료 코드가 아니라 로그에 있는 이유입니다. 수신 측 리스너를 --allow-delete와 함께 재시작하세요.

sync가 --delete를 아예 거부합니다.

relayium sync ~/documents user@backup-server:/srv/backups/ --delete
# refusing --delete with an empty source: this would delete everything on the destination. Check the path(s).

원본에서 파일이 하나도 잡히지 않아, 그대로 두면 미러가 목적지를 비워 버리는 상태입니다. 이 거부는 의도된 것입니다. 경로 오타를 확인하고, 거기 붙어야 할 것이 로그인 중일 때뿐 아니라 cron이 도는 시점에도 실제로 마운트되어 있는지 확인하세요.

백업이 돌고 0으로 끝나는데, 내용이 생각한 그것이 아닙니다.

ssh user@backup-server command -v relayium

원격에 relayium이 없으면 push는 SSH 위의 평범한 tar 스트림으로 물러납니다. 파일은 도착하니 아무도 불평하지 않지만, 그 경로에는 파일별 SHA-256 검증도 이어받기도 없습니다 — scp 대신 이걸 예약하는 두 가지 이유가 바로 그것입니다. 목적지에 CLI를 설치하면 되돌아옵니다. sync에는 이런 실패가 없습니다. 대체 경로가 아예 없어서 대신 요란하게 실패합니다.

자주 묻는 질문

백업 서버에 relayium이 설치되어 있어야 하나요?

명령에 따라 다릅니다. push는 어느 쪽이든 동작합니다: relayium이 설치되어 있으면 네이티브 프로토콜(재개 + 파일별 SHA-256 검사)을 사용하고, 없으면 push는 SSH를 통한 일반 tar 스트림으로 대체되어 순수한 서버에서도 동작합니다. sync는 항상 원격지에 relayium의 네이티브 프로토콜이 필요합니다 — sync에는 tar 대체 방식이 없으므로 먼저 그곳에 설치하세요.

백업이 암호화되고 검증되나요?

네. 모든 파일은 종단간 SHA-256 해시로 검사되며, SSH나 daemon-direct로 푸시할 때 바이트는 이미 해당 연결 자체의 암호화로 보호됩니다 — 추가로 설정할 것이 없습니다.

cron 작업이 중간에 중단되면 어떻게 되나요?

양쪽에 relayium이 있으면, 다음 예약된 실행이 전체를 다시 보내는 대신 부분 파일을 재개합니다. 깔끔하게 전체를 다시 보내고 싶다면 --no-resume을 넘기세요.

--delete가 실수로 대상을 지워버릴 수 있나요?

소스 디렉터리에 파일이 하나도 없으면 sync는 --delete 실행 자체를 거부합니다. 또한 삭제가 실제로 적용되려면 수신 측이 serve --allow-delete로 시작되어 있어야 합니다 — 그렇지 않으면 건너뛰어지고 결과로 보고됩니다.

계정이 필요한가요, 비용이 드나요?

아니요. CLI는 무료이며 push, pull, sync 모두 계정이 필요 없습니다. 전송은 본인의 SSH 연결이나 직접적인 daemon 연결을 통해 이루어지며, Relayium의 서버를 거치지 않습니다.

기억할 필요 없는 일정에 백업을 올려두세요 — 암호화되고, 재개 가능하며, 무료입니다.

CLI 받기