증분 백업이 전체 백업만큼 큰 이유는 무엇인가요?

소스가 실제로 많은 블록을 다시 쓸 때, 백업 엔진이 이전 변경 기준선을 잃었을 때, 보호 범위가 변경되었을 때, 또는 읽고 있는 숫자가 현재 증분 페이로드가 아닌 저장소 증가일 때 증분 백업은 거의 전체 백업 크기만큼 커질 수 있습니다. 복원 지점을 삭제하거나 작업을 재설정하거나 새 전체 백업을 시작하기 전에 이러한 가능성을 별도로 진단하세요.

먼저 어떤 숫자가 너무 큰지 식별하기

“증분이 전체 크기다”는 네 가지 다른 측정을 설명할 수 있습니다. 이들은 서로 교환 가능하지 않으며 각각 다른 원인을 가리킵니다.

한 실행에 대해 네 가지 숫자를 모두 기록하세요. 8TB를 스캔하지만 12GB만 전송하는 작업은 7TB를 전송하고 쓰는 작업과 매우 다르게 동작합니다.

작업 부하가 실제로 그렇게 많이 변경되었는지 확인하기

볼륨 수준 백업 소프트웨어는 변경된 저장 블록을 보호하며, 편집된 문서의 사용자에게 보이는 크기를 보호하지 않습니다. 작은 편집도 더 큰 블록을 변경할 수 있으며, 바쁜 서비스는 로그, 인덱스, 데이터베이스, 캐시 및 운영 체제 파일을 지속적으로 수정합니다. 최근 관리자 토론에서는 한 바이트의 변경이 포함된 백업 블록을 다음 증분의 일부로 만드는 이유를 설명합니다.

대규모 실행이 다음 이벤트 중 하나를 따랐는지 확인하세요:

• 데이터베이스 유지 관리, 압축, 재인덱싱 또는 트랜잭션 로그 증가
• 가상 머신 업데이트, 스왑 활동, 안티바이러스 검사 또는 게스트 조각 모음
• 미디어 트랜스코딩, 사진 라이브러리 재인덱싱, 썸네일 재생성 또는 메타데이터 재작성
• 대용량 아카이브, 암호화된 컨테이너, 메일박스 또는 디스크 이미지 파일이 제자리에서 다시 작성되는 경우
• 파일시스템 균형, 풀 확장, 블록 재배치 또는 스냅샷 통합

백업 창을 애플리케이션 로그 및 저장소 쓰기 그래프와 비교하세요. 소스 쓰기가 동시에 증가했다면, 백업이 실제 델타를 보고하는 것이지 백업 오류가 아닐 수 있습니다.

변경 추적이 기준선을 잃었는지 확인하기

블록 추적 시스템은 현재 상태를 알려진 이전 변경 ID와 비교합니다. 스냅샷 복원, 추적 재설정, 무효 변경 맵, 호스트 마이그레이션, 이전 세션 실패 또는 백업 작업 재생성은 이 관계를 깨뜨릴 수 있습니다. 다음 실행은 안전한 기준선을 설정하기 위해 전체 소스를 읽거나 보호할 수 있습니다. 실제 CBT 복구 절차에서는 변경 추적 재설정 후 정상 증분 백업이 재개되기 전에 새 활성 전체 백업이 필요할 수 있음을 설명합니다.

다음과 같은 로그 용어를 찾아보세요 CBT 재설정, 변경 ID 무효, 저널 래핑됨, 기준선 누락, 새 체인또는 전체 스캔 필요로그를 보존하지 않고 추적을 반복해서 재설정하지 마세요; 반복 재설정은 원래 트리거를 숨기고 반복적인 전체 크기 실행을 유발할 수 있습니다.

백업 범위와 소스 식별이 변경되지 않았는지 확인하세요

작업이 여전히 증분으로 표시되더라도 이전과 다른 소스를 보호할 수 있습니다. 포함된 경로 아래의 새 마운트, 파일 시스템 크기 조정, 변경된 장치 식별자, 다른 호스트 이름, 새 공유 경로 또는 확장된 포함 규칙은 엔진이 새로운 내부 구조를 구축하게 만듭니다. 커뮤니티 문제 해결 사례에 따르면 추가 볼륨과 마운트 지점이 변경되지 않은 작업에 포함될 수 있습니다.

이전 및 현재 작업 정의를 내보내 비교하세요:

• 보호된 루트, 마운트, 공유, 데이터셋 및 가상 디스크
• 호스트, 볼륨 및 파일 시스템 식별자
• 포함 및 제외 패턴
• 스냅샷 제공자 및 일관성 모드
• 암호화, 압축 및 중복 제거 설정

소스가 의도적으로 확장된 경우 전체 크기의 증분 백업이 예상될 수 있습니다. 이후 실행마다 크기가 계속 크다면 진단을 계속 진행하세요.

백업 세분화가 파일에 적합한지 확인하세요

파일 수준, 블록 수준 및 콘텐츠 정의 청킹 엔진은 편집, 이름 변경 및 재작성에 다르게 반응합니다. 블록 중복 제거 시스템은 폴더가 이동될 때 메타데이터만 기록할 수 있지만, 더 단순한 파일 수준 엔진은 이동된 경로를 삭제된 파일과 새 파일로 처리할 수 있습니다. 한 블록 기반 예에서는 디렉터리 이름 변경이 변경되지 않은 모든 데이터 블록을 다시 업로드하지 않고 경로 메타데이터만 변경합니다.

큰 변경 가능한 파일은 특별한 주의가 필요합니다. 데이터베이스, VM 이미지, 암호화된 금고 또는 단일 아카이브는 작은 내부 변경을 발견하기 위해 전체를 읽을 수 있으며, 최종 저장량은 청크 경계와 중복 제거에 따라 달라집니다. 대용량 데이터베이스에 관한 논의는 수 기가바이트 데이터베이스 파일이 변경된 청크만 전송되더라도 전체를 읽을 수 있다고 설명합니다.

애플리케이션이 일관된 내보내기, 트랜잭션 로그 백업 또는 애플리케이션 인식 백업 방법을 제공한다면, 해당 워크플로우를 라이브 단일 파일 백업과 비교하세요.

합성 전체 및 유지 활동과 큰 증분을 분리하세요.

합성 전체 백업은 이전 전체 백업과 이후 증분 백업에서 저장소 내에서 조립됩니다. 전체 소스를 다시 읽지 않고도 전체 크기의 복구 객체를 만들 수 있습니다. 백업 유형 개요는 합성 전체 백업이 기존 전체 및 증분 체인에서 만들어진다고 설명합니다.

오래된 복원 지점이 잠겨 있거나 가지치기가 실행되지 않았거나 삭제된 스냅샷이 여전히 청크를 참조하거나 병합이 일시적으로 작업 공간을 필요로 할 때 저장소 성장도 높게 유지될 수 있습니다. 한 디렉터리 목록만 판단하지 말고 작업 타임라인을 확인하세요:

백업 체인을 재구성하기 전에 단일 변수 테스트를 실행하세요.

1. 현재 작업 구성, 상세 로그, 복원 지점 목록 및 저장소 용량을 저장하세요.
2. 조용한 테스트 시간을 선택하고 안전하다면 알려진 고쓰기 애플리케이션을 일시 중지하세요.
3. 작은 테스트 파일 하나를 만들고 한 번 수정한 후 설정을 변경하지 않고 동일한 증분 작업을 실행하세요.
4. 스캔된 바이트, 전송된 바이트, 기록된 바이트, 중복 제거된 바이트 및 유지된 바이트를 기록하세요.
5. 소스 변경 없이 두 번째 증분 백업을 실행하세요.

두 개의 제어된 실행이 모두 전체 크기를 유지한다면 추적, 소스 식별 또는 작업 체인 구성을 중점적으로 확인하세요. 크기가 작아지면 변경 속도가 정상으로 돌아올 때까지 정상 작업 부하를 하나씩 복원하세요. 이렇게 하면 백업 엔진 동작과 애플리케이션 변동을 구분할 수 있습니다.

원인에 맞는 수정 적용

대상 크기를 산정할 때 버전 기록과 보존 정책이 저장소를 활성 소스보다 크게 만들 수 있음을 기억하세요. 같은 구분은 ZimaSpace 가이드의 버전 및 백업 기록을 위한 NAS 용량 계획에서 다룹니다.

매 실행마다 새 기준선이 생성되면 중단하고 문제를 심각하게 검토하세요

로그에서 반복되는 기준선 무효화, 소스 식별자 예상치 못한 변경, 복원 지점 사라짐, 저장소 메타데이터 손상 보고, 또는 변경 없음 테스트가 거의 전체 소스를 쓰는 경우 체인을 삭제하기 전에 문제를 심각하게 검토하세요. 적어도 하나의 대표 복원 지점이 테스트될 때까지 현재 복원 지점을 유지하세요. 작업을 다시 생성하면 증거가 사라지고 유일한 복구 가능한 기록이 제거될 수 있습니다.

자주 묻는 질문

큰 폴더를 이동하거나 이름을 바꾸면 전체 크기의 증분이 발생할 수 있나요?

백업 엔진에 따라 다릅니다. 콘텐츠 또는 블록 중복 제거 도구는 기존 데이터를 재사용하고 주로 경로 메타데이터만 저장할 수 있지만, 파일 수준 도구는 이동된 파일을 새 객체로 처리할 수 있습니다. 대규모 데이터 세트를 재구성하기 전에 대표 폴더 하나로 정확한 제품을 테스트하세요.

합성 전체 백업이 NAS가 전체 소스를 다시 업로드했다는 뜻인가요?

반드시 그런 것은 아닙니다. 합성 전체 백업은 일반적으로 이미 저장소에 있는 데이터로 조립됩니다. 소스 읽기 및 네트워크 전송 카운터를 저장소 쓰기 카운터와 비교하여 작업이 어디서 발생했는지 확인하세요.

왜 작은 데이터베이스 편집이 큰 증분을 만들 수 있나요?

애플리케이션은 눈에 보이는 기록 변경이 작더라도 많은 저장 블록을 다시 쓰거나, 데이터베이스를 압축하거나, 로그를 회전시키거나, 청크 경계를 변경할 수 있습니다. 애플리케이션 일관성 백업 또는 내보내기를 사용하고 그 델타를 라이브 데이터베이스 파일과 비교하세요.