☰

두 Linux 시스템 간에 휴대용 암호화 ZFS 형식 드라이브 공유 문제

tag-icon • tag-icon zfs
두 Linux 시스템 간에 휴대용 암호화 ZFS 형식 드라이브 공유 문제

암호화된 ZFS 형식의 휴대용 USB 하드 드라이브를 공유하려는 두 대의 Linux(NixOS) 시스템이 있습니다. 단일 시스템에서는 이 작업이 제대로 작동하도록 했지만 두 번째 시스템에 마운트하려고 하면 드라이브의 ZFS 파일 시스템이 손상되었을 수 있습니다.

USB 드라이브를 한 시스템에서 다른 시스템으로 이동하기 전에 zpool을 내보내 마운트 해제했습니다. 두 번째 시스템의 드라이브에서 zpool을 가져올 수 있기를 바랐지만 ZFS의 zpool 개념을 오해했을 수도 있습니다. zpool list, zpool import -a, 등 의 다양한 조합을 사용하여 두 번째 시스템에서 ZFS 드라이브를 전혀 볼 수 없게 했습니다. zpool import -D드라이브는 확실히 로 표시되었지만 /dev/sdb이 두 번째 시스템에서 ZFS의 자동 감지는 알 수 없는 이유로 단순히 이를 무시했습니다.

결국 나는 zpool이 이 시스템에서 미러링해야 하는 완전히 가상의 것이라고 생각하면서 간단한 작업을 수행했지만 sudo zpool create z /dev/sdb이 명령은 경고 없이 이 드라이브의 원래 ZFS 파일 시스템을 덮어쓴 것 같습니다. 이제 드라이브는 암호화되지 않은 비어 있는 파일 시스템이 되었으며 여기에서 데이터를 복구할 수 있는지조차 확신할 수 없습니다. 다행히 백업이 있어서 총 손실은 아니었습니다.

두 가지 질문:

  1. 기존 vdev 위에 새 zpool을 생성하면 해당 장치의 이전 ZFS 파일 시스템이 영구적으로 파괴됩니까?

  2. 기존의 암호화된 ZFS 드라이브 zpool을 한 시스템에서 다른 시스템으로 가져오고 압축, 암호화, 데이터 세트 등과 같은 모든 원래 zpool 구성 옵션을 가져올 수 있는 방법은 무엇입니까? 그렇지 않다면 zpool import무엇입니까?

답변1

실험을 통해 첫 번째 질문에 답했다고 가정합니다. 예, zpool create영향을 받은 vdev의 기존 풀을 손상시키는 작업을 수행합니다.

이 풀을 공유하려는 시스템 간의 호환성을 보장하기 위해 노력하고 있다는 점을 고려하면 zpool 구조의 메커니즘이 정확하고 잠재적인 방해 요소가 없다고 확신할 때까지 암호화를 포기하는 것이 좋습니다. 테스트가 성공하지 못하게 하세요.

ZFS 풀을 시스템 간에 이식할 수 있는 데 필요한 조건 중 하나는 풀을 구성하는(그리고 풀 메타데이터에 인코딩된) 블록 장치가 풀을 가져올 모든 시스템에서 명확해야 한다는 것입니다. 이로 인해 등과 같은 물리적 장치만 사용하는 것은 현명하지 못합니다 /dev/sdb. 사용할 각 드라이브에 파티션을 만들고 사용되는 각 파티션에 고유한 레이블을 할당하는 것이 더 좋습니다. 드라이브의 일련 번호는 풀 메타데이터뿐만 아니라 출력에서도 전자적으로 표시되고 blkid물리적 드라이브 섀시 검사 시 사람이 볼 수 있으므로 사용하기 편리한 문자열인 경우가 많습니다.

따라서 하드 드라이브의 일련 번호가 이면 6SL0CTD해당 드라이브에 파티션을 만들고 레이블을 지정해야 합니다 zfs-data-6SL0CTD. 그런 다음 가변 물리적 장치 대신 해당 논리 장치를 참조하는 풀을 만듭니다.

# zpool create tank /dev/disk/by-partlabel/zfs-data-6SL0CTCD

또한 의 매뉴얼 페이지를 읽고 zpool import무엇을 가져오는지(또는 가져오지 않는 이유) 확실하지 않을 때 사용할 수 있는 비파괴적 도구가 많이 있다는 점에 유의하세요.

매개변수가 없는 경우:

# zpool import

가져올 수 있는 풀이 표시됩니다. 현재 테스트 케이스는 없지만, 풀도 보여줄 것이라고 믿습니다.할 수 없다일반적으로 누락되거나 고장난 장치로 인해 가져올 수 없습니다. 장치가 "누락"되는 원인 중 하나는 풀 메타데이터에 /dev/sdb를 사용해야 한다고 나와 있지만 호스트에 이미 /dev/sdb가 있고 해당 장치에 풀과 일치하는 메타데이터가 없기 때문일 수 있습니다. 다시 말하지만, 파티션 레이블을 할당하고 파티션 레이블만을 기반으로 풀을 생성하는 것이 중요한 이유입니다. 해당 파티션 레이블이 있으면 풀을 찾을 수 있으며 무엇이든 상관 없습니다.물리적파티션이 나타나는 장치.

# zpool import -N tank

풀을 가져오지만 tank풀에서 어떤 파일 시스템도 마운트하지 않습니다. 이는 풀의 두 번째 수준 검사로 사용될 수 있습니다. 아무것도 마운트되지 않았지만 풀의 통계를 검사할 수 있고 풀을 scrub침대로 둘 수도 있습니다.

명확한 장치 이름을 사용하도록 풀을 올바르게 생성했다면 나중에 이것이 왜 중요한지 알 수 있습니다.

zpool status -P풀에 있는 모든 장치의 전체 논리적 경로가 표시됩니다.

# zpool status -P
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 21h34m with 0 errors on Sun Oct 10 21:58:23 2021
config:

    NAME                                            STATE     READ WRITE CKSUM
    tank                                          ONLINE       0     0     0
      /dev/disk/by-partlabel/zfs-data-6SL0CTCD    ONLINE       0     0     0

errors: No known data errors

반대로 zpool status -L표시됩니다 .물리적풀에 있는 모든 장치의 장치 이름:

# zpool status -L
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 21h34m with 0 errors on Sun Oct 10 21:58:23 2021
config:

    NAME                                            STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      sdb1                     ONLINE       0     0     0

errors: No known data errors

물리적 장치 노드 대신 파티션 레이블을 사용하는 최종 결과는 풀을 가져오는 모든 시스템에서 출력이 zpool status -P동일하지만 출력은 zpool status -L다를 수 있다는 것입니다. 따라서 zpool create풀을 가져와야 할 수 있는 모든 시스템에서 명확성이 보장되는 비변형 논리 장치 측면에서 명령을 작성해야 하는 이유입니다.

명확한 장치 이름으로 구성된 풀을 확보한 후에는 풀을 가져올 수 있어야 하는 호스트에 합리적으로 유사한 ZFS 스택이 있다는 가정하에 zpool에 암호화를 적용하는 것이 간단해야 합니다.

관련 정보