Backblaze B2의 무료 10GB로 서버 외부 백업을 구축한 실제 기록. rclone 암호화 미러 구성법과, 콘솔 용량이 두 배로 보이는 버전 누적·동기화 중 한도 초과 경고 등 직접 겪은 시행착오 3가지와 해결책을 정리했습니다.
Backblaze B2는 첫 10GB를 영구 무료로 주는 클라우드 스토리지입니다. rclone과 함께 쓰면 서버 백업을 암호화한 상태로 매일 자동 미러링할 수 있어, 무료 서버를 쓰는 개인에게는 사실상 유일하게 부담 없는 외부 백업 수단입니다. 다만 무료 10GB를 쓸 때 정말 봐야 하는 숫자는 "지금 쓰는 용량"이 아니라 "동기화가 도는 몇 분간의 순간 용량"입니다. 6월 중순부터 실제로 돌려보며 겪은 세 가지를 적었습니다.
최종 업데이트: 2026-08-05 · 환경: Oracle Cloud 무료 서버(Ubuntu 24.04, ARM) + rclone 1.73.4 + Backblaze B2
왜 외부 백업을 알아봤나 — 무료 서버의 유일한 약점
저는 오라클 클라우드(OCI)의 평생 무료 서버에 여러 사이트를 올려 쓰고 있습니다. 만드는 과정은 아래 두 글에 정리해 두었습니다.
서버 자체는 잘 돌아갑니다. 백업도 서버 안에서 매일 자동으로 만들어집니다. 그런데 어느 날 이런 생각이 들었습니다. 그 백업이 서버 안에 있다. 서버가 사라지면 백업도 같이 사라집니다.
무료 서버라 더 신경이 쓰였습니다. 유료 서버라면 결제가 밀려도 보통 유예 기간이 있지만, 무료 등급은 정책이 바뀌거나 계정에 문제가 생기면 내가 손쓸 방법이 별로 없습니다. 랜섬웨어나 실수로 인한 삭제까지 생각하면, 백업은 "다른 회사의 다른 저장소"에 한 부 더 있어야 합니다.
그래서 조건을 정리했습니다. ① 개인이 감당할 비용(가능하면 0원), ② 자동화 가능, ③ 내 데이터를 남의 서버에 맡기니 암호화는 필수. 이 세 가지로 찾다가 Backblaze B2를 알게 됐습니다.
Backblaze B2란 무엇인가 — 기본 기능과 요금
Backblaze B2 Cloud Storage는 S3 호환 오브젝트 스토리지입니다. 쉽게 말해 "파일을 넣어 두는 인터넷 창고"이고, 아마존 S3와 같은 방식으로 말을 알아듣기 때문에 S3용 도구를 대부분 그대로 쓸 수 있습니다. 이 점이 중요합니다 — 전용 프로그램을 배울 필요 없이 이미 있는 도구를 씁니다.
주의할 점은 Backblaze가 서로 다른 두 제품을 판다는 것입니다. 개인 PC를 통째로 백업하는 Computer Backup(PC 1대당 월정액, 용량 무제한)과, 이 글에서 다루는 B2 Cloud Storage(쓴 만큼 내는 창고)는 다른 서비스입니다. 서버 백업에 쓰는 것은 B2입니다.


요금은 2026년 8월 확인 기준으로 이렇습니다.
| 항목 | 내용 |
|---|---|
| 무료 저장용량 | 첫 10GB는 계속 무료 (기간 제한 없음) |
| 저장 요금 | 10GB 초과분에 대해 $6.95 / TB · 월 — byte-hour(용량×시간) 기준으로 계산 |
| 다운로드(egress) | 월 평균 저장량의 3배까지 무료, 초과분 $0.01/GB |
| API 호출 | Class A·B·C 무료 / Class D는 하루 2,500회 무료, 이후 10,000회당 $0.004 |
| 최소 보관 기간 | 없음 (최소 보관 위반금·최소 파일 크기 요금 없음) |
개인이 서버 백업 용도로 쓸 때 실질적으로 의미 있는 부분만 다시 짚으면 이렇습니다.
- 10GB 무료는 "체험 기간"이 아닙니다. 계속 무료입니다. 소규모 사이트 몇 개의 백업은 이 안에 들어갑니다.
- 10GB는 하드 리밋이 아닙니다. 넘으면 막히는 게 아니라 넘은 만큼만 과금됩니다. 좋기도 하고 무섭기도 한 점입니다 — 모르는 사이에 조금씩 청구될 수 있습니다.
- byte-hour 과금이라 순간 용량이 초과 되어 과금 되는 경우는 있지만 경고 알림 설정으로 어느정도 요금폭판을 막을 수는 있습니다.
어떻게 구성했나 — rclone으로 암호화해서 올린다
도구는 rclone을 썼습니다. 40여 개 클라우드에 파일을 동기화해 주는 무료 오픈소스 명령어 도구인데, 암호화 기능이 내장되어 있는 게 결정적이었습니다.
핵심은 저장소를 2단으로 겹치는 것입니다.
내 서버 /backup
↓
b2crypt ← 암호화 레이어 (여기서 파일 내용과 파일명이 암호화된다)
↓
b2src ← Backblaze B2 계정 (버킷: 내 백업 버킷)
이렇게 하면 rclone이 올리기 전에 내 서버에서 암호화합니다. Backblaze 쪽에는 처음부터 암호문만 도착하고, 파일 이름조차 알아볼 수 없는 문자열로 바뀝니다. 백업 파일에는 사이트 소스와 데이터베이스가 전부 들어 있으니, 이건 선택이 아니라 필수라고 봤습니다.
설정은 rclone config에서 대화형으로 진행합니다. B2 remote를 먼저 만들고(type = b2), 그 위에 crypt remote를 만들어(type = crypt) remote 값으로 앞의 B2 버킷을 가리키면 끝입니다.
다 만들면 remote가 두 개 보입니다. 설정 내용은 rclone config redacted로 확인하는 게 안전합니다 — 비밀값을 가려서 보여주기 때문입니다.
$ rclone listremotes
b2src:
b2crypt:
$ rclone config redacted
[b2crypt]
type = crypt
filename_encryption = standard
directory_name_encryption = true
password = XXX
password2 = XXX
remote = b2src:내-백업-버킷
[b2src]
type = b2
account = XXX
key = XXX
### Double check the config for sensitive info before posting publicly
filename_encryption = standard과 directory_name_encryption = true가 앞에서 말한 "파일 이름까지 암호화"에 해당하는 설정입니다. 그리고 rclone이 마지막 줄에 "공개하기 전에 민감한 정보가 없는지 다시 확인하라"고 스스로 경고를 붙여 줍니다.
동기화 명령은 이렇습니다. 이 한 줄을 매일 새벽에 cron으로 돌립니다.
rclone sync /backup b2crypt: --transfers 8 --delete-before --b2-hard-delete
옵션 중 --delete-before와 --b2-hard-delete가 왜 붙었는지가 이 글의 본론입니다. 둘 다 사고를 겪고 나서 추가한 것입니다.
에피소드 1 — 콘솔 사용량이 실제의 두 배로 보였다
구축 첫날(2026년 6월 19일)부터 이상했습니다. 실제 데이터는 4.1GB인데 Backblaze 콘솔에는 8.8GB로 나왔습니다. 무료 10GB 중 88%를 쓴 것으로 보이니 당황했습니다.
원인은 B2의 버전 관리였습니다. B2는 같은 이름의 파일을 덮어쓰면 예전 파일을 지우지 않고 "숨김(hidden) 버전"으로 남깁니다. 실수로 지웠을 때 되살릴 수 있게 해 주는 안전장치인데, 백업 미러링에서는 같은 데이터가 두 벌씩 쌓이는 결과가 됩니다. 첫 동기화가 중간에 끊겼다 재실행된 게 방아쇠였습니다.
진단은 두 숫자를 비교하면 바로 나옵니다.
rclone size b2crypt: # 실제 내 데이터 (암호화 레이어 기준)
rclone size b2src:버킷명 --b2-versions # 숨은 옛 버전까지 포함한 실제 저장량
두 값이 크게 다르면 옛 버전이 쌓인 것입니다. 정리는 이렇게 합니다.
rclone cleanup b2src:버킷명
이 명령으로 8.8GB가 4.1GB로 내려갔습니다. 그리고 재발을 막기 위해 두 가지를 상시 적용했습니다.
- --b2-hard-delete — 파일을 지울 때 숨김 처리 대신 즉시 완전 삭제합니다.
cron에 rclone cleanup을 매번 함께 실행하도록 붙였습니다. 남은 옛 버전과 미완성 업로드를 매일 청소합니다.

에피소드 2 — 실제 사용량은 58%인데 "75% 넘었다"는 메일이 왔다
오늘(2026년 8월 5일) 아침 Backblaze로부터 저장 용량이 75%를 넘었다는 경고 메일을 받았습니다. 마침 전날 다른 서버의 백업을 이 서버로 가져오는 작업을 했던 터라, 그게 함께 올라간 줄 알았습니다.

확인해 보니 아니었습니다. 실제 버킷 용량은 이랬습니다.
$ rclone size b2crypt:
Total objects: 12
Total size: 5.400 GiB (5797998955 Byte) → 5.80GB, 무료 10GB의 58%
숨은 버전까지 포함해도 같은 12개였습니다. 옛 버전 누적도 아니고, 전날 작업한 백업도 올라가지 않았습니다. 그런데 왜 75%인가.
답은 동기화 로그에 있었습니다.
06:00~06:02 새 파일 12개 업로드 완료 (5.401 GiB) ← 옛 파일이 아직 그대로 있다
06:02:19 옛 파일 6개 삭제 (5.267 GiB freed)
순서를 보세요. 새 파일을 다 올린 다음에 옛 파일을 지웁니다. 그래서 그 2분 16초 동안 버킷 안에는 어제 백업 + 오늘 백업이 동시에 들어 있습니다. 합치면 약 11.5GB — 무료 한도의 115%입니다. Backblaze가 그 구간의 용량을 재면 당연히 경고가 나갑니다.
이게 rclone의 버그는 아닙니다. rclone sync의 기본 동작(--delete-after)이고, 오히려 안전한 기본값입니다. 새 파일이 무사히 올라간 것을 확인한 뒤에 옛것을 지우니까요. 문제는 용량 한도가 데이터의 2배보다 작을 때 이 안전장치가 한도를 넘긴다는 점입니다.
해결은 옵션 하나입니다.
rclone sync /backup b2crypt: --delete-before --b2-hard-delete
| 기본값 (--delete-after) | --delete-before | |
|---|---|---|
| 순서 | 새것 업로드 → 옛것 삭제 | 옛것 삭제 → 새것 업로드 |
| 동기화 중 최대 용량 | 약 11.5GB (한도의 115%) | 약 5.8GB (한도의 58%) |
| 위험 구간 | 없음 | 업로드 완료 전까지 약 2분간 원격에 사본이 없음 |
에피소드 3 — 내가 만든 감시 알림은 왜 없었지?
사실 저는 이런 상황을 대비해 용량 감시 스크립트를 이미 만들어 두었습니다. 용량이 80%를 넘으면 텔레그램으로 알려주도록 해 두었는데, 정작 이번에 아무 알림도 오지 않았습니다. Backblaze 쪽 메일이 유일한 신호였습니다.
이유는 간단한 것이였습니다. 그 스크립트는 실행되는 그 순간의 용량만 잽니다. 매주 월요일 오전 7시에 한 번 재는데, 문제가 되는 순간 피크는 매일 오전 6시에 2분간만 존재합니다. 구조적으로 절대 못 봅니다.
이게 이번에 가장 배운 점입니다. 감시는 "무엇을 재는가"만큼 "언제 재는가"가 중요합니다. 평균이나 현재값만 보는 감시는 짧고 뾰족한 피크를 놓칩니다. 그리고 놓친 줄도 모릅니다 — 알림이 안 온 것과 문제가 없는 것이 구분되지 않으니까요.
그래서 감시 주기를 주 1회에서 매일, 동기화 직전 시각으로 바꿨습니다. 순간 피크는 여전히 못 보지만, 피크의 원인이 되는 "원본 용량"의 증가 추세는 매일 잡힙니다. 실제로 제 백업 원본은 7월 중순 4.53GB에서 8월 초 5.27GB로 자라고 있었습니다. 이 추세를 먼저 봤다면 경고 메일을 받기 전에 알았을 겁니다.
무료 10GB로 쓸 때 실제로 계산해야 하는 값
여기까지의 교훈을 숫자 하나로 정리하면 이렇습니다. 무료 10GB에서 안전한 "원본 크기"는 10GB가 아닙니다.
| 동기화 방식 | 안전한 원본 크기 | 이유 |
|---|---|---|
| 기본값 (--delete-after) | 약 4.5GB 이하 | 동기화 중 최대 용량이 원본의 약 2배가 된다 |
| --delete-before | 약 9GB 이하 | 최대 용량이 원본과 거의 같다 |
제 경우 원본이 5.4GB였으니, 기본값으로는 이미 한도를 넘고 있었던 겁니다. 두 달 동안 몰랐던 건 요금이 byte-hour 기준이라 2분치 초과분의 금액이 사실상 0원에 가까웠기 때문입니다. 돈은 안 나갔지만 경고는 나갔습니다.
처음 쓰는 사람이 놓치기 쉬운 것 5가지
- 버킷은 반드시 Private으로. Public으로 만들면 URL을 아는 누구나 파일을 내려받을 수 있습니다. 백업 버킷을 Public으로 두는 건 사고입니다.
- 애플리케이션 키는 버킷 단위로 발급하세요. 계정 전체 권한을 가진 마스터 키를 서버에 두면, 서버가 뚫릴 때 다른 버킷까지 함께 털립니다. 저는 해당 버킷만 접근하는 전용 키를 만들어 서버에 두었습니다.
- 암호화는 올리기 전에, 내 쪽에서. 업체 측 암호화는 업체가 열 수 있습니다.
- 복구 키는 서버 밖에도 보관. 서버 안에만 있으면 서버와 함께 사라집니다. 그러면 백업이 남아 있어도 영구히 못 엽니다.
- 콘솔의 Caps & Alerts를 설정해 두세요. 이번에 저를 구한 것은 제가 만든 감시가 아니라 Backblaze가 보낸 메일이었습니다. 무료로 쓰는 사람에게는 이게 마지막 안전망입니다.
자주 묻는 질문
정리 — 무료 10GB는 충분하지만, 계산은 두 배로 해야 한다
결론은 이렇습니다. Backblaze B2의 무료 10GB는 개인이 소규모 서버 백업을 외부에 두기에 충분합니다. 두 달 가까이 실제 비용은 0원이었고, 매일 새벽 자동으로 돌아가며 손댈 일이 없었습니다. 무료 서버를 쓰는 분이라면 조합해 볼 가치가 확실히 있습니다.
다만 처음 시작한다면 두 가지만 기억하면 저처럼 헤매지 않습니다. 첫째, 콘솔 숫자와 실제 데이터가 다를 수 있습니다(옛 버전 누적). 둘째, 동기화가 도는 몇 분간은 용량이 두 배가 됩니다. 그래서 무료 10GB로 안전하게 다룰 원본은 4~5GB 선이고, 옵션 하나(--delete-before)로 그 한계를 9GB까지 늘릴 수 있습니다.
그리고 마지막으로, 이번에 제일 크게 배운 것은 백업이나 저장소 이야기가 아니었습니다. 내가 만든 감시가 조용한 것과 문제가 없는 것은 다르다는 사실입니다. 알림을 만들었다면, 그 알림이 못 보는 시간대가 어디인지도 함께 적어 두어야 합니다.
서버에 직접 접속해서 이런 것들을 확인하는 방법을 알고 싶다면, 공유호스팅에서 SSH를 여는 과정을 정리한 케미클라우드 SSH 키 등록 방법도 함께 보시면 도움이 됩니다.
참고한 공식 문서
- Backblaze — B2 Cloud Storage Pricing — 무료 10GB·$6.95/TB·egress 3배 무료
- Backblaze — B2 Cloud Storage 공식 문서 — 버킷·애플리케이션 키·파일 버전
- rclone — Backblaze B2 — --b2-hard-delete, --b2-versions, cleanup 동작
- rclone — Crypt — 클라이언트 측 암호화, 파일명 암호화
- rclone — sync 명령 — --delete-before / --delete-during / --delete-after 차이