원래 사용자의 문제는 단순히 “두 ZimaOS 장치에서 데이터를 복사할 수 없다”는 것이 아니었습니다. ZimaOS 1.5.x를 실행하는 시스템 간에 약 600GB를 이동하던 중, 두 서버 자체는 계속 온라인 상태였지만 Files 전송이 “호스트가 다운되었습니다”라는 메시지와 함께 반복적으로 중단되었습니다.
이 과거 동작은 현재 ZimaOS와 구분해야 합니다. IceWhale은 이제 다른 NAS에서 데이터를 이동할 때 Files의 LAN Storage를 사용할 것을 명시적으로 권장하며, 현재 Backup 앱은 다른 Zima 장치를 대상으로 지정할 수 있고 재개 가능한 장애 허용 작업을 제공합니다. 매우 큰 데이터를 전송할 때는 일회성으로 눈에 보이는 복사를 원하는지, 재개 가능한 보호 작업을 원하는지, 아니면 가장 빠른 물리적 이동을 원하는지에 따라 방법을 선택하세요.
두 호스트가 모두 온라인 상태였지만 원본 Files 전송이 반복적으로 재설정됨
사용자는 양방향을 모두 시도했습니다. 기존 ZimaOS 장치에서 새 장치로 푸시하거나 새 장치에서 기존 장치로 가져오는 경우 모두, 원본 대시보드에 계속 접속할 수 있었지만 브라우저 기반 Files 작업은 결국 중단되었습니다.
커뮤니티에서는 가장 재개하기 쉬운 CLI 옵션으로 rsync를 권장함
커뮤니티 답변에서는 SSH를 통한 rsync와 부분 전송 지원을 사용하면 복사가 중단되어도 처음부터 다시 시작하지 않고 재실행할 수 있다고 제안했습니다. 이는 고급 사용자에게 유용한 안내지만, IceWhale 직원이 게시한 내용은 아니며 원래 사용자가 이를 사용했다고 확인한 것도 아닙니다.
현재 IceWhale 안내에서도 NAS 간 마이그레이션에 Files를 사용함
현재 ZimaOS 문서에서는 기존 NAS를 Files의 LAN Storage로 추가한 뒤 폴더를 새 ZimaOS 저장소로 복사할 것을 권장합니다. 따라서 이전 1.5.x의 시간 초과 사례를 근거로 “대규모 마이그레이션에는 Files를 절대 사용하지 말라”고 일반화해서는 안 됩니다.
일반적인 방식으로 내용을 확인하며 복사하려면 현재 LAN Storage 마이그레이션 절차를 사용하세요.
현재 Backup은 다른 Zima 장치를 대상으로 지정할 수 있음
수동으로 대상 위치를 탐색하는 것보다 재개 기능이 중요한 장시간 전송의 경우, 현재 Backup 앱은 다른 Zima 장치를 대상으로 지원합니다. IceWhale은 일정 예약, 실시간 진행률, 재개 및 장애 허용 기능을 문서화하고 있습니다.
현재 재개 가능한 Zima 간 백업 절차를 참조하세요.
SMB는 브라우저 복사 방식의 간단한 대안임
원래 커뮤니티에서는 대상 장치에 원본 SMB 공유를 마운트한 뒤 대상 측에서 복사하는 방법도 권장했습니다. 사용자는 이전에 마운트된 SMB 공유를 사용해 구형 NAS에서 ZimaOS로 데이터를 성공적으로 이동한 경험이 있었습니다.
장치가 물리적으로 가까우면 USB 또는 NVMe 이동 장치가 가장 빠를 수 있음
수백 GB 또는 수 TB를 전송할 때는 고속 외장 SSD/NVMe를 사용하면 네트워크 변수를 모두 피할 수 있습니다. 단, 원본에서 이동 장치로 한 번 복사하고 이동 장치에서 대상 장치로 다시 복사해야 합니다.
작은 파일이 많으면 마이그레이션이 훨씬 느려 보일 수 있음
AppData, 썸네일, 사진 사이드카 파일, 코드 트리 및 기타 메타데이터 중심 데이터셋은 각 파일마다 열기, 생성 및 메타데이터 작업이 필요하므로 대용량 미디어 파일보다 훨씬 느리게 이동될 수 있습니다.
원본을 삭제하기 전에 확인하세요
어떤 마이그레이션이든 완료한 후 대표 폴더와 가능한 경우 파일 수를 비교하고, 대상 장치에서 중요한 파일을 직접 열어 보세요. 새 장치를 성공적으로 사용하고 백업이 생성될 때까지 원본을 그대로 유지하세요.
Files와 Backup은 서로 다른 마이그레이션 문제를 해결함
원본을 탐색하고 특정 폴더를 선택하며 대상에서 복사된 파일을 즉시 확인하려면 Files가 더 적합합니다. 전송에 수 시간 또는 수 일이 걸릴 것으로 예상되고 재개 및 장애 허용, 일정 예약, 복구 가능한 작업 기록이 중요하다면 Backup이 더 적합합니다.
Backup 작업을 투명한 “이동”이라고 부르지 마세요. Backup은 자체 복원 방식에 따라 보호된 복사본을 생성하므로, 원본을 삭제하기 전에 대상의 폴더 구조를 확인하세요.
복사 도구를 최적화하기 전에 네트워크 경로를 확인하세요
명목상 1GbE 연결이라도 두 장치가 실제로 기가비트 이더넷으로 협상되었는지, Wi-Fi나 100Mb/s 구간이 포함되지 않았는지, 스위치와 케이블이 정상인지 확인하세요. 복사 도구는 느린 물리적 연결 속도를 초과할 수 없습니다.
그런 다음 큰 파일 하나를 테스트하세요. 큰 파일은 빠르지만 디렉터리 트리는 느리다면, 원시 네트워크 대역폭보다 데이터셋의 파일 수와 메타데이터 처리 부담이 더 큰 원인일 가능성이 높습니다.
사용자 파일과 실행 중인 AppData는 서로 다르게 처리해야 함
영화, 사진 및 문서는 일반적으로 일반 파일처럼 복사할 수 있습니다. 실행 중인 애플리케이션 데이터베이스와 AppData는 내부 일관성을 유지하려면 애플리케이션을 중지하거나, 데이터를 내보내거나, 애플리케이션에 맞는 절차로 마이그레이션해야 할 수 있습니다.
실행 중인 데이터베이스 디렉터리를 장치 간에 복사한다고 해서 유효한 애플리케이션 마이그레이션이 된다고 가정하지 마세요.
공유 권한은 의도적으로 보존하거나 다시 구성하세요
모든 바이트가 도착했더라도 대상 ZimaOS 장치에는 자체 사용자, 공유 정의 및 컨테이너 매핑이 있습니다. 필요한 Samba 권한과 앱 볼륨 경로를 다시 구성한 다음, 관리자 권한이 없는 실제 사용자의 계정으로 접근을 테스트하세요.
중요한 데이터에는 2단계 전환을 사용하세요
대규모 NAS 마이그레이션에서는 먼저 기존 장치를 활성 상태로 유지한 채 대량의 데이터를 복사하세요. 전환 직전에 쓰기 작업을 중지하거나 일시 중지하고, 최종 증분 또는 재개 가능한 전송을 실행한 뒤 대상을 확인하고 클라이언트를 새 장치로 전환하세요. 이렇게 하면 중단 시간을 줄이고 유일한 정상 복사본을 너무 일찍 삭제하는 일을 방지할 수 있습니다.
ZimaOS 장치 간 마이그레이션 FAQ
원본 사례를 통해 대용량 복사에서 Files가 항상 신뢰할 수 없다는 사실이 입증되었나요?
아니요. 해당 사례는 1.5.x에서 발생한 오류를 기록한 것입니다. 현재 IceWhale 안내에서는 NAS 마이그레이션에 여전히 Files/LAN Storage를 사용합니다.
현재 어떤 옵션이 재개 가능한 Zima 간 전송을 지원하나요?
현재 Backup 앱은 다른 Zima 장치를 대상으로 지정할 수 있으며 재개 및 장애 허용 기능을 포함합니다.
rsync가 원래 사용자가 최종적으로 사용한 방법이라고 확인되었나요?
아니요. rsync는 커뮤니티의 조언이었으며, 사용자는 이후 마이그레이션이 완료되었다고만 말했고 최종 전송 방법은 문서화하지 않았습니다.
