There are four types of backup, each has different time constraints that you can time down to the fraction of a second to convince yourself of the speed of each.
- First backup (count of changed files is the same as all files by definition)
- Fast scan using file system events (count of files changes has little effect other than the time to back each up)
- Deep scan using filesystem traversal on both the source and destination (count of files changed has no effect, all files are counted and compared)
- Problem backup where you have to do a consistency check on the destination or purge files before the backup starts ( skip these as they are edge cases)
To time things and simulate a deep scan:
time tmutil compare
To time a full backup
time tmutil startbackup —-block
I find backups to sparsebundles the worst to mange since they are finicky and you’re adding several layers of error with network and embedded filesystem with sparse storage overhead. Direct attached backups are superior for me and I use arq or rsync if I must have network backups. You can rsync or arq from a local time machine destination which gets the best of both worlds.
If you prefer a graphical tool to opening the command line, go immediately to this web site to get the time machine mechanic. It collects timing data from the system logs and does all sorts of excellent checking on backup health and statistics in general, far past simple timing measurements.