짧게 답하면: Time Machine은 이전 백업을 삭제하도록 설계되어 있어요. 시간별 백업은 하루, 일별 백업은 한 달, 주별 백업은 디스크가 찰 때까지 남아요. 그다음엔 가장 오래된 것부터 사라져요.
이에 대한 설정은 없어요. Time Machine에 3년을 보관하라고 할 수 없고, 유일한 조절 수단은 디스크 크기예요.
문서화된 동작이고, 몇 년째 바뀌지 않았어요.
그래서 가장 오래된 백업의 나이는 한 가지로 정해져요. 백업 디스크가 Mac의 데이터보다 얼마나 큰지, 그리고 그 데이터가 얼마나 자주 바뀌는지예요. Mac 데이터 900GB를 담은 1TB 드라이브는 몇 주를 주고, 200GB를 담은 같은 드라이브는 몇 년을 줘요. 어느 쪽인지 아무도 알려주지 않아요.
위의 것이에요. 알림 센터에서 “Time Machine이 공간 확보를 위해 일부 이전 백업을 삭제했습니다”를 볼 때도 있지만, 아무것도 못 볼 때도 그만큼 많아요. 알림은 놓치기 쉽고 꺼 두기도 쉬우니까요.
실제로 무엇이 남아 있는지 확인하세요.
tmutil listbackups연결된 대상의 모든 백업이 오래된 순서로 출력돼요. 왼쪽의 날짜를 따라 내려가면 일정의 모양이 보여요. 끝부분에는 일간 백업, 그 앞에는 주간 백업, 그리고 시작 날짜가 얼마나 이전까지 되돌아갈 수 있는지 알려 줘요.
때로 Time Machine은 기존 기록을 버리고 새로 시작해요. macOS 업그레이드, 복구된 볼륨, 바뀐 디스크 식별자, 손상된 백업 인덱스가 모두 원인이 될 수 있어요. 이전 백업은 디스크에 남아 공간을 차지하면서도 복원 화면에서는 접근할 수 없을 수 있어요.
대상에 대해 tmutil listbackups를 실행하면 아직 접근할 수 있는 것이 보여요. 2년간 쓴 드라이브에서 가장 오래된 항목이 며칠 전 것이라면 이런 일이 일어난 거예요.
APFS Mac에서 Time Machine은 내장 디스크에도 스냅샷을 보관하므로, 백업 드라이브가 연결되어 있지 않아도 무언가를 복원할 수 있어요. 약 24시간 동안 보관되고, 공간이 필요하면 자동으로 삭제돼요.
tmutil listlocalsnapshots /사람들은 이걸 발견하고 백업이라고 생각했다가 사라진 걸 알게 돼요. 원본과 같은 디스크에 있으므로 드라이브가 고장 나면 둘 다 잃어요. 오늘 오후에 알아챈 실수에는 유용해요. 백업은 아니에요.
네트워크 대상에서는 모든 기록이 스파스 번들 하나 안에 있어요. 인터넷의 백업 문제 조언은 “sparsebundle을 지우고 다시 시작하라”로 끝나는 경우가 아주 많은데, 그렇게 하면 가졌던 모든 버전이 한 번에 지워져요. 디스크 이미지 오류에는 그렇게 하지 않는 해결책이 있으니 먼저 시도해 볼 만해요.
솔직히 말하면 거의 없어요.
할 수 없는 것은 보존 정책을 정하는 거예요. 일수도, 최소 버전 수도, “매달 첫 백업은 영원히 보관” 같은 것도 없어요. 이 페이지 맨 위의 일정이 인터페이스의 전부예요.
정해진 디스크를 오래 쓰기 위한 것이고, 그 목적에는 합리적인 답이에요. 문제는 이 정책이 실행되는 동안 보이지 않는다는 거예요. 8개월 전 파일 버전을 찾으러 가는 날이 디스크가 실제로 얼마나 먼 과거까지 닿는지 알게 되는 날이고, 그때는 답이 이미 정해져 있어요.
이전 버전은 직접 정할 때까지 남아 있어요. 30일이 되면 버리는 카운터도, 몰래 솎아 내는 일정도 없어요.
공간이 부족해지면 앱이 물어보고, 무엇이든 하기 전에 무엇을 지울지, 그러면 얼마나 확보되는지 알려줘요. 계획을 먼저 세우고 나중에 실행하므로, 규칙에 실수가 있어도 일주일 동안은 되돌릴 수 있어요.
메인 화면은 기록이 얼마나 먼 과거까지 닿는지 보여주고, 이 페이지 전체가 다루는 게 바로 그 숫자예요. 그리고 최신 백업 복원은 라이선스가 끝난 후에도 모든 요금제에서 무료이므로, 기록은 비용을 내는 편의 기능이지만 파일을 되찾는 건 그렇지 않아요.
Time Machine을 계속 쓴다면, 오늘 할 만한 일은 tmutil listbackups를 실행해서 첫 날짜를 보고, 그만큼이면 충분한지 정하는 거예요. 3-2-1 규칙은 질문의 나머지 절반, 즉 모든 걸 담은 디스크 하나가 고장 나면 어떻게 되는지를 다뤄요.
아니요. 설정도, 유지되는 defaults 명령도, 백업을 고정하는 지원되는 방법도 없어요. 조절할 수 있는 건 디스크 크기, 백업하는 양, 그리고 대상을 여러 개 쓰는 것뿐이에요.
드라이브를 연결한 상태에서 tmutil listbackups를 실행하세요. 첫 줄이 아직 복원할 수 있는 가장 오래된 백업이에요. 드라이브의 사용 기간이 아니라 그 날짜가 기록이 거슬러 올라가는 범위예요.
네, 원래 그렇게 설계되어 있어요. 가장 오래된 백업이 지워져 최신 백업을 위한 공간을 만들어요. 디스크가 가득 찼는지도 확인해 볼 만해요. 공간 부족 메시지는 빈 공간보다는 작업 크기를 어떻게 계산하는지와 관련된 경우가 많거든요.
아니요. 원래 파일과 같은 디스크에 있고, 하루 정도 보관되며, 시스템이 공간을 원하면 삭제돼요. 오늘 오후의 실수로 인한 삭제는 다루지만 그 이상은 아니에요.
업데이트로 백업 인덱스가 무효화되어 새 체인이 시작될 수 있어요. 이전 데이터는 복원 화면에서 접근할 수 없지만 디스크에 남아 있는 경우가 많아요. tmutil listbackups로 아직 접근할 수 있는 것을 알 수 있고, 최근 며칠 것만 나온다면 체인이 다시 시작된 거예요.
관련 글: Time Machine에서 공간이 부족하다고 할 때, 3-2-1 규칙, Copy Shelter와 Time Machine 비교.