Time Machine wants 4.50 PB to backup 266.14GB

Question

I'm currently unable to backup via Time Machine, as backups fail with the following error message:

"Time Machine couldn't complete the backup to "Time Machine"". "The backup disk needs 4.50 PB for the backup but only 337.69 GB are available. Select a larger backup disk or make the backup smaller by excluding files."

If I go into Time Machine Options, the estimated size of a full backup is 266.14GB. The source volume is only 500GB.

Things I've tried already:

• running Disk Utility First Aid on both the boot volume (the one to be backed up) and the Time Machine disk
• restarting the Mac
• checked the Time Machine disk is included in the "Exclude the items from backups". It is.

Does anyone know why Time Machine might be massively over-estimating the size required to complete a backup?

4.50 PB is 4,500 Terrabytes, right?!

Edits:

• I'm using macOS 10.14.3 (up to date as of the time of writing)
• the boot volume is APFS (Encrypted)
• the Time Machine Volume is Mac OS Extended (Journaled, Encrypted)

Edit 2019-02-28

I have now discovered the following file which shows as 4.5PB:

ls -l ~/.android/avd/Nexus_5_API_26.avd/cache.img.qcow2
-rw-r--r--  1 notmyrealusername  staff  4503601804345344  7 Feb 14:34 /Users/notmyrealusername/.android/avd/Nexus_5_API_26.avd/cache.img.qcow2```

if I run `file` on this file:

```file ~/.android/avd/Nexus_5_API_26.avd/cache.img.qcow2
/Users/notmyrealusername/.android/avd/Nexus_5_API_26.avd/cache.img.qcow2: QEMU QCOW Image (v3), has backing file (path cache.img), 69206016 bytes

And yet the SSD holding the file is only 500GB

df -h
Filesystem      Size   Used  Avail Capacity  iused               ifree %iused  Mounted on
/dev/disk1s1   466Gi  241Gi  221Gi    53%  3704178 9223372036851071629    0%   /

How is this possible?

Answer 1

I'm going to take a wild swing at it being either bad local backups or a corrupted TM drive - or both - as I've had nothing but trouble with both ever since APFS was introduced. Mojave has been better than either of the Sierras, but still it happens occasionally [across two different Mac Pros running 2 different OSes, both with a permanently mounted internal TM drive.]

I can usually force backups to start to behave by clearing down 'stuck' local backups from Terminal but frequently I've had to use DiskWarrior to also fix the Time Machine drive itself. Hopefully your TM drive is still HFS+, as DiskWarrior can't fix APFS yet.

To clear down local backups, open terminal & type

tmutil listlocalsnapshots /

That will give you a list, similar to

com.apple.TimeMachine.2019-02-10-163737
com.apple.TimeMachine.2019-02-10-174021
com.apple.TimeMachine.2019-02-10-183659
com.apple.TimeMachine.2019-02-10-193738

For some unknown reason it just seems to hang onto way more of these than seems sensible, though it should clean them up itself.

You can clean these up forcibly using

tmutil thinlocalsnapshots / 1000000000000 1

[this is an overkill number, designed to clean every last one of them, aggressively; otherwise you just seem to have to do it over again]

List snapshots again, as above & you ought to end up with just one. If that ends in (dataless) then try a reboot & see if it goes away on its own. If not, you should be able to clear it manually using the date/timestamp, for example

tmutil deletelocalsnapshots 2019-02-10-163737

If you find one with an am or pm timestamp, see APFS/High Sierra - tmutil deletelocalsnapshots will not delete snapshots - Error parsing argument

Once you done the tidying up, then let Time Machine try one more run. If it fails you may need to repeat the above. I'd be almost certain, though, that you will have to run DiskWarrior over the Time Machine drive & let it repair it. I have never found any other utility that can fix drive corruption like this. Disk Utility won't do it.

Note: I have no affiliation with DiskWarrior; merely a satisfied customer. It does seem to be able to fix things nothing else can touch, though I have no clue how it actually achieves this.

Answer 2

I ran into this issue this weekend, with TM reporting that it needed >500 PB to back up a 250 GB machine.

As noted in my comment above, I used the command below (using GNU find, sort, and du installed by homebrew) to try to find any large / likely corrupt files (as reported by OP), and interestingly none were found:

sudo find / -size +1000M -exec du -sh {} + | sort -rh

However, I was able to find and delete the suspect file with the below process from a shell in Recovery Mode:

1. boot into recovery mode (shutdown, hold ⌘R while booting)
2. [this step can likely be skipped, just reporting what I did] open Disk Utility to mount your hard drive if encrypted, run First Aid, then quit Disk Utility
3. open Terminal
4. use diskutil list to find the drive in question, for me it was disk2 but you may need to modify
5. mount the drive: diskutil mountDisk /dev/disk2
6. in this shell your PATH won't include some of the tools we'll be using, so I started by adjusting it to include them: PATH=/Volumes/MyDriveName/usr/bin:"$PATH"
7. define a little helper function to show the sizes of files and directories in the current directory: size() { du -sh * | sort -h; }
8. cd /Volumes/MyDriveName
9. run size
10. I noted a directory that showed a spuriously large size (512P)
11. cd to that directory
12. repeat from #9 until you've found the file in question
13. if it looks like a file that can safely be deleted (mine was in an OmniFocus backup from 7 years ago), rm it
14. reboot and log in as normal
15. Attempt a Time Machine backup -- at this point mine completed without error

This could probably be simplified by using the find command from above in the recovery shell, but this is how I went about it.

I should also note that I suspect there is a deeper problem with my machine that led to this weird error in the first place; running fsck_apfs (or "First Aid" in Disk Utility) in both normal mode and Recovery Mode both reported an error that couldn't be repaired, so other users encountering the above probably shouldn't assume that everything is "fine" if the above solves their immediate issue. That said, the Time Machine backup was now able to run to completion, so hopefully I'll at least be able to restore from backup if the drive fails or becomes irrecoverably corrupt (fingers crossed).