restic vs BorgBackup vs rclone — 소규모 리눅스 서버 백업 도구 선택 가이드

"백업은 했는데 복원이 안 되더라" — 도구 선택이 운명을 가른다

장애가 터진 새벽에야 깨닫게 되는 진실이 있습니다. 백업은 '저장'이 아니라 '복원'이 목적이라는 사실이죠. cron으로 tar를 돌려 외장 디스크에 던져두긴 했는데, 막상 복원하려니 압축이 깨졌거나, 암호를 까먹었거나, 정작 필요한 시점의 스냅샷이 덮어쓰기로 사라진 경험. 1인 개발자나 소규모 팀 인프라 담당자라면 한 번쯤 겪어봤을 겁니다.

그래서 이 글은 흔한 트러블슈팅이 아니라 **"내 상황에 맞는 도구를 자신 있게 고르는 의사결정"**에 집중합니다. restic, BorgBackup, rclone — 셋 다 훌륭하지만 본질이 다릅니다. 결론부터 말하면 셋 중 하나가 정답이 아니라, 당신의 저장 백엔드와 예산과 dedup 요구에 따라 답이 달라집니다. 30분 안에 자동 백업을 구축할 수 있도록, 복붙 가능한 예제까지 모두 담았습니다.

핵심 차이 한눈에 보기: 3종 정면 비교표

먼저 가장 헷갈리는 부분부터 정리합니다. 세 도구의 가장 큰 차이는 "이게 진짜 백업 도구냐, 아니면 동기화 도구냐"입니다.

표에서 가장 중요한 한 줄은 맨 아래입니다. rclone에는 '시점 복원'이 없습니다. rclone은 백업처럼 쓸 수 있지만, 본질은 미러링입니다. 이 차이가 도구 선택의 출발점입니다.

상황별 추천: "당신 상황이 X라면 Y를 쓰세요"

(a) 오프사이트 클라우드(B2/S3) 위주라면 → restic

저장소를 Backblaze B2나 S3 같은 객체 스토리지에 두고 싶다면 restic이 가장 편합니다. 별도 데몬 설치 없이 클라이언트만으로 S3/B2에 네이티브로 붙고, 암호화·dedup·압축이 기본 내장이라 설정이 단순합니다. 단일 바이너리라 배포도 쉽고, 멀티 플랫폼 복원도 매끄럽습니다. "클라우드에 던져두고 잊고 싶다"면 restic이 정답에 가깝습니다.

(b) 로컬 NAS + 강력한 중복제거·압축이 목표라면 → BorgBackup

같은 서버를 매일 통째로 백업하는데 변경량은 적다면, Borg의 dedup 효율이 빛을 발합니다. 압축 알고리즘(zstd/lz4) 선택 폭이 넓고, 로컬·SSH 저장소에서의 성숙도와 속도가 뛰어납니다. 다만 Borg는 저장소 쪽에 borg 바이너리가 필요하고(SSH 경유), S3 직결은 약하므로 로컬 디스크/NAS/내가 SSH로 접근 가능한 서버에 둘 때 최강입니다. B2에 올리고 싶다면 rclone을 경유하는 구성이 필요합니다.

(c) 단순 파일 동기화·미러링이면 → rclone (단, 백업이 아님)

정적 파일, 미디어 자산, 이미 다른 곳에 원본이 있는 데이터를 클라우드로 미러링만 하면 된다면 rclone이 가볍고 빠릅니다. 하지만 이건 백업이 아닙니다. rclone sync는 소스에서 지운 파일을 대상에서도 지웁니다. 실수로 원본을 날리고 sync가 돌면 백업본도 함께 증발합니다. 시점 복원이 필요하면 restic/Borg를, rclone을 백업처럼 쓰려면 최소한 버전 관리(B2 file versions)나 --backup-dir 옵션을 병행해야 합니다.

복붙 실전 설정: init → backup → 보존정책 → 자동화

restic 기본 흐름 (Backblaze B2 예시)

# 환경 변수로 저장소·인증·암호 지정
export RESTIC_REPOSITORY="b2:my-backup-bucket:server01"
export B2_ACCOUNT_ID="<keyID>"
export B2_ACCOUNT_KEY="<applicationKey>"
export RESTIC_PASSWORD="<강력한_복원암호>"

# 1) 저장소 초기화 (최초 1회)
restic init

# 2) 백업 실행
restic backup /etc /var/www /home --tag daily

# 3) 보존 정책 + 정리 (일 7 / 주 4 / 월 6 유지)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# 4) 무결성 검증 (주기적으로)
restic check --read-data-subset=5%

BorgBackup 기본 흐름 (SSH 원격 저장소)

export BORG_REPO="ssh://[email protected]:22/./repo"
export BORG_PASSPHRASE="<강력한_복원암호>"

# 1) 저장소 초기화 (repokey: 키를 저장소에 보관)
borg init --encryption=repokey

# 2) 백업 생성 (zstd 압축, 아카이브 이름에 날짜)
borg create --compression zstd,6 \
  ::'{hostname}-{now:%Y-%m-%d}' /etc /var/www /home

# 3) 보존 정책
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6

# 4) 무결성 검증
borg check --verify-data

cron 한 줄 자동화

# 매일 새벽 3시 백업 + 정리 (로그는 /var/log로)
0 3 * * * /usr/local/bin/restic-backup.sh >> /var/log/restic.log 2>&1

systemd service + timer (권장)

cron보다 로깅·실패 추적이 깔끔합니다. 두 파일을 만들고 타이머만 enable하면 됩니다.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=restic daily backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /var/www /home --tag daily
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Persistent=true 덕분에 백업 시간에 서버가 꺼져 있었어도 부팅 후 놓친 작업을 따라잡습니다. 소규모 운영에서 의외로 자주 구원받는 옵션입니다.

흔한 함정 4가지

랜섬웨어가 이제는 백업 저장소 자체를 노려 암호화·삭제하는 시대입니다. 3-2-1 원칙(사본 3개, 매체 2종, 오프사이트 1개)과 함께 immutable/append-only 백업이 다시 주목받는 이유죠.

1. append-only 모드를 쓰지 않는다 — Borg는 원격 저장소를 append-only로 강제할 수 있습니다. SSH authorized_keys에 command="borg serve --append-only ..."를 걸어두면, 침해된 클라이언트가 기존 아카이브를 삭제하지 못합니다. B2/S3라면 Object Lock(불변성)이나 버전 관리를 켜두세요.
2. restic prune의 비용을 간과한다 — 클라우드 저장소에서 prune은 메모리·시간·API 호출을 꽤 잡아먹습니다. 매일 prune 대신 백업은 매일, prune은 주 1회로 분리하면 비용과 부하를 줄일 수 있습니다.
3. rclone sync를 백업으로 착각한다 — 앞서 강조했듯 sync는 대상의 파일을 소스에 맞춰 삭제합니다. 버전·시점 복원이 없으니, 백업 목적이면 restic/Borg를 쓰거나 최소 --backup-dir과 저장소 버전 관리를 병행하세요.
4. 암호/키 분실 = 영구 복원 불가 — restic의 RESTIC_PASSWORD, Borg의 passphrase/keyfile을 잃으면 데이터는 영원히 사라집니다. 비밀번호 관리자에 보관하고, Borg keyfile은 별도 안전한 위치에 백업하세요.

실무 경험담: 저는 단일 VPS는 restic + B2로, 사내 NAS 백업은 Borg로 이원화해 운영합니다. "클라우드 직결의 편의는 restic, 로컬 dedup·압축 효율은 Borg"라는 단순한 기준 하나가, 도구 고민에 쓰던 시간을 대폭 줄여줬습니다.

저장 비용 대략 비교: B2 vs S3

소규모 백업에서 비용을 가르는 건 저장 단가보다 egress(다운로드) 비용인 경우가 많습니다. 복원 테스트나 실제 복구 시 데이터를 끌어내려야 하는데, S3 Standard의 egress는 무시할 수 없습니다.

※ 단가는 자주 바뀌므로 발행 시점 기준 공식 가격(Backblaze, AWS) 을 반드시 확인하세요. 위 표는 상대적 경향을 보여줄 뿐 정확한 금액이 아닙니다.

요점은 명확합니다. 수십~수백 GB 규모의 오프사이트 백업이라면 B2가 비용 면에서 유리한 경우가 대부분이고, S3 호환 저장소(B2·Wasabi 등)의 가격 경쟁 덕에 선택지도 넓어졌습니다.

결론: 오늘 당장 시작할 한 줄

완벽한 백업 설계를 기다리느라 백업을 미루는 것이 가장 위험합니다. 지금 바로 시작하세요.

export RESTIC_REPOSITORY="b2:my-backup-bucket:server01"
restic init && restic backup /etc /var/www

그리고 반드시 복원 테스트(restic restore / borg extract)를 한 번이라도 돌려보세요. 복원되지 않는 백업은 백업이 아닙니다.

자주 묻는 질문 (FAQ)

Q. restic과 BorgBackup 중 처음 시작하기엔 뭐가 쉬운가요? A. 클라우드(S3/B2)에 바로 올릴 거면 restic이 설정이 단순해 입문에 좋습니다. 로컬 NAS나 SSH 접근 가능한 서버에 강력한 dedup·압축으로 쌓을 거면 Borg가 효율적입니다.

Q. rclone만으로 백업해도 되나요? A. 권장하지 않습니다. rclone은 동기화 도구라 시점 복원·버전 관리가 기본 제공되지 않습니다. 굳이 쓴다면 저장소의 버전 관리(B2 file versions)나 --backup-dir을 반드시 병행하세요.

Q. 랜섬웨어로 백업 저장소까지 당하지 않으려면? A. Borg는 --append-only 모드, S3/B2는 Object Lock(불변성)이나 버전 관리를 켜고, 3-2-1 원칙으로 오프사이트 사본을 분리 보관하세요. 백업 서버의 인증 키도 클라이언트와 분리하는 것이 안전합니다.