Short answer: Preparing backup is Time Machine working out what changed since last time. Usually it can read that from a change log the system keeps. When that log is unusable it walks every file on the disk instead, and that is the difference between forty seconds and four hours.
The command in the next section tells you which of the two is happening, so you can stop guessing.
Before it copies a single byte, Time Machine has to decide what to copy. macOS keeps a running log of filesystem changes called FSEvents, and in the good case Time Machine asks that log for everything that changed since the last backup, which takes seconds even on a full disk.
In the bad case that log cannot answer. Then Time Machine falls back to a deep scan, which means comparing every file on the source against the last backup, one at a time. On a Mac with a million files, most of them tiny, that is hours of work before anything is copied. The progress bar tells you none of this. It says "Preparing backup" for both.
Two commands. Neither changes anything.
tmutil statusLook for Percent and BytesCopied. During a genuine preparing phase both stay at
zero, which is expected. What you want is the log, which says out loud which path it took:
log show --predicate 'subsystem == "com.apple.TimeMachine"' --last 1h --info | grep -i -E "deep|event|scan|prepar"A line mentioning Deep event scan or event database is not usable is the
answer. It is scanning everything. A line about reading events and a small number of paths means the
change log worked and something else is slow.
To watch it live instead, and stop with Control-C:
log stream --predicate 'subsystem == "com.apple.TimeMachine"' --infoWith no earlier backup to compare against, the whole disk gets read. A few hours is normal for a full drive over USB, and much longer over wifi. A macOS update also invalidates the change log, so the first backup after one is a deep scan by definition. Plug in, leave it overnight, and check in the morning before doing anything else.
This is the common one on a Mac that has been running for a while. An unclean shutdown, a full disk, or a repaired volume can all leave FSEvents unusable, and after that every backup is a deep scan until something rebuilds it. The backup still works. It just costs hours each time.
A restart rebuilds the log for the boot volume in many cases, and it is the cheapest thing to try.
An interrupted backup leaves a folder ending in .inProgress on the destination. Time
Machine tries to reconcile it before it starts anything new, and on a network destination that reconcile
can take longer than the backup would have. Look on the backup drive, in
Backups.backupdb on an HFS+ disk or in the volume's own folder on an APFS one.
Deleting an .inProgress folder throws away an unfinished backup and nothing else. Every
completed backup is a separate folder and is not touched. Move it to the Trash from Finder, empty the
Trash, and start a backup by hand.
A deep scan is bound by the number of files, not their size. One 40 GB video file is one comparison. A 40 GB node_modules directory can be two million. Xcode's DerivedData, npm and yarn caches, Docker images, Homebrew's cellar and a Steam library are the usual suspects, and every one of them is regenerable.
Exclude them in System Settings, General, Time Machine, Options. Doing that shortens both the scan and the copy, and it costs you nothing you would ever want back.
Time Machine writes a disk image to a NAS or a shared Mac, and every one of those file comparisons goes over the wire. On wifi, at the end of a house, a deep scan can genuinely take a day. Move the Mac next to the router, or use ethernet, and see whether the same backup finishes in an hour.
If it never finishes at all, the problem is more likely the share itself, and verification is the way to find out whether what is already there is readable.
.inProgress folder in the first place. Time Machine can be stopped safely from the menu bar
item or with tmutil stopbackup.Preparing backup is a status, and it is the same status whether the job will finish in a minute or never. The number you actually want is when the last backup that worked finished, and Time Machine puts that behind a menu you have to open.
Copy Shelter shows the age of the last backup that completed on its main screen, and it says something after seven days without one. It also names the phase it is in and the file it is on while it works, so a long job looks like a long job and a stuck job looks stuck.
And when a backup does finish, being finished is a claim about the copy nobody has checked. Copy Shelter reads it back against the hashes it stored, on a schedule, so a backup that has quietly stopped being readable is something you find out on an ordinary Tuesday.
Seconds to a couple of minutes when the change log is working, whatever the size of the disk. Hours when it has fallen back to a deep scan. The log command above tells you which, and that is the only reliable way to know.
Yes. Nothing has been written yet during that phase. Stop it from the Time Machine menu bar item, or run tmutil stopbackup. Force quitting or pulling the drive during the copy phase is the risky one, and it is what leaves an .inProgress folder behind.
Only if you exclude something irreplaceable. Caches, build directories, package manager folders and downloaded game libraries can all be rebuilt from the internet. What to back up on a Mac goes through the list.
Then it is scanning the source, and not writing yet. Drive activity starts in the copy phase. If an hour of log output shows nothing at all from the TimeMachine subsystem, the process itself may be wedged, and a restart is the next step.
It has the same job to do and the same two ways to do it, so a first run reads everything. What differs is that it says which phase it is in and what it is working on, and the score on its main screen counts the last backup that finished, and never the one that started.
Related: Time Machine says there is not enough space, when a backup stops running and says nothing, and Copy Shelter and Time Machine compared.