증분 오프사이트 백업을 위해 Btrfs Send 및 Receive를 구성하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Configure Btrfs Send and Receive for Incremental Off-Site Backups - Zima Store Online

Btrfs send와 receive는 읽기 전용 하위 볼륨 스냅샷을 효율적인 오프사이트 복제 체인으로 전환할 수 있습니다. 첫 번째 전송에서는 스냅샷 전체를 보냅니다. 이후 전송에서는 이전에 복제된 스냅샷을 상위 항목으로 사용하므로 새 스냅샷을 재구성하는 데 필요한 변경 사항만 네트워크를 통해 전송됩니다.

ZimaOS에서는 먼저 원본과 오프사이트 대상이 실제로 Btrfs 파일 시스템인지, 그리고 SSH 액세스가 가능한지 확인하세요. ZimaSpace의 최신 디스크 형식 가이드에는 BTRFS 읽기/쓰기 지원이 나와 있으며, ZimaOS SSH 가이드에서는 개발자 모드에서 터미널 액세스를 활성화하는 방법을 설명합니다.

시작하기 전에 백업 체인을 이해하세요

Btrfs send/receive는 하위 볼륨 복제이며 일반적인 디렉터리 복사 명령이 아닙니다. 원본은 Btrfs 하위 볼륨이어야 하며, 사용되는 모든 스냅샷은 btrfs send 읽기 전용이어야 합니다. 읽기 전용 마운트는 읽기 전용 하위 볼륨 스냅샷을 대신할 수 없습니다.

공식 btrfs send 문서에서는 두 가지 모드를 설명합니다. 전체 전송에는 스냅샷 전체가 포함됩니다. 증분 전송은 송신자와 수신자 양쪽에서 동일한 상태로 사용할 수 있는 스냅샷과 함께 -p 또는 -c를 사용합니다.

간단한 오프사이트 체인에서는 다음과 함께 명시적인 상위 항목 하나를 사용합니다. -p:

snapshot-A  --전체 전송-->  오프사이트 snapshot-A
snapshot-B  --send -p A-->  오프사이트 snapshot-B
snapshot-C  --send -p B-->  오프사이트 snapshot-C

다음 증분 전송이 완료되고 검증될 때까지 현재 상위 항목을 삭제하거나 수정하지 마세요.

원본이 Btrfs 하위 볼륨인지 확인

예시 경로를 시스템의 실제 마운트 지점으로 바꾸세요. 백업 스냅샷이 보호 중인 데이터 내부에 중첩되지 않도록 스냅샷 디렉터리는 라이브 원본 하위 볼륨 외부에 있어야 합니다.

findmnt -no FSTYPE --target /mnt/pool/data
sudo btrfs subvolume show /mnt/pool/data
sudo btrfs version

첫 번째 명령은 다음을 보고해야 합니다. btrfs두 번째 명령은 성공적으로 식별해야 합니다. /mnt/pool/data 하위 볼륨으로. 일반 디렉터리일 뿐이라면 여기서 중지합니다. btrfs send 임의의 디렉터리는 전송할 수 없습니다.

오프사이트 시스템에서 수신 위치에 대해 동일한 파일 시스템 검사를 실행합니다. btrfs receive 복제된 하위 볼륨을 Btrfs 파일 시스템에 생성해야 합니다.

백업 데이터를 스트리밍하기 전에 SSH 준비

오프사이트 전송 스트림은 바이너리 파일 시스템 데이터입니다. SSH는 전송 중 인증과 암호화를 제공하므로 실용적인 전송 수단입니다. 어느 엔드포인트에서든 ZimaOS를 사용하는 경우 먼저 SSH를 활성화하고, Btrfs 스트림을 시도하기 전에 일반 로그인을 테스트하세요.

ssh backup@backup.example.net

무인 작업에는 키 기반 SSH 인증을 사용하세요. 원격 계정에서도 다음을 실행할 수 있어야 합니다. btrfs receive 비대화식으로. 원격에서 sudo Btrfs 스트림과 동일한 표준 입력에서 비밀번호 프롬프트를 읽습니다. 필요한 수신 작업에만 범위를 제한한 권한 규칙이 광범위한 비밀번호 없는 루트 액세스보다 안전합니다.

대화형 관리 세션에서 대상 디렉터리를 생성합니다.

ssh -t backup@backup.example.net \
  'sudo mkdir -p /mnt/backup/btrfs-recv'

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

첫 번째 읽기 전용 스냅샷 생성

라이브 소스 서브볼륨의 변경되지 않는 읽기 전용 스냅샷을 생성합니다. -r 이 플래그가 중요한 이유는 Btrfs 증분 전송이 전송 작업 중 변경되지 않는 스냅샷에 의존하기 때문입니다.

sudo mkdir -p /mnt/pool/.snapshots

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260831-1000

전송하기 전에 속성을 확인합니다.

sudo btrfs property get \
  /mnt/pool/.snapshots/data-20260831-1000 ro

예상 결과는 다음과 같습니다. ro=true.

초기 전체 스냅샷을 오프사이트로 전송

첫 번째 전송에는 상위 항목이 없으므로 전체 전송입니다. Bash 호환 셸에서 다음을 활성화하면 pipefail 파이프라인 양쪽에서 발생한 오류가 호출 셸에 표시됩니다.

set -o pipefail

sudo btrfs send \
  /mnt/pool/.snapshots/data-20260831-1000 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

다음인 경우 sudo -n 원격 호스트에서 실패하면 재시도하기 전에 원격 권한 설정을 수정하세요. 스트리밍 파이프라인 내부에서 비밀번호 프롬프트를 표시하는 방식으로 대체하지 마세요.

공식 btrfs receive 문서에는 성공적으로 수신된 서브볼륨이 읽기 전용이 된다고 나와 있습니다. 또한 스트림이 적용되는 동안 사용자가 수신 경로를 수정해서는 안 된다고 경고합니다.

상위 항목으로 사용하기 전에 수신된 스냅샷 확인

SSH 세션이 종료되었다고 백업 체인이 정상이라고 가정하지 마세요. 두 스냅샷을 모두 검사합니다.

sudo btrfs subvolume show \
  /mnt/pool/.snapshots/data-20260831-1000

ssh backup@backup.example.net \
  'sudo -n btrfs subvolume show \
  /mnt/backup/btrfs-recv/data-20260831-1000'

송신 측에서 스냅샷을 확인합니다. UUID. 수신 측에서 복제된 서브볼륨은 해당 소스 식별자를 다음으로 표시해야 합니다. 수신된 UUID. 또한 수신된 서브볼륨이 읽기 전용인지 확인합니다.

이 확인을 마친 후에만 data-20260831-1000 다음 증분 백업의 상위 항목이 됩니다.

다음 증분 스냅샷 생성 및 전송

실시간 데이터가 변경된 후 새 읽기 전용 스냅샷을 생성합니다.

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260901-0200

그런 다음 이전 스냅샷 이후의 변경분만 전송합니다.

set -o pipefail

sudo btrfs send \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

첫 번째 전송의 부모 스냅샷이 두 시스템에 일치하는 형태로 여전히 존재하기 때문에 이 작업이 가능합니다. 새 스냅샷이 성공적으로 수신되고 확인되면, data-20260901-0200 다음 실행의 부모가 될 수 있습니다.

부모 스냅샷을 동일하게 유지

증분 체인을 손상시키는 가장 일반적인 방법은 부모로 사용 중인 스냅샷의 읽기 전용 상태나 내용을 변경하는 것입니다. Btrfs는 발신자와 수신자가 대응하는 기록을 식별할 수 있도록 수신된 스냅샷을 수신된 UUID로 추적합니다.

서브볼륨 플래그와 수신된 UUID에 관한 공식 Btrfs 안내에서는 수신된 스냅샷을 읽기 전용에서 읽기-쓰기로 변경하면 증분 전송에서 사용하는 전제가 깨진다고 경고합니다.

따라서 오프사이트 수신 스냅샷은 파일을 탐색하거나 복원하거나 편집하기 위해 쓰기 가능 상태로 변경하지 마세요. 쓰기 가능한 복구 사본이 필요하다면 보호된 수신 스냅샷에서 별도의 스냅샷을 생성하세요.

sudo btrfs subvolume snapshot \
  /mnt/backup/btrfs-recv/data-20260901-0200 \
  /mnt/restore/data-20260901-0200

새 복원 스냅샷은 기본적으로 쓰기 가능하지만, 원본 수신 스냅샷은 이후 증분 전송을 위해 그대로 유지됩니다.

안전한 스냅샷 보존 규칙 사용

오래된 스냅샷을 모두 영원히 보관할 필요는 없지만, 다음 전송에 필요한 부모 스냅샷은 두 시스템 모두에 보관해야 합니다. 간단한 순환 규칙은 다음과 같습니다.

새 읽기 전용 소스 스냅샷을 생성합니다.
이전의 성공한 스냅샷을 사용하여 전송합니다. -p.
새 오프사이트 수신 스냅샷을 확인하세요.
새 스냅샷을 다음 부모로 승격하세요.
그런 다음에만 보존 정책에 따라 오래된 복구 지점을 삭제하세요.

여러 개의 과거 스냅샷을 보관하면 유용한 롤백 지점을 제공할 수 있지만, 동일한 파일 시스템에 있는 스냅샷은 독립적인 백업이 아니라는 점을 기억하세요. 오프사이트 복제본은 별도의 시스템과 위치에 또 다른 사본을 저장하므로 중요합니다. ZimaSpace의 3-2-1 백업 가이드에서는 오프사이트 사본이 로컬 이중화로는 대비할 수 없는 장애를 어떻게 막아 주는지 설명합니다.

중첩된 Btrfs 서브볼륨을 별도로 처리하세요

Btrfs 스냅샷은 중첩된 서브볼륨 전체에 재귀적으로 적용되지 않습니다. 다음의 경우 /mnt/pool/data 다른 서브볼륨을 포함하는 경우, 상위 스냅샷에는 중첩된 데이터의 전체 스냅샷이 아니라 서브볼륨 스텁이 포함됩니다.

백업 계획을 확정하기 전에 서브볼륨을 나열하세요.

sudo btrfs subvolume list /mnt/pool

중요한 애플리케이션 데이터가 중첩된 서브볼륨에 있다면, 각 서브볼륨에 대해 별도의 읽기 전용 스냅샷 체인을 생성하고 복제하세요.

-p와 -c 중 언제 사용할지 알아보기

선형 백업 기록의 경우 -p 가장 단순하고 감사하기 쉬운 옵션입니다. -c 옵션을 사용하면 Btrfs가 추가 스냅샷의 일치하는 익스텐트를 재사용할 수 있도록 하나 이상의 클론 소스를 추가할 수 있지만, 이러한 클론 소스도 양쪽 끝에 정확히 동일한 상태로 존재해야 합니다.

클론 소스가 변경되지 않았고 양쪽 시스템에 모두 존재한다는 점을 입증할 수 없다면 사용하지 마세요. 오프사이트 백업 작업에서는 단일 상위 스냅샷 체인이 일반적으로 더 안전합니다.

선택 사항: 압축된 익스텐트에 프로토콜 2 사용

충분히 최신 버전의 Linux 및 btrfs-progs에서는 Btrfs send 프로토콜 2가 압축된 익스텐트를 사용해 더 효율적으로 전송할 수 있습니다. --compressed-data공식 send 문서에 따르면 프로토콜 2를 사용하려면 송신 측과 수신 측 모두에 btrfs-progs 6.0 이상이 설치되어 있어야 하며, 송신 측에서는 Linux 6.0 이상이 필요합니다.

sudo btrfs send \
  --proto 2 \
  --compressed-data \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

옵션이 존재한다는 이유만으로 이를 활성화하지 마세요. 먼저 양쪽 엔드포인트의 버전을 확인하고, 최적화보다 호환성이 중요하다면 기본 프로토콜을 사용하세요.

일반적인 증분 전송 및 수신 실패 문제 해결

send 명령에서 스냅샷이 읽기 전용이 아니라고 표시됩니다

다음 명령으로 스냅샷을 다시 생성하세요 btrfs subvolume snapshot -r쓰기 가능한 스냅샷을 읽기 전용 마운트로 마운트하는 것만으로는 전송 요구 사항을 충족하지 못합니다.

증분 전송에서 상위 스냅샷을 찾거나 사용할 수 없습니다

송신 측에 정확히 일치하는 상위 스냅샷이 여전히 존재하고, 수신 측에도 그에 대응하는 수신된 스냅샷이 여전히 존재하는지 확인하세요. 어느 한쪽의 상위 스냅샷이 삭제되었거나 변경되었거나 쓰기 가능 상태가 되었다면, 가지고 있는 경우 일치하는 상위 스냅샷을 복원하세요. 그렇지 않다면 새로운 읽기 전용 스냅샷을 생성하고 전체 시드 전송을 새로 시작하세요.

btrfs receive에서 대상 서브볼륨이 이미 존재한다고 표시됩니다

btrfs receive 은 동일한 수신 이름을 가진 기존 서브볼륨을 덮어쓰지 않습니다. 먼저 기존 서브볼륨을 검사하세요. 수신이 실패했거나 불완전하며 삭제해도 안전하다는 것을 확인했다면, 동일한 전송을 재시도하기 전에 해당 불완전한 서브볼륨을 삭제하세요.

수신 상위 스냅샷이 도착한 후 변경되었습니다.

변경된 스냅샷을 새 증분 스트림의 기반으로 사용하지 마세요. 변경되지 않은 일치하는 수신 상위 스냅샷이 없다면 새 전체 백업 체인을 시작하세요.

중첩된 디렉터리 내부의 파일이 스냅샷에서 누락됩니다.

해당 디렉터리 자체가 Btrfs 서브볼륨인지 확인하세요. 중첩된 서브볼륨은 상위 스냅샷에 재귀적으로 포함되지 않으므로 자체 send/receive 체인이 필요합니다.

전송 중 WAN 또는 SSH 연결이 끊깁니다.

성공적으로 완료되고 결과 서브볼륨이 올바르게 검증될 때까지 receive가 실패한 것으로 간주하세요. 문서화된 Btrfs send/receive 명령 인터페이스는 스트림 재개 옵션을 제공하지 않습니다. 신뢰성이 낮은 장거리 연결에서는 send 스트림을 스테이징 파일에 기록하고, 재개 가능한 전송 방식으로 해당 파일을 전송한 다음, 완료된 신뢰 파일을 에 입력하는 방법을 고려하세요. btrfs receive.