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

Click here to return to the 'Be careful with Time Machine and non-Apple NAS storage...' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Be careful with Time Machine and non-Apple NAS storage...
Authored by: rjbailey on Jan 26, '09 08:16:17AM
This is all true, but it doesn't have anything to do with this hint. The hint merely disables the automatic initiation of Time Machine backups. The remote sparsebundle is mounted and dismounted by the OS just as it otherwise would be.
I've been using this method for a couple of months now without a problem. In fact my frequency of corruption of the sparsebundle image on the server has decreased, because I can begin backups when I know there is less chance of server interruption. And also simply because the number of backups is lower. (Do I really need 24 backups each day? Others, maybe. Me, no.)

[ Reply to This | # ]
Be careful with Time Machine and non-Apple NAS storage...
Authored by: dbs on Jan 30, '09 07:18:06PM

You're right that this doesn't have anything to do with the above hint (except to say that the setup described is dangerous), but you're probably not right that it works just the same.

Although I don't know for certain that this is the only reason third-party file servers aren't supported, I can explain why this is almost certainly dangerous: For any file system to have a reliable disk journal (which is what tries to prevent filesystem corruption), it needs to guarantee that the journal is in a known state before any other operations occur. If you're using a disk image over a network, this would mean that you have to guarantee that all journal-related transactions are physically written to the remote disk before other operations are executed. (E.g., not stored in a cache, memory, or a network switch.) Since the NAS just sees multiple writes to a file (the disk image) it will happily cache it (problematic if the power goes out), wait for the network connection to close before writing it (problematic if the network is flaky), or even re-order them for performance (defeats the atomicity requirement of the journal). I'm guessing that Apple doesn't support third-party NAS systems because no third-party SMB or AFP servers support this capability as far as I know, and if they did, Apple would have to have to verify it was supported, and have a way to use it.

I'm sure someone with more understanding of filesystems and journaling (or HFS+ in particular) could give a more detailed description, but that's the general gist of it.

Either way, if you actually care about your backup (and that's kind of the point of a backup) it would be very foolish to trust it to something that is explicitly not supported. I was personally quite disappointed that this isn't supported since I had bought a mirrored NAS for precisely this purpose. So what I do is to backup over a wired network to a time capsule (supported config) and then do an rsync to a NAS in another physical location. This gets around the journal issue by only copying the data when the disk is in a known state: e.g., unmounted. I verify filesystem before each copy, and haven't had a problem yet even with hourly backups from two computers.

[ Reply to This | # ]