Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '10.5: Use multiple Time Machine disks for redundancy' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: Use multiple Time Machine disks for redundancy
Authored by: SOX on Jun 04, '09 09:43:55AM

Okay here's what can happen if you copy the cookies.

I don't know exactly how time machine does it's thing. But nominally it uses hooks in the OS to notify it when things on the main disk change so it has a list of pending backups. It does not do it the way rsync does it by labriously checking concurrency of the siles system and comaring every modification date.

if you have two disks that report the same cookie time machine may beleive they are the same disk so it won't realize that a file that was changed last week then backed up to disk B, is not actually on disk A and needs to be backed up. That file is not on the pending backup list anymore.

so here's a worked example: imagine you have two files, a preferences and a database for an application like say iphoto that have stay synched (entries in one need corresponding entries in the other).

week 0 (disk 1 connected): A and B are changed.
Week 1 (Disk 2 connected): A is changed but not B
Week 2 (Disk 1 connected): B is changed but not A
Week 3 (disk 2 is connected): On tuesday, A is changed.

On Thursday you decide to revert the home directory back to it's state on Wednesday. What happens?

Well you get the A from tuesday week 3 and you get the B from week 0.

it's subtle because if you were too look in the backup directory for wednesday you would see both files, A and B present. You just would not realize they were not mutuall consistent. One was a B written 3 weeks earlier with an A written the previous day.

over time, there would be no day in the backups that contained all the files that were present together on that day!

However when time machine can tell you have switched disks because the cookies changed then it knows it needs to discard the invalid pending list and do an explicit check of what files changed since the last bakcup by comparing them between the disks. hence the sync that occurs makes sure the backup contians mutuall consistent files.

It could be that periodically timemachine does this check anyhow, so some of the time you may get away with the copied cookie method. it's just not assured.

the bottom line is: why bother when it's simpler not to use cookie copies. just let time machine do it for you as it wants to.





[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: palahala on Jun 04, '09 11:37:21AM
I can assure that, when I swap drives, Time Machine always needs to back up a lot more than it would when not swapping the drives. Using for example TimeTracker I can also validate that old files are surely copied...

[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: palahala on Jun 04, '09 11:43:20AM
By the way, Ars Technica has has some nice technical insight about Time Machine and how it relies on fsevents.

[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: mantrid on Jun 04, '09 12:25:51PM

That Ars article is exactly what I was thinking of. I have strong misgivings that the hint submitter is just guessing and stating their guesses as alarmist facts.



[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: osxpounder on Jun 05, '09 11:42:17AM

I look at the hint and our comments as information, not alarmist. If we have facts or experience to offer, or theories to share that others might want to test, that can be helpful.

It's not as helpful merely to vaguely devalue the hint that someonetook time and trouble to share the hint with us, especially when all you've got are 'misgivings', not facts. Seems to me you're doing the same thing you just criticized.



[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: mantrid on Jun 05, '09 01:30:08PM

The difference is that my comment is a comment and explicitly expressed as my personal misgivings. Their's is stated as a fact, in a submitted hint, as justification to use said hint. To me, that is a huge difference. What some idiot says in the comments doesn't carry nearly as much weight as something in a published hint on macosxhints.com.

If you had read the Ars article about TimeMachine and file system events beforehand, and then come across this hint and read that statement, you also might have thought "woah, where did that come from"? Unsubstantiated claims that something is "dangerous" and will "actually" (the word used) "actually slowly corrupt your backups" is alarmist. Consider how the statement would be interpreted if read without prior exposure to the Ars article, or other sources. No corroboration has appeared from the poster in subsequent posts, whereas palahala has included several links rebutting the claim. No instructions to say "do this to demonstrate corruption". No links to documentation. Not even a link to something as anecdotal as a web forum where someone reports corruption. Now after the fact, we are seeing comments like "I don't know exactly how time machine does it's thing" or "I don't think either of us knows" coming from the submitter, and at least one instance of an argument based on a misinterpretion of a linked article. So what exactly were the original claims based on?

I'm still hoping to see the proof, but if an admission is coming that the statement was based on speculation rather than fact, the sooner the better.

By the way, I'm not vaguely devaluing the hint at all. I think it's a fine hint that I'm sure many will find useful. That doesn't excuse the inclusion of (still unsubstantiated) statements of what is looking more and more like speculation as fact. Speaking generally, the fact that hints on macosxhints go through a screening process before publication has helped to keep the reliability of the information that can be found here at a high level, something that would be threatened if unsubstantiated claims and misinformation are complacently allowed to persist.



[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: osxpounder on Jun 08, '09 09:25:04AM

Good points. Fair enough.



[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: palahala on Jun 04, '09 01:22:55PM

Some more notes:

Apparently, Time Machine stores the last known event ID on the backup itself, in an extended attribute com.apple.backupd.SnapshotVolumeLastFSEventID.

So: I doubt the suggested corruption could occur.

And a nice article for developers: Monitoring File Changes with the File System Events API, using some lastEventId to find all files that have changed.



[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: SOX on Jun 04, '09 04:43:42PM

You could answer this in part by doing this:

sudo bzgrep -i backupd /private/var/log/system.log.*.bz2 | grep travers

According to the article you linked to if you don't get a "Node requires traversal" message every time you swap drives then it may not be detecting the out-of-sync condition.

as a further check you could also try

sudo bzgrep -i backupd /private/var/log/system.log.*.bz2 | grep from

and see if there's a huge number of megabytes copy every time you swap drives.



[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: palahala on Jun 05, '09 01:57:28AM
if you don't get a "Node requires traversal" message every time you swap drives then it may not be detecting the out-of-sync condition

My point is: Time Machine gets the com.apple.backupd.SnapshotVolumeLastFSEventID attribute from the backup disk. After swapping disks, this event ID will be lower than the event ID used by the previous backup. This is exactly the same when using two disks like in your hint. Next, TM can simply ask fseventd for the changes since that (lower) last known event ID.

There is no "out-of-sync condition" (other than the fseventsd database having been recreated for unrelated reasons, which requires a deep traversal for both backup disks once plugged in at some later time). One should NOT expect any "Node requires deep traversal" when swapping disks, not when using your hint, nor when using cloned disks.

(And yes, like I wrote: there is a huge number of megabytes copy every time I swap drives, easily noted in the logs with Time Machine Buddy, or by looking a the files that have been copied using TimeTracker.)

[ Reply to This | # ]

10.5: Use multiple Time Machine disks for redundancy
Authored by: SOX on Jun 05, '09 08:51:07AM

Perhaps I'm mistaken but my understanding of this is that in order to recover from a condition where the fsevents log has lost track of what need to be updated-- which will be the case here-- then a deep traversal is required to compare the current state of the main disk to the last backup on the old disk. That's in fact what the page you lined to says.

Thus when you swap in a new disk two things have to happen. First something has to trigger the detection of the incomplete fsevents log, and second a deep traversal has to occur.

When you manually repoint the time machine to a new disk it knows for sure it has to recatalog the disk. But when you simply swap disks that masquererade as each other using the cookie trick then you must reply on some secondary check to trigger the detection that the fsevents lof is out of sync with the disk. You are speculating that it can do this by looking at the lastudate events UUID and seeing if this is still in the fsevents log somewhere. It's possible this is true, I don't think either of us knows.

So what I was asking you to test on your system was: if is true then you should be seeing a node-travesral required message or at least some other message about the detection of this condition.

I'd also be curious to know what you think the purpose of the cookie is and what the negative consequences of removing it are.



[ Reply to This | # ]
10.5: Use multiple Time Machine disks for redundancy
Authored by: palahala on Jun 05, '09 09:56:44AM
a condition where the fsevents log has lost track of what need to be updated-- which will be the case here--

No, that is not the case here... Time Machine knows very well what data is on each backup disk. It then asks fseventd or some related API what has changed since.

When you manually repoint the time machine to a new disk it knows for sure it has to recatalog the disk.

If you're saying that you see the "Node requires deep traversal" message each time you manually assign another disk, then something is wrong on your Mac.

You are speculating that it can do this by looking at the lastudate events UUID and seeing if this is still in the fsevents log somewhere. It's possible this is true, I don't think either of us knows.

That's not speculating, that's exactly what is described in each article I mentioned earlier (though it's not the log's UUID but the FSEventsID counter). Time Machine is not keeping track of any changes. It doesn't have to, as long as it knows the last ID it used when writing to some backup.

So, I don't see anything confirming your "actually slowly corrupt your backups".



[ Reply to This | # ]