USB 백업 속도는 빠른 캐시가 가득 차거나 지속적인 작업으로 더 느린 스토리지, 열 또는 전송 한계가 드러나면 수십 GB 이후 급격히 떨어지는 경우가 많습니다.
처음 50GB는 보편적인 기준이 아닙니다. 이는 전송이 버스트 동작에서 정상 상태 동작으로 넘어갔거나, 다른 파일 집합에 도달했거나, SSD 캐시가 가득 찼거나, SMR 정리가 시작되었거나, 인클로저가 과열되었거나, USB 재시도가 발생했다는 단서입니다. 정확한 진단을 위해서는 동일한 원본 데이터를 대상으로 대용량 파일 및 소용량 파일 테스트를 통제된 방식으로 수행하면서 대상 지연 시간, 온도, 링크 오류, 실제 기록 바이트 수를 기록해야 합니다.
속도 저하가 바이트 수, 시간 또는 파일 수를 따라 발생하는지 확인
경과 시간, 전송 바이트 수, 파일 수, 평균 파일 크기, 원본 읽기 속도, 대상 쓰기 속도, 처리량이 떨어지는 정확한 시점을 기록하면서 범위를 제한한 백업을 반복합니다.
Fio는 순차 및 무작위 작업을 구분하므로, 대상 장치가 고정된 바이트 용량 이후 느려지는지 아니면 백업이 많은 소용량 파일에 도달했을 때만 느려지는지 확인하는 데 적합합니다.
파일 구성과 관계없이 동일한 기록 기가바이트 수 부근에서 속도 저하가 발생한다면 캐시와 열 한계를 조사합니다. 파일 수나 디렉터리 깊이를 따라 달라진다면 메타데이터 및 애플리케이션 오버헤드일 가능성이 높습니다.
SSD 버스트 캐시가 가득 찼는지 확인
대상 미디어를 식별하고 모델, 여유 공간, 온도, 펌웨어, 지속 쓰기 동작을 기록합니다. 처음 1분의 속도와 속도 저하 이후의 속도를 비교합니다.
Crucial은 백그라운드 가비지 컬렉션에 정리 시간이 필요할 때 SSD 성능이 떨어질 수 있다고 설명합니다. 따라서 짧은 고속 버스트는 드라이브의 장시간 쓰기 속도를 나타내지 않습니다.
드라이브가 식고 백그라운드 정리를 수행할 수 있을 만큼 작업을 일시 중지한 다음 동일한 데이터로 재개합니다. 일시적인 속도 회복은 캐시 또는 열 압박을 뒷받침하지만, 온도와 지연 시간 데이터를 확인하지 않으면 어느 쪽인지 특정할 수 없습니다.
드라이브 관리형 SMR 정리 배제
USB 대상 장치에 드라이브 관리형 SMR 디스크가 포함되어 있는지 확인합니다. 하나의 대형 순차 스트림과 여러 소용량 파일을 반복적으로 업데이트하거나 생성하는 백업을 비교합니다.
Seagate는 SMR이 예측 가능한 쓰기에서 가장 잘 작동한다고 설명합니다. 반면 조각화된 업데이트나 무작위 업데이트는 추가적인 내부 데이터 이동을 일으켜 정상 상태 속도를 낮출 수 있습니다.
용량이나 브랜드만으로 SMR이라고 판단하지 마세요. 정확한 모델을 확인하고, 빈번한 증분 백업이나 메타데이터 중심 백업과 작업 특성이 맞지 않는 드라이브는 사용하지 마세요.
USB 리셋, 자동 절전 및 링크 재시도 확인
백업 시작 전부터 속도 저하가 발생할 때까지의 호스트 로그를 저장합니다. 장치 리셋, UAS 오류, 명령 중단, 협상된 속도 변경, 연결 끊김, 자동 절전 전환을 확인합니다.
Linux 커널은 USB 런타임 전원 관리를 문서화하고 있어, 스토리지 미디어 자체의 속도 저하와 지속 부하에서 반복적으로 절전, 재개 또는 리셋되는 전송 경로를 구분하는 데 도움이 됩니다.
USB 링크가 연결된 상태로 유지되더라도 재시도로 인해 유효 처리량이 감소할 수 있습니다. 파일 시스템이나 백업 설정을 변경하기 전에 후면의 직접 연결 포트, 정상 작동이 확인된 짧은 케이블, 올바른 전원 어댑터, 다른 호스트를 사용해 테스트합니다.
백업이 소용량 파일 작업으로 전환되는지 확인
속도 저하가 발생한 전후의 백업 로그를 확인하고 평균 파일 크기, 파일 생성률, 메타데이터 작업, ACL 처리, 체크섬, 압축, 암호화를 비교합니다.
Red Hat은 소용량 파일 스토리지를 메타데이터 중심 작업으로 설명합니다. 따라서 백업이 대용량 페이로드 파일에서 생성, 닫기, stat 및 디렉터리 업데이트가 많은 작업으로 전환되면 낮은 MB/s 값이 정상일 수 있습니다.
초당 파일 처리 수와 초당 메가바이트 수를 함께 측정합니다. 소용량 파일 단계에서는 바이트 처리량이 낮게 표시되더라도 스토리지 스택이 계속 바쁘면서 응답성을 유지할 수 있습니다.
여유 공간, discard 및 쓰기 증폭 확인
대상의 여유 공간, 스냅샷 보존, 휴지통 사용량, 씬 할당 여부, USB 브리지와 파일 시스템을 통해 discard가 SSD에 전달되는지 여부를 기록합니다.
fstrim 매뉴얼은 사용하지 않는 블록을 효율적으로 재사용하려면 지원되는 스토리지에 해당 정보가 전달되어야 한다고 설명합니다.
안전하게 전달하지 못하는 인클로저에서는 discard를 활성화하지 마세요. 먼저 충분한 여유 공간을 확보한 다음, 지원되는 정리 작업 후 동일한 백업 구간을 비교합니다.
하드웨어를 교체하기 전에 통제된 A/B 백업 실행
대용량 파일 테스트 세트 하나와 동일한 크기의 소용량 파일 테스트 세트 하나를 만듭니다. 냉각 후 각각을 동일한 대상에 실행하고, 온도와 오류를 기록하면서 다른 USB 경로나 대상에서도 반복합니다.
ZimaSpace의 대규모 초기 백업 준비 가이드는 백업 일정 및 네트워크 포화와 대상 장치의 정상 상태 성능을 구분하는 데 필요한 관련 방법을 제공합니다.
속도 저하가 캐시 고갈, SMR 정리, 파일 구성, 발열, USB 재시도 또는 재사용 가능한 여유 공간 부족 중 하나의 측정 가능한 조건을 따라 발생하고, 수정된 경로가 예상되는 정상 상태 속도를 유지하면 진단이 완료된 것입니다.
자주 묻는 질문
50GB 이후 속도가 느려지면 드라이브에 50GB 캐시가 있다는 뜻인가요?
아닙니다. 해당 기준은 경과 시간, 온도, 파일 구성, 여유 공간 압박 또는 내부 정리를 반영할 수도 있습니다. 캐시 크기를 추정하기 전에 다양한 데이터 형태로 반복 테스트하세요.
백업을 일시 중지하면 속도가 일시적으로 회복되는 이유는 무엇인가요?
일시 중지로 SSD가 캐시된 데이터를 정리하거나, SMR 디스크가 쓰기를 재구성하거나, 인클로저가 냉각되거나, USB 전송 경로가 복구될 수 있습니다. 이 요인들을 구분하려면 온도와 지연 시간 로그가 필요합니다.
백업 성능을 초기 속도로 판단해야 하나요?
아닙니다. 용량 계획에는 캐시가 가득 차고 데이터, 메타데이터, 검증 및 보존 작업의 일반적인 구성이 적용된 후의 안정적인 속도를 사용해야 합니다.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

