You may have seen this topic about use of Time Machine by Mac clients somehow automagically inducing the creation of ZFS snapshots.
That does not seem to be happening on my CORE server. That might be fine. I don’t know for sure that I need it. Or maybe getting this behavior is just a matter of checking some box somewhere.
What I know I do need is to understand the relationship between APFS snapshots (the ones made by Time Machine on a Mac client) and ZFS snapshots (the ones made by a TrueNAS server).
It seems possible, based on the thread linked above, that the two kinds of snapshot are somehow related under some circumstances.
My goal is to have a second-tier backup of the Macs off-site over the internet on a second CORE server. I might want that only for APFS snapshots or ZFS snapshots. In other words, I might want to avoid pushing/copying/synchronizing a Time Machine backup which is in progress.
Is there a write-up of some kind which covers this? I’ve tried searching and failed finding.
There is no relationship between APFS and ZFS. The post you’re referencing is some special SMB server code that runs in certain configurations where on SMB client disconnect we take a ZFS snapshot of the underlying dataset if the snapshot history plist has a new member created during the course of an SMB session. There’s nothing magical here. It’s just a plain ZFS snapshot that can be managed via normal ZFS mechanisms. The advantage is that the snapshot occurs when the sparsebundle volume underlying the time machine volume is in a quiesced state.
That sounds suspiciously similar to exactly what I would want. 
How do I enable this SMB server code so I can start to see this in action?
(It’s been another few hours, with many more TM backups over those hours, since I started hoping to see these snapshots start to accumulate on the Snapshots page. Nothing yet.)
You select the multiuser time machine preset for an SMB share. Preferably on SCALE. This auto-creates a dataset for the macos client when it connects and does what I described.
So maybe this is a SCALE thing unavailable on CORE?
My multi-user time machine share has the default configuration; maybe I need to check some box in the advanced options?
But then of course there is a deeper question: Do I need to care?
Ultimately what I care about is the ability to have a second copy of these backups on another TrueNAS server. (somewhat more detail above)
I’m concerned that directing one server to start copying data to another while a Mac client has a backup in progress will not end well.
It also seems likely to be dodgy — or at least potentially very confusing — to perform ZFS snapshots on a schedule which doesn’t respect/consider Mac client backups which may be in progress.
These SMB-induced snapshots seem like they might be the key to alleviating this concern.
There was recent-ish change in MacOS client behavior that isn’t accounted for in 13.0-U6.1. That’s why I suggested SCALE.
I chose CORE over SCALE because it seemed CORE had priorities better aligned with mine. However, if SCALE does this snapshot thing, then maybe that’s reason alone to use SCALE. Or not. It’s still not clear to me that my concern is real and, if so, whether this would address it.
I suppose it’s also disquieting to hear that this automagic snapshotting depends on details which Apple has been known to change. Do I want to take a dependency on that and then have clients unhappy when they upgrade their Macs and then — perhaps years later — discover the hard way that second-tier backups had quietly become unreliable? That would be a bad day to be me.
It seems it might actually be smarter to find a way to make this work without relying on those snapshots. And, assuming that can be done, their absence might actually be a good thing.
I suppose it’s also disquieting to hear that this automagic snapshotting depends on details which Apple has been known to change.
This is true of anything related to time machine. Apart from that you’re making a lot of speculation based on a few comments from me about implementation details. If you’re that concerned, you’re more than welcome to review the code and give feedback.
chose CORE over SCALE because it seemed CORE had priorities better aligned with mine
I don’t see any difference in priorities between the two (apart from kernel it’s based on).
1 Like
Oh, I assume your code is fine.
And indeed I was assuming your code has no better way to do this than to depend on details of macOS client behavior which are — apparently, per above — subject to change by Apple. In other words I assume that if Apple offered a better way you’d be using it.
All I was getting at was that maybe I don’t want to take that kind of dependency on macOS, which feels weird given that we are talking about backing up Macs, but here we are. 
FWIW, the main priority I was thinking about was that CORE seems to have fewer features apart from … ahem … core NAS features, which are all I care about for the foreseeable future.
All I was getting at was that maybe I don’t want to take that kind of dependency on macOS, which feels weird given that we are talking about backing up Macs, but here we are
What do you mean? You’re concerned about a minor fix to how we were checking for changes to a plist file, but you’re not concerned about using MacOS (which is largely proprietary) that using time machine protocol (proprietary and largely undocumented) over Apple’s custom SMB2/3 protocol extensions (which are largely undocumented, but graciously maintained by 3rd parties).
Any part of this could theoretically regress at any given time due to changes from apple, but what happens is that you update your server when fix is available.
