2015 년 10 월 15 일 업데이트 : 오늘 나는 zpool split새로운 풀 (새로운 이름으로)을 기존 풀에서 분리하는 명령을 발견했습니다 . 두 풀이 동일한 시스템에 존재할 수 있고 개별적으로 제거 될 수 있기 split때문에 offline및 보다 훨씬 더 깨끗 detach합니다. export[ed]시스템에서 플러그를 뽑기 전에 새 풀을 깨끗하고 적절하게 정리할 수도 있습니다 .

(원래 게시물은 다음과 같습니다.)

경고! 이 페이지에 대한 다양한 의견 zpool detach은 드라이브가 가능하거나 드라이브를 다시 장착하고 포함 된 데이터에 액세스 할 수 있음을 의미합니다.

그러나이 스레드 (및 자체 실험)에
zpool detach따르면 분리 된 드라이브에서 “풀 정보”를 제거합니다. 다시 말해, a detach는 드라이브 의 빠른 재 포맷 과 같습니다 . 후 detach많은 양의 데이터 드라이브에 계속있을 수 있지만 될 것입니다 사실상 불가능 드라이브를 다시 마운트하고 사용 가능한 파일 시스템으로 데이터를 볼 수 있습니다.

결과적으로 파괴 된 수영장을 복구 할 수 있다고 생각하기 detach때문에보다 파괴적 인 것처럼 보입니다 !destroyzpool import

A는 detach것입니다 하지umount , 도zpool export , 도zpool offline .

내 실험에서 처음 zpool offline장치와 zpool detach동일한 장치를 사용하면 나머지 풀은 장치가 존재하지 않았 음을 잊어 버립니다. 그러나 장치 자체는 offline[d]이전에 있었기 때문에 장치 자체에 detach[ed]알림이 표시되지 않습니다 detach. 따라서 장치 자체에는 여전히 풀 정보가 있으며 다른 시스템으로 이동 한 다음 성능 import[ed]이 저하 된 상태 로 이동할 수 있습니다 .

추가로 보호 하기 위해 명령 을 실행하기 전에 명령 을 실행하기 전에 detach장치를 물리적으로 분리 할 수도 있습니다 .offlinedetach

나는 이것을 사용 희망 offline, 다음 detach, 다음 import내 풀을 백업 처리합니다. 원래 포스터와 마찬가지로, 4 개의 드라이브를 사용하고, 2 개는 일정한 미러에, 2 개는 월별, 회전, 오프 사이트 (및 오프라인) 백업에 사용할 계획입니다. 오프 사이트로 전송하기 전에 별도의 시스템에서 가져 와서 스크러빙하여 각 백업을 확인합니다. 원래 포스터와 달리 매월 전체 백업 드라이브를 다시 작성하는 것은 중요하지 않습니다. 사실, 나는 새로운 비트를 갖도록 완전한 재 작성을 선호합니다.

답변