짧게 답하면: 폴더 날짜가 아니라 백업 안의 가장 최신 파일 날짜를 확인하세요. 폴더의 타임스탬프는 백업 완료와 전혀 관계없는 이유로 바뀌어요.
그 안의 가장 최신 파일이 어제보다 오래됐다면, 도구가 뭐라고 하든 백업은 실행되지 않고 있는 거예요.
대부분의 백업 조언은 엉뚱한 재난을 다뤄요. 디스크가 죽거나, 노트북을 도난당하거나, 홍수가 나는 극적인 재난을 상상하죠. 그런 일은 드물고 누구나 이해해요.
흔한 경우는 지루해요. 다른 것을 꽂으려고 드라이브를 뺐다가 다시 꽂지 않았어요. 정전 후 NAS가 재시동됐는데 공유가 다시 마운트되지 않았어요. 한 달 동안 매일 밤 작업 시간에 노트북이 닫혀 있었어요. 스크립트가 오류로 종료됐는데, 1년 내내 문제없던 로그는 아무도 읽지 않으니 아무도 몰랐어요.
이 모든 경우에 아무것도 고장 나지 않았어요. 사람이 보는 어디에도 오류가 뜨지 않아요. 백업 폴더는 여전히 있고, 여전히 파일로 가득하고, 크기도 그대로예요. 바뀐 건 더 이상 새로워지지 않는다는 것뿐이고, 시스템의 어떤 것도 그걸 말할 가치가 있다고 여기지 않아요.
백업 저장 위치를 지정하세요. 그 안에서 가장 최근에 수정된 파일을 찾아 날짜를 출력해요.
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5첫 번째 열은 Unix 타임스탬프예요. 바로 읽으려면:
find /Volumes/Backup -type f -newermt '-2 days' | head아무것도 출력되지 않으면 이틀 동안 아무것도 기록되지 않은 거예요. 그게 답이고, 파일 자체의 속성이기 때문에 어떤 상태 화면보다 믿을 만해요.
Time Machine의 경우:
tmutil latestbackup가장 최신 스냅샷의 경로를 이름에 날짜와 함께 출력하고, 없으면 오류를 출력해요.
본능적으로 Finder에서 백업 폴더를 보고 수정일 열을 읽게 돼요. 그 숫자는 생각하는 그런 숫자가 아니에요.
디렉터리의 수정 시간은 무언가가 추가되거나 제거될 때 바뀌고, 그 안의 파일 내용이 바뀔 때는 바뀌지 않아요. Spotlight 색인, 다시 기록되는 .DS_Store, 백신 검사기, 자체 메타데이터를 건드리는 클라우드 클라이언트. 이 중 무엇이든 오래된 백업 폴더를 오늘 아침에 기록된 것처럼 보이게 할 수 있어요.
기록은 그 안의 파일이에요. 폴더가 아니에요.
StartCalendarInterval을 쓰는 launchd 작업은 Mac이 잠자는 동안 실행되지 않고, 요청하지 않으면 나중에 따라잡지도 않아요. 자정에 덮어 둔 노트북의 자정 백업은 단 한 번도 실행된 적이 없어요.launchd 작업은 불만을 파일에 기록하고, 그 파일만이 알고 있어요.직접 한다면, 해결책은 데드맨 스위치예요. 백업이 일어나지 않았을 때 알리는 장치죠. 백업 실패와는 다른 사건이고, 위의 경우들은 앞의 것만 잡아낼 수 있어요.
가장 간단한 방법은 가장 최신 파일의 나이를 확인하고 너무 오래됐으면 알리는 작업이에요.
if [ -z "$(find /Volumes/Backup -type f -newermt '-2 days' 2>/dev/null | head -1)" ]; then
osascript -e 'display notification "No backup in two days" with title "Backup"'
fi이것을 백업과 별도로 자체 일정에 따라 실행하세요. 그래야 백업 일정이 고장 나도 감시하는 쪽까지 고장 나지 않아요. 사람들이 이 마지막 부분을 잘못 해요. 백업 작업 안에서 실행되는 확인은 백업 작업이 실행되지 않았다고 보고할 수 없어요.
정말 원하는 것은 부재 자체가 경보가 되고, 도구가 빠진 것의 이름을 알려 주는 거예요.
Copy Shelter는 이를 바탕으로 만들어졌어요. 각 저장 위치에 마지막으로 기록한 시점과 마지막으로 확인한 시점을 추적하고, 성공한 백업 없이 7일이 지나면 알려 줘요. 위치의 이름을 밝히므로 "서랍 속 드라이브를 8월 14일 이후로 보지 못했어요" 같은 알림을 받아요. 또한 백업을 다시 읽어 모든 조각을 저장된 해시와 대조하므로, 실행은 되지만 읽을 수 없는 결과를 만드는 백업도 잡아내요. 이 페이지에서 한 단계 더 나아간 고장이죠.
표시되는 점수는 최근에 검증된 것만 세요. 실행되지 않은 백업은 가진 백업이 아니고, 숫자가 그렇게 말해 줘요.
그럴 필요가 없어야 해요. 그게 이 페이지의 요점이에요. 직접 하는 확인은 결국 그만두게 되고, 보통 설정한 지 3주쯤 지나서예요. 부재 알림을 자동화하고, 직접 확인은 알림이 왔을 때 하세요.
도움이 되지만 한계가 있어요. Time Machine은 10일 동안 백업을 완료하지 못하면 경고하는데, 그 알림은 무시하기 쉽고 익숙해지기도 쉬워요. 또한 로컬 디스크에서는 확인하지 않기 때문에, 완료한 백업을 읽을 수 없다는 것도 알려 줄 수 없어요.
그건 권한 문제이고, 모든 상태 표시가 성공이라고 말해서 더 고약해요. 저장 위치의 파일 수와 원본의 파일 수를 비교하세요. 수만 개의 파일이 있어야 할 백업에 40개만 있다면, macOS가 폴더 접근을 거부하고 있는데 작업은 그걸 듣지 못하는 거예요.
다른 방식으로, 네. 동기화 클라이언트는 로그아웃되고, 용량이 차고, 스스로 일시 정지하는데, 그걸 알려 줄 배지는 보지도 않는 메뉴 막대의 작은 아이콘이에요. 파일도 원래 자리에 그대로 있어서 아무것도 이상해 보이지 않아요.
대체로 그래요. 서로 다른 이유로 고장 나고 따로 확인되는 저장 위치 두 개는 하나에 대한 어떤 모니터링보다 가치가 있어요. 모니터링은 사본이 사라졌다고 알려 주고, 두 번째 사본은 그래도 괜찮다는 뜻이에요. 3-2-1 규칙을 참고하세요.
관련 글: 백업을 실제로 읽을 수 있는지 확인하기, 3-2-1 규칙.