서론

홈서버를 운영한 지 약 반년 정도가 지났다.

고작 반년 사이에 무슨 사건·사고가 있었겠냐 하지만, 생각보다 다양한 일이 있었다.
집의 퓨즈가 나가 정전되어 서버가 내려간다든지, 멀티탭을 잘못 뽑는다든지 등등.

사실 SSD만 있다면 그냥 웃어넘겼겠지만,
NAS용 HDD의 경우 강제로 중단되면 디스크에 손상이 갈 수 있기에 미뤄두었던 백업 시스템을 구축해 보고자 한다.

보다 근본적인 해결을 위해 이사하면 UPS(Uninterruptible Power Supply)를 구매할까도 생각 중이다.

본론

대충 찾아보았을 때는 Proxmox에서 제공하는 PBS(Proxmox Backup Server)라는 자체 백업 서비스가 존재한다고 한다. 얼핏 들었을 때는 해당 기능을 일종의 스냅샷(Snapshot)을 뜨는 것이라 이해하였으나, Gemini와 교차 검증을 하니 전혀 다른 개념임을 알 수 있었다.

Proxmox의 스냅샷(Snapshot)과 Proxmox Backup Server(PBS)를 이용한 백업은 완전히 다른 개념이다.

1. Proxmox 스냅샷 (Snapshot)
- 개념: 특정 시점의 VM/LXC 상태(메모리 상태 포함 가능)를 현재 실행 중인 동일한 디스크(스토리지)에 기록하는 기능이다.
- 특징: 생성 및 복원(롤백) 속도가 즉각적이고 매우 빠르다.
- 한계: 원본 스토리지가 물리적으로 고장 나거나 파일 시스템이 손상되면, 그 안에 들어있던 스냅샷 데이터도 함께 소실된다. 진정한 의미의 재난 복구(DR)용 백업이 아니며, 주로 OS 업데이트나 위험한 설정 변경 전에 단기적으로 되돌리기 위한 용도로 쓰인다.

2. PBS 백업 (Proxmox Backup Server)
- 개념: VM/LXC의 전체 설정 파일과 디스크 데이터를 완전히 분리된 외부 스토리지(PBS 서버)로 복사하여 안전하게 보관하는 독립적인 전체 백업이다.
- 특징: 원본 스토리지나 운영 서버 전체에 치명적인 장애가 발생하더라도, PBS에 저장된 데이터만 무사하면 언제든 빈 깡통 서버에 기존 환경을 온전히 복원할 수 있다. PBS는 중복 제거(Deduplication)와 변경된 블록만 전송하는 증분 동기화(Dirty-bitmap) 기술을 사용하므로 전체 백업임에도 용량 효율과 속도가 매우 뛰어나다.

출처 | Google. (2026). Gemini 3.1 (PRO) [Large language model]. https://gemini.google.com

딱 봐도 PBS 백업을 이용해야겠다는 생각이 물씬 든다.

3-2-1 백업 전략

백업 인프라를 구성할 때 가장 기본적이고 널리 사용되는 전략이다. 단순히 데이터를 복사하는 것을 넘어, 물리적인 재난 상황에서도 데이터를 안전하게 보호하기 위한 검증된 방법론이다.

3-2-1 원칙은 데이터 손실 사고 발생 시 신속하게 데이터를 복구하고 복원할 수 있도록 설계된 데이터 백업 전략입니다.

- 3개의 데이터 사본을 만듭니다.
- 그중 2개의 사본을 서로 다른 미디어 장치에 로컬로 저장합니다. 그러한 장치로는 컴퓨터에 내장된 하드 드라이브나 외장 하드 드라이브를 포함한 이동식 저장 장치를 사용할 수 있습니다.
- 나머지 1개의 사본은 클라우드 백업 소프트웨어 등의 오프사이트 솔루션에 원격으로 저장합니다.

출처 | '3-2-1 백업 전략'의 뜻과 사용법, Dropbox Experience

즉, 간단히 말하면 원본 데이터를 포함하여 2개의 사본을 각각 다른 저장 장치에 저장하되, 그중 한 개는 클라우드에 저장함으로써 안정성을 보장하고자 하는 전략이다.

3-2-1 백업 전략의 적용

현재 내 홈서버는 아래와 같은 저장장치로 구성되어 있다.

Proxmox가 사용하는 NVMe SSD 1TB Xpenology로 Passthrough하여 사용하는 HDD 2TB X 4

때문에 홈서버 환경에서 3-2-1 전략의 '2(서로 다른 저장 매체)'를 충족하기 위해 가장 먼저 로컬 스토리지 간의 교차 백업을 고려했다. 즉 Proxmox의 백업 데이터를 Xpenology HDD에 저장하고, Xpenology의 백업 데이터를 Proxmox SSD에 저장하면 되는 게 아닌가 생각했다.

천재적인 아이디어라 생각하여 Gemini에게 질문하였으나, 답하기를

...

하지만 이는 동일한 물리적 서버(메인보드, 파워서플라이 등)에 종속되어 있으므로, 낙뢰나 전력 서지 등 시스템 전체에 영향을 미치는 하드웨어 장애에는 여전히 취약하다.

따라서 진정한 의미의 물리적 분리를 달성하기 위해서는, 결국 외장 하드디스크 등을 활용해 서버와 전원/데이터 케이블이 분리된 오프라인 백업 매체를 마련하는 것이 가장 확실한 방법이다.

라고 하더라.

따라서 진정한 의미의 물리적 분리를 달성하려면 외장 하드디스크 등을 활용해야 한다. 하지만 최근 AI로 인해 HDD, SSD의 가격이 미쳐 날뛰고 있어 가격이 안정화될 때까지 잠시 미루고, 현재 서버의 남는 NVMe 자원과 클라우드를 최대한 활용하는 타협안을 적용하기로 했다.

참고로 홈서버 구성을 위해 SSD를 구매한 2025.08.23 기준, 1TB에 10만 원에 구매했었다.

이를 시각화해 보면 아래와 같은 형식이다.

PBS에 대한 이해

데이터를 안전하게 보호하려면 실시간 미러링이 아닌, 과거의 정상적인 시점(Point-in-Time)으로 되돌릴 수 있는 스케줄링 기반의 백업이 필요하다. 실시간 동기화는 랜섬웨어 감염이나 파일 삭제와 같은 치명적인 오류까지 즉각적으로 복제해 버리기 때문이다.

이를 위해 Proxmox VE는 가상 머신이 실행되는 동안 메모리상에서 디스크의 변경된 블록만 추적하는 'QEMU Dirty Bitmap' 기술을 활용한다.

Incremental & Deduplication

Backups are sent incrementally from the client to the Proxmox Backup Server, where data is then deduplicated. Typically, changes between periodic backups are low. Reading and sending only the changes reduces the storage space used and the network impact.

Periodic backups usually produce large amounts of duplicate data. The deduplication layer in the Proxmox Backup solution reduces the amount of duplicate data, reducing the physical space required for data storage.

When doing deduplication, there are different strategies to get optimal results in terms of performance and/or deduplication rates. Depending on the type of data, data can be split into fixed or variable sized chunks; Proxmox Backup Server supports both strategies.

출처 : Proxmox Backup Server Feature, https://www.proxmox.com/en/products/proxmox-backup-server/features

백업 스케줄이 실행되면, 전체 디스크를 스캔하는 대신 이 Dirty Bitmap을 참조하여 새롭게 변경된 데이터 블록만 즉각적으로 읽어 들인다. 이후 추출된 데이터를 최대 4MB 크기의 수많은 조각(Chunk)으로 잘게 쪼개고 해시값을 대조하여, 기존 서버에 없는 완전히 새로운 청크만 네트워크로 전송한다.

결과적으로 100GB 용량의 시스템을 백업하더라도 실제 전송되는 용량은 극히 적지만, 저장소에는 최소 25,000개 이상의 자잘한 파일들이 생성되어 보관된다.

후술하겠지만, 이러한 아키텍처는 시스템 부하와 로컬 저장 공간을 극적으로 절약해 주지만, 수만 개의 파일 전송과 잦은 API 요청을 감당해야 하기에 원격 클라우드 스토리지 선정 시 매우 까다로운 기준을 요구하게 된다.

원격 저장소 선정

일반적으로 백업 데이터를 저장하기 위해 사용하는 다양한 서비스들이 존재한다.

초기에는 기가바이트당 보관 비용이 매우 저렴한 AWS S3 Glacier를 고려했다. 하지만 Glacier와 같은 콜드 스토리지(Cold Storage)는 데이터를 저장할 때는 저렴하지만, 긴급하게 복원하기 위해 데이터를 꺼낼 때 발생하는 검색 비용과 시간 지연이 문제였다.

AWS S3 Glacier 스토리지 요금 | 출처 : Amazon S3 Glacier 서비스(저장소용 Glacier API) 요금

AWS S3 Glacier 데이터 전송 요금 | 출처 : Amazon S3 Glacier 서비스(저장소용 Glacier API) 요금

대충 100GB를 보관하고, 1년에 1회 내려받는다고 하면 아래와 같이 나온다.

보관 비용: $0.0045 * 100GB * 12개월 = $5.4
반출 비용: $0.126 * 100GB = $12.6
Total: $18 (한화 약 27,160 원 / 26.03.28 기준)

계산상으로는 합리적으로 보이나, 앞서 언급한 PBS의 청크 분할 구조를 대입하면 치명적인 문제가 발생한다. AWS Glacier는 파일을 올리고(PUT) 읽는(GET) API 요청 횟수마다 과금을 매기기 때문에, 수만 개의 청크 조각을 처리할 경우 막대한 API 호출 비용 폭탄을 맞게 된다.

또한 PBS가 주기적으로 백업 데이터를 검증(Verify)하고 정리(GC)하려면 데이터를 즉시 읽어 들여야 하는데, 지연 시간이 긴 콜드 스토리지는 타임아웃 오류를 일으켜 백업 시스템 자체를 멈추게 만든다.

결과적으로 주기적인 백업 및 검증이 필요하고, 언제든 즉각적인 복구가 가능해야 하는 개인 홈서버 환경에는 적합하지 않다고 판단하여 무료 또는 저렴한 핫 스토리지(Hot Storage) 대안인 Backblaze B2와 Cloudflare R2를 비교선상에 올렸다.

비교 항목	AWS S3 Glacier	Backblaze B2	Cloudflare R2
스토리지 보관 요금 (월)	GB당 $0.0045	GB당 $0.006	GB당 $0.015 (매월 10GB 무료)
이그레스(반출) 요금	GB당 $0.126	월 보관 용량의 3배까지 무료 (초과 시 GB당 $0.01)	전면 무료 ($0)
API 요청 요금 (업로드)	1,000건당 $0.03	전면 무료	월 100만 건 무료 (초과 시 100만 건당 $4.50)
API 요청 요금 (다운로드)	1,000건당 $0.01 + 검색 비용	일 2,500건 무료 (초과 시 1만 건당 $0.004)	월 1,000만 건 무료 (초과 시 100만 건당 $0.36)
스토리지 타입	Cold Storage (접근 대기 3~12시간)	Hot Storage (즉각 접근 가능)	Hot Storage (즉각 접근 가능)

초기에는 데이터를 내려받을 때 발생하는 트래픽 비용인 '이그레스(Egress)'가 전면 무료인 Cloudflare R2가 압도적으로 좋아 보였다. 하지만 홈서버의 실제 재난 복구(DR) 시나리오를 대입해 보니 굳이 이 정도까지 필요할까? 싶었다.

개인 홈서버의 디스크가 완전히 고장 나서 전체 데이터를 클라우드에서 내려받아야 하는 치명적인 재난 상황은 1년에 한 번 발생할까 말까 한 일이다. 즉, 한 달에 전체 데이터를 3번이나 복원할 일이 없는 홈서버 환경에서 Backblaze B2의 이그레스 정책은 '월 보관 용량의 3배까지 무료'이므로, 100GB를 백업해 두었다면 매월 300GB의 다운로드가 무료로 제공된다. 즉 사실상 '완전 무료'와 동일하게 작동한다

따라서 결과적으로 실질적인 이그레스 비용이 둘 다 0원이라면, 보관 비용 단가가 R2($0.015)의 절반 이하인 B2($0.006)를 선택하는 것이 가장 경제적이고 합리적인 결정이다.

백업 환경 구축

어느 정도 계획이 세워졌으니 이제 직접 실행할 순서다.

1. PBS LXC 생성

적당한 스펙(2코어 CPU, 2GB RAM, 100GB SSD)으로 LXC를 만들어 주었다. 앞서 언급하였듯이 미쳐 돌아가는 HDD,SSD 값이 정상화되기 전엔 그냥 호스트용 SSD 일부를 할당하여 백업 예정이다. 추후 구매하게 되면 마운트 경로로 바꿔주기만 하면 그만이다.

참고로 위 이미지상으로는 고정 IP 형식으로 10.80.60.200/32로 subnet mask를 지정하였으나, 이러할 경우 추후 Proxmox 호스트와의 연결이 원활하지 않을 수 있으므로 subnet mask를 24로 생성해야 한다.

이후 아래 명령어를 통해 해당 LXC 내부에 PBS를 설치할 수 있다.

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs-enterprise.list
apt update
apt install proxmox-backup-server -y

이때 한 가지 주의할 점이 있다. 혹시 데비안(Debian) LXC 템플릿으로 생성하였다면 설치 과정에서 에러가 발생할 수 있다. 이는 IPv6 설정 문제로 패키지 저장소 접근이 막히는 이슈로, LXC 내부 터미널에서 아래 명령어를 통해 IPv4를 강제해 주면 해결할 수 있다.

echo 'Acquire::ForceIPv4 "true";' > /etc/apt/apt.conf.d/99force-ipv4
apt install proxmox-backup-server -y

정상적으로 설치되었다면 할당한(된) LAN IP:8007 로 접근하면 위처럼 로그인 화면을 확인할 수 있다. 로그인은 root:Proxmox PW 로 할 수 있다.

이후 원활한 스케쥴링을 위해 PBS CLI를 통해 타임존을 변경하면 된다.

dpkg-reconfigure tzdata

2. PBS DataStore 생성

가장 먼저 해야 할 일은 백업된 파일들이 실제로 저장될 공간인 '데이터스토어(Datastore)'를 만들어주는 것이다. 하지만 웹에서 버튼을 누르기 전에 반드시 PBS LXC 내부 터미널에서 마운트 디렉터리를 먼저 생성하고 권한을 부여해 주어야 한다. 권한이 없으면 웹에서 경로 추가 시 에러를 뿜어낸다고는 하는데 굳이 확인해 보진 않았다.

디렉토리 생성과 더불어 PBS가 백업을 위해 사용하는 시스템 계정인 backup 계정으로 소유권도 넘겨주었다.

mkdir -p /mnt/pbs_backup
chown backup:backup /mnt/pbs_backup

권한 부여가 끝났다면 웹 대시보드로 돌아가 데이터스토어를 추가해 준다.

이후 본체인 Proxmox 대시보드로 돌아가 방금 만든 PBS를 백업 저장소로 등록한다.

이때 가장 중요한 것이 Fingerprint(지문)로, Proxmox가 PBS 서버를 신뢰할 수 있도록 암호화 지문을 입력해야 하는데, 이는 PBS 대시보드의 'Dashboard' 탭 하단 'Show Fingerprint' 버튼을 눌러 쉽게 복사할 수 있다. 이와 더불어 이전 설정한 PBS LAN IP와 DataStore, 인증 정보를 정상적으로 입력하면 연동이 완료되어 PVE 좌측 스토리지 목록에 닻 아이콘과 함께 PBS 저장소가 나타난다.

3. PBS Job 생성

PBS 생성과 연동을 완료하였다면 이제 실제 백업을 수행할 차례이다.

주의할 점으로는 백업 대상인 VM, LXC 들을 선택할 때 PBS가 PBS LXC를 백업해서는 안 된다.

상기 이미지처럼 매일 새벽 2시에 선택된 VM, LXC들을 백업하도록 구성하였다. 테스트를 위해 일회성으로 실행해 보면 아래처럼 정상적으로 백업이 수행됨을 확인할 수 있다.

하지만 이렇게 될 경우 아무리 PBS가 증분백업을 해준다고 해도 홈서버를 장기간 운용할수록 점차 용량이 증가하게 될 것이다.

100GB (원본) + 하루 1GB 데이터 수정 X 365일 = 465GB

따라서 아래처럼 주기적으로 불필요한 백업본을 정리할 수 있도록 PBS 내에서 Prune 작업을 생성해 주었다

위와 같이 설정하게 되면 매일 03:00 마다 백업 파일을 아래 기준에 맞춰 정리한다.

Keep-Last: 3 (최근 3개 백업본 보관)
Keep-Daily: 7 (최근 일주일 백업본 보관)
Keep-Weekly: 4 (최근 한 달치는 주 1회 단위로 보관)
Keep-Monthly: 6 (최근 반년 치는 월 1회 단위로 보관)

여기서 추가로 고려해야 하는 것이 있다. Prune 작업은 목록(인덱스)에서 제거만 할 뿐, 실제 파일을 삭제하지는 않는다. 따라서 PBS Datastore 탭에서 Garbage Collection 스케줄을 추가해야 한다

이후 해당 백업본을 활용하여 VM, LXC를 편리하게 생성할 수 있다. 필자는 이를 통해 그간 혼재되어 있던 ID와 IP를 나름의 체계에 맞게 이 기회에 다 통일하였다.

VM, LXC ID AS-IS / TO-BE | 출처 : 내 Proxmox

4. Backblaze B2 연동

로컬 백업 환경 구성이 끝났으니, 이제 3-2-1 전략의 핵심인 클라우드(B2) 백업을 구성할 차례다.

앞서 언급하였듯이, PBS는 가상 머신의 '가상 디스크(OS와 설정 파일)'만 백업할 뿐 하드디스크 패스스루로 연결된 하드의 데이터는 백업하지 않는다. 따라서 계획했던 대로 'PBS 데이터'와 'NAS 데이터'를 각각 다른 방식으로 B2 클라우드에 쏴주는 투트랙(Two-Track) 전략을 본격적으로 실행에 옮긴다.

Backblaze b2 Bucket | 출처 : 내 Backblaze 대시보드

위와 같이 PBS, NAS 데이터 백업을 위한 버킷을 각기 생성해 주었다. 특이하게도 Backblaze는 Bucket 이름을 전체 사용자가 공유하기에 불가피하게 이름을 저렇게 지어주었다. 또한 데이터 백업 과정에서 잔여 데이터가 남는 걸 방지하기 위해 Lifecycle에서 최신본만 저장해 두도록 하였다.

이후 실제 연동을 위해 Application Key를 생성해 주었다.

생성한 Key는 이 페이지를 벗어나면 조회가 불가능하니 꼭 복사해두자

Backblaze B2 Application Keys | 출처 : 내 Backblaze 대시보드

또한 특이하게도 NAS를 위한 Application Key를 생성할 때에는 아래 이미지처럼 목록 조회 권한을 부여해야 한다.

NAS Backblaze Application Key 생성 | 출처 : 내 Backblaze 대시보드

여기까지 생성을 마쳤으면 이제 실제 연동할 차례이다.

4-1. PBS > B2 백업

PBS 자체는 외부 클라우드인 B2로 직접 전송하는 기능이 없기 때문에, 리눅스 환경의 클라우드 동기화 툴인 rclone을 활용하였다.

apt install rclone -y

설치가 정상적으로 되었다면 rclone config 를 통해 연동을 진행할 수 있다. 대충 진행하다가 아래 옵션만 true 로 활성화해 주었다.

Option hard_delete.
Permanently delete files on remote removal, otherwise hide files.
Enter a boolean value (true or false). Press Enter for the default (false).

연동이 완료되었다면 테스트를 위해 일회성으로 데이터를 동기화하였다.

--fast-list는 B2 클라우드 구조에 맞춰 API 호출 횟수를 획기적으로 줄여주고 작업 속도를 높여주는 필수 옵션이며, --transfers 16은 16개의 파일을 동시에 병렬로 전송하여 업로드 속도를 끌어올려 주는 옵션이다.

rclone sync /mnt/pbs_backup b2:<BUCKET_NAME> --fast-list --transfers 16 -v

Bucket을 다시 확인해 보면 정상적으로 동기화가 완료되었음을 확인할 수 있다.


...

<6>INFO  : .chunks/ffcc/ffcc06c0f96781fb59fb0303c8e53cfcaadc0017b2af2405564fde95b625d1b0: Copied (new)
<6>INFO  : .chunks/fff9/fff9b3d69d313f88442c282f6d0daad9e61a786c01174c05cf727e9aad66cc15: Copied (new)
<6>INFO  : .chunks/ffd3/ffd3a1677489ea0f1bd23585566878d88c9a6272290e53278c92d1c7edbf630e: Copied (new)
<6>INFO  : 
Transferred:       25.185 GiB / 25.185 GiB, 100%, 9.520 MiB/s, ETA 0s
Transferred:        25979 / 25979, 100%
Elapsed time:     38m44.5s

Backblaze PBS Bucket | 출처 : 내 Backblaze 대시보드

백업이 잘 수행되었으므로, 이제 crontab 을 통해 스케쥴링까지 하면 끝이다.

0 5 * * * /usr/bin/rclone sync /mnt/pbs_backup b2:siroh-pbs --fast-list --transfers 16 --log-file=/var/log/rclone-pbs.log --log-level INFO

4-2. NAS > B2 백업

Xpenology 내부 데이터를 백업할 차례이다. Hyper Backup 패키지를 설치해 준 뒤 아래처럼 S3 저장소를 연동해주면 끝이다.

연동 과정에서 Bucket 이름을 다 긁어오기 때문인지 이전 Application Key를 생성할 때 목록 조회 권한을 부여해야 된다.

마찬가지로 추후엔 마운트 된 외장하드 로컬 디렉토리를 향한 Hyper Backup을 추가해 주기만 하면 된다.

Synology Hyper Backup 설정 | 출처 : 내 Xpenology

이후에 할 일은 백업할 공유 폴더와 일정, 보관 주기만 선택해 주면 끝이다.

상기 과정을 완료하고 마찬가지로 테스트를 위해 백업을 수행해 보았다.

여기서 '클라이언트측 암호화'를 활성화 하였는데, 이는 B2에 백업하기 전 NAS에서 한 차례 암호화를 수행한 뒤 올리는 방식이다. 약간의 오버헤드가 있겠지만 안전을 위해 설정해 주었다.

만약 설정하였다면 추후 복호화를 위한 .pem 키를 다운받아 꼭 저장하자. 잃어버린다면 셀프 랜섬웨어를 겪을 수 있다.

Sysnology Hyper Backup 로그 | 출처 : 내 Xpenology

Backblaze NAS Bucket | 출처 : 내 Backblaze 대시보드

결론

위 과정을 통해 최종적으로 구성한 백업 절차를 정리해 보면 아래와 같다.

순서	작업명	실행 주기 및 시간	작업 주체
1	VM/LXC 백업	매일 02:00	PBS
2	Prune	매일 03:00	PBS
3	Garbage Collection	매일 04:00	PBS
4	rclone Sync (B2)	매일 05:00	PBS LXC
5	Hyper Backup (B2)	매일 06:00	Xpenology
6	백업 무결성 검사	매주 일요일 07:00	Xpenology