NAS 간 파일 이전은 대개 지루한 작업으로 여겨진다. 양쪽 장비가 모두 SMB를 지원하고 내부망이 빠르며, Windows에는 파일을 안정적으로 복사하는 도구가 오래전부터 있었으니 말이다. 그런데 오랫동안 써온 Synology NAS의 데이터를 새 Ubiquiti UniFi UNAS Pro 8으로 옮기는 이 뻔해 보이는 작업이, 스콧 핸슬먼(Scott Hanselman)에게는 자신이 이미 안다고 믿었던 것들을 다시 배우는 하룻밤이 됐다. 그 과정에서 드러난 함정들은 사내 파일 서버나 스토리지를 다루는 한국 실무자에게도 그대로 재현될 수 있다.
92%에서 멈추는 파일의 정체
처음에는 탐색기로 복사를 시작했다가 특정 파일에서 오류가 났다. 괄호나 문장부호가 든 파일명을 의심했지만, 문제의 '05 Wires.m4p'는 딱히 특이할 게 없는 이름이었다. Robocopy로 바꿔 다시 시도하자 늘 92% 지점에서 Windows 오류 665를 반환했다. 여기서 질문을 '이 파일명이 뭐가 문제인가'에서 '경로의 어느 구간이 이 파일을 거부하는가'로 바꾼 것이 전환점이었다. Synology에서 로컬 Windows로 복사하면 성공했고, 그 로컬 파일을 UNAS로 복사하면 같은 오류가 났다. 읽기와 임시 저장은 되는데 UNAS에 쓰는 단계가 문제였던 것이다.
원인은 NTFS의 대체 데이터 스트림(ADS)이었다. 일반적으로 파일 내용이라 여기는 이름 없는 스트림 외에, NTFS 파일은 이름이 붙은 별도 스트림을 품을 수 있다. DIR /R로 확인하니 4.5MB짜리 음악 파일 옆에 '01APIC_03.jpg'라는 약 360KB의 명명된 스트림이 붙어 있었다. Robocopy가 본문을 다 넘긴 뒤 이 추가 스트림에서 걸렸기 때문에 92%라는 애매한 실패 지점이 나온 것이다. 해법은 /COPY 플래그의 X, 즉 '대체 데이터 스트림 건너뛰기'였다. 디렉터리에는 /DCOPY:DATX가 대응한다. 여기서 중요한 구분은, DATX가 MP3나 JPEG 파일 포맷 내부에 저장된 메타데이터를 지우는 게 아니라 파일에 딸린 별도의 파일시스템 스트림만 복제하지 않는다는 점이다. 이 경우 그 스트림은 새 NAS에 보존할 필요가 없는 것이었다.
오래된 습관이 성능을 갉아먹을 때
ADS 문제를 넘긴 뒤 본격적인 이전을 시작하자 속도가 들쭉날쭉했다. 수백 Mbps가 나오다가 뚝 떨어지고, 작은 파일 하나에서 한참 멈춰 있기도 했다. 버퍼링인지, 느린 디스크인지, 패리티 계산인지, 아니면 노후한 Synology의 한계인지 알 수 없었다. 스레드 수를 줄이고 단일 스레드도 시도했지만 소용없었다. 결국 /Z를 제거하자 상황이 바뀌었다. /Z는 중단된 파일을 처음부터가 아니라 이어서 복사하는 재시작 모드인데, 불안정한 연결에서는 유용하다. 저자 본인도 2007년 글에서 이를 권했을 정도다. 하지만 Microsoft의 현행 마이그레이션 지침은 재시작을 위한 추가 로깅이 복사 성능을 크게 떨어뜨릴 수 있으니 신중히 쓰라고 경고한다. /Z를 뺀 나머지 약 48GB는 실패 파일 없이 평균 약 187MB/초로 복사됐다. 변수를 하나만 통제한 벤치마크는 아니지만, 안정적인 로컬 네트워크라면 /Z 없이 시작하고 정말 필요할 때만 추가하는 편이 낫다는 결론에는 충분한 차이였다.
스레드 옵션 /MT도 마법의 숫자가 아니다. 1부터 128까지 지정할 수 있고 숫자 없이 주면 기본 8스레드다. Microsoft 지침 역시 스레드가 많다고 무조건 빨라지지 않으니 실제 워크로드로 측정하라고 못 박는다. /MT:4를 '한 파일을 네 배 빠르게'로 오해하면 안 된다. 파일을 열고 대상을 만들고 읽고 쓰고 메타데이터를 처리한 뒤 닫는 각 단계에는 네트워크나 스토리지가 대기하는 구간이 생기는데, 여러 파일을 동시에 진행하면 그 유휴 시간을 겹쳐 쓸 수 있다. 이 음악 컬렉션에는 4스레드가 잘 맞았고 16은 뚜렷한 이득이 없었다. 다만 사진 5만 장이 든 디렉터리와 900GB 디스크 이미지 네 개는 전혀 다른 워크로드이므로, /MT를 모든 명령에 박아 넣을 상수로 삼아선 안 된다. 처리량이 목적이라면 /NP, /NFL, /NDL로 출력을 줄이고 로그로 리디렉션하는 것도 함께 권장된다.
/J와 SMB 멀티채널이라는 반전
수백 GB짜리 대용량 파일을 옮길 때는 버퍼 없는 I/O를 뜻하는 /J가 대용량에 권장되니 당연한 선택처럼 보였다. 그런데 /J를 켜자 NAS 대 NAS 전송이 급격히 느려졌다. 중간의 Windows 덕분에 구간을 나눠 검증할 수 있었는데, 같은 대용량 파일을 Synology에서 로컬로 직접 복사하면 약 250MB/초가 나왔다. Synology의 읽기 성능 자체는 문제가 없었던 것이다. /J를 빼자 Synology→UNAS 직접 복사가 다시 살아났다. /J가 나쁘다는 결론이 아니라, Windows가 한 SMB 서버에서 읽으면서 동시에 다른 SMB 서버로 쓰는 이 특정 경로에서는 버퍼 I/O가 훨씬 나았다는 얘기다. 명령줄 스위치는 동작을 기술할 뿐 성능 향상을 보장하지 않는다. /J는 I/O 모델을, /MT는 동시성을, /Z는 재시작성을 바꿀 뿐, 그 변화가 이득이 될지는 시스템의 나머지에 달려 있다.
가장 뜻밖의 발견은 노후한 Synology를 향한 오해였다. 스피닝 디스크를 단 오래된 기계라 수백 Mbps가 한계라고 지레짐작했지만, 이 장비에는 1GbE 인터페이스가 네 개 있고 SMB 3는 멀티채널을 지원한다. SMB 멀티채널은 하나의 SMB 세션이 여러 네트워크 경로를 동시에 쓰게 해 대역폭을 합친다. Windows에서 활성 채널을 확인하니 네 개의 1GbE가 모두 연결에 참여하고 있었다. PC 쪽 2.5GbE 어댑터가 더 작은 파이프가 되면서 약 250MB/초가 도착했다. 즉 Synology는 한 개의 기가비트에 묶여 있던 게 아니라 서버 측 네 경로를 함께 쓰고 있었던 셈이다. Synology 문서는 이 멀티채널을 통상적인 링크 애그리게이션과 구분한다. 멀티채널은 단일 클라이언트의 SMB 성능을 높이는 반면, 링크 애그리게이션은 여러 클라이언트·서비스에 걸친 총량 처리에 가깝다는 것이다.
마지막으로 'Windows를 중간에 두는 건 불필요하지 않냐, rsync는 어떠냐'는 물음도 남는다. Synology는 rsync 서버를, UniFi Drive는 데몬 모드로 rsync 소스에서 당겨오는 백업 작업을 지원한다. 별도의 영화 공유 폴더로 rsync를 시험하니 약 67MB/초가 나왔고, 정리해야 할 추가 디렉터리 중첩이 생겼다. rsync가 일반적으로 느리다거나 디렉터리 동작을 제대로 설정할 수 없다는 뜻은 아니다. 다만 이 환경에서는 Robocopy 경로가 원하는 UNC 공유 구조를 그대로 보존하며 약 187MB/초에 이르렀기에, 우회로처럼 보이는 Windows 경유가 두 NAS의 직접 rsync 전송보다 오히려 빨랐다. 저자는 rsync가 네 개의 1기가 연결을 활용하지 못한 탓으로 추정한다. 실무적 교훈은 분명하다. 파일명이나 장비 노후를 탓하기 전에 경로를 반씩 나눠 병목을 격리하고, 옵션은 대표 데이터 조각으로 먼저 측정한 뒤 대규모 전송에 투입하라는 것이다.