전체 리 실버없이 ZFS 디스크를 분리했다가 다시 연결할 수 있습니까?

총 4 개의 드라이브가있는 ZFS 미러 풀이 있습니다. 두 드라이브는 오프 사이트 백업 회전에 사용됩니다. 초기 리 실버 링 detach후 attach디스크를 나중에 나중에 증분 리 실버 만 수행 할 수있을 것으로 기대 했지만 테스트에서는 연결된 디스크에 이미 거의 모든 풀이 포함되어 있는지 여부에 관계없이 전체 리 실버를 수행하는 것으로 보입니다. 내용.

offline/ online접근 방식을 사용하면 디스크를 완전히 재구성하지 않고 디스크 만 업데이트하여 원하는 결과를 얻을 수 있습니까? 또는이 작업을 예상대로 수행하려면 각 백업 디스크를 1 디스크 풀로 사용하고 send최신 스냅 샷을 최신 상태로 만들어야 할 때마다 완전히 다른 작업을 수행해야 합니까?

디스크를 오프 사이트로 "회전"시키기 위해 ZFS 어레이를 망가 뜨리지 마십시오. 보시다시피, 재 구축 시간이 길고 리 실버 링 프로세스가 사용 된 데이터 세트 크기를 읽거나 확인합니다 .

기능이 있으면 스냅 샷을 작성하고 원격 시스템으로 데이터를 보내는 것이 깨끗하고 방해가되지 않는 접근 방식입니다. 전용 단일 디스크 풀, 복사 및 zpool 내보내기 / 가져 오기 프로세스를 수행 할 수 있다고 가정하지만 매우 우아하지는 않습니다.

추가 실험 후 나는 공정한 해결책을 찾았지만 상당한 절충안이 따른다. offline분리되었지만 분리되지 않은 디스크 는 나중에 증분 리실 버닝 작업만으로 온라인 상태로 되돌릴 수 있습니다 ( " 장치가 온라인 상태가되면 풀에 기록 된 모든 데이터는 새로 사용 가능한 장치와 재 동기화됩니다. "). 내 테스트에서 이것은 약 40GB의 데이터 델타로 28 시간에서 30 분이 조금 넘는 3 디스크 미러의 리 실버 링 시간을 제공합니다.

단점은 오프라인 디스크가있는 모든 풀이 성능이 저하 된 것으로 표시된다는 것입니다. 여전히 미러링 된 풀에 두 개 이상의 온라인 디스크가있는 경우 이는 사실상 경고입니다. 무결성과 중복성은 그대로 유지됩니다.

다른 사람들이 언급 했듯이이 전반적인 접근 방식은 이상적이지 않습니다. 스냅 샷을 원격 풀로 보내는 것이 훨씬 적합하지만 제 경우에는 불가능합니다.

요약하면 풀에서 디스크를 제거하고 나중에 전체 리 실버 링없이 디스크를 다시 추가해야하는 경우 다음과 같은 방법을 권장합니다.

• 풀에서 디스크를 오프라인으로 : zpool offline pool disk
• 드라이브를 물리적으로 잡아 당기려면 스핀 다운하십시오. hdparm -Y /dev/thedisk
• 드라이브가 오프라인 상태 인 상태에서 풀을 성능 저하 상태로 유지
• 디스크를 풀에 다시 추가하려면 zpool online pool disk

그리고 아직 테스트되지 않았으므로 델타 리 실버 링 작업이 정확하지 않을 위험이 있습니다. "실시간"풀 및 / 또는 오프라인 디스크에 문제가 발생할 수 있습니다. 그런 일이 발생하면 업데이트하지만 지금은이 접근법을 실험 해 보겠습니다.

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 개는 월별, 회전, 오프 사이트 (및 오프라인) 백업에 사용할 계획입니다. 오프 사이트로 전송하기 전에 별도의 시스템에서 가져 와서 스크러빙하여 각 백업을 확인합니다. 원래 포스터와 달리 매월 전체 백업 드라이브를 다시 작성하는 것은 중요하지 않습니다. 사실, 나는 새로운 비트를 갖도록 완전한 재 작성을 선호합니다.

동일한 머신에서 미러에 2 개의 드라이브가있는 새 풀을 작성해 보셨습니까? 그런 다음 작업 풀에서 스냅 샷을 생성 한 다음 해당 스냅 샷을 새 풀로 전송하고 반복하면 다음 스냅 샷 전송이 증분됩니다. "원격 시스템에 데이터 전송"과 동일하지 않습니다. 동일한 시스템 / 서버 / 시스템 내의 풀이 기 때문입니다. 이 설정을 사용하면 zpool split / offline / detach / attach를 계속 적용 할 수 있지만 소스 풀이 아닌 두 번째 (복사) 풀에서만 수행 할 수 있습니다.