Resolved Time Machine inherit sparsebundle fails

[Arak]

Catalina has been migrated to new blade SSD (if it only plays a role in this case - by occasion Mac motherboard has been replaced with one of stronger graphic card; also CPU upgrade took place).
Before migration Time Machine backups were made to two destinations: external USB drive and sparse-bundle on network share. Backups to both destinations ran independently, automatic carry out of backups was always disabled, as well as it keeps to be in this state. Subsequently to migration the inherit operation for external USB drive could be completed successfully, also associate disk operation succeeded fully in that case.
Problematic is however the inherit of Time Machine sparse bundle stored on network share.

sudo tmutill inheritbackup /Volumes/TMnetshare/compno3.backupbundle

completes with error message "Invalid target".

Network share mounts in general on the Mac with no problem - using Finder to mount. Also the same sparse bundle mounts with no problem on the same Mac - also using Finder to do the mount. tmutil however can't complete inherit operation. Its manual has been consulted to check for possible mistakes in tmutil usage, but none could be found. TM backup in this sparse bundle worked very well prior the migration of Catalina to new SSD. Sparse bundle is not mounted to Mac while trying to do inheritbackup.

I am perplexed how to look further for possible reasons and solutions.
Network share housing sparse bundle uses own credentials, inherit backup however is conducted subsequently to successful mount of network share hence different credentials should not play a role here. Account on network device housing the share has read-write access, as it was before migration. Nothing changed on side of network share, only the Mac underwent low number of hardware upgrades.

In course of troubleshooting the sparsebundle TM backup has been removed from list of targets - TM ui in System Preferences. This way the sparsebundle is no more listed in TM System Preferences as used destination. One can add only the network share as new destination, however not the existing and valid sparse bundle.

Following command fails however as well:

sudo ls -Alh /Volumes/TMnetshare/
ls: : Operation not permitted

Network share side user executing above command has read-write access.

 

[Arak]

Operation not permitted for latter command has been fixed by relaxing privacy settings for terminal app at appropriate point.

Interesting finding was made in course of troubleshooting:
tmutil verb 'inheritbackup' has following syntax according to tmutil manual:

tmutil inheritbackup {machine directory | sparsebundle}

Hence the manual distinguishes two cases: non-sparsebundle (external drives) and sparsebundle.

Based on former experience and observation that backup inherit succeeded for external usb the idea arose to try another syntax for problematic case - the sparsebundle. Sparsebundle has been first mounted manually from shell, then inheritbackup tried with another syntax - the argument pointing into mounted backup image, then into the T.M. target bundle, finally at machine directory. In the end command returns without errors.
Right now it is only the associatedisk which is still pending. It succeeded on external disk few days ago, thus myself hopes it will also succeed in case of sparsebundle on network share.

EDIT
Well inheritbackup and associatedisk have been executed for sparse bundle in mind without an output of errors. However the list of registered Time Machine destinations still doesn't present the sparse bundle. It only presents two external usb drives which had been migrated from previous Catalina.
Any idea if any way exist to add existing sparse bundle for continuation of backup history? Also for read-only use of backup history in existing sparse bundle. I found only ways to add network share as additional destination and afraid Time Machine, if myself does this way, be creating new destination sparsebundle aside existing one. The intention is however to continue usage of existing sparse bundle.
Unfortunately, in course of latest troubleshooting I decided to remove network share backup destination from list of used destinations.

In other words, if in current status one conducts addition of network share, of such one with existing backup destination sparsebundle already stored to, will Time Machine
* purge the existing one and create new from scratch?
* create new sparse bundle as backup destination while not touching the existing one (under rename of sparse bundle file)?
* behave in yet other way?

EDIT 2
If it concerns Catalina (no idea how it works for other macOS releases) it turns out that Time Machine examines unregistered network share for presence of existing T.M. backups not until the network share gets added to list of destinations and the first backup iteration starts (additionally, backup inherit and disk association completed, however unclear in which order in the sequence of all steps). If T.M. detects presence of existing backup the user gets informed and asked how to handle destination (start from scratch, inherit backup, ...). Myself used Back Up With Consistency Scan (System Preferences > Time Machine > Shift key depressed).

EDIT 3
Yet other station on journey to working Time Machine backups.
Current status is that T.M. UI presents backup destination (that one on network share) as registered destination. Backup was started November 2023 and got a number of snapshots in the period since its initiation till Catalina migration to new system SSD. Time Machine recovery screen (former Star Wars screen) presents sparse bundle as a chain of backups - those two created today past fixing recent troubles, and a bit higher number of former backups (those created before Catalina got migrated to new system SSD) - the red-color horizontal strips right edge of T.M. recovery screen. Myself interprets this fact as a sign that backup-inherit and disk-association to new Catalina were effective. If to navigate however in Finder window (still in the data recovery mode) one can not step in those backups (snapshots) created before backup was reattached to migrated Catalina. Only those two snapshots created after reattachment (means today) can be effectively navigated into.

tmutil calculatedrift /Volumes/TMbackup/Backups.backupdb/compno3

successfully calculates drift between each pair of snapshots while problem is observed - this applies also to those backups created before Catalina migration to new SSD.
"/Volumes/TMbackup" is mount point of TM sparse bundle.

Which configuration item should be checked as next to search for possible reason and solution?

I know the function I complain about right now worked very well before Catalina got migrated to new system SSD.

 

[Brian33]

Backup was started November 2023 and got a number of snapshots in the period since its initiation till Catalina migration to new system SSD. Time Machine recovery screen (former Star Wars screen) presents sparse bundle as a chain of backups - those two created today past fixing recent troubles, and a bit higher number of former backups (those created before Catalina got migrated to new system SSD) - the red-color horizontal strips right edge of T.M. recovery screen. Myself interprets this fact as a sign that backup-inherit and disk-association to new Catalina were effective.

Yes, I think so. Glad you got to this point!

If to navigate however in Finder window (still in the data recovery mode) one can not step in those backups (snapshots) created before backup was reattached to migrated Catalina. Only those two snapshots created after reattachment (means today) can be effectively navigated into.

If I understand you correctly, you are in the Time Machine interface, and are unable to move back to backups made before the time of migration to a new blade SSD. I believe this happens when the boot volume name or UUID has changed. That is, your older backups are of a different volume UUID that is not currently connected to the Mac.

I was able to fix this situation by entering the Time Machine interface as usual, and pressing Shift-Command-C (this is Finder's shortcut for Go-->Computer). Then look in the window for the old boot volume name and double-click that. Now can you access the old backups?

 

[Arak]

Thanks for your input.

If I understand you correctly, you are in the Time Machine interface, and are unable to move back to backups made before the time of migration to a new blade SSD. I believe this happens when the boot volume name or UUID has changed. That is, your older backups are of a different volume UUID that is not currently connected to the Mac.

If to browse the backup internally, I mean inside backup store (terminology used in tmutil manual) Backups.backupdb,
then further in machine directory (compno3), then in snapshot directory 2023-12-04-151833 (as well as every other snapshot directory) the two snapshot volumes found are named identical way as Mac internal system drive as of this minute (following Catalina migration). Myself understands this as a sign that associating new system drive (backup source) with snapshot volume was effective. Wait, you're right - volume name and UUID have a good chance to be two different things, even if to discuss it only in context of backup destination. Time Machine might use both.

I was able to fix this situation by entering the Time Machine interface as usual...

You mean the T.M. data recovery screen rather than System Preferences > Time Machine?
Yes it works your way!
Only this way diving into older backups works perfectly.
Before I let T.M. recovery screen to open Finder window and go to file system location of its own choice.
Thank you.
Hmm, if to repeat test few times more Shift+cmd+C stops to be as effective as effective it initially was. Testing while being in sub-directory of user profile which has among all user profile sub-directories the best chance to change snapshoot by snapshoot. EDIT: It means using the two pads to click arrow up, arrow down (following Finder window open by Shift+cmd+C) worked very well only once - the very first test run. Over multiple test repetitions it works very well however only if to use the timeline at screen right edge.

 

[Arak]

Supplemental point.
What is the proper tmutil command syntax for associating disk (Time Machine as context) in following situation?
Catalina, backup source drive is APFS, internal boot and system drive with two volumes inside (according to design made by Apple, read-only system and read-write user data), destination is HFS+ (external USB drive, or sparse bundle on network share).

As for my recent handling based on "tmutil associatedisk" myself:
* used the argument "-a"
* conducted disk association for both read-only system volume as source and for read-write user data volume as source

Myself starts to fall in uncertainty if the second bullet measure is not a mistake. Should it be a mistake may it be an major issue, ways might exist to undo?

 

[Arak]

Myself handled existing T. M. backup in sparse bundle so far. In the beginning I also mentioned shortly an external USB drive as used T. M. destination. Latter one is however a backup with very flat snapshot history - created on dedicated external drive directly before Catalina migration process was started - just to have one fresh additional bootable clone of straightforward data structure in the case migration should fail at some point. Shortly after migration myself decided to inherit and associate this one for testing and exercise.

One other external USB drive has being used as actual T. M. external USB destination long period of time before Catalina migration. That one has really deep snapshot history stored. The overall goal is to have inherited and associated existing both sparse bundle backup as well external USB backup. Sparse bundle is less or more done right now. Inheriting and associating of external USB was still pending, which I took for accomplishing last hour. These are the achieved results:

tmutil inheritbackup /Volumes/TMbackup_Catalina_externalusb/Backups.backupdb/compno3

command completes without errors

tmutil associatedisk -a /Volumes/OWC\ Aura\ Pro\ -\ Data   /Volumes/TMbackup_Catalina_externalbus/Backups.backupdb/compno3/Latest/Macintosh\ HD\ -\ Data

it completes with error message
"A local volume mount point and a snapshot volume path are required. Never before had this problem."
No idea why it was not encountered before.
Upon this I checked the mount points of both APFS volumes on system drive in operation using DiskUtility, alternatively using System Information app. Different patterns of mount points path string were found. I like to emphasize that all materials to be found in web and addressing the question of associating the disk to new setup use the pattern /Volumes/... as tmutil associatedisk first argument.
To try to fix encountered command error I replaced first argument values with mount point string of pattern as found in System Information app:

tmutil associatedisk -a /System/Volumes/Data  /Volumes/TMbackup_Catalina_externalusb/Backups.backupdb/compno3/Latest/Macintosh\ HD\ -\ Data

Voila, command completes without error. Same for APFS system volume:

tmutil associatedisk -a /  /Volumes/TMbackup_Catalina_externalusb/Backups.backupdb/compno3/Latest/Macintosh\ HD

Also success on execution of this command.

Subsequently one test in Time Machine backup history browsing screen: I can jump in Finder window from arbitrary snapshot to its descendant or ancestor with no problems and use for it those two click-pads right to Finder window, arrow up, arrow down. Opening Finder window by Shift + cmd + C was not necessary.
I think I will redo it same way for sparse bundle destination.

 

[Arak]

At the end I have both old backup destinations running and connected to new Mac. Time Machine timeline of snapshots merges both pretty well. I can jump forward and back through whole history. Two interactive buttons right to Finder window (T. M. data recovery screen) work same well as timeline UI-element at screen right edge.

Major conclusions/finding: Time Machine is highly sensitive to errors in file system of backup destination, yet apparently to runtime transient errors/dirty artifacts in memory of involved processes. In latter case macOS reboot (eventually in addition the restart of backup storage devices) helps to resolve instability. I noticed that former problems with lack of functionality of those two interactive buttons right to Finder recovery window must had the cause even in errors these kinds. In case of problems please add to your troubleshooting the run of Disk Utility First Aid function, optimally as first or one of first steps - apply it at all possible levels of storage data structuring levels (e.g. APFS drive/image, container, volumes). If it is sparse bundle on network share do not hesitate to check network share level for possible errors too, ideally by using operating system of network share storage device because it is its native file system (unless network share administrator decided other way). No idea how well macOS performs on searching for instance EXT4 volumes for errors.

MacOS assigns during its installation a name to all drives, inclusively to system drive which usually is acting as backup source. The name usually reflects storage device brand and model name. Apple factory gave to my Mac's very first system drive the name "Macintosh HD". These names can be found also on side of backup destination: snapshot volume within machine directory. If one migrates system to new drive of different brand/model the backup source and destination sides do not match any longer at this point (there exist more such points than this one). One of results of 'tmutil associatedisk ...." is that snapshot volume name gets at this point synced to new source drive.

There is a span of macOS major releases where one can observe on destination side an interesting mixture of two worlds: old one with HFS+ and the new one APFS. In that case HFS+ is formatting the carrier volume while machine directory stores two volumes typical for APFS: system read-only and data read-write. Backup of system state before Catalina migration in sparse bundle made by myself presented both volumes in machine directory. In case of same sparse bundle however adapted to migrated Catalina I managed in some way however to unintentionally destroy this pattern - only data snapshot volume is working and browsable; I decided to delete inaccessible one (read-only system snapshot volume), with result as described at beginning of this answer.

One further observation that myself made years ago and which seems to be valid till Catalina: As for HFS+ Apple was recommending to format with Journaling enabled and without case-sensitiveness. By some unclear reason time machine was (in all cases seen by myself) formatting sparse bundle (if HFS+ is default) with case sensitiveness enabled. I have no idea what was the purpose of this discrepancy.

This Mac has never automatic backup enabled (Time Machine). It is the user and administrator who decides when next snapshot is to be created on destination. Same applies to alternation external usb and sparse bundle destination.