Mojave time machine back up failing

Again, the Mac Extended Journaled Case-Sensitive or not Case Sensitive doesn't work for everybody.

Nice if it does for a lot of users though. For the remaining ones...

I do not have the Mac Cleanup folder on my machine.

I tried with an external disk as well as a dedicated partition on a NAS.

I tried to format APFS (TimeMachine reformats it automatically as it doesn't recognize that format), I tried Mac Extended Journaled Case-Sensitive, Mac Extended Journaled not Case-Sensitive, Journaled alone, encrypted or not, NTFS, FAT, exFAT

None of those do work. TimeMachine behaves normally until it reaches about 95% without a hitch and then starts growing forever until the drive is full.

I just gave up. This is totally amateur.

For me it looks very much like a temporary folder thing.

TM is adding stuff to a temp folder and constantly thinks that this has to be backup, too?

Nobody has found out which folder to exclude yet?

Isn't there any chance to find out where TM is writing to?

I thought about that but then the total size to backup would grow during the entire process.

With TM it starts growing forever only once it has backed up about 95% of the disk. Before that, target size doesn't grow.

I am on an Macbook Air with 10.14.2 and the backup disc is an 1TB external USB disc with Mac OS Extended (Case-sensitive, Journaled).

As a next test, I removed the .inProgress file and disabled the Filesystem Protections with:

cmd-R Restore Mode

csrutil disable

csrutil enable --without fs

Now TM started all over again and is working on backing up 140GB. This amount seems okay for a full backup, BUT:

It is VERY SLOW !!!

It still calculates time remaining since more than three hours....

I expect this backup to take about 11 days!!

Not funny...

I thought all was well with my Case Sensitive drive. Completed multiple Time Machine backups up till today. Now it's locking up again when Time Machine attempts a back up.

I turned off Time Machine. I have at least one good TM backup, so I'll rely on my documents backing up to iCloud (not sure how much I should trust any of it right now).

As we enter 2019, it is amazing how Apple has become the case study of a "company in trouble" (plummeting stock, questionable product strategy, struggling sales, buggy software). Some of it is because Apple is an easy target, but this experience has made me question my confidence in the company as well.

What makes me feel worse about this is that my support case with Apple was dismissed as being Western Digital's problem. I think their view of these threads is that its a place for whiners to hang out and complain about their self-inflicted problems -- which may be a little true :) -- but they refuse to acknowledge that if there are multiple people reporting similar issues, maybe, just maybe, it's actually something that requires Apple to look into.

After I set Filesystem Protections: disabled

the backup was very slow, but after about 4 hours it suddenly speeded up.

The idea of "Filesystem Protections: disabled" did not change anything:

TM still came into the "endless growing" situation.

Now I see errors like this:

2018-12-31 18:22:51.067749+0100 localhost backupd-helper[104]: (TimeMachine) [com.apple.TimeMachine:TMLogError]

Failed to remove '/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Ollis MacBook Air/2018-12-30-083856/Macintosh HD/.MobileBackups.trash',

error: Error Domain=NSCocoaErrorDomain Code=642 "You can’t save the file “.MobileBackups.trash” because the volume “Macintosh HD@snap-97108” is read only."

UserInfo={NSFilePath=/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/Ollis MacBook Air/2018-12-30-083856/Macintosh HD/.MobileBackups.trash, NSUserStringVariant=(

I switched back to

# csrutil status

System Integrity Protection status: enabled.

Then started a TM backup. Now I am back to this kind of error messages:

2019-01-01 16:32:13.564064+0100 localhost backupd[2174]: (TimeMachine) [com.apple.TimeMachine:TMLogError]

Failed to remove attribute 'com.apple.backupd.SnapshotVolumeLastFSEventID' from 'file:///',

error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"

Still the problem of "endless growth" persists.

:-(

I have no more ideas what to test and I am waiting for an Apple bug fix desperately.

I submitted feedback as well. Hopefully there is a Time Machine team that's reading it. I thought they disbanded the Time Capsule team that the feedback form referred to, but that may explain why this problem still exists.

It looks like you need a Developer's account to access the Apple Bug Reporter?

No, you don't need a Developer's account, rtm808. As far as i remember, I just had to use my Apple ID and password — same as you need to post in these Discussion pages. I have posted a number of different bugs in the Bug Reporter in the last year or two, and I certainly am no Developer or pundit of any kind.

I wonder how many of the reports of TM/Mojave problems are caused by TM wrongly reporting times, dates and sizes of backups?

My computer is a Mac mini with MacOS 10.14.2 and my backup drive is a Samsung 1 TB one, partitioned into two equal 500 GB partitions, one of which I use with Time Machine. It is Mac OS Extended (Journaled) formatted.

I last backed my HD up onto this backup drive relatively recently and my usage of the computer has been routine and modest (emails, a couple of small document downloads, etc.), so 'Preparing Backup…' should not have lasted long. Yesterday afternoon at about 15:35 I initiated a new TM backup, but, to discourage hold-ups, I deleted the 'in progress' file from my backup drive and allowed Spotlight to do a complete indexing first.

'Preparing Backup…' lasted about 5 hours. From about 22:30, TM began to show 'Backing up'. At 23:20 the amount to be backed up was shown as '3:80 GB of 6.93 GB' and remained unchanged thereafter; the time till completion was shown as about 40 minutes, but gradually increased over the hours. After about 5 hours, I stopped TM and disconnected the backup drive.

This morning I reconnected the drive and examined what had been backed up. I obviously could not examine every file, but as far as I could tell everything had been completely backed up and was up to date. There appeared to be no way of reliably ascertaining the time of completion, but it was probably before 23:20 last night, relatively soon after the start of 'Backing up'.

I conclude that in my system TM does eventually do a complete backup to a drive formatted as Mac OS Extended (Journaled), that, however, it takes its time to start backing up after starting 'Preparing Backup…', and that it shows misleading information while backing up and even when backing up may already have been completed. Whether 3.80 GB or 6.93 GB or the difference, 3:13 GB, were not backed up I have not been able to ascertain, unfortunately.

I have updated my report in the Bug Reporter accordingly. I really think that that is the best place to report these problems and failures, because the Bug Reporter allows one — indeed, asks one — to attach a 'sysdiagnose' file containing a wealth of information about the inner workings of TM, generated while TM is working, by means of a Terminal code or a combination of key-strokes. I know that the Apple engineers read these reports, because when I first submitted a bug report about TM but failed to generate and attach a sysdiagnose file, the engineers replied within the Bug Reporter, asking me to repair my omission.

I have a 2018 MacBook Pro with the same TM problems. The same error message and the same attempts to resolve it with no resolution. I bought a new LaCie 2 TB drive and TM has never worked on it to do an entire backup.

I get an "account not found" error when I attempt to log in to the Bug Reporter with my Apple ID (same one I use here). On the Bug Reporter page, it mentions signing in with a developer account, so I'm guessing that's why I can't sign in.

Apple Bug Reporter is a web-based tool that developers can use to report issues with Apple software and services, request enhancements to APIs and tools, and track the status of their feedback. To access Apple Bug Reporter, sign in with the Apple ID associated with your developer account.

In any case, hopefully those who have reported it via the Bug Reporter will get more traction with the defects with Time Machine.

Yes, I've tried entering my Apple ID several times with the same result. It's the same Apple ID that I use to sign in here, which I did right after my failed attempt to reach the Bug Reporter, so I know my username and password work.

You definitely need an Apple Developer plan to report the bug.

It checks this beforehand and offers to subscribe. If you have a developper plan, then you can go further and post.

You also need to include a sys diagnostic zip file that takes about 10 minutes to be generated, otherwise, you can't post.

I just went through the entire process and used my developper account, not my personal one.

And submitted the details and tests, all hard disks tried (HP, Toshiba, Samsung, Seagate,WesternDigital), all of them formatted with each and every available format. I did actually attempt about 60 backups. All formats, all disks, all failed and grew forever until the disks were full.

We'll see whether we have an answer.

You may require (or have required) a Developer Account, sjordi. I did not require a Developer Account, I have not got a Developer Account, I do not need a Developer Account, I am not a Developer and I do not intend to get a Developer Account.

As for having to produce and submit a sysdiagnose file, I mentioned this earlier in this string. I at first failed to do so, and the Apple people replied, both in the Bug Reporter and by email, asking for one (proving that they do read these bug reports), which I then did create and submit, twice over, at two stages during the very lengthy TM backup process.