NAS 공간이 스냅샷으로 사용되는지 또는 라이브 파일로 사용되는지 테스트하는 방법

에바 왕

IceWhale author

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

How to Test Whether NAS Space Is Used by Snapshots or Live Files - Zima Store Online

예, 동일한 시점의 데이터셋 사용량, 참조된 공간 또는 논리적 크기, 스냅샷이 보유한 공간, 풀 여유 공간을 비교하면 구분할 수 있습니다.

NAS에서 표시되는 폴더의 내용보다 훨씬 적은 여유 공간을 보고할 때 이 판단이 중요합니다. 서로 구분해야 할 두 상태는 라이브 데이터셋 할당과 스냅샷에 의해서만 유지되는 블록입니다. 저장된 구성과 삭제해도 되는 데이터로 시작하고, 한 번에 한 분기만 관찰하며, 테스트로 인해 데이터 손실, 권한 또는 가용성 위험이 커지면 중단하세요.

스냅샷 공간과 라이브 파일 공간을 판단하는 조건 정의

변경하기 전에 소프트웨어 및 펌웨어 버전, 장치 식별 정보, 마운트 또는 네트워크 경로, 여유 공간, 권한, 관찰된 증상을 기록하세요. 기준선에는 NAS에서 표시되는 폴더의 내용보다 훨씬 적은 여유 공간을 보고하는 상황을 재현할 수 있을 만큼 충분한 세부 정보가 포함되어야 합니다.

첫 번째 후보는 라이브 데이터셋 할당입니다. 두 번째는 스냅샷에 의해서만 유지되는 블록입니다. 현재 OpenZFS 공간 속성은 테스트에 사용되는 메커니즘 또는 명령 경계를 정의하지만, 이 특정 홈 서버에서 직접 관찰한 결과를 대신하지는 않습니다.

판별 테스트를 실행하기 전에 합격 조건과 중단 조건을 작성하세요. 합격은 한 분기에서 예측한 증거를 변경하면서 관련 없는 서비스는 그대로 유지해야 하며, 실패 시에는 추측에 기반한 수정 작업을 연쇄적으로 실행하지 말고 저장된 상태로 시스템을 되돌려야 합니다.

원래 요구 사항을 낮추지 않고 주장 테스트

다음 판별법을 사용하세요. 풀 및 데이터셋 회계 정보를 기록하고, 삭제해도 되는 큰 파일 하나를 삭제한 다음, 스냅샷을 삭제하지 않은 상태에서 전후를 비교합니다. 결과가 변경된 변수에 기인하도록 작업 부하, 클라이언트, 경로, 파일 집합, 시간을 일정하게 유지하세요.

ZFS 할당 회계를 사용해 두 분기를 실제로 구분할 수 있는 필드를 선택한 다음, 해당 필드의 타임스탬프, 종료 상태, 오류 메시지, 장치 또는 스냅샷 식별 정보, 지연 시간, 전송된 바이트 수, 권한 및 복구 상태를 수집하세요. 식별 정보, 내구성 또는 애플리케이션 상태가 테스트 대상인 경우 명령이 정상적으로 종료된 것만으로는 충분하지 않습니다.

재시작, 재연결, 재마운트 또는 콜드 캐시가 원래 조건에 포함되는 경우, 해당 작업 후 테스트를 한 번 반복하세요. 첫 실행이 파괴적이거나 환경을 복원할 수 없다면 중단하고 삭제해도 되는 복사본에서 대신 재현하세요.

zfs list -o name,used,refer,usedbysnapshots,usedbydataset,usedbychildren

합격, 실패 및 예외 결과 해석

합격: 스냅샷이 여전히 블록을 참조하기 때문에 사용 공간은 그대로인 상태에서 라이브 참조 공간이 감소합니다. 결론이 보편적인 주장이 아닌 조건부 결론으로 유지되도록, 합격한 정확한 버전, 식별 정보 및 작업 부하를 기록하세요.

실패: 참조 공간과 사용 공간이 모두 높은 상태로 유지되거나, 다른 데이터셋, 클론, 예약 공간 또는 메타데이터 할당이 해당 공간을 소유합니다. 네트워크, 메모리, 권한 또는 소스 일관성이 두 분기에 모두 영향을 줄 수 있으므로 실패가 자동으로 반대 분기를 입증하지는 않습니다. 추가 조치를 취하기 전에 이러한 공통 종속성을 분리하세요.

예외 또는 모호한 결과: 삭제를 중단하고 정리하기 전에 모든 데이터셋, 스냅샷, 클론 및 예약 공간을 파악하세요. 복구 가능한 복사본이 생길 때까지 로그를 보존하고 복구, 정리, 삭제, 재파티션 또는 재귀적 소유권 명령을 실행하지 마세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

원래 작업 부하에서 판단 확인

관찰된 분기에 맞는 조치를 적용한 다음, 축소한 대체 조건이 아니라 원래 조건을 다시 실행하세요. 스냅샷이 여전히 블록을 참조하기 때문에 사용 공간은 그대로인 상태에서 라이브 참조 공간이 감소하는 현상이 두 주기 동안 또는 관련된 재부팅, 절전, 중단이나 부하 전환 후에도 유지될 때만 판단이 유효합니다.

변경 불가능한 백업 기간을 사용해 가장 가까운 종속 워크플로를 확인하되, 원래 트리거는 변경하지 마세요. 관련 없는 데이터셋, 공유 폴더, 컨테이너, 사용자 및 복구 지점은 이전의 접근성과 타이밍을 유지해야 합니다.

중단 경계는 명확합니다. 참조 공간과 사용 공간이 모두 높은 상태로 유지되거나, 다른 데이터셋, 클론, 예약 공간 또는 메타데이터 할당이 해당 공간을 소유한다면 마지막으로 검증된 구성으로 돌아가 증거를 보존하세요. 그리고 해당 분기가 반복적으로 재현될 때만 더 심층적인 플랫폼 또는 하드웨어 테스트로 확대하세요.

목표 결과가 유지된 후에는 백업 검증 주기와 비교하여 문제가 인접 서비스로 이동하지 않았는지 확인하세요. 새로운 백업, 식별 정보, 시간 초과 또는 가용성 문제가 발생한 성공적인 목표 테스트도 여전히 실패한 변경입니다.

FAQ

스냅샷 공간과 라이브 파일 공간에 관해 남는 질문은 대개 파일을 삭제해도 풀 공간이 확보되지 않는 이유, logicalused가 물리적 공간과 같은지 여부, 삭제 전에 스냅샷 공간을 예측할 수 있는지에 관한 것입니다. 아래 답변에서는 이러한 예외 사례를 주요 판단과 분리합니다.

합격 경계는 바뀌지 않습니다. 스냅샷이 여전히 블록을 참조하기 때문에 사용 공간은 그대로인 상태에서 라이브 참조 공간이 감소해야 합니다. 후속 조건으로 파일 시스템, 식별 정보, 네트워크 경로 또는 애플리케이션 버전이 변경되면 해당 변경의 영향을 받는 판별 테스트만 다시 실행하세요.

참조 공간과 사용 공간이 모두 높은 상태로 유지되거나, 다른 데이터셋, 클론, 예약 공간 또는 메타데이터 할당이 해당 공간을 소유한다면 실험을 확대하지 마세요. 이 시점에서는 삭제를 중단하고 정리하기 전에 모든 데이터셋, 스냅샷, 클론 및 예약 공간을 파악하세요. 플랫폼, 스토리지 또는 하드웨어 담당자에게 에스컬레이션하기 전에 증거를 보존해야 합니다.

파일을 삭제해도 풀 공간이 확보되지 않는 이유는 무엇인가요?

스냅샷이 해당 블록을 여전히 참조하고 있거나, 클론, 예약 공간 또는 다른 데이터셋이 할당을 소유하고 있을 수 있습니다.

logicalused는 물리적 공간과 같은가요?

아니요. 압축, 복사본 수, 메타데이터 및 공유로 인해 논리적 값과 할당된 값은 서로 달라집니다.

삭제 전에 스냅샷 공간을 예측할 수 있나요?

참조 및 고유 공간 속성이 도움이 되지만, 공유 블록이 있으므로 회수되는 공간은 전체 스냅샷 체인에 따라 달라집니다.

스냅샷 공간과 라이브 파일 공간에 대한 실질적인 답은 여전히 조건부입니다. 스냅샷이 여전히 블록을 참조하기 때문에 사용 공간은 그대로인 상태에서 라이브 참조 공간이 감소해야 합니다. 참조 공간과 사용 공간이 모두 높은 상태로 유지되거나, 다른 데이터셋, 클론, 예약 공간 또는 메타데이터 할당이 해당 공간을 소유한다면 삭제를 중단하고 정리하기 전에 모든 데이터셋, 스냅샷, 클론 및 예약 공간을 파악하세요. 원래 작업 부하를 견디지 못하는 부분적인 성공은 호환성이 아닙니다.