Time Machine은 현재 Mac과 NAS 대상이 기존 백업 기록과 더 이상 연결되지 않는다고 판단하면 새 sparsebundle을 시작합니다.
Time Machine은 기존 백업을 다른 컴퓨터, 다른 네트워크 볼륨, 다른 공유 식별자 또는 호환되지 않는 대상 구성에 속한 것으로 처리할 수 있지만, 이전 백업은 파일로 계속 표시될 수 있습니다. 일반적인 원인으로는 macOS 마이그레이션, 로직 보드 또는 호스트 이름 변경, “새 백업 생성” 선택, NAS 또는 공유 이름 변경, Time Machine 광고 설정 변경, 사용자 전환, 다른 볼륨 UUID 제공 등이 있습니다. 기존 기록에 다시 연결하기 전에 두 sparsebundle을 모두 보존하세요.
두 번째 Sparsebundle이 실제로 생성되었는지 확인
백업을 한 번 시도하기 전후에 Time Machine 공유를 나열합니다. sparsebundle 이름, 생성 시간, 논리적 크기, 소유자, Mac 이름, NAS 호스트 이름, 공유 이름 및 선택된 대상을 기록하세요.
Apple은 새 Mac이 기존 백업 기록을 이어받거나 새 백업을 생성할 수 있다고 설명합니다. 따라서 하드웨어 교체 또는 Migration Assistant 사용 후 새 번들이 나타났다면 마이그레이션 선택이 첫 번째 분기점입니다.
기존 sparsebundle 안에 임시 파일만 나타난다면 중단된 백업을 먼저 진단하세요. 새로운 컴퓨터를 나타내는 이름의 별도 번들이 나타났다면 Mac과 대상의 식별자를 계속 확인합니다.
현재 Mac의 식별자와 기존 기록 비교
Mac의 현재 컴퓨터 이름, Time Machine에서 사용할 수 있는 하드웨어 UUID 또는 플랫폼 식별자, 마이그레이션 기록, 로직 보드 변경 여부, 이전 Mac이 아직 해당 백업을 사용하는지 기록하세요.
Samba의 vfs_fruit 모듈은 Time Machine SMB 지원과 서버 식별자 동작을 제공하며, 이는 macOS가 네트워크 대상을 인식하는 방식에 영향을 줍니다.
Time Machine 또는 SMB가 새 sparsebundle을 열고 있는 동안 이전 번들과 일치하도록 이름을 변경하지 마세요. 파일 이름 변경만으로 백업 내부 식별자를 안전하게 다시 작성할 수는 없습니다.
NAS가 동일한 공유와 경로를 계속 제공하는지 확인
이전 NAS와 현재 NAS의 호스트 이름, SMB 주소, 공유 이름, 데이터 세트 경로, Time Machine 용도, 검색 이름 및 전용 백업 계정을 비교하세요.
TrueNAS에서는 공유를 Time Machine SMB 용도로 설정해야 합니다. 따라서 겉보기에 같은 경로에 일반 SMB 공유를 다시 만들어도 다른 대상 기능으로 제공될 수 있습니다.
이전 공유의 이름을 변경했거나 다시 구축했다면, 안전한 경우 원래 서비스 식별자를 복원하세요. 또는 새로 검증한 대상에 이전 번들을 의도적으로 마이그레이션한 후 선택하세요.
Time Machine 폴더와 사용자가 변경되었는지 확인
Time Machine에 동일한 공유 폴더가 계속 선택되어 있는지, 현재 계정이 번들 옆에서 테스트 파일을 읽고, 만들고, 이름을 변경하고, 삭제할 수 있는지 확인하세요.
Synology 설정 안내에서는 Time Machine용 특정 SMB 공유 폴더를 선택해야 합니다.
Finder에 같은 표시 이름의 다른 공유가 보이더라도 새 사용자 또는 폴더 때문에 이전 번들이 보이지 않거나 쓰기 불가능할 수 있습니다. 테스트 중에는 동일한 NAS를 여러 계정으로 동시에 마운트하지 마세요.
Time Machine SMB 설정이 다르게 다시 생성되지 않았는지 확인
NAS 업그레이드, SMB 프로토콜 설정, Time Machine 플래그, 할당량, 휴지통 옵션, 영구 핸들 및 AFP에서 SMB로의 마이그레이션 여부를 비교하세요.
QNAP은 전용 Time Machine 백업 폴더 설정을 문서화하고 있습니다. 이는 일반적인 쓰기 가능 공유와 Time Machine 광고 공유가 반드시 동일하지 않음을 보여줍니다.
이전 구성에서 Samba 매개변수 한두 개를 수동으로 복사하지 말고, 지원되는 Time Machine 사전 설정을 다시 적용하세요. 서비스 설정을 변경하기 전에 이전 번들을 보존하세요.
광고된 백업 볼륨 UUID가 변경되었는지 확인
Bonjour 또는 서비스 검색 세부 정보를 기록하고, 현재 광고된 볼륨 식별자를 저장된 구성 또는 이전 서버 인스턴스와 비교하세요.
Netatalk 문서에서는 광고된 볼륨 UUID가 Time Machine 볼륨을 구분한다고 설명합니다. 따라서 새 서버 식별자 아래에서 동일한 경로를 사용해도 다른 백업 디스크로 처리될 수 있습니다.
두 개의 활성 대상에 동일하거나 중복된 UUID를 임의로 지정하지 마세요. 이전 서버를 폐기했고 저장된 기록이 동일하다는 사실을 알고 있는 경우에만 이전 식별자를 복원하세요.
두 번들을 삭제하지 않고 기존 기록에 다시 연결
자동 백업을 중지하고, 공유 메타데이터를 스냅샷하거나 복사하고, 다른 Mac의 연결을 해제하고, 이전 sparsebundle이 읽기 전용으로 마운트되는지 확인한 다음, 각 기록을 소유한 Mac을 확인하세요.
ZimaSpace의 사용할 수 없는 Time Machine SMB 백업 문서에서는 일반적인 연결 및 이미지 상태 문제를 다룹니다. 이 문서는 두 번째 기록이 생성되는 문제에 초점을 맞춥니다.
Time Machine이 의도한 기존 기록에 새 백업을 추가하고, 세 번째 번들이 나타나지 않으며, 현재 복원 탐색과 테스트 파일 복구가 모두 성공하면 문제가 해결된 것입니다.
자주 묻는 질문
두 sparsebundle을 병합할 수 있나요?
간단하게 지원되는 파일 수준 병합 방법은 없습니다. 두 기록을 모두 보존하고 올바른 기록에 다시 연결하거나, 이전 번들을 별도의 복구 소스로 유지하세요.
새로 생성된 sparsebundle을 삭제해야 하나요?
이전 기록에 안전하게 다시 연결하고 테스트하기 전에는 삭제하지 마세요. 식별자가 변경된 후 생성된 최신 백업이 새 번들에만 있을 수 있습니다.
같은 공유가 화면에 표시되도록 다시 선택하면 항상 이전 백업이 계속되나요?
아니요. 공유 경로가 동일해 보여도 Mac 식별자, 계정, 광고된 볼륨 식별자 또는 Time Machine 서비스 구성이 다를 수 있습니다.
지원 및 팁
더 읽어보기

Docker 볼륨을 복원하면 파일 내용은 복원되지만 확장 속성은 사라지는 이유는 무엇인가요?
xattr 인벤토리, tar 및 Rsync 옵션, 네임스페이스, 대상 지원, 권한, 레이블, 앱 메타데이터와 테스트를 다루는 볼륨 복원 진단.

Compose 파일을 변경한 후에도 실행 중인 컨테이너의 메모리 제한이 기존 값으로 유지되는 이유는 무엇인가?
실행 중인 cgroup, 재시작과 재생성, Compose 필드, 하드 및 소프트 제한, 상위 범위, 스왑, 런타임 힙을 다루는 메모리 제한 진단입니다.

리버스 프록시를 재시작하면 셀프 호스팅 앱 하나의 모든 세션이 무효화되는 이유는 무엇인가요?
재시작 범위, 쿠키 소유권, 비밀 키 순환, 캐시 기반 세션, 스티키 라우팅, 인증 게이트웨이 및 복구를 다루는 세션 손실 진단.

