스냅샷 복제가 대상 풀을 가득 채우지 않도록 방지하는 방법

에바 왕

IceWhale author

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

How to Prevent Snapshot Replication From Filling the Destination Pool

보존된 스냅샷과 변경된 블록이 대상의 정리 정책이 해제할 수 있는 속도보다 빠르게 누적되면 스냅샷 복제로 대상 풀이 가득 찰 수 있습니다.

이를 예방하려면 소스 보존 기간, 대상 보존 기간, 복제 주기, 여유 공간 알림을 하나의 정책으로 설계해야 합니다. 복제본이 소스보다 더 많은 기록을 유지하는 것은 정당할 수 있지만, 그 선택에는 한계가 있어야 합니다. 증분 전송의 기준으로 필요한 스냅샷이 무엇인지, 오래된 스냅샷이 고정하는 고유 데이터가 얼마나 되는지, 북마크로 일부 로컬 소스 스냅샷을 대체할 수 있는지, 다음 대규모 변경 세트가 도착하기 전까지 여유 공간이 얼마나 남아 있는지 추적하세요.

대상 보존 정책을 명시적으로 설정하세요

대상에 보관할 시간별, 일별, 주별, 월별 복구 지점의 수를 결정하고, 그 기록 보존 기간이 소스와 다른 이유를 문서화하세요. 소스에서 삭제된 오래된 대상 스냅샷을 복제 소프트웨어가 자동으로 모두 정리한다고 가정하지 마세요.

ZFS 복제 개요에서는 스냅샷이 복구 지점이자 증분 전송의 경계이므로 복제에 스냅샷 정책이 필요하다고 설명합니다.

변경량이 많은 데이터셋에는 가장 짧은 보존 기간을 적용하세요. 더 긴 기록이 구체적인 복구 가치를 제공하는 경우가 아니라면 특히 그렇습니다. 변경량이 적은 아카이브에는 별도의 일정을 적용하여, 잦은 복구 지점이 거의 도움이 되지 않는 곳에서 하나의 전역 정책으로 공간을 낭비하지 않도록 하세요.

오래된 스냅샷이 고정하는 변경량을 추정하세요

대규모 삭제, 이동, 미디어 교체 또는 VM 재작성 전후에 스냅샷의 USED, 스냅샷 간 기록된 데이터, 대상 풀의 여유 공간을 측정하세요. 라이브 데이터가 사라진 뒤에도 스냅샷이 오래된 블록을 계속 유지할 수 있습니다.

TrueNAS 복제 안내에서는 현재 라이브 데이터셋이 작아져도 스냅샷 변경량이 오래된 블록을 보존한다고 경고합니다.

이 변경량을 기준으로 보존 기간에 필요한 용량을 산정하세요. 빠르게 변경되는 VM 이미지에 30일간의 기록을 보관하는 대상은 라이브 크기는 같지만 대부분 추가만 이루어지는 가족 사진 데이터셋보다 훨씬 큰 용량이 필요할 수 있습니다.

다음 복제를 위해 풀의 여유 공간을 확보하세요

가장 현실적인 규모의 수신 증분 데이터와 로컬 스냅샷 증가량, 일반적인 파일시스템 오버헤드를 고려하여 운영상 필요한 여유 공간 하한을 설정하세요. 풀이 거의 가득 찬 뒤가 아니라 하한에 도달하기 전에 알림을 보내세요.

Oracle의 스냅샷 보존 논의에서는 스냅샷 생성이 처음에는 저렴하다는 이유로 스냅샷을 비용이 없는 것으로 취급하지 않고, 명시적인 보존 정책이 스냅샷 증가를 제어한다고 설명합니다.

대상이 긴급 상태에 도달하기 전에 중요하지 않은 보존 기간을 일시 중지하거나 단축하세요. 복제 대상은 새 블록을 수신하고 커밋할 공간이 필요하므로, 현재 라이브 데이터셋을 저장할 만큼만 공간을 남기는 것은 안전한 용량 계획이 아닙니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

증분 기록을 보존할 수 있는 경우 북마크를 사용하세요

ZFS 버전과 복제 도구가 북마크를 지원한다면, 오래된 소스 스냅샷이 더 이상 완전한 로컬 복구 지점으로 필요하지 않을 때 북마크로 증분 전송 참조를 보존할 수 있는지 검토하세요.

오프사이트 백업 설계에서는 북마크가 증분 전송 기준을 보존한다는 점을 보여 주며, 스냅샷 보존을 독립적으로 운영할 수 있게 합니다.

모든 스냅샷을 북마크로 대체하지는 마세요. 대상의 복구 기록에는 실제 스냅샷이 여전히 필요하며, 공통 기준을 관리하는 방식은 복제 도구마다 다릅니다. 대상의 복구 목표를 약화하지 않으면서 소스 측 구성을 단순화할 수 있는 경우에만 북마크를 사용하세요.

복제에 필요한 스냅샷만 보호하세요

정리하기 전에 소스와 대상이 공유하는 가장 최근의 공통 스냅샷을 확인하세요. 도구가 홀드 또는 이와 동등한 보호 기능을 사용하는 경우, 정리 작업이 이를 준수하는지와 더 이상 필요하지 않은 홀드가 결국 해제되는지 확인하세요.

FreeBSD ZFS 핸드북에서는 홀드를 명시적으로 해제할 때까지 홀드가 공유 스냅샷을 보호한다고 설명합니다.

공통 기준 하나가 필요하다는 이유만으로 모든 과거 스냅샷을 보존하지 마세요. 복제에 실제로 필요한 소수의 스냅샷만 보호한 다음, 그보다 오래된 독립 복구 지점은 대상 보존 정책에 맡기세요.

백업 기록과 별도로 복제 스냅샷을 점검하세요

일부 도구는 예약된 시간별 또는 일별 스냅샷 외에 자체 동기화 스냅샷을 생성합니다. 대상에서 두 종류를 모두 나열하고, 도구가 생성한 스냅샷 집합이 정리 규칙 없이 계속 증가하지 않는지 확인하세요.

Sanoid 및 Syncoid 관련 논의에서는 동기화 스냅샷이 안전장치 역할을 한다고 설명하며, 모든 복제 스냅샷이 장기 백업 기록을 위한 것은 아니라고 봅니다.

매월 또는 대규모 데이터셋 이동 후에 대상을 점검하세요. 예상한 복구 지점이 남아 있고, 다음 증분 전송에 유효한 공통 기준이 있으며, 풀의 여유 공간이 정의한 하한보다 높게 유지된다면 정책이 정상적으로 작동하는 것입니다. 대상이 이미 예상치 못하게 가득 찬 경우에는 스냅샷 공간 진단에 관한 관련 ZimaSpace 문서를 복구 절차로 활용하세요.