대소문자만 다른 파일 이름 충돌은 백업에 복원 대상이 동등하다고 간주하는 두 경로가 포함된 경우 크로스 플랫폼 NAS 복원 중에 발생합니다. Linux 홈 서버는 이를 보존할 수 있습니다 Photo.jpg 및 photo.jpg 별도의 파일로 저장되는 반면, Windows 볼륨, 기본 macOS 볼륨 또는 SMB 클라이언트는 해당 이름들을 하나의 대상으로 처리할 수 있습니다. 복원 도구는 그 후 덮어쓰기, 이름 변경, 건너뛰기, 병합 또는 중단해야 합니다.
충돌한 경로와 도구가 이를 어떻게 처리했는지 알기 전까지 전체 복원을 계속하지 마십시오. 영향을 받은 트리를 격리된 임시 위치에 복원하고, 결정론적 임시 이름으로 두 소스 객체를 모두 보존하며, 라이브 NAS 공유로 데이터를 이동하기 전에 경로 매핑 기록을 만드십시오.
왜 백업은 복원 대상이 거부하는 두 이름을 저장할 수 있나요?
백업 저장소는 대상 파일시스템의 비교 규칙을 강제하지 않고 경로를 불투명한 이름으로 기록할 수 있습니다. Linux 파일시스템은 대문자와 소문자를 구분하는 반면, Windows와 기본 macOS 파일시스템은 입력된 대소문자를 보존하지만 이름을 대소문자 구분 없이 비교하는 경우가 많습니다. 크로스 플랫폼 복원 논의에서는 소스 경로가 백업에서는 유효하지만 복원 시스템에서는 표현할 수 없을 수 있음을 보여줍니다.
가정용 NAS에서는 Linux 컨테이너 볼륨, 개발자 디렉터리, 사진 가져오기 트리 또는 미디어 라이브러리를 Windows 또는 macOS에서 접근할 공유에 복원한 후에 이런 현상이 자주 발생합니다. 백업이 반드시 손상된 것은 아니며, 대상 네임스페이스에 구별되는 이름의 수가 더 적을 뿐입니다.
대소문자 보존 SMB는 대소문자 구분 저장소와 다릅니다
SMB 공유는 원래 대소문자를 표시할 수 있지만 대소문자를 구분하지 않는 조회를 수행할 수 있습니다. TrueNAS 커뮤니티 예시는 데이터셋과 SMB 접근 계층에서의 다른 대소문자 규칙을 설명합니다. 따라서 서버는 혼합 대소문자 이름을 로컬에 저장할 수 있지만 Windows 또는 macOS SMB 클라이언트는 이를 별도의 객체로 인식하지 못할 수 있습니다.
NAS 파일 시스템 설정뿐 아니라 실제 복원 경로를 테스트하세요. 복원 작업이 사용할 동일한 클라이언트, 프로토콜, 마운트 및 대상 디렉터리를 통해 대소문자만 다른 두 개의 무해한 파일을 만드세요. 두 번째 생성이 실패하거나 첫 번째 파일로 해결되면 해당 경로는 원본 트리를 안전하게 받을 수 없습니다.
폴더 이름 충돌은 전체 하위 트리를 병합할 수 있습니다
충돌은 최종 파일 이름뿐 아니라 모든 디렉터리 구성 요소에서 발생할 수 있습니다. 백업에 Photos/2025/A.jpg와 photos/2025/B.jpg가 포함된 경우, 대소문자를 구분하지 않는 대상은 두 경로를 하나의 디렉터리로 병합하거나 두 번째 경로를 거부할 수 있습니다. 리눅스와 윈도우 혼합 전송 계정은 디렉터리 구성 요소 충돌이 파일 경로를 잘못 연결하거나 파일을 누락시킬 수 있는 사례를 보여줍니다.
대상 경로의 대소문자 변환 규칙을 적용한 전체 상대 경로를 비교하세요. 중복된 기본 이름만 검사하는 보고서는 상위 디렉터리에서 발생하는 충돌을 놓칠 수 있습니다.
복원 도구는 모든 충돌을 안전하게 처리하지 못합니다
복원 애플리케이션은 “이미 존재함” 오류로 중단되거나, 접미사를 추가하거나, 첫 번째 파일을 유지하거나, 마지막 파일을 유지하거나, 디렉터리 트리를 병합할 수 있습니다. 충돌 쌍의 한 멤버가 건너뛰어졌음에도 일부 작업은 성공 또는 경고 상태로 완료됩니다. 대소문자 구분으로 인한 파일 이름 충돌 처리의 불일치에 대한 연구는 도구의 동작을 가정하지 말고 관찰해야 하는 이유를 보여줍니다.
대규모 복원 전에 대소문자만 다른 파일 및 디렉터리 쌍을 포함하는 작은 테스트 백업을 만드세요. 도구가 실패하는지, 이름을 변경하는지, 덮어쓰는지, 병합하는지 기록하고, 이후 두 파일의 내용 해시를 확인하세요.
유니코드 정규화는 유사한 충돌을 일으킬 수 있습니다
두 개의 파일 이름은 미리 조합된 악센트 문자와 결합 마크가 뒤따르는 기본 문자와 같이 서로 다른 유니코드 코드 포인트 시퀀스를 사용하면서도 동일하게 보일 수 있습니다. APFS 이름 처리는 일부 모드에서 정규화된 비교를 사용하면서도 형태를 보존하며, 대소문자 구분과 유니코드 정규화가 파일 이름 조회에서 상호 작용하는 방식을 참고하세요.
모든 겉보기 대소문자 충돌이 대문자와 소문자만의 문제라고 가정하지 마세요. 악센트, 아시아 언어 또는 시각적으로 동일한 이름이 포함된 경우 이스케이프되거나 코드 포인트 인식 형식으로 이름을 내보내세요.
복원을 중단하고 두 객체를 먼저 모두 보존하세요
충돌이 발생하면 라이브 대상에 복원을 중단하세요. 덮어쓰기가 활성화된 상태로 동일 작업을 반복 실행하지 마세요. 승자가 탐색 순서에 따라 바뀔 수 있습니다. 대소문자를 구분하는 스테이징 파일 시스템을 만들거나 두 이름을 모두 표현할 수 있는 Linux 환경을 통해 복원하세요. Windows 명령줄 문서에서는 대소문자 구분 디렉터리가 일반 Windows 애플리케이션이 구분할 수 없는 이름을 보존할 수 있음을 설명하며, 스테이징이 두 객체를 모두 표현할 수 있는 네임스페이스를 사용해야 하는 이유를 보여줍니다.
충돌하는 각 객체를 다음과 같은 고유한 임시 이름으로 복원하세요. Photo.jpg.__case1 및 photo.jpg.__case2원본 경로, 백업 버전, 크기, 체크섬 및 선택한 임시 이름을 CSV 또는 JSON 매핑 파일에 보관하세요.
라이브 공유로 이동하기 전에 충돌을 결정론적으로 이름 변경
어떤 파일이 먼저 발견되었는지에 의존하지 않는 규칙을 선택하세요. 확장자를 유지하면서 소스 플랫폼 레이블, 안정적인 해시 조각 또는 명시적 순서를 추가하세요. 예를 들어, Photo__linux_A1B2.jpg 및 photo__linux_C3D4.jpg 의미가 불분명한 자동 “copy” 접미사를 수용하는 대신에.
백업 저장소나 원본 소스에서 이름을 변경하기 전에 매핑을 검토하세요. ZimaSpace의 플랫폼 간 복사 전 대소문자 구분 파일 이름 충돌 감지 가이드를 사용하여 재구성된 스테이징 트리를 스캔하고 해결되지 않은 쌍이 남아 있지 않은지 확인할 수 있습니다.
파일 이름 변경 후 애플리케이션 참조 복구
이름이 변경된 미디어 파일은 라이브러리 데이터베이스에서 사라질 수 있고, 컨테이너 구성은 이전 경로를 가리키며, 사진 애플리케이션은 이름이 변경된 객체를 새 자산으로 처리할 수 있습니다. 먼저 데이터를 복원한 후 정확한 철자에 의존하는 재생 목록, 사이드카 링크, 스크립트, 데이터베이스 기록, 바인드 마운트 및 애플리케이션 인덱스를 업데이트하세요.
셀프 호스팅 애플리케이션의 경우 원래 경로를 설명하는 데이터베이스와 구성을 보존하세요. 파일 시스템만 복원하면 모든 바이트를 유지할 수 있지만 경로 참조가 일치하지 않으면 애플리케이션이 완전하지 않을 수 있습니다.
충돌 보고서를 사용하여 복구 조치 결정
| 관찰된 결과 | 가능한 원인 | 안전한 복구 조치 |
|---|---|---|
| 두 번째 파일이 “이미 존재함”을 보고 | 대상은 이름을 대소문자 구분 없이 비교 | 둘 다 대소문자 구분 임시 영역에 복원하고 결정론적으로 이름 변경 |
| 두 개의 소스 폴더가 하나로 보임 | 상위 디렉터리가 대소문자만 다름 | 정규화된 전체 경로를 비교하고 병합된 하위 트리를 분할 |
| 복원 완료되었으나 객체 수가 적음 | 도구가 한 충돌 멤버를 건너뛰거나 덮어씀 | 충돌 로그 검토 및 경로 목록과 해시 비교 |
| 이름은 동일해 보이지만 대소문자가 다름 | 유니코드 정규화 또는 지원되지 않는 문자 | 이스케이프된 코드 포인트를 검사하고 임시 영역에서 정규화 |
| 파일은 존재하지만 애플리케이션이 찾을 수 없음 | 이름 변경으로 정확한 경로 참조가 깨짐 | 애플리케이션 메타데이터, 인덱스 및 컨테이너 마운트 업데이트 |
자주 묻는 질문
SMB 공유가 둘 다 보존할 수 있나요 File.txt 및 file.txt?
기본 데이터셋, SMB 서버 구성, 클라이언트 및 애플리케이션이 모두 호환 가능한 대소문자 구분 의미론을 사용할 때만 가능합니다. 대소문자 구분 NAS 데이터셋만으로는 모든 SMB 클라이언트가 두 이름을 생성하고 주소 지정할 수 있음을 증명하지 않습니다.
대소문자 구분 APFS 볼륨에 복원하면 모든 충돌이 해결되나요?
아니요. 대소문자만 다른 쌍을 보존할 수 있지만, 이후 SMB 대상, Windows 클라이언트, 애플리케이션, 아카이브 형식 또는 유니코드 비교 규칙이 이름을 병합하거나 거부할 수 있습니다.
왜 시각적으로 동일한 두 파일 이름이 여전히 충돌할 수 있나요?
대상은 서로 다른 유니코드 시퀀스를 사용하지만 동일한 비교 형식으로 정규화할 수 있습니다. Finder나 Explorer가 이름을 표시하는 방식에만 의존하지 말고 코드 포인트를 검사하세요.
최종 요점
대소문자만 다른 파일 이름 충돌은 백업이 교차 플랫폼 복원 대상이 표현할 수 있는 것보다 더 많은 고유 경로 이름을 보존할 수 있기 때문에 발생합니다. 첫 번째 충돌에서 중지하고, 호환 가능한 임시 영역에 복원하며, 결정론적 임시 이름으로 모든 객체를 보존하고, 매핑을 기록하며, 데이터를 라이브 홈 NAS 공유로 가져오기 전에 개수와 체크섬을 검증하세요.
지원 및 팁
더 읽어보기

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

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

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

