Time Machine Drive corrupted - space manager is invalid

[XMI]

I have a brand new M4 MacBook Pro, brand new 2TB SanDisk SSD, and twice now my Time Machine drive has been corrupted. Both times were my fault (I accidentally yanked the thunderbolt cord w/o ejecting first), but even so, I've never seen this kind of disk corruption before.

Regular disk utility wouldn't help, so I booted into Recovery mode and tried Disk Utility there.

Error messages are not promising, it fails with

** Checking the space manager.
warning: (oid 0xxxxx) cib: invalid o_cksum (0xffffffffffffffff)
error: failed to read spaceman cib 1 at address 0xxxxx
Space manager is invalid.

My SSD is brand new, but to be sure, I checked the serial # on this site: https://support-en.wd.com/app/firmwareupdate and it says I have no updates needed.

Last time this happened I gave up and reformatted the drive (not a big problem since i'd only been running Time Machine on it for a couple of days).

But I really want a reliable Time Machine solution.

Is this a macOS bug? I'm running Sequoia 15.2

 

[XMI]

More tests:

diskutil list
/dev/disk8 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +2.0 TB disk8
Physical Store disk6s2
1: APFS Volume TimeMasheen2024 673.4 GB disk8s2

sudo diskutil apfs unlockVolume /dev/disk8s2
Passphrase:
Unlocking any cryptographic user on APFS Volume disk8s2
Passphrase incorrect or user does not exist

# I know the passphrase is correct


sudo diskutil verifyVolume /dev/disk8s2
Started file system verification on disk8s2 (TimeMasheen2024)
Verifying file system
Volume is already unmounted
Performing fsck_apfs -n -x /dev/rdisk8s2
Checking the container superblock
Checking the checkpoint with transaction ID 6698
Checking the space manager
warning: (oid 0x70f3) cib: invalid o_cksum (0xffffffffffffffff)
error: failed to read spaceman cib 2 at address 0x70f3
Space manager is invalid
The volume /dev/rdisk8s2 with UUID 00000000-0000-0000-0000-000000000000 could not be verified completely
File system check exit code is 8
Restoring the original state found as unmounted
Error: -69845: File system verify or repair failed
Underlying error: 8

 

[Apple_Robert]

How can it be a bug when you said it was your fault both times? I would reformat and try the process again. I haven't had any TM (backing up to my Synology NAS) problems with my M4 MBP.

 

[XMI]

How can it be a bug when you said it was your fault both times?

Here's the thing: I've been messing around with disk drives when they used to be floppy format. I have a good sense of what it takes to corrupt a drive.

For the past decade or so, failing to eject a drive before unplugging it would generally (on Windows) do nothing bad, and (on macOS) give you a mild scolding.

It was really really really hard to corrupt a drive by mistreating it. Even harder with SSDs.

I'm not saying it never happened, but it was like a 1 in 100 or 1 in 1000 occurrence

Here, I'm now 2 for 2 with this particular drive.

What's changed?
* new SSD from Sandisk
* new M4 MacBook pro and OS (15.2)

 

[elvisimprsntr]

If you want an alternative TM solution, look at enterprise class open source TrueNAS SCALE. You can enable multi user SMB TM and let all devices backup to the same appliance. Ends up being a Ron Popeil “set it and forget it” appliance. Runs on almost any x64 appliance, which you can pick up a used NAS appliance off evilBay. Has a bit of a leaning curve but is infinitely more reliable and flexible.

TrueNAS - Open Enterprise Storage

TrueNAS is the World's #1 Open Source Enterprise Storage, based on OpenZFS. It is trusted by millions and deployed worldwide.

www.truenas.com

 

[HobeSoundDarryl]

Mac is finicky about ejections. You HAVE to formally eject it or risk disc corruptions. TM discs are probably at greater risk because- unless you change defaults- there may be writes in progress up to every hour. Yank the cord on any drive during a write and it will probably get corrupted.

This won't be fixed by you not changing your approach to using your new MBpro with external storage.

Yes, it's unfortunate that macOS can't seem to handle this sort of thing as well as Windows does but this is only one of many quirks with macOS. On the other hand, macOS does a number of things BETTER than Windows... so you gain some and you lose some.

Evolve your approach or this matter won't be resolved to your satisfaction. There's no obvious or secret setting to change that will make pulling a cord at any time work just fine.

A possible option that still uses TM is to switch it from fully automatic to fully manual control, then you can plug in, run the backup process, then eject the drive when done. In this variation of default, you'll be paying more attention to the backup process and thus know that as soon as it is done, you formally eject the drive.

OR, you can switch to other options like Carbon Copy Cloner or Super Duper to do the same... but all Mac apps need drives formally ejected vs. just pulling the cord. Sometimes the latter won't do any harm but other times you'll get catastrophic errors.

One last option: buy yourself a NAS that supports Time Machine- like Synology- and set it up to handle TM backups. That will let you use TM to automatically back up but there will be no drive cord to pull. A NAS can do all kinds of other things for you including being your own rent-free cloud storage but this particular one is quite handy for this exact need. One of several backups I execute leans on a Synology NAS and it works great as a TM "drive" without a typical HDD cord.

If you go the NAS way, I suggest a SECOND backup to that Sandisk too and securely storing it offsite... regularly fetching it to freshen up the backup. This onsite-offsite rotation (using any combination of at least TWO backup drives) approach protects against very real flood-fire-theft scenarios, where both your MB and your backup drive sitting right next to it would likely be lost. If you have one pretty fresh backup offsite, you can recover from those scenarios. I store my offsite disc in a bank safe deposit box.

 

[AlumaMac]

I'm still on Monterey and I had multiple TM drive corruptions with a particular drive and assumed it was defective. I switched over to Carbon Copy Cloner and HFS+ formatting and the drive has been flawless for over a year. So seems as if TM or APFS may have been the culprit.

 

[XMI]

Thanks all for suggestions and help. Googling my specific error "failed to read spaceman cib 2" reveals only a couple other people with this same issue, and nobody had solutions.

I gave up and reformatted the drive, and started time machine again from scratch.

I do have another offline backup using SuperDuper as well.

 

[HobeSoundDarryl]

Adjust your approach to formally eject it vs. just pulling the plug... or you'll very likely have similar problems again.

 

[gilby101]

So seems as if TM or APFS may have been the culprit.

TM with APFS is super reliable. Much more so than HFS+.

nobody had solutions

You have been offered the solution in this thread. Don't yank the cable.

You may have been very unlucky. But you can only test that by repeating the experiment over and over to get an idea of how often cable yanking causes the problem - and I don't really suggest you should do that.