손상된 ZFS 복제 체인은 언제 다시 시드해야 할까요?

유효한 공통 기반을 입증할 수 없거나 체인을 복구하려면 대상의 검증되지 않은 롤백이 필요한 경우에는 다시 시드하세요. 먼저 마지막으로 읽을 수 있는 복제본을 보존하세요.

홈 NAS에서는 다음 증분 전송이 실행될 때까지 강제로 진행하는 지름길이 유혹적일 수 있습니다. 하지만 이렇게 하면 누락된 상위 스냅샷, 서로 달라진 대상, 또는 더 이상 여러분이 생각하는 데이터셋이 아닌 수신 대상이 숨겨질 수 있습니다. 양쪽을 변경하지 않은 상태에서 먼저 목록을 작성하고, 공유 기반이 여전히 존재하는지 입증한 다음, 안전한 증분 연속 전송을 뒷받침할 증거가 없으면 단계적으로 전체 시드를 수행하세요.

양쪽에 여전히 동일한 기반이 있는지 입증하기

소스 데이터셋, 대상 데이터셋, 스냅샷, 북마크, 그리고 모든 수신 재개 상태를 읽기 전용으로 목록화하는 것부터 시작하세요. 편리한 스냅샷 이름만 일치시키지 말고, 후보 기반이 의도한 데이터셋에 속하며 동일한 복제 이력을 나타내는지 확인하세요. 정리하기 전에 목록을 저장해 두면 다음 조치를 선택한 이유를 설명할 수 있습니다.

증분 ZFS 복제는 수신 측에 이미 존재하는 기반에 의존합니다. 따라서 실용적인 스냅샷 복제 시퀀스는 동일한 레이블만으로 연속성이 증명된다고 가정하지 않고 공유 이력을 의도적으로 보존합니다.

검증된 기반이 양쪽에 모두 있으면 비파괴적인 증분 테스트를 진행하세요. 이름은 존재하지만 ID 또는 데이터셋 경로가 다르면 체인이 입증되지 않은 것으로 간주하세요. 공통 기반이 더 이상 남아 있지 않다면 스냅샷을 추가로 삭제하거나 대상의 과거 상태로 강제 롤백하지 마세요. 이미 단계적 재시드 쪽으로 결정이 기울어진 상태입니다.

복제본을 변경하지 않고 증분 계획 테스트하기

검증된 기반과 최신 대상을 사용해 제안된 전송을 구성하되, 아직 실제 대상에 파이프하지 마세요. 시험 실행, 상세 예상치, 또는 복제 도구의 미리보기 모드를 사용하세요. 수신 작업이 데이터를 변경하기 전에 소스 경로, 대상 경로, 기반 스냅샷, 대상 스냅샷, 재귀 플래그, 예상 스트림 크기를 확인하세요.

스케줄러가 공통 기반 스냅샷 없음을 보고하는 것은 단순히 재시도를 요청하는 것이 아니라 안전하지 않은 추측을 거부하는 것입니다. 반복해서 재시도해도 삭제된 공유 이력이 다시 만들어지지는 않습니다.

정확한 기반과 대상에서 생성된 델타 크기의 스트림은 체인 복구를 뒷받침합니다. 데이터셋 전체 크기에 가까운 스트림, 예상과 다른 데이터셋, 또는 강제 롤백이 필요한 경우에는 미리보기가 실패한 것입니다. 그 지점에서 중단하고 현재 복제본을 보존하세요. 명령이 실행될 때까지 플래그를 바꾸는 것은 검증이 아닙니다.

이력과 대상 상태가 일치할 때만 복구 선택하기

공통 기반이 검증되었고, 대상이 독립적인 작업 복사본으로 변하지 않았으며, 미리보기에서 예상한 델타가 제안된 경우에만 증분 경로를 복구하세요. 복구 기간 동안 대상은 읽기 전용으로 유지하세요. 도구에서 허용한다면 먼저 새 하위 데이터셋이나 스테이징 대상에 전송한 다음, 승격하기 전에 비교하세요.

유효한 기반이 없거나, 대상이 서로 달라졌거나, 필요한 롤백으로 여전히 필요한 스냅샷이 삭제되거나, 체인을 입증하는 데 드는 시간이 통제된 새 전체 전송 비용을 초과하는 경우에는 재시드하세요. 증분 스냅샷 계보에 관한 논의에서도 중간 이름보다 사용 가능한 공통 지점을 유지하는 것이 더 중요하다는 점을 강조합니다.

다른 검증된 복사본이 있지 않다면 공간을 확보하기 위해 기존 대상을 지우지 마세요. 더 안전한 재시드는 별도의 데이터셋이나 풀에 기록하고, 새 복사본을 검증한 다음에야 손상된 체인을 폐기하는 방식입니다. 둘 다 보관할 용량이 없다면 마지막으로 읽을 수 있는 복제본을 실험 대상으로 만들지 말고, 작업을 일시 중지한 후 임시 공간을 확보하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

두 번의 복제 주기에 걸쳐 새 체인 검증하기

한 번의 성공적인 전체 수신은 스트림이 도착했다는 사실만 증명합니다. 소스에서 작은 테스트 파일이나 속성 변경을 만든 다음, 다음 예약 스냅샷을 생성하고 새 공통 기반을 사용해 두 번째 증분 주기를 실행하세요. 두 실행이 끝난 후 데이터셋 속성, 스냅샷 목록, 일부 파일, 복제 로그를 비교하세요.

원래 장애에 재개 동작이 포함되어 있었다면, 이전의 재개 토큰 실패 경로를 누락된 계보 문제와 분리하세요. 그래야 같은 증상 때문에 잘못된 복구 절차로 되돌아가지 않습니다.

새 시드를 읽을 수 있고, 두 번째 증분 전송이 델타 크기로 성공하며, 재부팅 또는 예약 실행 후 예상한 스냅샷과 파일이 나타나면 복구가 완료된 것입니다. 이러한 검사가 통과될 때까지 이전 복제본을 보관하세요. ID가 다시 변경되거나, 대상을 읽기 전용으로 유지할 수 없거나, 도구가 반복해서 예상과 다른 기반을 선택하면 추가 조사를 요청하세요.