Time Machine의 상태를 확인하는 일반적인 방법은 유틸리티를 사용하고 상태를 확인하는 것입니다.

 tmutil status

이제 텍스트가 실행 중일 때 종료 0을보고하고 상태가 리턴 된 이후에 실행 중이 아닐 때 텍스트를 처리해야합니다. 올바른 상태가 아닙니다.

나는 사용할 것이다 :

tmutil status | grep "Running = 0;"

시스템이 현재 실행 중이 아닌 경우 0을, 백업중인 경우 1을 리턴합니다. 그러나 High Sierra에 백업하면 스냅 샷이 아닌 이벤트가 발생합니다. 스냅 샷은 말 그대로 APFS가 아닌 외부 드라이브에 대한 것입니다. 내부 SSD만이 APFS 처리를 받고 로컬 스냅 샷은 “현재 존재하는 것”만큼 “실행되는”것이 아니며 백업 프로세스가 아닌 Thinning 프로세스 인 경우 “실행”되지 않습니다.

Thinning 프로세스 backupd-helper는 명령 행 도구가 없어 수행 할 때 확인하지만 다음과 같은 차단 호출을 실행하여 실행 시간을 정할 수 있습니다.

 tmutil thinlocalsnapshots / 1000000000

위는 1 기가 바이트를 얇게하기에 충분한 제로가 있습니다. 100GB를 다시 요구하려면 두 개의 제로를 추가하십시오.

너무 많은 스냅 샷의 개념을 수정 (적어도 가볍게 도전)하고 싶습니다. APFS는 쓰기 파일 시스템에 대한 복제본이며 이러한 잘못된 점의 유일한 예는 고도로 고안되었거나 기본이 아닌 구성으로 보입니다. 주위에있는 파일은 이미 디스크에 기록됩니다. 시스템은 정리에 대해 “게으른”상태이며 a) 시스템이 상대적으로 유휴 상태라는 것을 알 때까지 처리 시간을 소비하지 않습니다. b) 스토리지가 상대적으로 유휴 상태이고 아직 여유 공간이 부족하지 않습니다.

애플은 여전히 ​​마운트 할 스냅 샷 수, 정리 임계 값 설정 방법, 외장 드라이브가 연결되어 있지 않고 로컬 스냅 샷이 존재하는 상황에서 유지할 간격 수에 여전히 영향을 미칩니다.

더 깊이 파고들 수 있습니다 :

tmutil listlocalsnapshots /
tmutil thinlocalsnapshots / 1
tmutil deletelocalsnapshots YYYY-MM-DD-HHMMSS

다시 한 번, 로컬 볼륨의 자동 프로세스에서 스냅 샷을 얇게하거나 삭제해야하는 곳을 아직 보지 못했습니다. 외장 드라이브에서 대용량 백업을 제거하려는 경우 삭제가 유용 할 수 있습니다. 이전에 사용했던 실제 레버는 Time Machine 제외를 사용하여 약간의 변경이 발생한 큰 파일의 백업을 생략하는 것이 었습니다. APFS가 이러한 파일에 어떻게 반응하는지는 여전히 알려야합니다. 제 생각에 다른 유형의 파일을 다른 APFS 볼륨에 배치하고 적극적으로 주기적으로 얇게 만들거나 백업 제외를 계속 보면서 계속해서 할당 된 공간을 절약 할 수 있는지 확인할 수 있습니다 쓰기 성능 및 스토리지 이점에 따라 복사 속도가 느려집니다.

답변

Backup session status:
{
    ClientID = "com.apple.backupd";
    Running = 0;
}