Mac – Time Machine wants 4.50 PB to backup 266.14GB

backuperrorhard drivetime-machine

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?

Best Answer

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.