홈 NAS 스냅샷이 이미 손상된 데이터를 왜 보존할 수 있을까요?

가정용 NAS 스냅샷은 파일 시스템 상태를 보존하는 역할을 하므로 손상된 데이터를 보존할 수 있습니다. 데이터베이스, 문서, 사진 또는 미디어 파일이 스냅샷 생성 시 이미 손상되어 있다면, 그 스냅샷을 복원할 때 동일한 손상된 버전이 재현될 수 있습니다.

손상 시점이 중요합니다. 스냅샷은 나중에 덮어쓰여질 이전 버전을 보호할 수 있지만, 한 번도 캡처되지 않은 깨끗한 버전을 만들어내지는 못합니다. 복사-쓰기 블록 공유는 또 다른 경우를 만드는데, 물리적 손상이 블록을 참조하는 여러 파일 시스템 뷰에 영향을 줄 수 있습니다.

스냅샷은 알려진 정상 복사본이 아니라 파일 시스템 상태를 보존한다

파일 시스템 스냅샷은 특정 시점의 저장 상태를 기록합니다. 예를 들어 OpenZFS에서는 스냅샷이 파일 시스템 또는 볼륨의 읽기 전용 버전이며, 처음에는 모든 파일을 복제하지 않고 활성 데이터셋과 데이터를 공유합니다. OpenZFS 스냅샷 문서는 스냅샷이 활성 데이터셋이 변경될 때까지 공유되는 데이터를 어떻게 보존하는지 설명합니다.

이 작업은 저장된 내용이 의미상 올바른지 여부를 판단하지 않습니다. 애플리케이션이 잘못된 레코드를 썼거나, 동기화 도구가 잘못된 버전을 복사했거나, 랜섬웨어가 원본 바이트를 암호화된 내용으로 대체했을 때도 파일 시스템은 구조적으로 읽을 수 있는 파일을 보존할 수 있습니다. 따라서 스냅샷의 성공은 상태가 보존되었음을 의미할 뿐, 그 상태가 정상임을 보증하지는 않습니다.

스냅샷 시점에 존재하는 손상은 복구 지점의 일부가 된다

자정에 생성된 예약 스냅샷을 생각해 보십시오. 만약 애플리케이션이 오후 10시에 데이터베이스를 손상시켰다면, 자정 스냅샷은 손상 후의 파일 시스템 상태를 기록합니다. 그 스냅샷으로 롤백하면 데이터베이스가 자정 시점으로 돌아가지만, 자정 시점은 이미 정상적인 복사본을 제공하기에는 너무 늦은 시점입니다.

동일한 상황은 잘못된 동기화, 불완전한 가져오기, 실수로 저장, 또는 무단 암호화 후에도 발생할 수 있습니다. 스냅샷은 손상을 특별한 속성으로 “고정”하지 않고, 단지 캡처 시점에 존재하던 버전을 보존할 뿐입니다. 이전 스냅샷에는 여전히 사용 가능한 버전이 있을 수 있지만, 손상 이후 생성된 모든 스냅샷은 동일한 논리적 오류를 포함할 수 있습니다.

손상 시점이 스냅샷의 유용성을 결정한다

스냅샷은 복구 지점 이후에 원하지 않는 논리적 변경이 발생할 때 가장 유용합니다. 예를 들어 월요일 스냅샷에 정상적인 파일이 포함되어 있고 화요일에 라이브 파일이 덮어쓰여졌다면, 월요일 스냅샷을 통해 이전 데이터를 여전히 확인할 수 있습니다. 하지만 파일이 이미 월요일에 손상되었다면, 그 복구 지점은 문제를 해결할 수 없습니다.

기저 저장소 손상은 다른 경로를 만듭니다. 스냅샷은 생성 시 건강했을 수 있지만, 여전히 참조하는 물리적 블록이 손상되고 파일시스템이 검증된 복사본을 재구성할 수 없으면 나중에 읽을 수 없게 될 수 있습니다. 그래서 손상 시점은 블록 공유 및 저장소 중복성과 함께 고려되어야 합니다.

카피 온 라이트 블록 공유는 손상된 하나의 블록이 스냅샷 전체에 영향을 줄 수 있습니다.

카피 온 라이트 스냅샷은 변경되지 않은 데이터가 공유되기 때문에 공간 효율적입니다. Btrfs 저장 모델 문서는 스냅샷과 그 원본 서브볼륨이 공통의 수정되지 않은 데이터를 공유한다고 설명합니다. 따라서 스냅샷은 역사적인 파일시스템 뷰이며, 자동으로 별도의 매체에 두 번째 물리적 복사본이 아닙니다.

라이브 파일이 정상적으로 수정될 때, 카피 온 라이트는 변경을 위해 새 저장 공간을 할당하고 스냅샷은 이전 블록을 계속 참조합니다. 이 분리가 롤백을 가능하게 합니다. 그러나 변경되지 않은 블록이 여전히 공유되고 그 저장 블록이 나중에 읽을 수 없거나 잘못된 데이터를 반환하면, 그것에 의존하는 모든 뷰가 동일한 장애를 겪을 수 있습니다.

체크섬과 중복 저장은 불일치를 감지하고 다른 복사본을 제공하여 결과를 바꿀 수 있지만, 스냅샷 자체는 그런 보호를 생성하지 않습니다. 카피 온 라이트는 버전 분리를 제공할 뿐 독립적인 하드웨어 장애 영역을 만들지 않습니다.

체크섬과 스크럽은 무결성을 검사하지만, 스냅샷은 그렇지 않습니다.

스냅샷, 체크섬, 스크럽은 보호 스택의 서로 다른 부분에 속합니다. 스냅샷은 기록을 보존하고, 체크섬은 저장된 바이트가 예상치 못하게 변경되었는지 판단하는 데 도움을 주며, 스크럽은 오류를 찾기 위해 저장된 데이터를 사전에 읽습니다. 이러한 기능을 서로 교환 가능하다고 생각하면 복구 지점이 증명할 수 있는 것에 대해 잘못된 신뢰를 갖게 됩니다.

체크섬은 예상치 못한 블록 변경을 감지할 수 있습니다

Btrfs 체크섬 문서는 체크섬이 쓰기 전에 계산되고 블록이 저장소에서 읽힐 때 검증된다고 명시합니다. 불일치는 검색된 블록이 파일시스템이 저장하려던 블록과 다르다는 것을 드러낼 수 있습니다.

일치하는 체크섬이 문서, 데이터베이스, 미디어 파일이 논리적으로 올바르다는 증거는 아닙니다. 애플리케이션이 정상 쓰기 경로를 통해 잘못된 데이터를 쓴 경우, 파일시스템은 그 잘못된 바이트에 대해 유효한 체크섬을 계산할 수 있습니다. 블록은 애플리케이션 수준 내용이 사용할 수 없더라도 파일시스템 관점에서는 온전한 상태입니다.

중복성은 스크럽이 손상을 복구할 수 있는지 여부를 결정합니다

스크럽은 체크섬 오류, 읽기 오류, 특정 메타데이터 문제를 감지할 수 있지만, 감지와 복구는 다릅니다. Btrfs 스크럽 문서는 복제된 저장소에서 자동 복구가 다른 복제본의 검증된 정상 데이터를 사용한다고 설명합니다. 유효한 대체 복사본이 없으면 파일시스템은 손상된 블록을 식별할 수는 있지만 재구성하지 못할 수 있습니다.

USENIX의 ZFS 데이터 무결성 연구도 체크섬 기반 감지와 중복성을 이용한 복구를 구분합니다. 실용적인 교훈은 “스크럽이 손상을 고친다”는 것보다 좁은 의미로, 스크럽은 저장 시스템이 신뢰할 수 있는 대체 데이터를 찾거나 재구성할 수 있는 실패만 복구할 수 있다는 점입니다.

스냅샷 보존은 건강한 상태가 여전히 존재할 때만 도움이 됩니다

손상은 항상 즉시 발견되는 것은 아닙니다. 거의 열리지 않는 사진, 아카이브, 프로젝트 파일은 누군가 사용하려고 시도하기 전까지 몇 주 동안 손상된 상태로 남아 있을 수 있습니다. 만약 스냅샷 순환이 손상 이전의 모든 버전을 이미 제거했다면, 최근 스냅샷이 많이 모여 있어도 건강한 복구 지점을 포함하지 않을 수 있습니다.

따라서 보존 기간은 스냅샷 생성 빈도뿐만 아니라 감지 가능한 기간을 반영해야 합니다. 시간별 스냅샷은 최근 기록을 세밀하게 제공하는 반면, 더 오래 유지되는 일간, 주간 또는 월간 스냅샷은 눈치채지 못한 오류를 회피할 수 있는 기간을 연장합니다. 보편적인 일정은 없으며, 유용한 간격은 변경 속도, 사용 가능한 용량, 그리고 중요한 파일이 보통 얼마나 빨리 확인되는지에 따라 달라집니다.

라이브 NAS 데이터를 교체하기 전에 스냅샷을 검증하세요.

날짜별 스냅샷 선택은 첫 단계일 뿐입니다. 전체 데이터셋을 롤백하거나 라이브 파일을 교체하기 전에, 가정용 NAS 플랫폼이 허용한다면 후보 버전을 별도의 위치에 복원하세요. 이는 검증되지 않은 복구 시도가 여전히 유용할 수 있는 최신 데이터를 덮어쓰는 것을 방지합니다.

1. 손상이 처음 나타난 시점을 추정하세요.
2. 그 시점 이전의 스냅샷을 선택하세요.
3. 후보 버전을 별도의 폴더나 클론에 복원하세요.
4. 라이브 데이터를 교체하기 전에 복구된 내용을 열어 검증하거나 비교하세요.

검증은 데이터 유형에 맞게 이루어져야 합니다. 알려진 체크섬은 변경되지 않은 아카이브를 확인할 수 있고, 데이터베이스는 자체 일관성 검사가 필요하며, 사진이나 비디오는 디코딩이 필요할 수 있습니다. 복구 지점, 독립 복사본, 장치 외 보호 간의 더 넓은 관계는 이 가정용 NAS 백업 전략을 참조하세요.

자주 묻는 질문

손상 이전에 찍은 스냅샷도 읽을 수 없게 될 수 있나요?

예. 스냅샷은 이후 파일 변경으로부터 이전의 논리적 상태를 보호하지만, 동일한 저장 풀과 물리적 블록을 공유할 수 있습니다. 만약 그 블록 중 하나가 손상되고 검증된 중복 복사본이 없다면, 논리적 손상보다 이전에 생성된 스냅샷도 읽을 수 없게 될 수 있습니다.

성공적인 스냅샷은 그 안의 모든 파일이 정상임을 의미하나요?

아니요. 성공적인 스냅샷은 파일시스템이 복구 지점을 생성했다는 것을 의미합니다. 이는 모든 파일이 열리고, 디코딩되고, 신뢰할 수 있는 버전과 대조되거나, 생성한 애플리케이션에 의해 검증되었다는 뜻은 아닙니다.

데이터 스크럽이 애플리케이션이 기록한 손상을 복구할 수 있나요?

보통은 아닙니다. 애플리케이션이 잘못된 내용을 정상적으로 기록한 경우, 파일시스템은 유효한 체크섬과 함께 잘못된 바이트를 저장할 수 있어 스크럽이 블록 수준의 불일치를 감지하지 못할 수 있습니다. 복구하려면 이전의 정상 버전, 애플리케이션 인지 수리 과정, 또는 독립적인 복사본이 필요합니다.

손상된 라이브 파일을 교체하면 이전 스냅샷이 복구되나요?

아니요. 라이브 파일 교체는 활성 데이터셋에 대해 정상적인 데이터를 기록하거나 참조하지만, 이전 스냅샷은 계속해서 그들의 과거 상태를 나타냅니다. 손상된 버전을 유지한 스냅샷은 만료되거나 삭제될 때까지 일반적으로 손상된 상태로 남아 있습니다.