백업을 보내려 는 풀은 zfs send기본 시스템의 백업을 위해 특별히 설정되었습니다. 원격 위치에 드라이브 미러가 있어야 합니까? 아니면 다음에 호출될 때 zfs가 오류를 수정할 만큼 똑똑합니까 zfs send?
명확히 하자면: 집에 zfs 풀로 미러링된 드라이브 2개가 있는 메인 서버가 있습니다. 이제 zfs가 포함된 OS를 실행하는 외부 서버로 대체할 수 없는 데이터를 보내고 싶습니다.
문제는 오프사이트 중복성도 필요한지 여부입니다.
zfs scrub외부 위치에서 오류가 발견되었다고 가정해 보겠습니다 . zfs send버그가 수정 될까요 ?
답변1
미러가 반드시 필요한 것은 아니지만 그렇게 하면 풀에 저장된 데이터의 신뢰성이 높아집니다.
영향을 받은 데이터가 중복되지 않으면 ZFS는 오류를 복구하지 않습니다. 디스크 자체는 불량 블록을 내부적으로 교체하여 처리하므로 풀을 다시 보내면 문제가 "수정"됩니다. 그러나 나는 이것에 너무 많은 것을 걸지 않을 것이며 계속 실패하는 디스크를 교체하지도 않을 것입니다.
불량 섹터는 디스크 자체에서는 발견되지 않으므로 읽어야 합니다. 이 zpool scrub명령은 zfs 풀에서 오류를 검색하도록 설계되었습니다.
답변2
이것Solaris ZFS 모범 사례 문서이 질문에 대답하세요:
ZFS 중복성(RAIDZ 또는 미러링) 없이 생성된 풀은 데이터 불일치만 보고할 수 있습니다. 데이터 불일치를 수정할 수는 없습니다. ZFS 중복 없이 생성된 풀은 비중복 ZFS 구성에서 디스크를 교체하거나 분리할 수 없기 때문에 관리하기가 더 어렵습니다.
zfs send/recv데이터를 덮어쓸 때(올바른 플래그를 사용하는 경우) 이것이 걱정할 사항인지 여부는 귀하의 사례에 따라 다릅니다 . 예를 들어, 5분마다 새 블록을 전송하고 기본 풀이 2분 후에 종료되는 경우 백업 풀이 일주일, 한 달 또는 그 이상에 한 번만 업데이트되는 경우보다 손상 가능성이 훨씬 낮습니다.
하드웨어 가용성도 중요할 수 있습니다. 백업 디스크가 수명을 다했지만(문제 없습니다. 기본 풀은 여전히 남아 있음) 하루 동안 교체할 수 없어 예약된 여러 백업이 이제 실패하게 된다면 어떻게 될까요? 중복성은 데이터 무결성뿐만 아니라 하드웨어 수준에서도 도움이 됩니다. 물론, 계속 작동할 다른 두 대의 기계가 있는 경우에는 문제가 되지 않습니다.
특별한 사용 사례(공간이나 포트 제한으로 인해 하나의 디스크만 사용할 수 있고 풀 크기가 최대 디스크 크기의 절반 미만)의 경우 copies=2백업 풀을 설정하는 옵션이 있습니다. 이렇게 하면 데이터가 백업 풀에 내부적으로 복제되어(200% 공간 필요) 데이터 무결성을 제공하지만 하드웨어 오류로 인해 여전히 백업 풀이 파괴될 수 있습니다. 그럼에도 불구하고 장기 오프사이트 백업 스토리지나 단일 디스크만 사용할 수 있는 소규모 시스템에 유용할 수 있습니다. 기존 데이터에서는 작동하지 않으므로 나중에 전체 백업이 필요합니다.
또한 링크 가이드의 경고:
ZFS 전송 스트림이 파일이나 테이프에 저장되어 있고 파일이 손상되면 해당 스트림이 수신되지 않으며 모든 데이터를 복구할 수 없습니다.
즉, 그렇게 하지 않을 타당한 이유가 없는 한 send이 옵션을 와 함께 사용해야 함을 의미합니다 receive. 활성 가져오기 풀만 손상 여부를 검사할 수 있기 때문입니다. 스트림만 저장하려는 경우(예: 대상 풀이 여러 스트림을 동시에 보유하는 경우) zstreamdump무결성 검증이 권장됩니다.