The bug where Time Machine fails to backup files that tmutil say are included, or fails to identify changed files, seems to be back in 10.13 High Sierra. The bug was introduced around 10.10, persisted through 10.11, was fixed in 10.12, and now seems to have regressed.
Has anyone else done their own validations of Time Machine and noticed similar faults? Curious what configs are involved if others are seeing this, and have filed bug reports.
There are other oddities such as this gem below where after wiping the TM drive (HFS+ encrypted) and doing a full backup, the metadata of some TM files don't make sense. For example, in the case below, the created and modified times of the files on the backup drive are earlier than the dates on the source despite the first backup being done several days later on 10/04/2017. I haven't yet been able to think of a scenario where this discrepancy makes sense... I'm using rsync dry runs to identify discrepancies such as this and of course rsync properly detects a stale file on the backup drive [i.e. CCC works just fine].
From the source APFS SSD:
➜ ~ GetFileInfo "/Users/jon/Library/Containers/com.omnigroup.OmniFocus2/Data/Library/Application Support/OmniFocus/Backups/OmniFocus 2017-09-27 153941.ofocus-backup/20170926172332=kib_CHElbJ7+dwJMDoSRZc8.zip"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 09/27/2017 15:39:41
modified: 09/27/2017 15:39:41
Compare this to a just made Time Machine Backup:
➜ Macintosh HD pwd /Volumes/Time Machine/Backups.backupdb/iMac/2017-10-04-151405/Macintosh HD
➜ Macintosh HD GetFileInfo "Users/jon/Library/Containers/com.omnigroup.OmniFocus2/Data/Library/Application Support/OmniFocus/Backups/OmniFocus 2017-09-27 153941.ofocus-backup/20170926172332=kib_CHElbJ7+dwJMDoSRZc8.zip"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 09/26/2017 11:23:32
modified: 09/26/2017 11:23:32
Anyway... More of a PSA not to trust that Time Machine is backing up your data like advertised, even if tmutil says the files are "included." And this is a feeler to see if anybody else can reproduce similar behavior and file a bug report to increase visibility to Apple since this is a catastrophic failure in my book since it results in unexpected data loss.
Has anyone else done their own validations of Time Machine and noticed similar faults? Curious what configs are involved if others are seeing this, and have filed bug reports.
There are other oddities such as this gem below where after wiping the TM drive (HFS+ encrypted) and doing a full backup, the metadata of some TM files don't make sense. For example, in the case below, the created and modified times of the files on the backup drive are earlier than the dates on the source despite the first backup being done several days later on 10/04/2017. I haven't yet been able to think of a scenario where this discrepancy makes sense... I'm using rsync dry runs to identify discrepancies such as this and of course rsync properly detects a stale file on the backup drive [i.e. CCC works just fine].
From the source APFS SSD:
➜ ~ GetFileInfo "/Users/jon/Library/Containers/com.omnigroup.OmniFocus2/Data/Library/Application Support/OmniFocus/Backups/OmniFocus 2017-09-27 153941.ofocus-backup/20170926172332=kib_CHElbJ7+dwJMDoSRZc8.zip"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 09/27/2017 15:39:41
modified: 09/27/2017 15:39:41
Compare this to a just made Time Machine Backup:
➜ Macintosh HD pwd /Volumes/Time Machine/Backups.backupdb/iMac/2017-10-04-151405/Macintosh HD
➜ Macintosh HD GetFileInfo "Users/jon/Library/Containers/com.omnigroup.OmniFocus2/Data/Library/Application Support/OmniFocus/Backups/OmniFocus 2017-09-27 153941.ofocus-backup/20170926172332=kib_CHElbJ7+dwJMDoSRZc8.zip"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 09/26/2017 11:23:32
modified: 09/26/2017 11:23:32
Anyway... More of a PSA not to trust that Time Machine is backing up your data like advertised, even if tmutil says the files are "included." And this is a feeler to see if anybody else can reproduce similar behavior and file a bug report to increase visibility to Apple since this is a catastrophic failure in my book since it results in unexpected data loss.