백업이 하나도 없었습니다 — 원룸에서 3-2-1을 짜며 막힌 곳

서버 한 대에 나스와 AI를 얹고 나서 한동안 만족했습니다. 시스템 디스크는 SSD 두 장 미러, 데이터는 하드 8개. 어디를 봐도 이중화가 돼 있으니 안전하다고 생각했어요. 그런데 어느 날 게스트 설정을 잘못 건드려 되돌리려는데, 되돌릴 곳이 없다는 걸 알았습니다. 백업이 하나도 없었습니다.

미러는 백업이 아니었습니다

미러 구성은 디스크 한 장이 죽어도 서비스가 멈추지 않게 해줍니다. 제가 Proxmox를 설치하면서 확인했던 것도 그거였어요. 그런데 미러가 막아주는 건 딱 그 하나, 하드웨어 고장뿐입니다.

미러는 두 장에 똑같이 씁니다. 그래서 제가 파일을 지우면 양쪽에서 동시에 지워집니다. 설정을 망가뜨리면 양쪽 다 망가진 설정이 됩니다. 랜섬웨어가 암호화하면 양쪽 다 암호화돼요. 실수도 사고도 그대로 복제됩니다.

정리하면 이렇습니다. 미러는 멈추지 않게 해주는 장치고, 백업은 되돌릴 수 있게 해주는 장치입니다. 목적이 다릅니다. 제가 갖고 있던 건 앞의 것뿐이었고, 정작 제가 필요했던 건 뒤의 것이었어요.

3-2-1이 요구하는 세 가지

백업 쪽에서 오래 통용되는 규칙이 있습니다. 숫자 세 개가 각각 다른 위험을 막습니다.

3 — 사본을 세 벌 둔다 (원본 포함)
2 — 서로 다른 매체 두 종류에 나눈다
1 — 그중 하나는 집 밖에 둔다

왜 이렇게 나누는지는 각 숫자가 막는 사고를 보면 분명해집니다. 사본이 하나면 그게 죽는 순간 끝이고, 같은 매체에 몰아두면 그 매체 계열의 공통 결함에 한꺼번에 당합니다. 그리고 같은 방에 다 있으면 화재나 침수, 도난에는 전부 무력해요.

여기서 중요한 건 같은 풀 안의 스냅샷은 사본으로 세지 않는다는 점입니다. 풀이 통째로 날아가면 스냅샷도 같이 날아가니까요. 저는 이걸 사본 하나로 착각하고 있었습니다.

전부 백업하려다 아무것도 못 합니다

처음엔 나스 전체를 백업하려고 용량을 계산했습니다. 수십 테라바이트가 나왔고, 그 순간 계획이 멈췄어요. 감당이 안 되니까 아무것도 안 하게 되더라고요.

그래서 데이터를 세 등급으로 나눴습니다.

되살릴 수 없는 것 — 사진, 문서, 직접 만든 코드와 설정, 블로그 원고. 세상에 저한테만 있는 것들입니다. 용량은 의외로 작습니다. 여기가 진짜 백업 대상이에요.

다시 받을 수 있는 것 — AI 모델 파일, 미디어 라이브러리, 배포판 이미지. 용량의 대부분이 여기입니다. 그런데 없어지면 다시 받으면 됩니다. 시간이 아깝지 돌이킬 수 없는 건 아니에요. 모델 저장소를 나스로 옮겼던 것도 같은 판단이었습니다. 백업하지 않기로 했습니다.

다시 만들 수 있는 것 — 게스트 자체. 운영체제와 패키지는 재설치하면 되고, 필요한 건 그 위에 얹은 설정입니다.

이렇게 나누고 나니 실제 백업 대상 용량이 처음 계산의 몇십 분의 일로 줄었습니다. 백업 계획이 막히는 이유는 대개 용량이 아니라 등급을 안 나눠서입니다.

Proxmox에 이미 들어 있던 것

세 번째 등급, 그러니까 게스트 백업은 따로 도구를 살 필요가 없었습니다. Proxmox에 내장돼 있어요.

Proxmox VE의 백업은 항상 전체 백업이고, 게스트 설정과 데이터를 함께 담습니다. 웹 화면에서도 되고 vzdump 명령으로도 됩니다. 백업 모드는 세 가지인데 기본값인 snapshot 모드는 게스트를 켜둔 채로 진행해 중단 시간이 가장 짧고, 대신 약간의 불일치 위험을 감수합니다 (출처: Proxmox VE Wiki — Backup and Restore).

# 게스트 하나를 지정한 저장소에 백업
vzdump 101 --storage backup-nas --mode snapshot --compress zstd

# 복원
qmrestore /mnt/backup/vzdump-qemu-101.vma 601   # 가상머신
pct restore 601 /mnt/backup/vzdump-lxc-102.tar  # 컨테이너

보존 정책도 옵션으로 잡습니다. 최근 몇 개, 며칠, 몇 주, 몇 달을 각각 지정하는 방식이에요. 공식 문서의 권고가 인상적이었는데, 보존 기간은 필요한 것보다 넉넉하게 잡으라고 합니다. 나중에 줄이는 건 언제든 되지만 한 번 지워진 백업은 다시 만들 수 없기 때문입니다.

두 번째 매체를 원룸에서 고르기

여기서부터 원룸 조건이 발목을 잡습니다. 서버를 한 대로 합친 이유 자체가 자리와 전기였는데, 백업하겠다고 두 번째 기기를 상시로 켜두면 그 결정을 뒤집는 셈이니까요.

그래서 상시 켜두지 않는 쪽으로 가려 합니다. 외장 디스크에 주기적으로 받아두고 평소엔 뽑아두는 방식이에요. 뽑아둔 디스크는 랜섬웨어가 건드릴 수 없다는 이점도 있습니다. 연결돼 있지 않은 게 방어입니다.

대신 단점이 분명합니다. 사람이 꽂아야 하니 잊어버리면 그날부터 백업이 안 됩니다. 자동화된 것만 살아남는다는 걸 여러 번 겪었는데, 여기서는 자동화를 일부러 포기하는 셈이에요. 알림을 걸어두는 정도로 버틸 수 있을지는 해봐야 알 것 같습니다.

마지막 한 칸은 아직 비어 있습니다

3과 2까지는 그림이 그려졌는데, 집 밖 사본은 아직 못 정했습니다. 선택지는 두 가지로 좁혔어요.

하나는 클라우드입니다. 자동화가 되고 사람 손이 안 갑니다. 대신 매달 돈이 나가고, 올릴 때 가정용 인터넷의 업로드 속도가 걸립니다. 무엇보다 남의 서버에 올리는 거라 올리기 전에 암호화하는 문제를 먼저 풀어야 합니다.

다른 하나는 외장 디스크를 다른 장소에 두고 주기적으로 바꿔오는 방식입니다. 비용이 거의 없고 통제권이 완전히 제 손에 있습니다. 대신 전적으로 사람 손에 달려 있어서, 두어 달 지나면 안 하게 될 것 같다는 예감이 듭니다.

솔직히 아직 결론을 못 냈습니다. 다만 이건 확실해졌어요. 1을 못 채웠다고 3과 2를 미룰 이유는 없습니다. 셋 다 갖춘 뒤에 시작하려다 결국 아무것도 안 하고 있었던 게 지금까지의 상태였으니까요.

정리

미러는 백업이 아닙니다. 고장을 막아줄 뿐 실수와 사고는 그대로 복제합니다. 되살릴 수 없는 것만 골라내면 백업 대상은 생각보다 작아지고, 게스트 백업은 Proxmox에 이미 들어 있습니다.

그리고 백업은 복원해봐야 백업입니다. 받아둔 파일이 정말 열리는지, 복원한 게스트가 정말 뜨는지 확인하기 전까지는 백업이 있다고 말하기 어렵습니다. 저는 아직 거기까지 못 갔어요. 그래서 이 글은 완성된 구성이 아니라 여기까지 정한 기록입니다.