rsync + cron으로 서버 자동 백업 매일 새벽 — 3분 설정 가이드 (2026)

서버가 날아가도 괜찮다면 백업이 필요 없습니다. 그렇지 않다면 들으세요. 디스크 고장, 랜섬웨어, 실수로 rm -rf. 하루아침에 모든 데이터가 사라지는 건 생각보다 자주 일어납니다. 클라우드라고 안전하지 않습니다. VPS 제공자가 디스크 장애를 겪으면, 그 안에 있는 데이터는 복구 불가능할 합니다. 백업이 있으면 최소 하루 전으로 돌아갈 합니다. rsync와 cron을 쓰면 매일 새벽 자동으로 백업되는 시스템을 3분 만에 만들 합니다.

올바른 설정과 활용법을 통해 시스템 효율을 크게 높이고 비용을 절감할 합니다.

보안과 자동화를 동시에 구축하는 것이 장기적인 유지보수 관점에서 가장 확실한 방법입니다.

왜 백업을 미루는가 무엇일까요?

대부분의 사람은 백업의 중요성을 압니다. 하지만 미룹니다. 이유는 간단합니다. 백업은 귀찮고, 설정하는 데 시간이 들고, 당장 급한 일이 아니기 때문입니다. ‘나중에 해야지’라고 하다가, 어느 날 서버가 날아가고 나서야 후회합니다.

핵심은 ‘자동화’입니다. 한 번 설정해 두면 더 이상 생각하지 않아도 되는 백업 시스템을 만들어야 합니다. 매일 새벽 알아서 실행되고, 실패하면 알림이 오고, 백업 서버는 물리적으로 분리되어 있는. 이걸 rsync + cron 조합으로 만들 합니다.

rsync는 증분 백업을 해줍니다. 전체를 매번 복사하는 게 아니라, 바뀐 파일만 전송합니다. 처음에는 전체 복사이지만, 두 번째부터는 변경된 블록만 전송합니다. 빠르고 트래픽도 적게 나옵니다. 수백 기가바이트 데이터베이스도 매일 새벽에 몇 분이면 동기화됩니다.

rsync가 하는 일 무엇일까요?

rsync + cron으로 서버 자동 백업 매일 새벽 — 3분 설정 가이드 (2026)

rsync는 ‘원격 동기화(remote sync)’ 도구입니다. 로컬-로컬, 로컬-원격 간 파일 동기화를 합니다. 핵심은 증분 전송입니다. 파일 전체를 보내는 게 아니라, 변경된 부분만 보냅니다.

rsync의 --delete 옵션은 원본에서 지워진 파일을 백업에서도 지워줍니다. ‘네가 버린 건 내가도 버려’라고 하는 충직한 거울 같습니다. 좀 비현실적이지만요. 원본과 백업을 완전히 똑같이 유지합니다.

주요 옵션을 정리하면 이렇습니다.

rsync -avz --delete /원본/ /백업위치/

// -a: 아카이브 모드 (권한, 심볼릭 링크, 타임스탬프 보존)
// -v: 진행 상황 출력
// -z: 전송 중 압축
// --delete: 원본에 없는 파일을 백업에서도 삭제 (양방향 동기화 아님, 원본 기준)

수동 백업 먼저 해보기 무엇일까요?

먼저 수동으로 한 번 백업을 해봅니다. /var/www/ 디렉토리를 백업 서버로 동기화하는 예시입니다.

// 수동 백업 (원격 서버로)
rsync -avz --delete \
  /var/www/ backup@remote-server:/backup/www/

// 진행 과정이 출력됩니다:
// building file list ... done
// sending incremental file list
// ./
// index.html
// images/
// images/logo.png
#
// sent 1.2M bytes  received 32 bytes  340K bytes/sec
// total size is 45M  speedup is 37.5

처음 실행하면 전체 파일이 전송됩니다. 두 번째부터는 speedup이 크게 올라갑니다. 변경된 파일만 전송되기 때문입니다. 수백 메가바이트 데이터베이스도 변경분이 몇 메가바이트면 그 부분만 전송됩니다.

SSH 키 인증 설정 무엇일까요?

자동 백업을 하려면 비밀번호 없이 SSH 접속이 가능해야 합니다. cron이 새벽 3시에 실행할 때 비밀번호를 입력할 사람이 없기 때문입니다. SSH 키 인증을 설정합니다.

// 백업 서버에 SSH 키 생성 (원본 서버에서)
ssh-keygen -t ed25519 -f ~/.ssh/backup_key -N ""

// 공개키를 백업 서버에 등록
ssh-copy-id -i ~/.ssh/backup_key.pub backup@remote-server

// 테스트 (비밀번호 없이 접속되어야 함)
ssh -i ~/.ssh/backup_key backup@remote-server echo "OK"

“OK”가 출력되면 성공입니다. 이제 비밀번호 없이 백업 서버에 접속할 합니다. cron이 rsync를 실행할 때 자동으로 인증됩니다.

cron으로 자동화 — 매일 새벽 3시 무엇일까요?

이제 이 명령을 cron에 등록합니다. crontab -e로 편집기를 엽니다.

// crontab 편집
crontab -e

// 매일 새벽 3시에 자동 백업 등록
0 3 * * * rsync -avz --delete -e "ssh -i /home/user/.ssh/backup_key" /var/www/ backup@remote-server:/backup/www/ >> /var/log/rsync_backup.log 2>&1

cron 표현식을 해석하면: 분(0) 시(3) 일(*) 월(*) 요일(*). 즉 매일 새벽 3시 0분에 실행됩니다. 백업 로그는 /var/log/rsync_backup.log에 쌓입니다. 백업이 실패하면 로그에서 원인을 찾을 합니다.

SSH 키 경로를 -e 옵션으로 명시해야 합니다. cron 환경은 일반 쉘과 다르기 때문에 기본 SSH 키를 못 찾을 합니다. 또 절대 경로를 쓰는 게 안전합니다.

백업 실패 시 이메일 알림 받기 무엇일까요?

백업이 조용히 실패하는 것이 가장 위험합니다. cron에 MAILTO를 설정하거나, 명령 끝에 실패 체크를 추가하면 백업 실패 시 즉시 알림을 받을 합니다.

// crontab 상단에 MAILTO 설정
MAILTO=admin@example.com

// 또는 rsync 종료 코드를 체크해서 알림
0 3 * * * rsync -avz --delete -e "ssh -i /home/user/.ssh/backup_key" \
  /var/www/ backup@remote-server:/backup/www/ \
  >> /var/log/rsync_backup.log 2>&1 \
  || echo "BACKUP FAILED on $(hostname)" | mail -s "rsync backup FAIL" admin@example.com

|| 연산자는 앞의 명령이 실패했을 때만 뒤의 명령을 실행합니다. rsync가 정상 종료(코드 0)하면 아무 일도 일어나지 않고, 비정상 종료하면 이메일이 발송됩니다. systemd 자동 복구와 마찬가지로, 장애를 방지하는 게 아니라 장애를 빨리 발견하는 것이 핵심입니다.

백업 확인하기 무엇일까요?

설정한 다음 날 아침에 백업이 잘 됐는지 확인합니다.

// 백업 로그 확인
tail -50 /var/log/rsync_backup.log

// 백업 서버에서 파일 확인
ssh -i ~/.ssh/backup_key backup@remote-server ls -la /backup/www/

// 파일 개수 비교 (원본 vs 백업)
find /var/www/ -type f | wc -l
ssh backup@remote-server "find /backup/www/ -type f | wc -l"

두 숫자가 같으면 정상입니다. 로그에 에러가 없는지 확인하세요. 디스크 공간 부족, 권한 문제, 네트워크 장애가 가장 흔한 실패 원인입니다.

백업 원칙: 3-2-1 무엇일까요?

백업의 황금 원칙은 3-2-1입니다. 데이터 3개 복사본, 2개 매체, 1개 원격. rsync로 원격 서버에 백업하는 건 2개 복사본(원본 + 원격)에 해당합니다. 한 단계 더 가려면 백업 서버에서 또 다른 곳(예: S3, 외장 하드)에 복사본을 만드세요.

가장 중요한 것은 백업 서버가 물리적으로 다른 머신이어야 한다는 점입니다. 같은 VPS 안에 디렉토리를 만들어서 백업하는 건 의미가 없습니다. 그 VPS가 죽으면 원본과 백업이 같이 날아갑니다. 다른 VPS, 다른 클라우드, 외장 하드 중 하나에 백업해야 합니다. restic 기반 백업 가이드를 참고하면 더 고급 증분 백업 시스템을 구축할 합니다.

주의점: –delete의 위험과 날짜별 백업 무엇일까요?

--delete 옵션은 원본에서 삭제된 파일을 백업에서도 지웁니다. 장점은 백업이 원본과 똑같이 유지된다는 것입니다. 단점은 실수로 원본을 지우면 백업에서도 사라진다는 것입니다. 새벽에 백업이 실행되기 전에 실수를 발견하면 다행이지만, 백업 후에야 알아채면 복구가 안 됩니다.

중요한 데이터는 별도로 보관하세요. --delete 없이 매일 날짜별로 백업 디렉토리를 만드는 방법도 있습니다. rsync --link-dest를 쓰면 하드 링크로 증분 백업을 만들면서 --delete의 위험을 피할 합니다. 디스크 공간은 조금 더 쓰지만 안전합니다.

// --link-dest로 날짜별 증분 백업
TODAY=$(date +%Y%m%d)
YESTERDAY=$(date -d "yesterday" +%Y%m%d)

rsync -avz \
  --link-dest=/backup/www/$YESTERDAY/ \
  /var/www/ backup@remote-server:/backup/www/$TODAY/

// 결과: 매일 새 디렉토리가 생성되지만,
// 변경되지 않은 파일은 하드링크이므로 디스크를 추가로 안 씀
// 7일분 보관 후 오래된 건 삭제 → 롤링 백업 완성

이 방식은 매일 스냅샷처럼 보이면서도 실제 디스크 사용량은 증분에 가깝습니다. 실수로 파일을 지워도 전날 백업에서 복구할 합니다. PostgreSQL 백업 자동화와 조합하면 데이터베이스까지 커버할 합니다.

정리 무엇일까요?

백업은 미루면 안 됩니다. rsync + cron으로 매일 새벽 자동 백업을 설정하는 데 3분이면 충분합니다. 한 번 설정하고 잊으세요. 그러다 어느 날 서버가 날아가도, 하루 전 데이터로 돌아갈 합니다. 이게 무인 운영의 기본입니다.

이 글은 VPS 실전 운영 시리즈의 마지막 입니다. UFW 방화벽(EP24), Let’s Encrypt SSL(EP25), WireGuard VPN(EP26)으로 보안을 갖추고, 백업까지 설정했다면 VPS 무인 운영의 기반은 완성입니다. 구독하고 VPS 백업 팁 매주 받아보세요. 백업은 ‘해야 한다’는 걸 아는 것에서 끝나지 않습니다. 오늘 설정하세요.