☰

ZFS 전체 스냅샷 보내기/받기

tag-icon • tag-icon linux filesystems zfs snapshot replication
ZFS 전체 스냅샷 보내기/받기

저는 서버 A의 ZFS 풀을 서버 B(백업 서버)로 백업하고 zfs send/recv일일 증분 스냅샷을 사용해 왔습니다.

서버 B는 백업 서버 역할을 하며 서버 A와 서버 C에 대해 각각 2개의 풀( zfs41및 zfs49/tank)을 예약합니다.

하드웨어 문제로 인해 이제 서버 A의 ZFS 풀이 사라졌습니다. 최대한 빨리 복원/복구하고 싶습니다.

현재 내 서버 B의 스냅샷 목록은 다음과 같습니다.

NAME                        USED  AVAIL     REFER  MOUNTPOINT
zfs41@2021Nov301205        14.9G      -     3.74T  -
zfs41@2021Dec011205        3.87G      -     3.74T  -
zfs41@2021Dec021205        3.77G      -     3.74T  -
zfs41@2021Dec031205           0B      -     3.74T  -
zfs49/tank@2021Nov301705   368G      -     3.52T  -
zfs49/tank@2021Dec011705  65.2G      -     3.52T  -
zfs49/tank@2021Dec021705  66.4G      -     3.52T  -
zfs49/tank@2021Dec031705     0B      -     3.52T  -

zfs49/tank@2021Dec031705서버 B의 최신 버전은 어디에 있나요?

전체 풀(스냅샷 포함)을 서버 A로 다시 보내고 싶지만 실행할 정확한 명령을 모르겠습니다.

질문: 서버 B에서 zfs send zfs49/tank@2021Dec031705 | ssh <Server A host ip> zfs recv tank전체 ZFS 풀과 서버 A의 모든 스냅샷을 수신하기에 충분합니까(그래서 증분식 백업을 계속 보내고 받을 수 있습니까?)

답변1

먼저 서버 A에 빈 풀을 만들어야 합니다. zfs recv새 풀을 생성할 수 없습니다. 따라서 서버 A에서는 다음과 같습니다.

zpool create -R /mnt zfs49 [ mirror diskID1 diskID2 ]

...또는 원하는 다른 VDEV 구조. 서버 A의 VDEV 구조는 손실된 풀의 이전 구조와 일치할 필요가 없습니다. 데이터를 담을 수 있을 만큼 충분히 크면 됩니다. 따라서 지난번 선택에서 경험을 얻었다면 이번에는 풀을 만들 때 더 나은 선택을 하시기 바랍니다. 하지만 그렇습니다. 4k 기본 드라이브를 사용하는 경우에도 기다려야 합니다 ashift=12.

또한 아래 설명을 통해 풀 이름과 파일 시스템 이름이 동일하다는 것을 이해하므로 zfs49서버 B의 풀 파일 시스템을 서버 A의 풀 파일 시스템으로 복원합니다.tankzfs49tank

각 파일 시스템을 명시적으로 전송하는 것보다 를 사용하여 recursive snapshot모든 파일 시스템과 해당 스냅샷을 포함하여 전체 풀을 전송하는 방법을 설명하는 것이 더 유리할 수 있습니다.

위의 서버 A에 빈 풀을 생성한 후 다음 단계는 서버 B에 최신 재귀 스냅샷을 생성하는 것입니다. 이 스냅샷은 주로 일회성 복구 작업을 위한 것이므로 이름 지정 체계와 일치할 필요는 없습니다 YYYYMonDDHHMM. 실제로 이 복구 작업 스냅샷은 수명이 짧을 가능성이 높으므로 다른 작업 스냅샷과 구별하는 것이 도움이 될 수 있습니다.

xfer이 일회성 전송의 특정 목적을 위해 서버 B에서 재귀 스냅샷을 생성하고 이름을 으로 지정하는 것이 좋습니다 . 따라서 서버 B에서는 다음과 같습니다.

zfs snap -r zfs49@xfer

이제 Server A 에 명명된 원시(빈) 풀이 있으므로 zfs49이 재귀 스냅샷을 서버 B에서 서버 A(서버 B에서 시작)로 전송할 수 있습니다.

zfs send -R zfs49@xfer | ssh <Server A ip> zfs recv -Fuv zfs49

나는 다음과 같은 이유로 -Fuv옵션을 많이 사용하는 경향이 있습니다 zfs recv.

  • -u새로 복구된 파일 시스템을 서버 A에서 (일시적으로) 마운트 해제된 상태로 두겠다고 확인했습니다. ZFS한 시스템에서 다른 시스템으로 풀을 전송하고 기존 장착 지점을 파괴(덮어쓰기)할 때 문제가 발생하기 쉽습니다. 단계 -R /mnt에 있는 옵션 도 zfs create이를 방지하기 때문에 '멜빵과 벨트'의 경우일 수도 있지만, 백업을 옮기고 복원할 때 너무 조심하기는 어렵다.
  • -v완료된 각 스냅샷이 차례로 나열되므로 작업이 어떻게 진행되고 있는지 피드백을 주세요.

zfs진행률 표시기의 경우 전송이 Andrew Wood의 강력한 파이프라인 뷰어를 활용할 수 있는 좋은 기회라는 것을 알 수도 있습니다 pv(1).

(서버 B에서:)

zfs send -R zfs49@xfer |
  pv -Wbraft |   
  ssh <Server A ip> zfs recv -Fuv zfs49/tank

조정pv옵션당신의 취향과 필요에 맞게.

전송이 완료되면 서버 A의 풀을 확인하고 특히 마운트 지점에 주의를 기울이십시오. 구문 /mnt에 따라 마운트 지점이 zpool create ...접두어로 붙는다는 점을 기억하십시오. 원하는 경우 (서버 A에서) 다음을 수행할 수 있습니다.

zpool export zfs49
zpool import -N zfs49
zfs list

이렇게 하면 풀을 가져와 기본 마운트 지점을 표시하지만 명령에서는 실제로 아무것도 설치하지 말라고 zpool import -N지시합니다 . zpool이는 풀의 장착 지점이 실제로 어디에 있는지 나란히 비교하는 데 도움이 됩니다. 풀의 마운트 지점이 서버 A의 기존 마운트 지점을 덮어쓰지 않는지 확인하십시오. 그렇지 않으면 잠재적으로 중요한 파일 시스템에 액세스하지 못할 수 있습니다. 이 사용은 새로 생성된 파일 시스템이 잘못된 위치에 마운트되는 위험을 최소화하기 위한 시도로 zpool import -N위에 설명된 사용과 일치합니다 .zpool recv -u

마지막으로, 서버 A의 풀 모양이 만족스러우면 xfer두 시스템 모두에서 스냅샷을 제거할 수 있습니다. 서버 A에서:

zfs destroy -rv zfs49@xfer
ssh <Server B> zfs destroy -rv zfs49@xfer

좋은 해결책이 없는 한 가지 주의 사항은 풀 자체의 속성을 백업하고 복원하는 것이 간단하지 않다는 것입니다. 즉, zpool대신 읽기 및 쓰기 옵션을 전달해야 합니다 zfs. 여기에는 , 및 bootfs기타 모든 유용한 정보가 포함됩니다. zpool get all zfs49대부분의 기본값은 합리적일 수 있으며, 과거에 기본값을 변경한 경우 해당 기본값을 인식하고 필요에 맞게 서버 A의 새 풀에서 속성을 수동으로 변경할 수 있기를 바랍니다. 그렇지 않으면 풀 속성을 백업하고 복원하는 방법에 대한 주제가 아직 질문되지 않은 경우 자체 질문을 받을 자격이 있을 수 있습니다.

관련 정보