How do I know if a time machine backup is running? Due to APFS having a mind of its own and filling the hard disk with unwanted snapshots, I made a cron to run tmutil deletelocalsnapshots xxx. Later I found out that running this command while a backup is in progress will stop the backup. How can I know if a time machine backup is in progress to avoid running the command? The man page for tmutil doesn't list any status command.

Right now I'm doing the following in the script, since now backups mount at /Volumes/Time Machine Backups/:

ls -d /Volumes/Time* 2&gt;/dev/null|grep Machin &gt;/dev/null

if [[ $? != 0 ]]; then
     # run here tmutil snapshot deletion commands
fi


However, this doesn't seem to be very precise. The volume may be mounted some minutes later after a backup has started, and also stopping a backup leaves that mounted volume for a while. Finally, the name of the mounted volume might change in the future, making the check useless.
The canonical way to check status of time machine is to use the utility and check status or for newer os check the current phase only:

 tmutil status
 tmutil currentphase


Now, you have to process the text since it reports exit 0 when running and when it's not running since the status returned - not that there's a correct status.

I would use:

tmutil status | grep "Running = 0;"


That returns 0 if the system is not currently running and 1 if you are backing up. However, back up on High Sierra implies a non-snapshot event. The snapshots literally are to external drives which literally are not APFS. Only the internal SSD gets APFS treatment and the local snapshots are not something that "run" as so much as "just exist" and the "running" if anything is the thinning process - not the backing up process.

The thinning process calls backupd-helper which doesn't have a command line tool to check when done but you can time that running by issuing a blocking call like:

 tmutil thinlocalsnapshots / 1000000000


Above has enough zeros to thin one giga byte - add two zeros to ask for 100 GB back.



I do want to correct (or at least challenge lightly) the concept of too many snapshots. APFS is a copy on write filesystem and the only examples of this being bad seem highly contrived or non-default configurations. The files that are around are already written to disk. The system just is "lazy" about cleaning them up and doesn't expend any processing time until it knows the a) system is relatively idle b) storage is relatively idle and not yet running low on free space.

Apple is clearly still in flux with how many snapshots to keep mounted, how to set the cleanup thresholds, how many intervals to keep in situations where the external drive is not connected and the local snapshots exist.

You can dig deeper with:

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


Again, I've yet to see a place where I needed to thin or delete snapshots out of the automatic process on local volumes. The delete can be handy when you want to purge a large backup from an external drive. The real lever we used to have was to use Time Machine exclusions to omit the backup of large files that had tiny changes. It remains to be seen how APFS reacts to these files - my guess is you may be able to placethose type of files on a different APFS volume and thin aggressively and periodically or continue to watch the backup exclusions to see if that saves you allocated space without slowing down the copy on write performance and storage benefits.