3-2-1 Backup Strategy with restic and Backblaze B2
restic과 Backblaze B2로 구성하는 3-2-1 백업 전략
작성자는 RAID1 저장 장치와 Raspberry Pi에 둔 로컬 사본, Backblaze B2에 올린 원격 사본으로 3-2-1 백업을 구성합니다. restic의 암호화와 중복 제거, systemd 예약 실행 설정부터 재해 복구와 복원 테스트까지 실제 절차를 설명합니다.
- 주제
에디터 노트
백업의 실효성은 사본 수뿐 아니라 복호화 키와 복원 절차를 재난 뒤에도 확보하는지에 달려 있습니다. 작성자는 암호를 암호 관리자에 보관하고 실제 복원을 시험하라고 적었으며, 댓글에서는 집과 사무실이 함께 피해를 입으면 로컬에만 둔 키도 잃을 수 있다는 지적이 나옵니다. 키를 별도 물리적 장소에 보관할지, 원격으로 접근 가능한 암호 관리자에 맡길지는 글에서 구체적으로 정하지 않습니다. RAID1은 디스크 장애 대응에 도움을 주지만 별도 백업과 같지 않다는 댓글 경험은 원문의 3-2-1 구성과 맞닿아 있습니다. 반면 로컬 사본 하나와 원격 사본 하나면 충분하다는 의견도 있어 사본 수에 대한 합의는 없습니다. 원문이 제시하는 것은 개인 환경의 구성 사례이며, 1.2TB 업로드에 약 50시간이 걸렸다는 수치는 회선 조건에 따른 사례입니다. 댓글의 Hetzner 전환과 복원 경험은 다른 저장소 선택과 실제 복원 시험의 고려사항을 보탭니다.
AI 요약
3-2-1 백업은 중요한 데이터 사본을 세 개 두고, 서로 다른 매체에 로컬 사본 두 개를 보관하며, 나머지 하나는 외부 장소에 두는 방식입니다. 작성자는 14TB 드라이브 두 개를 RAID1으로 묶은 DAS와 4TB 드라이브를 연결한 Raspberry Pi 5를 로컬에 두고, 약 1.5TB의 중요 데이터를 Backblaze B2에 별도로 백업합니다. B2는 클라우드 저장소를 제공하고 restic은 업로드 전에 파일을 암호화하고 청크로 나눕니다. 중복 제거도 restic이 처리합니다.
restic과 B2 설정
작성자는 /etc/restic 디렉터리에 B2 계정 정보와 저장소 주소를 담은 b2.env 파일을 만들고, 저장소 암호는 별도 password 파일에 둡니다. 암호는 openssl rand -base64 32 명령으로 만들며 두 파일의 권한을 chmod 600으로 제한합니다. 저장소 암호를 잃으면 B2에 남은 데이터도 복호화할 수 없으므로 암호 관리자에 보관하고 출력물로 따로 보관하는 방안도 언급합니다.
restic init으로 저장소를 초기화한 뒤 restic backup으로 사진과 문서 디렉터리를 백업합니다. 작성자는 업로드 속도가 최대 60Mbps인 케이블 인터넷 회선에서 1.2TB를 올리는 데 약 50시간이 걸렸다고 설명합니다. 업로드된 데이터는 암호화된 상태로 B2에 저장됩니다.
systemd 예약 실행과 복원
작성자는 systemd 서비스에 restic backup과 보존 정책을 지정한 restic forget 명령을 넣고, timer를 설정해 매일 새벽 3시에 실행하도록 합니다. 타이머에는 최대 30분의 무작위 지연과 시스템이 꺼져 있던 동안 놓친 실행을 처리하는 Persistent 설정도 포함합니다.
로컬 장치가 모두 사라진 상황에서는 새 시스템에 restic을 설치하고 저장소 암호와 B2 접속 정보를 복구합니다. restic snapshots로 저장소 접근을 확인한 다음 restic restore latest --target /mnt/recovery를 실행합니다. 복원한 파일은 대상 디렉터리 아래에 원래 경로 구조를 유지하므로 저장 위치를 고려해야 합니다. 작성자는 주기적으로 restic check를 실행하고 실제 복원도 시험하라고 권합니다.
Lobsters 반응
- @atmosx — 비슷한 설정을 쓰고 있으며 restic 스크립트도 공유합니다. 다만 3-2-1은 지나치게 엄격하다고 봅니다. 통계적으로는 로컬 사본 하나, 특히 RAID1 미러와 원격 사본 하나면 충분하다고 생각합니다. Backblaze는 매우 저렴하지만 2007년부터 적자를 내고도 벤처 자금으로 계속 운영되는 점이 놀랍습니다. 저렴한 가격은 반갑지만 AWS S3 같은 고급 기능이 없는 소규모 경쟁사에는 안타깝습니다.
- @rkaw92 — ZFS RAID와 미러링에서 명시적으로 제외한 추가 디스크를 함께 사용합니다. 추가 디스크에는 rsync만 합니다. 십 대 때 RAID5를 망가뜨려 소중한 가족 사진을 잃은 경험이 있습니다. 배열을 수정하던 중 커널 버그도 겪었지만 그 일로 RAID는 백업이 아니라는 점을 배웠습니다. 원격 사본도 두지만 주 저장소와 설정을 완전히 분리한 로컬 사본도 도움이 됩니다.
- @atmosx — RAID5는 써본 적이 없고 ZFS 미러를 12~15년간 문제없이 사용했습니다. HDD에 결함이 생겼을 때도 기본적인 유지보수 작업으로 시스템을 다시 작동시켰습니다.
- @rkaw92 — 비슷한 구성을 쓰다가 미국 기술 기업을 벗어나려 Hetzner Storage Box로 옮겼습니다. EU 거주자로서 합리적인 선택이라고 봅니다. restic 덕분에 전환은 간단했지만 데이터를 처음부터 다시 올리는 데 한 달이 걸렸습니다. Hetzner에 SFTP로 전송하면 멈추는 문제가 있었는데 restic의 전송 수단으로 rclone을 설정하자 해결된 듯합니다. 복원도 실제로 시험했습니다. 클라우드 인스턴스를 빌려 데이터를 다시 받고 일부를 확인하는 데 하루를 썼습니다. 파일이 괜찮아 같은 절차를 다시 실행할 수 있다는 자신감이 생겼습니다.
- @Semanticist — 직장에서는 tarsnap으로 백업했는데 안정적이고 저렴했지만 복원 속도가 매우 느렸습니다. 매일 복원 테스트에 20시간이 걸려 지속하기 어려웠습니다. restic과 Backblaze B2는 비슷한 수준으로 작동하면서 복원이 훨씬 빨라 Dropbox에서 파일을 내려받는 것보다 백업에서 복원하는 편이 빠를 정도였고, 결국 Dropbox도 없앴습니다. 집에서는 개인 이메일을 restic으로 Backblaze에, rsync로 Hetzner Storage Box에 백업하며 NAS도 Backblaze B2에 백업합니다. 저렴하고 안정적인 원격 백업을 손쉽게 쓸 수 있습니다. 일반 사용자에게 Dropbox 같은 서비스도 예전의 플로피 디스크나 USB 드라이브보다 큰 개선이고, 시스템을 조금 다룰 줄 아는 사람이라면 글의 구성은 견고하고 저렴합니다.
- @atmosx — 올해 초 계산했을 때 B2와 Google Storage 같은 서비스는 5TB 정도까지 NAS와 HDD를 백업용으로 사는 것보다 저렴했습니다. 8~10TB 이상이면 로컬 저장 장치가 비용 면에서 유리합니다. B2 가격대와 비슷한 서비스를 운영하는 업체 대부분은 적자를 내고 있을 것 같습니다. 5TB 원격 백업의 실제 비용은 더 높다는 뜻입니다.
- @spookylukey — 암호 관리자에 암호를 보관하고 출력물도 따로 두라는 조언이 중요합니다. 원격 백업이 필요한 큰 재난은 집이나 사무실 화재, 로컬 장치와 중요 문서 도난입니다. 복호화 키를 로컬에만 보관하면 원격 백업을 쓸 수 없습니다. 키를 보관할 세 번째 물리적 장소가 없다면 원격 백업도 로컬 백업만 있는 셈으로 봐야 합니다. 그래서 원격 백업에 별도의 암호화를 추가하지 않습니다.
- @oneirine — 작성자가 Backblaze 자체 백업 제품 대신 B2와 restic을 선택한 이유가 궁금합니다. Backblaze가 암호화 키를 볼 수 없게 하려는 이유로 보이지만 다른 이유도 있는지 묻습니다.
- @rkaw92 — Backblaze 백업 앱은 데스크톱용이고 서버에는 맞지 않는 것 같습니다. Linux 버전도 없습니다. Windows 사용자는 무제한 상품을 쓰지만 Linux 사용자는 용량에 따라 요금을 냅니다.
- @oneirine — Linux를 지원한다고 생각했는데 확인해봤어야 했습니다.
- @TFL — restic은 여러 저장소를 지원한다는 점이 좋습니다. 비슷한 구성을 사용했는데 하나의 설정으로 로컬 SSD, Odroid HC2, B2에 모두 백업할 수 있었습니다.
- @riking — "백업은 최소 두 가지 형식으로 보관합니다."
원문: chuck.is / 번역·요약: Trawling