On Thu, Dec 4, 2014 at 6:45 PM, Michael <[email protected]> wrote: > > On 2014-12-04, at 11:47 AM, Arno Hautala <[email protected]> wrote: > >> The tl;dr for this that tmutil might provide some of what you're >> looking for, but if you don't trust TimeMachine, you should use a >> different backup tool. > > It isn't about whether or not I trust Time Machine, or a different tool.
Ultimately, it is. Either the backup app is trustworthy (including acceptable rates of errors from bugs, faulty hardware, cosmic rays) or you find a tool or multiple backup strategies that do provide that level of trust. > 1. No backup tool will protect against a drive error that stores the wrong > thing onto the disk. At best, you can flush the system cache, and re-read the > file. That only guarantees that it matches today. You want to start using ZFS and ECC RAM. > 2. No tool can be considered perfect against bugs. They can and will happen. > I found, and reported, an issue with Time Machine. Does not mean that other > tools don't have other problems. Visible on OpenRadar? > FSEvents tells backupd which directories have modified files; backupd checks > each of those directories to see which files have been changed. It then > consults an internal list of "do not back up", the system list of > user-specified "do not back up" files, and the per-file "do not back up" meta > data flag. If all of those pass, then it decides to back it up. > > I want a list of all the files on the machine that would be backed up if it > were doing a "from-scratch" backup, EXCEPT for those where FSEvents says > "This needs to be backed up". > > That is the list of everything on the backup that should match the file > system. So, you want a list of files that have already been backed up, that haven't changed on the filesystem, so you can verify that the data has been correctly backed up. In the ideal case, if performed immediately after the backup completes, this would be every file in the backup. I think the easiest way to do this would be to just compare the backup to the current state (tmutil compare). If the list of differing files is the same as the list of files that need to be backed up (collected by fsevents), your backup can be considered verified. The easier way would be to use ZFS, snapshots, and compare a snapshot to your current state (zfs diff). > Yea, I want to force TM to re-backup, without having to change the file. Not > even change the date. Basically, a way to tell time machine "the existing > file on the backup properly belongs to an older backup set, but should be > replaced anew on the next backup set." The only system that provides this that I can think of is rsync. I suppose with rsnapshot you could manually rsync a specific file into an existing snapshot. Overall though, the point of a good backup system is that it's supposed to be automatic. You should periodically verify your backup, but I'd think this should just be a matter of diffing the backup to the current state. If anything differs, you can manually determine if: - it was properly not backed up - it differs because it's changed since the last backup, but the last backup is valid - if the backup file is corrupt - if the computer copy is corrupt >> You can use the tmutil command to see what differs in any two >> snapshots or from a snapshot to the current computer state. > > True. Now, do you have a way to say "Only tell me if backupd would not want > to back this up"? If it's different, but backupd would back it up, then I > don't care. Or if backupd would say "This is on the do not backup list", then > I don't care. So again, you want the list of files that are included in the backup, but haven't changed. I can't think of any easy way to get that list without scanning the entire disk. And at that point, you might as well just be comparing the whole backup. -- arno s hautala /-| [email protected] pgp b2c9d448 _______________________________________________ MacOSX-talk mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-talk
