콘텐츠 정의 청킹은 중복 백업 데이터를 어떻게 줄이나요?

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

콘텐츠 정의 청킹은 파일 콘텐츠를 기준으로 청크 경계를 선택하여 백업 중복 제거를 개선합니다. 파일에 삽입이나 삭제가 발생한 후에도 변경되지 않은 영역을 재사용할 수 있기 때문입니다.

증분 백업에는 버전 간 대부분의 내용이 변경되지 않는 대용량 파일이 자주 포함됩니다. 예를 들어 가상 디스크 이미지, 메일 아카이브, 파일 형태로 복사한 데이터베이스, 프로젝트 번들, 내보낸 미디어 라이브러리 등이 있습니다. 모든 청크가 고정된 바이트 오프셋에서 시작하면 앞부분에 작은 헤더를 삽입하는 것만으로도 이후의 모든 경계가 이동합니다. 이후의 바이트가 동일하더라도 말입니다. 콘텐츠 정의 청킹은 절대 위치가 아니라 로컬 바이트 패턴을 따라 분할하므로, 변경된 영역 이후 백업이 기존 청크와 다시 동기화될 수 있습니다.

고정 크기 경계는 작은 편집 하나를 수많은 새 청크로 만들 수 있습니다

고정 크기 청커는 바이트 내용과 관계없이 1MiB마다 자르는 방식으로 동작합니다. 앞부분에 바이트가 삽입되면 이전 스트림과 새 스트림의 오프셋이 서로 어긋납니다. 따라서 실제 콘텐츠의 대부분이 그대로여도 이후의 각 고정 청크에는 서로 다른 바이트 조합이 포함됩니다.

중복 제거를 위해 콘텐츠 정의 청킹이 개발된 이유는 콘텐츠에서 파생된 절단 지점이 로컬 편집 후 고정 오프셋으로는 놓칠 수 있는 중복을 감지하기 때문입니다. CDC의 이점은 어떤 파일이 서로 유사한지 예측하는 데 있지 않습니다. 위치가 이동한 후에도 유지될 수 있는 분할 방식을 중복 제거기에 제공하는 데 있습니다.

파일 전체가 관련 없는 바이트로 교체되었다면 어떤 청킹 알고리즘도 중복 콘텐츠를 만들어낼 수 없습니다. CDC는 여러 버전이 변경되지 않은 대규모 바이트 영역을 공유하지만 해당 영역이 파일 시작점에 대해 이동한 경우에 가장 큰 효과를 발휘합니다.

롤링 지문은 바이트 스트림에서 로컬 절단 지점을 검색합니다

CDC는 입력 위로 윈도우를 이동시키며 바이트가 윈도우에 들어오고 나갈 때마다 지문을 업데이트합니다. 지문이 설정된 조건을 충족하면 경계가 선언됩니다. 이때 비정상적으로 작거나 큰 청크가 생성되는 것을 막기 위해 최소 및 최대 청크 크기 규칙이 적용됩니다.

Borg의 청커는 롤링 콘텐츠 지문을 사용하므로 다음 후보 경계를 평가할 때마다 전체 윈도우를 처음부터 다시 해시할 필요가 없습니다. 지문은 주변 바이트에 따라 달라지므로 파일의 절대 오프셋이 바뀌더라도 동일한 로컬 시퀀스가 같은 절단을 유발할 수 있습니다.

따라서 롤링 지문은 저장된 백업 데이터의 최종 식별자가 아니라 경계를 찾기 위한 메커니즘입니다. 이 두 해시를 서로 같은 것으로 취급하면 중복 제거에서 실제로 재사용 여부를 결정하는 과정을 잘못 설명하게 됩니다.

최소, 최대 및 평균 청크 크기도 경계 검색 방식에 영향을 줍니다. 이러한 값은 후보 절단을 얼마나 자주 고려할지와 저장소가 관리해야 하는 메타데이터의 양을 결정합니다.

CDC는 편집 후에도 계속 어긋나는 대신 다시 동기화합니다

삽입이나 삭제가 발생하면 롤링 윈도우는 처음에 다른 바이트를 보게 되므로 편집 주변에서 서로 다른 청크 경계를 생성합니다. 이후 충분히 긴 변경되지 않은 영역으로 완전히 이동하면 동일한 로컬 콘텐츠 패턴을 만날 수 있고, 이전 버전과 일치하는 위치에서 다시 절단을 시작할 수 있습니다.

Borg는 다른 위치에서 바이트가 삽입되거나 제거되더라도 콘텐츠 정의 경계가 변경되지 않은 콘텐츠를 기준으로 안정적으로 유지될 수 있다고 설명합니다. 이러한 재동기화 덕분에 많은 편집이 파일 나머지 부분을 무효화하지 않고 소수의 새 청크로 제한됩니다.

Restic도 슬라이딩 지문을 사용해 파일을 가변 길이 블롭으로 분할하므로, 변경되지 않은 가변 길이 블롭을 여러 스냅샷에서 다시 참조할 수 있습니다. 저장소에는 이미 저장된 블롭을 식별하기 위한 인덱스가 여전히 필요합니다.

재동기화 거리는 청킹 매개변수와 변경된 바이트 패턴에 따라 달라지므로, CDC가 모든 편집마다 정확히 하나의 새 청크만 생성한다고 보장하지는 않습니다. CDC의 장점은 통계적 국소성에 있습니다. 변경 사항이 이후의 모든 경계를 이동시킬 가능성을 낮추는 것입니다.

강력한 청크 식별자가 경계 선택 후 재사용 여부를 결정합니다

경계를 찾는 것은 후보 청크가 어디에서 끝나는지만 알려줍니다. 저장소는 완성된 청크의 콘텐츠가 이미 존재하는지도 결정해야 합니다. 이 두 번째 결정에는 완성된 청크에 대해 계산한 더 강력한 콘텐츠 식별자 또는 인증된 해시가 사용되며, 저장소 인덱스에서 이를 조회합니다.

Borg는 경계를 결정하는 해시와 중복 제거 기준으로 사용되는 암호화 청크 식별자를 명확히 구분합니다. Restic 역시 롤링 지문을 두 청크가 동일하다는 증거로 취급하지 않고, 강력한 콘텐츠 해시를 사용해 저장된 블롭을 참조합니다.

이 2단계 설계는 저장 경로를 명확하게 보여줍니다. 롤링 해시는 후보 분할을 선택하고, 콘텐츠 해시는 그 결과로 만들어진 청크를 식별하며, 저장소 조회는 저장할지 재사용할지 결정합니다. CDC가 이러한 일치가 편집 후에도 유지될 가능성을 크게 높이기는 하지만, 실제 중복 제거 절감 효과는 마지막 두 단계에서만 발생합니다.

청크 크기와 데이터 변환이 연산 비용과 절감 효과의 경계를 결정합니다

평균 청크가 작을수록 변경 사항을 더 정밀하게 분리할 수 있지만, 지문 계산 횟수, 인덱스 항목, 조회, 메타데이터 객체 및 저장소 참조의 수가 증가합니다. 청크가 크면 인덱싱 오버헤드는 줄어들지만 작은 편집 하나로 재사용 가능한 데이터의 더 큰 단위가 무효화될 수 있습니다.

FastCDC는 강력한 중복 감지 기능을 유지하면서 롤링 해시의 CPU 오버헤드를 줄이는 데 초점을 맞춥니다. 이는 중복 바이트를 제거하기 전에도 청킹 자체가 상당한 비용이 될 수 있음을 보여줍니다. 최적의 매개변수는 청킹 작업량, 인덱스 크기 및 백업 세트의 유사성 패턴 사이에서 균형을 이룹니다.

청킹 전에 수행하는 변환은 CDC가 의존하는 바이트 유사성을 제거할 수도 있습니다. 서로 다른 논스를 사용하는 암호화, 작은 논리적 변경 후 파일 대부분을 다시 작성하는 형식, 일부 압축 레이아웃은 논리적으로 유사한 두 버전을 바이트 수준에서 서로 무관한 데이터처럼 보이게 만들 수 있습니다.

ZimaSpace의 중복 제거 인덱스 오버헤드 분석은 이 절충의 다른 측면을 다룹니다. 더 세밀한 재사용을 위해서는 이미 존재하는 데이터를 추적할 메타데이터와 메모리가 더 많이 필요합니다. CDC는 단순히 가변 크기 청크가 더 정교해 보이기 때문이 아니라, 회수되는 저장 공간이 추가 청킹 및 인덱스 비용을 초과할 때 가치가 있습니다.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.