|
|
10.5: Use multiple Time Machine disks for redundancy
setups like copying the hidden disk ID number, that while appearing to work, actually slowly corrupt your backups Can you extend a bit on this corruption issue? (So far I have encountered no issues with using the same Time Machine cookie on two disks, which I started using after TM had already built-up some history. So I use two identical copies as a base, to ensure the old history is available on both disks.)
10.5: Use multiple Time Machine disks for redundancy
Okay here's what can happen if you copy the cookies.
10.5: Use multiple Time Machine disks for redundancy
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...
10.5: Use multiple Time Machine disks for redundancy
By the way, Ars Technica has has some nice technical insight about Time Machine and how it relies on fsevents.
10.5: Use multiple Time Machine disks for redundancy
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.
10.5: Use multiple Time Machine disks for redundancy
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.
10.5: Use multiple Time Machine disks for redundancy
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.
10.5: Use multiple Time Machine disks for redundancy
Good points. Fair enough.
10.5: Use multiple Time Machine disks for redundancy
Some more notes: Apparently, Time Machine stores the last known event ID on the backup itself, in an extended attribute 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
10.5: Use multiple Time Machine disks for redundancy
You could answer this in part by doing this:
10.5: Use multiple Time Machine disks for redundancy
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 There is no "out-of-sync condition" (other than the (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.)
10.5: Use multiple Time Machine disks for redundancy
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.
10.5: Use multiple Time Machine disks for redundancy
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 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". |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.19 seconds |
|