3 ms·
The bigger question is why does Time Machine continue use a network file system for backups? It's so fragile you can't rely on it. It's gotten better in recent
by hughw 9mo ago
The bigger question is why does Time Machine continue use a network file system for backups? It's so fragile you can't rely on it. It's gotten better in recent years, possibly due to APFS, but that just means somewhat longer intervals between disasters (wipe out and reinitialize, losing all your backups). A T.M. using a custom protocol to save and restore blocks would fail sometimes too, but not ruin all your existing backups.
edit: I use Arq for daily backups, but T.M. for hourly. When T.M. eventually craters its storage, I have robust dailies in the cloud, so no worries.
- deleted 9mo ago[deleted]
- PunchyHamster 9mo ago> The bigger question is why does Time Machine continue use a network file system for backups? The problem is them fucking up. Every other popular backup solution that does it does it just fine. And doesn't hide failures silently
- crazygringo 9mo ago> The bigger question is why does Time Machine continue use a network file system for backups? As opposed to what? When you need to be able to back up to a drive on your network?
- hughw 9mo agoMounting a file system on a network share tightly couples the client to the server. It’s synchronous and it’s easy to leave the file system in an inconsistent state. Much more robust to build an asynchronous protocol with your own logic as rdbms do. You don’t see rdbms mounting remote file systems do you?
- opan 9mo agoOutsider perspective here (never used Time Machine), but my first thought is that rsync works amazingly both local and over the network. Can't imagine why it being over the network would be a problem. If it can resume a partial transfer and compare checksums to ensure a match, what's the problem?
- wlonkly 9mo agoIt's backups, not sync, so it needs to support things like incrementals/differentials, deduplication, retention rules, thinning, etc.