For late visitors to this question – the highest-voted answer is completely wrong. I offered the bounty but did not award it. The bounty was auto-awarded by the system. I cannot revoke it.
I have now managed to find a workaround & marked my own answer as accepted.
TL:DR
I've honed this issue down to one simple 'fact'.
The Time Machine drive will error with "The volume is the wrong format for a backup." on any attempt, by any method, to copy any file from within Backups.backupdb to any APFS volume. It works to any HFS+ volume.
I can copy a file to the TM volume root [outside the Backups.backupdb folder] & then copy out to APFS, but anything inside the backups folder will error.
I've trimmed most of the early experimental structure from this & left just the pertinent latest information
macOS Mojave, Mac Pro 5,1
Boot drive APFS [SSD], Time Machine drive HFS+ [HD]. All drives internal.
I have tested using two clones of my boot drive, as one SSD is mounted on a PCI card & the Mac considers it 'external'. This seems to make no difference. Boot drives are SSDs, GUID/APFS, case-insensitive.
Time Machine has been tested to three different drives, starting with the original year old backup & then with brand new backups & even brand new hard drives. All formatted GUID/HFS+ case-insensitive, as standard.
All drives have been tested with both TechTool Pro 14 & DiskWarrior [HFS only for DW] & all have a clean bill of heath.
All drives were formatted in Disk Utility using standard methods. Time Machine was set up & run as standard.
Files tested for recovery have been checked & opened to see they are still correct & not corrupted in any way – from original source & also directly from within Time Machine. Images & text files have been tested. No corruption detected at all.
Recoveries tested from Safe Mode [from where I deleted all local snapshots, including some sticky ones that wouldn't go away], no change.
Recoveries also tested from a new admin account. No change.
Additional, possibly pertinent [though possibly not] information.
Backups to the same Time Machine from HFS+ volumes will restore to the original HFS volume. Admin permission is requested.
Any file restored this way will then request admin perms even to delete [& even if 'ignore perms' is set on the drive.]. This is whether it was restored in the normal [working] manner back to HFS or manually dragged from an APFS backup to HFS.
Perms show the same as any other file on the volume, eg -rw-r--r--@ 1 glee staff which is exactly the same as any other file in the same folder that wasn't brought back from TM.
Removing all attributes xattr -c & setting perms to 'everyone' does not change this request for admin perm to delete.
Removing ACLs, chmod -N does stop this admin request, but I can't see what the offending ACL is 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown unless it's that the owner seems to be 0 not 501.
Realised SIP was disabled. Re-enabled, ran fix perms on boot drive
diskutil resetUserPermissions / id -u
trying yet another brand new Time Machine drive…
No change.
Any suggestions, next steps, tests to perform?
At the moment I am not willing to destroy the entire boot drive to clean install. I shall be able to try this as soon as Apple ship the new M1 iMacs, as I will then have a spare, almost identical Mac Pro I can play with.
Results of diskutil list & below diskutil apfs list
The boot volume is disk6 & disk7 which is PCI-mounted, though the OS thinks it's external.
If I boot instead from the other 'internal' SSD, 'Clone' I get exactly the same results.
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Downloads 1.0 TB disk0s2
3: Microsoft Basic Data MacWin7 202.1 GB disk0s3
4: Apple_HFS Empty 1.8 TB disk0s4
5: Apple_Boot Recovery HD 650.0 MB disk0s5
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS OhDaSpace 4.0 TB disk1s2
3: Apple_Boot Recovery HD 650.0 MB disk1s3
/dev/disk2 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS Tim O'Sheen 3.0 TB disk2s2
/dev/disk3 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk3
1: EFI EFI 209.7 MB disk3s1
2: Apple_APFS Container disk4 1000.0 GB disk3s2
/dev/disk4 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk4
Physical Store disk3s2
1: APFS Volume SSD2 26.3 GB disk4s1
2: APFS Volume Clone 478.2 GB disk4s2
3: APFS Volume Preboot 21.2 MB disk4s3
4: APFS Volume Recovery 515.6 MB disk4s4
5: APFS Volume VM 20.5 KB disk4s5
/dev/disk5 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk5
1: EFI EFI 209.7 MB disk5s1
2: Apple_HFS 4Space 3.0 TB disk5s2
3: Microsoft Basic Data MacWin7-safety 202.1 GB disk5s3
4: Microsoft Basic Data Acronis 829.8 GB disk5s4
/dev/disk6 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk6
1: EFI EFI 209.7 MB disk6s1
2: Apple_APFS Container disk7 1.0 TB disk6s2
/dev/disk7 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1.0 TB disk7
Physical Store disk6s2
1: APFS Volume KickMeHard 397.8 GB disk7s1
2: APFS Volume Preboot 21.2 MB disk7s2
3: APFS Volume VM 2.1 GB disk7s3
4: APFS Volume Recovery 507.6 MB disk7s4
+-- Container disk7 829CC676-CE99-4AF1-8119-2F1647C8E1EE
====================================================
APFS Container Reference: disk7
Size (Capacity Ceiling): 1023999787008 B (1.0 TB)
Capacity In Use By Volumes: 400643194880 B (400.6 GB) (39.1% used)
Capacity Not Allocated: 623356592128 B (623.4 GB) (60.9% free)
|
+-< Physical Store disk6s2 88456C48-AA1A-4A18-81AC-6FC0218583B5
| -----------------------------------------------------------
| APFS Physical Store Disk: disk6s2
| Size: 1023999787008 B (1.0 TB)
|
+-> Volume disk7s1 7828165C-2088-4328-9B9C-FE2CF9942E7F
| ---------------------------------------------------
| APFS Volume Disk (Role): disk7s1 (No specific role)
| Name: KickMeHard (Case-insensitive)
| Mount Point: /
| Capacity Consumed: 397756780544 B (397.8 GB)
| FileVault: No
|
+-> Volume disk7s2 E34F4E10-8186-476C-AB92-1E8B989C9FE1
| ---------------------------------------------------
| APFS Volume Disk (Role): disk7s2 (Preboot)
| Name: Preboot (Case-insensitive)
| Mount Point: Not Mounted
| Capacity Consumed: 21213184 B (21.2 MB)
| FileVault: No
|
+-> Volume disk7s3 04FB46F5-CA22-4B53-8510-53D438E80EDA
| ---------------------------------------------------
| APFS Volume Disk (Role): disk7s3 (VM)
| Name: VM (Case-insensitive)
| Mount Point: /private/var/vm
| Capacity Consumed: 2147504128 B (2.1 GB)
| FileVault: No
|
+-> Volume disk7s4 4F395B93-B320-4046-AC59-4420A7C10C5F
---------------------------------------------------
APFS Volume Disk (Role): disk7s4 (Recovery)
Name: Recovery (Case-insensitive)
Mount Point: Not Mounted
Capacity Consumed: 507604992 B (507.6 MB)
FileVault: No
Results from the other SSD, which contains 'Clone' just for reference
+-- Container disk4 3AF85C3F-0ABD-4F06-BE2D-4DE42BD4C286
| ====================================================
| APFS Container Reference: disk4
| Size (Capacity Ceiling): 999995129856 B (1000.0 GB)
| Capacity In Use By Volumes: 505167609856 B (505.2 GB) (50.5% used)
| Capacity Not Allocated: 494827520000 B (494.8 GB) (49.5% free)
| |
| +-< Physical Store disk3s2 4A9E7A66-914F-4321-A4E6-FD3B3B956CA7
| | -----------------------------------------------------------
| | APFS Physical Store Disk: disk3s2
| | Size: 999995129856 B (1000.0 GB)
| |
| +-> Volume disk4s1 54355C8A-F91B-4EEB-A954-42E626E4388E
| | ---------------------------------------------------
| | APFS Volume Disk (Role): disk4s1 (No specific role)
| | Name: SSD2 (Case-insensitive)
| | Mount Point: /Volumes/SSD2
| | Capacity Consumed: 26257211392 B (26.3 GB)
| | FileVault: No
| |
| +-> Volume disk4s2 558EF49B-214C-4336-9A5C-389B37AA69D9
| | ---------------------------------------------------
| | APFS Volume Disk (Role): disk4s2 (No specific role)
| | Name: Clone (Case-insensitive)
| | Mount Point: Not Mounted
| | Capacity Consumed: 478165762048 B (478.2 GB)
| | FileVault: No
| |
| +-> Volume disk4s3 F41AAE6B-B466-4461-970D-9E323E2A6319
| | ---------------------------------------------------
| | APFS Volume Disk (Role): disk4s3 (Preboot)
| | Name: Preboot (Case-insensitive)
| | Mount Point: Not Mounted
| | Capacity Consumed: 21204992 B (21.2 MB)
| | FileVault: No
| |
| +-> Volume disk4s4 897B0313-B840-485B-913D-1EAFD5A92DFE
| | ---------------------------------------------------
| | APFS Volume Disk (Role): disk4s4 (Recovery)
| | Name: Recovery (Case-insensitive)
| | Mount Point: Not Mounted
| | Capacity Consumed: 515588096 B (515.6 MB)
| | FileVault: No
| |
| +-> Volume disk4s5 608464EF-3335-49BD-9FAD-C8E83DE91DEE
| ---------------------------------------------------
| APFS Volume Disk (Role): disk4s5 (VM)
| Name: VM (Case-insensitive)
| Mount Point: Not Mounted
| Capacity Consumed: 20480 B (20.5 KB)
| FileVault: No
|
From comments – ls -lad@ produces 20 or so versions of this, varying only in Snap # & date/time
$ ls -lad@ /Volumes/Tim\ O\'Shanter/Backups.backupdb/*/*
drwxr-xr-x@ 8 root admin 272 30 May 19:26 /Volumes/Tim O'Shanter/Backups.backupdb/TetsMac/2021-05-30-72624 pm
com.apple.backup.SnapshotNumber 1
com.apple.backup.SnapshotVersion 1
com.apple.backupd.SnapshotCompletionDate 17
com.apple.backupd.SnapshotStartDate 17
com.apple.backupd.SnapshotState 2
com.apple.backupd.SnapshotTotalBytesCopied 12
com.apple.backupd.SnapshotType 2
Best Answer
UPDATE AGAIN:
A thing that sets your system apart from "ordinary" Mac systems is the fact that your boot drive is seen as external by the system, even though it is a SSD connected via PCI internally to the computer.
Depending on what kind of SSD you have, and exactly how it is connected, you could change the setup so that it is recognized as an internal boot drive by macOS. This could change what the system will recognize as okay to restore.
Vendors of some SSDs make a tool available to change whether or not the SSD is "internal" or "external". Essentially, for drives connected over a SCSI or similar-to-SCSI (e.g. USB) bus, this means that the disk controller has the field "Removable" set to 0 instead of 1. Using these tools is using hassle free.
For some drives you can make the change easily by simply overwriting the first byte on the drive. The first byte is a bit field where one specific bit is 0 for non-removable (internal) disks and 1 for removable (external) disks. In most cases you can simply write a zero to the first byte on the disk. I would advise taking a backup (i.e. dd-based backup or similar - obviously not Time Machine as that's not working for you) of the drive before doing that - especially if you're used to working a hex-editor and/or the
ddcommand.UPDATE:
After you've refined the question, I went back and actually tried this on an old Mojave Mac to see what I can find.
It seems the issue is that Finder is trying to be "intelligent", so whenever you try to move a
Backups.backupdbfolder or parts of it to a drive that is not supported as a destination by Time Machine, it will complain that the destination volume is "the wrong format".On Mojava you couldn't use APFS volumes for Time Machine backups - and that's why you get this error. The same error message can be seen if you try to copy the file to other types of destinations that are unsupported by Time Machine, for example if you try to copy the
Backups.backupdbfolder into Dropbox.If you want to copy that way, you can work-around the message by first copying the file outside the
Backups.backupdbfolder, and then copying it to the connected APFS drive. Or you could copy to a HFS+ drive.It might seem weird that the
Backups.backupdbfolder is treated differently than any other folder, but it is not uncommon for Apple to do stuff like this in a pragmatic manner. Even the actual operating system kernel treatsBackups.backupdbfolder as something special, so that they for example do not generate file system events themselves as any other folder would do.OLD ANSWER:
The bottom line is that your backup has somehow been corrupted. As you're having trouble restoring a specific file that was saved on the 6th of May, it is most probably at this time the corruption occurred.
It could be a software bug, a hardware error - or something simple like an unexpected power loss that occured to render the backup structure incomplete. Most likely the file is not really stored, but Time Machine "thinks" it is there.
You mention that you can see the specific file you're trying to restore in the folders for the 7th, 8th, etc. I would advise simply using Finder or the
cpcommand in the Terminal to copy the file from the backup to a normal disk. You would copy the file from for example the folder for the 7th.I'm afraid though, that most likely you'll find that the copy you make is incomplete - i.e. 0 bytes or can't copy at all. This is due to the file actually never having been saved properly in the first place (due to the one of the causes listed above).
As you have used the drive for performing backups after the corruption occurred, and now a great deal of time has passed, it is very unlikely that you will be able to use any data recovery tool to recover the data that you originally intended to store in the file.
UPDATE: You have since updated the question and the update indicates that the source volume and the Time Machine disk are somehow incompatible. This can happen for example if you have a case-sensitive Time Machine disk and try to restore it on an case-insensitive disk. That is not supported.