ZFS 데이터 세트 마이그레이션 가이드: 컨테이너 경로를 변경하지 않고 데이터 이동

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

안전한 접근 방식은 복제, 검증, 원래 마운트 지점으로의 원자적 전환, 롤백 데이터셋 보존을 단일 명령이 아닌 관찰 가능한 단계들의 연속으로 다루는 것입니다.

홈 서버 컨테이너 스택을 뒷받침하는 ZFS 데이터셋에서는 컨테이너가 사용하는 바인드 마운트 경로를 유지하면서 ZFS 데이터셋을 이동해야 한다는 점이 실질적인 위험입니다. 현재 식별 정보와 복구 지점을 기록하고, 가장 영향이 적은 판별부터 시작하며, 다른 변수를 변경하기 전에 성공과 실패 결과를 해석하고, 스토리지가 불안정해지거나 복구 가능한 유일한 사본이 노출될 상황에서는 중단하세요. 아래 워크플로는 원래 워크로드가 성공하거나 증거가 에스컬레이션 경계에 도달한 경우에만 종료됩니다.

데이터셋과 경로 계약을 파악하세요

소스 데이터셋, 하위 데이터셋, 스냅샷, 마운트 지점, canmount 값, 암호화 루트, 할당량, 예약 공간, ACL 동작, 그리고 그 안에 연결되는 모든 컨테이너 바인드 마운트를 기록하세요. 계약의 핵심은 컨테이너가 보는 호스트 경로이며, 그 아래에서 풀과 데이터셋 이름은 변경될 수 있습니다.

ZFS 복제는 스냅샷과 속성을 보존할 수 있으므로, 재귀 스트림에는 맹목적인 수신이 아니라 신중한 속성 검토가 필요합니다. 독립적인 ZFS send 및 receive 마이그레이션 문서에서는 내부 데이터셋 마이그레이션에 send와 receive를 사용하는 방법과 전환 전에 대상 계층을 점검해야 하는 이유를 설명합니다.

마이그레이션 전에 최신 외부 백업을 생성하거나 기존 복구가 가능함을 입증하세요. 소스에 숨겨진 하위 데이터셋, 알 수 없는 암호화 키 종속성, 또는 다른 활성 데이터셋과 겹치는 마운트 지점이 있다면 중단하세요. 이러한 조건에서는 올바른 스트림도 잘못된 위치에 마운트될 수 있습니다.

프로덕션 위에 마운트하지 않고 첫 번째 사본을 수신하세요

zfs snapshot -r oldpool/apps@move-0과 같은 재귀 스냅샷을 만든 다음, 마운트를 비활성화하거나 임시 마운트 지점을 사용하도록 설정한 대상 데이터셋으로 전송하세요. 암호화 및 속성 요구 사항에 맞는 플래그를 사용하고, 원시 암호화 스트림과 복호화된 수신이 동일한 키 동작을 한다고 가정하지 마세요.

수신 후 양쪽 트리에서 zfs list -r -t filesystem,snapshot과 zfs get -r mountpoint,canmount,encryptionroot,quota,reservation의 결과를 비교하세요. 복제된 마운트 지점 속성에 관한 포럼 토론은 복제된 마운트 지점 속성이 성공적인 마이그레이션에서도 예상치 못한 결과를 일으킬 수 있는 이유를 보여줍니다.

데이터셋과 스냅샷 계보가 일치하고 대상이 프로덕션 경로와 격리된 상태라면 첫 번째 사본은 통과한 것입니다. 대상이 소스 위에 마운트되거나 컨테이너가 보는 파일이 변경되면 대상을 내보내거나 마운트 해제하고, 증분 전송을 수행하기 전에 속성을 수정하세요.

쓰기 공백을 해소하고 마운트 지점을 전환하세요

앱이 계속 실행되는 동안 소스의 스냅샷을 하나 더 생성하고 증분 차이를 전송하세요. 최종 전환을 위해 모든 쓰기 작업을 중지하고, 바인드 마운트 경로 아래에 열린 파일을 가진 프로세스가 없는지 확인한 다음, 최종 스냅샷을 생성하고 해당 델타만 전송하세요. 다운타임은 최종 동기화와 경로 전환에만 한정하세요.

소스를 비프로덕션 마운트 지점 또는 canmount=noauto로 설정한 다음, 원래 호스트 경로를 대상에 할당하고 마운트하세요. 두 데이터셋이 동일한 마운트 지점을 차지하도록 두지 마세요. 오류가 올바른 계층을 가리키도록 애플리케이션 프런트엔드보다 먼저 데이터베이스와 종속 서비스를 시작하세요.

최종 전송이 실패하면 소스를 원래 경로에 다시 마운트하고 스택을 재시작하세요. 두 사본에 새로운 쓰기를 섞어서 수행하지 마세요. 롤백 조건은 명확합니다. 소스는 온전한 상태로 유지되며, 최종 스트림과 속성 검사가 통과하기 전까지 대상에서는 어떤 프로덕션 쓰기도 허용하지 않습니다.

변경되지 않은 경로에서 컨테이너를 검증하세요

컨테이너 런타임에서 바인드 마운트를 검사하고, 대표 파일을 열어 보며, 앱을 통해 임시 파일을 생성하고 삭제하고, 소유권, ACL, 확장 속성, 여유 공간 보고를 확인하세요. 스택을 두 번 재시작하고 컨테이너가 시작되기 전에 ZFS가 마운트되는지 확인하세요.

유지 관리 계획에 따라 스크럽이나 기타 풀 상태 점검을 실행하되, 이를 마이그레이션의 유일한 증거로 사용하지 마세요. 스냅샷 GUID 또는 대표 해시 매니페스트를 비교하고, 작은 항목 하나를 복원하며, 소스 계보를 폐기하기 전에 ZimaSpace의 중단 후 ZFS 복제를 재개할 수 있는지 확인하는 테스트를 사용하세요.

최소 한 번의 정상적인 백업 및 애플리케이션 주기가 성공할 때까지 소스를 읽기 전용으로 유지하세요. 컨테이너가 원래 경로를 사용하고, 예약 작업이 새 데이터셋을 대상으로 하며, 복제가 의도한 계보에서 계속되고, 롤백이 더 이상 필요하지 않을 때만 소스를 폐기하세요. 그렇지 않으면 마운트 지점을 되돌리고 두 기록을 모두 보존하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.