▲

나만의 백업 시스템 만들기 – 1부: 스크립트 이전의 전략

 (it-notes.dragas.net)
2P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • 백업의 중요성이 종종 과소평가되는 현상이 많음
  • 많은 이들이 클라우드 의존에 안주하며 데이터 보호의 책임을 인식하지 못함
  • 백업 계획을 세우지 않고 단순 복사에 의존하면 높은 위험을 초래함
  • 디스크 전체 또는 개별 파일 백업 방식에는 각각 장단점이 존재함
  • 신뢰할 수 있는 백업은 스냅샷 활용과 외부 저장소 확보가 핵심 요소임

백업의 중요성과 현실

  • 백업은 많은 사람들이 심각하게 생각하지 않는 영역임
  • 잘못된 방법이나 개념적 오류(예: RAID는 백업이 아님)로 인해 수많은 데이터가 손실됨
  • 데이터는 반드시 다양한 방식으로 보존되어야 하는 중요한 자산임

클라우드와 백업에 대한 오해

  • 클라우드에 모든 데이터를 맡기면서 실제로 데이터가 어떻게 보호되는지 묻지 않는 경우가 많음
  • 주요 클라우드 제공업체도 공유 책임 모델을 적용함
    • 인프라의 보안은 제공하지만 데이터 보호 책임은 사용자가 짐
  • 클라우드, 사설 서버, Kubernetes 등의 환경에서도 백업 부재 위험이 빈번함

필자의 데이터 복구 경험

  • 데이터센터 화재, 서버실 침수, 지진, 랜섬웨어, 악의적 공격, 관리자 실수 등 여러 데이터 손실 사례를 겪음
  • 인터넷에 연결된 서버(이커머스, 메일 등)는 데이터 무결성과 서비스 연속성 모두가 중요함
  • 백업은 단순 복사가 아님. 특히 동작 중인 데이터베이스 파일을 복사하는 것은 복구 불가 가능성을 높임

백업 전략 수립의 필수 질문

  • "얼마나 많은 위험을 감수할 것인가?", "어떤 데이터를 보호해야 하는가?", "데이터 손실 시 허용할 다운타임은?", "사용 가능한 저장 공간은?"
  • 백업을 동일한 머신에 두는 방식은 머신 장애 시 쓸모없음. 외부 저장소로의 백업이 안전함
  • 네트워크 대역폭, 복구 속도, 저장 공간 등 현실적 요소도 고려해야 함

디스크 전체 vs 파일별 백업

디스크 전체 백업

  • 장점
    • 완전 복구 가능. 시스템을 이전 상태로 신속하게 복구할 수 있음
    • 가상화 시스템과 결합시 유용. Proxmox 등은 이러한 전체 백업을 쉽게 지원함
    • 일부 솔루션은 전체 백업에서 개별 파일 복구도 지원함
  • 단점
    • 물리 서버의 경우 다운타임이 필요함
    • 공간 소모가 큼, 불필요한 데이터까지 저장됨
    • 파일시스템 특성에 따라 느리거나 호환성 문제가 발생할 수 있음

개별 파일 백업

  • 장점
    • 시스템 기본 유틸리티(tar, cp, rsync 등)로 가능
    • 변경분만 백업해 공간과 전송량 절감 가능
    • 개별 복구, 이동, 압축 및 중복제거 등 유연성 확보
    • 시스템 중단 없이 운용 가능
  • 단점
    • 단순 복사는 저장 공간을 많이 요구
    • 스냅샷 없이 동작 중인 파일 시스템을 백업하면 불일치·오류가 발생할 수 있음

스냅샷을 활용한 백업

  • 백업 대상이 동작 중인 파일 시스템일 때, 백업 "시작"과 "종료" 사이에 데이터가 변경될 수 있어 데이터 일관성이 깨짐
  • MySQL, 브라우저 히스토리 등 열려있는 데이터베이스는 파일 복사만으로 복구가 불가능한 경우가 발생함
  • 일관성 있는 백업을 보장하려면, 파일 시스템의 스냅샷 기능을 먼저 활용해야 함
  • 대표적인 방법
    • 네이티브 파일시스템 스냅샷(BTRFS, ZFS 지원 시스템)
    • LVM 스냅샷: 공간 낭비 및 스냅샷 삭제 시 시스템 중단 가능성 존재
    • DattoBD: 안정성 이슈가 간혹 발생하나 UrBackup 등과 조합해 활용 가능

백업 방식: Push vs Pull

  • Push: 백업 대상이 서버에 접속해서 데이터를 보냄
  • Pull: 중앙 백업 서버가 각 서버에 접속하여 백업을 수행함
  • 보안상 백업 서버는 외부 접속을 차단하고 필요할 때만 클라이언트에 접근하는 Pull 방식이 더 안전함
    • 침입, 랜섬웨어 발생 시 백업 데이터 삭제를 방지하기 위해, 백업 서버 자체의 스냅샷도 별도로 장기간 보관함

추천 백업 시스템의 주요 특징

  • 즉각 복구 및 고속 처리
  • 외부 저장소에 보관(단, 로컬 스냅샷은 즉시 롤백용으로 유지)
  • Google Drive, Dropbox 등 상용 클라우드 미사용 권장. 데이터는 스스로 보유해야 함
  • 압축, 중복제거 등 효율적 공간 관리
  • 동작에 필요한 추가 구성요소가 최소화되어야 함

향후 연재 계획

  • 다양한 백업 시나리오 및 실제로 사용하는 서버, 주요 세팅, 각종 소프트웨어 및 기술을 소개할 예정임
  • 다음 연재에서는 FreeBSD 기반 백업 서버 구축 방법을 다룰 예정임
▲
GN⁺ 9시간전  [-]
Hacker News 의견

  • 백업을 반드시 ‘푸시’ 방식으로 해야 하는 머신들은 자기 공간만 접근 가능하도록 제한함이 필요함, 그리고 더 중요한 점은 백업 서버가 보안을 위해 자체 파일시스템 스냅샷을 일정 기간 유지함임, 그래야 워크로드가 손상되고 백업 서버에 접근해 랜섬 요구를 위해 백업을 지운 최악의 상황이라도 서버에 스냅샷이 남아 있음, 내가 선호하는 방법은 클라이언트에게는 새 백업만 기록하고 삭제는 아예 못 하게 함이며, 삭제는 별도 절차(수동 또는 cron 등)로 처리함, 이런 방식은 rsync/ssh에서 .ssh/authorized_keys의 allowed command 기능으로 구현 가능함

    • 나는 두 가지 모두 활용함, 백업을 두 군데에 보관해야 하긴 하지만, 이 듀얼 백업 구조를 원래 추구했음, 백업 소스들은 중간 위치로 푸시하고, 주요 백업 저장소가 거기서 풀함, 중간 위치가 작은 용량으로 스냅샷 보관은 하나 주요 스토리지와 소스는 서로 아예 인증이 안 됨, 즉 각각 중간 위치만 인증 가능하며 역방향 인증도 없음, 이 3군데 중 한두 군데가 해킹당해도 나머지는 안전할 가능성 높음, 인증서 백업은 완전히 별도 처리해서 인터넷 연결 서버에 전부 저장되는 일 없게 함, 진짜 중요한 데이터는 추가 조치로 오프라인 백업까지 이중, 구조 분리로 실제 백업 검증이 번거롭긴 한데, 백업 스토리지는 주기적으로 체크섬을 검증해 그 결과를 중간 호스트에 보내고, 원본 호스트에서 생성한 해시와 비교하면서 손상 이벤트를 잡음, 이렇게 세팅한 결과 소스에서 백업 스냅샷 자체를 직접 해칠 수 없는 일종의 ‘소프트 오프라인’ 백업 구현임

    • 별도의 컨테이너 또는 백업 전용 유저를 써보는 것도 한 방법임, systemd-nspawn을 예시로 들면 경량 chroot jail처럼 사용 가능하며 내부에선 rm 실행 자체를 막을 수 있음, 간단히 pacman/pacstrap 등으로 chroot 만들고, systemd-nspawn/my machinectl로 관리, 이 방식은 평소 systemd와 별 차이 없이 접근제어, 파일 경로 제한, 메모리/CPU 제한, 특정 IP 대역만 접근 허용, 부팅 조건 세분화 등 다양한 컨트롤이 가능해서 유연함, BTRFS 서브볼륨 등도 활용하며, 필요하다면 시스템 전체를 systemd-vmspawn으로 완전히 분리 가능함, importctl로 복제 자동화도 매우 편함

    • 나는 “백업 서버가 백업 대상 서버에 대한 권한이 전혀 없는” 풀 방식 선호함, 라이브 서버가 루트권한을 해킹당해도 백업 시스템에는 영향 없음

    • 백업에 rclone copy를 사용하고 있는데, 오브젝트 삭제 권한이 없는 API키만 씀, rclone sync처럼 동기화하면 지워버릴 수도 있으니 이 방식이 더 안전함

    • syncoid에도 “클라이언트는 스냅샷/백업만 복사하고 삭제는 백업 서버가 직접 관리”하는 옵션이 있었으면 좋겠음, 현재는 삭제 권한을 줘야 해서 아쉬움

  • 놀라울 정도로 많은 사람들이 백업을 중요시하지 않음, 크고 작은 기업들 모두 마찬가지임, 내가 컨설팅하는, 연 매출 10억 유로 회사도 자체 백업이 없었고, 데이터센터 사업자가 불규칙하게 하는 디스크 카피에만 의존함, 복구 테스트도 스스로 해본 적 없음, 얼마 전 사용자 실수로 프로덕션 DB가 완전히 날아갔고, 최신 백업이 4일 전 거라 그 간의 트랜잭션을 모두 재현해야 했음, 그런데 이런 사고가 있었는데도 아무도 충격도 받지 않았고 그냥 평상시처럼 지나갔음

    • 이게 비즈니스에 정말 치명적이지 않은 한 괜찮다고 생각하는 듯함

    • 백업 요건을 과도하게 복잡하게 만드는 것도 흔히 본 현상임

    • 혹시 법적 이슈 때문일 수도 있음, 소송 혹은 법적 보존 의무 때문에 백업 자체가 오히려 위험 요소가 될 수도 있음

    • soc2 감사를 받은 재해복구 정책의 부작용임, 내가 근무한 회사도 모든 팀의 재해복구 정책(모두 soc2 승인)을 점검했는데, 결론적으로 진짜 대형 사고가 나면 회사를 접고 집에 가는 게 정상 복구보다 빠르겠단 결론에 도달함

    • 프로덕션 DB 전체 4일 데이터 손실이 진짜 사실이라면 고객이 화가 나지 않았겠냐고 묻고 싶음, 그 규모 회사에선 현실적으로 엄청난 타격이 될 것 같아서 실제로 어떻게 처리했는지 궁금함

  • 내용 공유에 감사함, 10년째 백업·재해복구 소프트웨어를 개발하면서 늘 나오는 경구는 “친구에게 백업/재해복구 솔루션 직접 만들라고 안 함”임, BCDR 구축은 워낙 빠뜨리기 쉬운 함정이 가득함, 몇 가지 핵심 포인트를 공유해보고 싶음, 백업은 ‘재해복구’가 아님, 진짜 사고 나면 수분~수시간 내 바로 복구돼야 비즈니스 신뢰를 지킬 수 있음, 재해복구 시간(RTO)·복구지점(RPO)가 관건임, rsync copy 방식 파일 복제만으론 파일시스템이 계속 변화하므로 시점 백업이 아님, 제대로 된 시점 백업에는 ‘크래시 컨시스턴트’ 혹은 ‘애플리케이션 컨시스턴트’ 백업이 필요한데, 후자는 중요 애플리케이션이 디스크에 상태를 저장하고 백업 중엔 멈추는 설정임, Microsoft VSS 같은 기능이 이 부분을 제공함, rsync copy나 크래시 컨시스턴트 백업을 절대 맹신하면 안 됨, 저장장치엔 머피의 법칙이 항상 적용되니 여러 장소에 백업(3-2-1 전략)이 반드시 필요함, 직접 경험상 어떤 종류의 디스크든 전부 고장남, NVMe SSD > SSD > HDD 순으로 내구성이 낫긴 해도 예외 없음, 더 적고 싶은 게 많은데 시간이 늦어 여기까지만 남김

    • 3-2-1 비유는 예전 방식임, 요즘은 데이터 보관 위치가 무제한이므로 로컬 스냅샷, 원격 복제 및 서로 다른 방식의 이중, 삼중 백업이 더욱 중요함, zfs로 기본 스냅샷을 두고, Borg 추가로 사용 중이며 이 조합이면 거의 어떤 재해에도 충분함

    • 그 경구가 Alice in Chains 공연에서 비슷한 말을 들었을 때 떠오름, BCDR 솔루션은 기업 간 신뢰의 상징임, 이런 시스템들은 수십조~수백조 규모의 데이터를 보호하고, CTO라면 오픈소스 방식엔 절대 회사 백업을 맡기지 않음, 기업의 IT 지출은 대부분의 자산 가치 및 반vendor 락인 전략에 맞춰 점층적으로 증가함, 전문가 경험상 랜섬웨어 방지에선 불변성(immutability), WORM 백업이 핵심이며, 법규 미준수로 정부 IT에서 문제된 사례도 다수 경험함, BCDR 업체들은 랜섬웨어를 세일즈 포인트로 내세우지만, 진정한 불변성은 여러 공간에 걸친 데이터 복제에서 증명됨, 이때 3-2-1 전략이 진가를 발휘함, 더 많은 백업 원칙에 대해 의견 듣고 싶음

    • NAS를 사용하는 경우, 동일 제조사 동일 모델의 하드디스크를 양쪽에 쓰지 않는 게 좋음

    • “여러 장소에 백업 필수(3-2-1)”란 말에 완전히 동의함, 하지만 대부분의 개인에겐 “1”(오프사이트)이 현실적으로 불가능하며, 결국 백업 서비스를 쓰지 않는 이상 직접 백업할 이유가 없게 됨, 주변에 내 도시 외부에 24시간 컴퓨터 돌려주고 관리해줄 사람 없음

    • “rsync copy나 심지어 크래시 일관성 백업은 절대 신뢰해선 안 됨” 부분은, 결국 모든 시스템/서비스가 인프라 툴로 재구성 가능하니 DB와 파일/오브젝트 저장소만 적극적으로 백업하면 된다는 결론임, 복잡하게 VM 전체 백업하는 건 진짜 의미 없음

  • 깔끔한 글이지만 아쉬운 지점이 있음, 진짜로 좋은 백업 시스템이란 복구 속도와 절차가 명확해야 한다는 점임, 여러 번 경험한 건 백업 자체는 잘 돼 있다며 안심하다가 정작 복구 시 일부만 복구되거나 수 일 넘게 걸려 엄청난 손해가 발생하는 케이스임, restic이란 도구는 파일 단위 중복 제거된 스냅샷 백업이 가능해서 ZFS 같은 스냅샷 파일시스템 없을 때 유용함, 그리고 “푸시” 백업 방식일 때는 랜섬웨어가 백업까지 삭제할 수 있으니 “풀” 방식이 맞음, 푸시라면 읽기 전용 미디어(Bluray 등) 쓰거나 최소한 auto-snapshot/ZFS로 시점 복구가 가능해야 낫다고 봄

    • 랜섬웨어가 푸시 백업까지 삭제할 수 있다 해도, 서버 권한을 잘 제한하면 문제없음, Borg와 Restic은 ssh로 append-only 보장 가능하고, 로컬에서는 오프라인 백업 드라이브를 마지막 방어선으로 로테이션함, 실제 방법은 여기 참고

    • restic의 append-only 모드에서 주기적 서버 내부에서만 pruning한다면 pull 방식 안 써도 괜찮은지 궁금함, 이게 restic 공식 권장 랜섬웨어 방지법이라 알고 있음

    • “복구 속도”가 정말 요구사항에 따라 다름, 가족 사진 백업이 6개월 걸려도 난 괜찮음

    • 읽기전용 미디어 대신 권한을 제한한 push 서버도 대안임, 예를 들어 ssh를 scp만 허용, chroot 환경 한정, 매일 폴더 회전식으로 백업하면 랜섬웨어라도 예전 데이터 삭제 불가, 내 백업 절차도 chroot+scp만 허용하는 ssh 서버로 관리 중이며, 추가로 읽기전용 미디어도 병행함

  • 나는 별도의 백업 시스템이 필요한 건 아니고, 가족 4명의 25년치 사진(폰, 카메라, 다운로드, 스캔 등)을 효율적으로 모아놓는 표준화된 방식이 있으면 충분할 것 같음, 아직까지 만족스러운 방법을 못 찾음

    • 나는 NAS에 Immich를 올려서 사용 중이고, 미디어와 Immich DB dump를 매일 AWS S3 Deep Archive에 백업함, Immich는 Google Photos 기능도 충분히 제공하며, 데스크톱 사진/스캔을 NAS에 추가해두면 Immich가 자동으로 불러옴, HN 유저라면 세팅이 어렵지 않음

    • “25년치 사진”이 북미식 데이터 단위냐고 농담을 던지며, 사실상 백업 시스템이 반드시 필요하다고 지적함, 나는 syncthing을 gnu/linux/windows/android에서 메쉬로 굴리고, 두 개의 데비안 VM에 아카이브를 정기적으로 스냅샷하고 borgbackup으로 2차 백업함, RPO는 24시간이지만 원하면 더 줄일 수 있음, 다만 애플 기기는 syncthing 백그라운드 동작이 막혀서 이 구성이 안 맞음, 내 경우는 사진 500GB, 기타 문서도 수십~수백GB지만 diff 기반 백업 덕분에 효율적임

    • 다운로드, 스캔은 진짜 중요하지 않으면 어차피 버릴 데이터임, 폰/카메라는 Nextcloud로 싱크하고, 자체 홈 네트워크로만 백업 동작시킴, 그 후 NAS에서 매일 백업 후 건강 체크, 마지막 단계는 신뢰할 만한 클라우드 백업 또는 다른 집 드라이브 활용, 이러면 2차 백업까지 완성임

    • PhotoPrism 또는 Immich 같은 셀프호스팅 솔루션이 사진 중복 제거와 검색/태깅에 유용함, 클라우드 백업은 Backblaze B2 + Cryptomator 조합으로 암호화 스토리지와 DIY 업로드 스크립트 사용 가능, TB당 월 1달러 수준임

    • 나는 syncthing을 쓰는데, 공식적으로 Android 미지원이지만 포크 버전을 쓰면 잘 동작함, 추가로 ente.io 또는 immich 셀프호스팅으로 사진 백업 권장, 문서는 paperless ngx 등 따로 관리함이 좋음

  • Dirvish는 꼭 한 번 써볼 만한 경량 rsync 래퍼로, 회전, 증분, 보존, 전/후처리 스크립트 등 훌륭한 기능을 제공함, 20년 넘게 내 데이터 생명을 구해줬음, 기사에서 제기한 점들과도 궁합이 매우 좋음, dirvish 공식 사이트, rsync 공식 사이트

    • dirvish는 rsync 대비 어떤 점이 더 쉽거나 뛰어난지 궁금함

  • 나는 썩 게으른 방식으로도 하드웨어 고장, 도난 이슈까지 전부 대응해봄, 데스크톱 내부 임시 저장, 집안 외장 디스크, 오프사이트 외장 디스크(전부 Samsung T7 Shield) 조합임, robocopy /MIR로 매일 임시 또는 작업 후 복제, 주 1회 외장에 백업, 한 달에 한 번 외장 오프사이트 교환함

    • 외장 디스크는 반드시 적어도 서로 다른 배치나, 더 나아가 다른 모델을 써야 함, 같은 모델·로트면 보통 동시에 고장날 확률 높음(특히 복구에 왕창 부하가 걸릴 때)

  • 타이밍이 좋아 내 archlinux 설정과 백업 전략을 공유함, 설정/백업 자동화 스크립트, borg 자동화 레이어도 공개함

    • 나는 python+b​​org로 SAN의 51 블록 디바이스 스냅샷, 71개 파일 시스템 백업, S3 싱크까지 자동화함, 복구는 오프사이트에서 실제 테스트했고 VM 부팅까지 문제 없이 성공했음, 자동화가 아직 복잡하고 미완성이라 복구 속도는 느리지만 아주 저렴하게 구축했음, borg 진짜 강력함, 이런 건 누구나 시도할 수 있고 결과적으로 매우 경제적임

  • 내가 가진 귀중한 데이터는 100MiB 미만이라, 선택된 경로만 tar+압축+암호화해서 한 주에 두 번씩 백업, 몇 달치만 로테이션 보관함, 집 안팎에 두며 점검이나 유지 보수도 거의 필요 없음, 몇 줄짜리 sh 스크립트만으로 문제없이 자동화되는 무난한 구성임

    • 내일 갑자기 내가 죽는다면 가족과 후손이 꼭 복구할 가치가 있는 데이터가 뭔지 돌아봐야 함, 수십만 개 파일보단 핵심적인 사진, 영상, 텍스트 몇 개면 충분할 수도 있음

    • 이 댓글이 나에게 진짜로 귀중한 데이터가 뭔지 다시 고민하게 했음, 내 사진은 압축해도 최소 수 GB, 연락처나 중요하지 않은 건 작음, 대체로 다른 건 잃어도 괜찮음, 복구키는 좀 더 안전하게 보관해야겠지만 가장 중요한 계정들은 오히려 복구키가 없음, 사진만도 2TB 가까이 됨(취미 사진가의 비애)

  • 백업 일관성에서 가장 어려운 점은, 어플리케이션 데이터를 서비스 다운 없이 일관되게 백업하는 게 사실상 불가능하다는 점임, 디스크 스냅샷으론 순간에 어떤 서비스가 mid-write인 상태에서 스냅샷될 수밖에 없어서, 복구 시 손상된 상태로 뛰어들 확률이 큼, DB 덤프는 이 문제를 상당부분 완화하지만, 종종 서비스 밖에서 백업해야 해서 쿼리 도중일 수 있음, 누가 그 부분에 대한 노하우 있으면 듣고 싶음

    • 대체로 DB는 이 부분에 견고해서 언제든 디스크 스냅샷 떠도 백업용으론 충분하다고 봄, 걱정되는 건 배터리 없는 캐시 등 특수 상황인데, 요즘 클라우드 등은 그런 구조가 거의 없어 별 문제 없음

    • DB 외에도 캡처해야 할 어플리케이션 상태가 더 있는지에 따라 전략이 다름(예를 들어 캐시도 백업해야 하는지 등), pg_dump/mysqldump가 실제로 라이브 DB 스냅샷을 안전하게 가능하게 하지만, 좀 느리고 덤프 용량이 커지는 등의 부담이 있음, 이 문제를 피하려면 큰 PostgreSQL DB엔 백업 전용 read-only replica를 두고 replication 멈춘 뒤 백업 실행, 이후 replication을 재개하는 방식도 경험함

답변달기