왜 홈 NAS에 여유 용량이 있어도 파일 수가 증가하면 백업과 스냅샷 작업이 더 오래 걸릴까요?

파일 수가 증가하면 백업 및 스냅샷 작업도 증가합니다. 모든 객체는 크기가 작아도 사라지지 않는 작업을 추가합니다. NAS는 총 저장 바이트가 충분한 여유 용량을 남겨도 이름 나열, 메타데이터 읽기, 상태 비교, 포함 기록, 인덱스 업데이트, 이후 삭제 또는 복원을 수행해야 합니다.

여유 용량은 더 많은 데이터 블록을 할당할 수 있는지 여부를 알려줍니다. 그러나 백업 워크플로가 처리해야 하는 네임스페이스 기록, 트랜잭션, 검사, 버전 관계 또는 복원 단계 수는 측정하지 않습니다.

왜 모든 파일이 고정된 백업 작업을 추가하나요?

백업 작업은 백만 개의 파일이 있는 디렉터리를 하나의 객체로 처리할 수 없습니다. 각 객체는 발견, 속성 읽기, 정책 검사, 카탈로그 항목, 대상 생성 등 고정된 백업 작업을 추가합니다.

큰 파일의 경우 고정된 설정 비용이 수 메가바이트 또는 기가바이트에 걸쳐 분산됩니다. 작은 파일의 경우 열기, 닫기, 권한, 저널 및 프로토콜 작업이 페이로드 전송보다 더 많은 시간을 소요할 수 있습니다.

병목 현상은 대역폭보다는 초당 작업 수일 수 있습니다. 네트워크 그래프는 거의 비어 있어도 디스크, 메타데이터 서비스 또는 백업 데이터베이스가 객체 기록을 계속 처리할 수 있습니다.

변경되지 않은 트리가 스캔하는 데 시간이 오래 걸리는 이유는 무엇인가요?

증분 도구는 변경된 내용을 확인한 후에야 변경되지 않은 데이터를 건너뛸 수 있습니다. 변경되지 않은 트리도 파일별 비교가 필요하므로, 거의 전송할 데이터가 없는 백업이라도 선택된 전체 트리를 탐색할 수 있습니다.

비교는 일반적으로 크기, 수정 시간, 파일 유형, 경로 및 이전 카탈로그 상태를 사용합니다. 수백만 개의 객체에 대해 이러한 필드를 읽으면 파일 내용이 이동하지 않아도 메타데이터 I/O와 네트워크 왕복이 발생합니다.

변경 저널과 파일시스템 스냅샷은 후보 집합을 좁힐 수 있지만, 백업 시스템이 필요한 기록을 신뢰하고 보존할 때만 가능합니다. 저널 범위가 누락되거나 카탈로그가 재구성되면 더 넓은 스캔이 필요할 수 있습니다.

체크섬과 증분 비교가 비용을 어떻게 증가시키나요?

메타데이터 비교는 상대적으로 저렴하지만 모든 콘텐츠 변경을 감지할 수는 없습니다. 체크섬 모드는 선택된 모든 파일을 읽으며, 콘텐츠 검증은 타임스탬프 비교가 건너뛸 데이터를 읽어야 할 수도 있습니다.

체크섬은 선택된 모든 객체에 대해 CPU와 저장소 읽기를 추가합니다. 이 비용은 작업이 불변 아카이브를 검증하거나 청크 중복 제거를 하거나 중단된 실행 후 데이터를 재검사할 때 특히 눈에 띕니다.

빠른 네트워크도 이 작업을 제거하지 못합니다. 소스는 여전히 파일을 찾아 읽어야 하기 때문입니다. 백업은 작은 무작위 읽기, 메타데이터 잠금, 해싱 처리량 또는 대상 카탈로그 업데이트에 의해 제한될 수 있습니다.

왜 스냅샷과 보존된 버전이 메타데이터 작업을 증가시키나요?

스냅샷은 변경된 블록을 효율적으로 보존할 수 있지만 백업 또는 관리 도구는 여전히 버전과 관계를 식별해야 합니다. 보존된 버전은 현재 객체, 이전 버전, 경로 및 정책 기록이 누적되면서 메타데이터 관계를 증가시킵니다.

파일 수준 스냅샷 브라우저는 각 라이브 경로에 대해 여러 과거 항목을 나열할 수 있습니다. 보존 가지치기는 메타데이터, 디렉터리 기록 또는 블록을 해제하기 전에 어떤 버전이 참조되는지 결정해야 합니다.

블록 수준 스냅샷 생성은 빠를 수 있지만 이후 복제, 카탈로그 작성, 삭제 및 복원 선택은 파일 수에 민감합니다. 스냅샷 속도만으로 전체 수명 주기 비용을 측정할 수 없습니다.

왜 삭제 및 복원 작업도 파일 수에 제한을 받나요?

많은 작은 파일을 삭제하거나 복원하는 것은 네임스페이스와 트랜잭션 작업을 반복합니다. 많은 작은 파일을 복원하는 것은 하나의 연속된 페이로드를 스트리밍하는 대신 설정 작업을 반복합니다.

복원은 디렉터리, 이름, 권한, 타임스탬프, 확장 속성, 링크 및 애플리케이션 메타데이터를 다시 생성해야 합니다. 대상은 또한 각 작업을 저널링하고 바이러스 백신, 인덱싱 또는 동기화 감시자를 업데이트할 수 있습니다.

큰 트리를 삭제하는 것도 각 이름과 객체 관계를 안전하게 제거해야 하기 때문에 비슷하게 느릴 수 있습니다. 하나의 파일에서 1테라바이트를 해제하는 것이 수백만 개의 객체에 분산된 몇 기가바이트를 삭제하는 것보다 더 간단할 수 있습니다.

홈 NAS는 어떻게 객체 수준 오버헤드를 줄여야 할까요?

파일 수와 바이트 용량은 별개의 차원입니다. 따라서 용량 계획은 객체 수, 백업 스캔 시간, 카탈로그 크기, 버전 수 및 복원 속도를 추적해야 합니다.

신뢰할 수 있는 경우 증분 변경 추적을 사용하고, 생성된 캐시는 제외하며, 개별 복원이 필요 없는 불변의 작은 객체는 아카이브로 그룹화하고, 백업 카탈로그는 작은 랜덤 I/O에 적합한 스토리지에 보관하세요.

초당 파일 수와 MB/s 모두에서 복원 처리량을 테스트하세요. 올바른 설계는 접근성과 복구 요구 사항을 유지하면서 반복되는 객체 처리를 줄입니다; 모든 것을 아카이브에 넣으면 개별 업데이트와 부분 복원이 더 어려워질 수 있습니다.

자주 묻는 질문

거의 데이터를 전송하지 않아도 백업이 느릴 수 있나요?

네. 변경되지 않은 수백만 개의 객체를 나열하고 비교하는 데 대부분의 시간이 소요될 수 있습니다.

스냅샷이 파일 수 오버헤드를 없애나요?

포인트 인 타임 캡처를 빠르게 할 수 있지만 버전 탐색, 변경 복제, 보존 가지치기 및 파일 복원은 여전히 메타데이터를 처리합니다.

작은 파일은 항상 함께 아카이브해야 할까요?

아니요. 아카이브는 객체 오버헤드를 줄이지만 개별 변경, 권한, 중복 제거, 검색 및 부분 복원을 더 복잡하게 만듭니다.

MB/s 외에 어떤 지표가 중요할까요?

초당 스캔된 파일 수, 변경된 객체, 메타데이터 지연, 카탈로그 성장, 스냅샷 수, 삭제 속도, 초당 복원 객체 수를 추적하세요.

최종 요약

파일 수가 증가하면 각 객체가 고정된 검색, 비교, 카탈로그, 버전, 삭제 및 복원 작업을 생성하기 때문에 백업 및 스냅샷 작업이 늘어납니다. 여유 공간은 향후 바이트 할당을 보호하지만 객체 수준 작업을 제거하지는 않습니다. 초당 파일 수와 복원 동작을 용량 및 대역폭과 함께 측정하세요.