691: A Menlo Phase
https://atp.fm/691
Apple's chip-fab options, branding the 20th-anniversary iPhone, Terminal and Xcode preferences, and some very special filenames.
Discussion
691: A Menlo Phase
https://atp.fm/691
Apple's chip-fab options, branding the 20th-anniversary iPhone, Terminal and Xcode preferences, and some very special filenames.
@atpfm was the homework bit @marcoarment referred to the rec diffs #286? I think it must be but it wasn’t as long as I expected from the reference. (I had to try to find it because I’m having big feelings about homework right now).
@atpfm the Time Machine discourse in the past couple of weeks has been bizarre. Stating it corrupts itself regularly is a very strange thing to conclude, even with anecdata. Even more so given the often praised cloning alternatives use the same mechanisms.
@jimmyjamesuk Cloning apps like SuperDuper and CarbonCopyCloner do not use the same mechanisms as Time Machine to track, perform, and store their copies.
@siracusa The claim was that TM gets corrupted over time.These are just snapshots on an apfs volume. SD and CCC must be using these same mechanisms. In any case what on earth do you think these apps use to copy? Magic? It’s either asr or the file copy apis. The claim that TM corrupts itself is unsubstantiated. Feel free to ask Howard Oakley.
@jimmyjamesuk As for Time Machine corrupting itself, I’ve seen it with my own eyes many, many, many times. Feel free to search the Internet until you are satisfied that this is a thing that actually happens frequently enough to be a legitimate factor in backup strategy decisions.
@siracusa that’s fine but I’ve seen it not corrupt itself many many times on many many machines. In both cases these are anecdotes. “Search for it” isn’t much of an answer either. How could you possibly know that these self-reported cases are the result of TM issues and not something else?
@jimmyjamesuk Same question for you: How could you possibly know this is *not* a problem? The best we can do is decide based on what we’re heard/read from other people and what we’ve experienced ourselves. In my position, I think I’ve heard from more people than the average Mac user, and I’d wager I’ve done more and more kinds of Time Machine backups than most, both as part of my Mac OS X reviews and in my own life.
@siracusa what lol? Is this how we are proceeding? You are making the claim, it is your job to provide evidence. As for my claim, it is based on the way that apfs works. People such as Howard Oakley from eclecticlight investigating it and the fact that you are praising tools like SuperDuper which use the same apis and filesystem features.
@jimmyjamesuk And to be clear, by “corrupts itself” I mean Time Machine itself says that it can no longer back up to the destination, and it instructs you to start a new backup, abandoning all past backups. I’m not aware of any reliable way to recover from this situation without doing as it suggests.
@siracusa and these are local backup? Not network backups?
@siracusa there are absolutely issues with network backups and I regularly see issues with them. That is not true for local backups.
@jimmyjamesuk I do both local and network Time Machine backups, and I’ve experienced corruption in both, including on local APFS. Feel free to continue to believe it’s “nonsense.” That belief doesn’t help me get my data back. (Having a diverse backup strategy does.)
@jimmyjamesuk There’s also the situation that a listener wrote in about where Time Machine claims there’s not enough room to make a backup, deletes all older backups while trying to to make room, and says there’s still not enough space (even when the destination volume is much bigger than the source volume). Erasing the destination volume is the only fix. This is likely another form of corruption (though I’ve only seen it myself a couple of times).
@siracusa Again, anecdotes which we cannot examine. To be clear, I think this claim is nonsense. Not in the sense that the listener is lying, but there are other possibilities. You are generalising from a few cases.
@jimmyjamesuk The thing that gets corrupted is not the snapshot on the source volume (although snapshots can become corrupted), it’s the structures that store the multiple backups on the destination volume and the databases that track the state of those backups. SuperDuper just makes a single copy, so there’s none of that structure or database stuff, and CCC uses its own, different system to store and track multiple versions of files.
@siracusa can you specify which structures you are referring to? The bulk of TM on apfs is a special “backup” volume type and snapshots. It’s not like the old hfs+ hard links solution.
@jimmyjamesuk All aspects of Time Machine data storage have changed multiple times over the years, but the behaviors I described have not been eliminated by any of those changes. These days, the tracking structures that are at fault may be on the system volume, not the destination. But it could also be APFS snapshot corruption, which I have seen in local snapshots on occasion.
@siracusa since the introduction of TM on apfs? Changed how? How do you know? Again what structures are you referring to? On occasion snapshot corruption is a different thing from TM usually corrupts itself.
@jimmyjamesuk Yes, since the introduction of APFS. (The listener this week was using APFS as well, I believe.)
@siracusa again, what changes are you referring to, and what structures? An apfs Time Machine volume is an apfs volume with snapshots. That’s essentially all. If snapshot corruption was as big a problem as you believe, it would have been causing much bigger issues.
@siracusa sorry my last sentence is nonsensical. I have no idea what the iPad keyboard is doing there.
@atpfm I think @siracusa is over-complicating the node_modules backup problem. You don't exclude individual node_modules folders; you exclude your entire ~/Developer directory. Everything in there is either clonable from a public repo, a scratch project you don't care if you lose, or an important project pushed to a remote.
@kmcmahon Nah, I want my stuff backed up even between pushes.
@Daytonlowell I don’t think so.