Initial / experimental support for time machine over SMB

seanm

Guru
Joined
Jun 11, 2018
Messages
570
@anodos any pros/cons to using one share as the destination for several Macs to time machine to, vs one share per Mac?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,544
@anodos any pros/cons to using one share as the destination for several Macs to time machine to, vs one share per Mac?

I can't think of any. If you set up the base user quota in ixnas, then It should also automatically limit how large the time machine volume can grow. It might be interesting to do it in [ homes ] shares to make it impossible for users to touch each others backups.
 

Free as in Nas

Dabbler
Joined
May 11, 2012
Messages
42
@anodos any pros/cons to using one share as the destination for several Macs to time machine to, vs one share per Mac?

It may open you up to Ransomware attacks that would affect multiple backups. For example, one of those machines get infected, the NAS share credentials are compromised, now the attacker has access to the infect machine's backups plus all the other machines. ZFS snapshots may make this a non-issue, but it is something to consider. It may also be non-issue if the time machine backups are done by multiple user accounts, so user A can't touch user B's backup, I haven't tested that out.
 

Free as in Nas

Dabbler
Joined
May 11, 2012
Messages
42
(sorry for the double post, this is completely different train of thought so I wanted to keep it separate)

I stumbled upon this comment in Reddit regarding the backup verification issue, https://www.reddit.com/r/freenas/co...hine_must_create_a_new_backup_for_you/ef733bo.

Quoted here for convenience:

I have this issue as well, and what I understand it to be is an issue when the ZFS pool does a scrub while your system tries to do a backup. Try scheduling your backups to have an 'off day' and use the ZFS scrub during that time. It helped on my end.

Secondly, you can also mound your time machine backup volume and do disk util checks to help ensure your dmg / bundle is in good working order. Check this link out:
http://thefunkstop.com/fix-corrupted-time-machine-backups/

Is there any truth to the issue being connected to ZFS scrub intervals? Is that the current thinking?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,544
It may open you up to Ransomware attacks that would affect multiple backups. For example, one of those machines get infected, the NAS share credentials are compromised, now the attacker has access to the infect machine's backups plus all the other machines. ZFS snapshots may make this a non-issue, but it is something to consider. It may also be non-issue if the time machine backups are done by multiple user accounts, so user A can't touch user B's backup, I haven't tested that out.

Hmmm... I didn't see this response at the time. I've actually added a configuration option for ixnas to auto-create per-user ZFS datasets for Samba [homes]. I will probably add a configuration option to automatically take ZFS snapshots on disconnect from [homes] as well. This is probably the best way of doing time machine over SMB when there's less than a couple of hundred users. Once I finish writing the feature, you will be able to create a dataset (tank/tm_homes), then create an SMB share pointing to it with "homes" checked and "time machine" checked.

Once you've done this, add the auxiliary parameter "ixnas:zfs_auto_homedir=true". This will cause Samba to automatically create datasets / SMB shares on the fly as they connect to either smb://server/homes or smb://server/<username>. You can specify a per-dataset quota via the auxiliary parameter: "ixnas:homedir_quota=500G". (This part currently works). In this case, users will only be able to access their own data.

On share disconnect samba will make the libzfs call to automatically snapshot the user's dataset. This will allow rollback in case the time machine backup gets corrupted or somehow attacked through ransomware. I will probably also write a configurable retention period for these auto-connect snapshots. (This part -taking snapshots and managing them- has to be written).
 
Last edited:

seanm

Guru
Joined
Jun 11, 2018
Messages
570
@anodos, so if that's the future, does it change the answer to post #61? Sounds like one dataset/share per time machine is probably best practice...?

Will existing time machine backups be able to be migrated to this new scheme? Or will they need to start over?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,544
@anodos, so if that's the future, does it change the answer to post #61? Sounds like one dataset/share per time machine is probably best practice...?

Will existing time machine backups be able to be migrated to this new scheme? Or will they need to start over?

Post #65 was me musing over a cup of coffee. If I go this route, it will probably be a FN 12 feature for when an SMB share is marked as both a homes share and a time machine share, and will be transparent to the user. I think there are two problems with having huge numbers of ZFS datasets (1) it will impact the amount of time it takes to import a pool and (2) you may run into GUI scalability issues. (2) is just something to be aware of if you decide to deploy this sort of thing in an environment with 10,000 macs. I think you'll be fine at less than 100, but should do your own testing before cutover if you are trying to scale up to 1000. As far as migration goes, `ixnas:zfs_auto_homedir` only creates a new dataset if the path doesn't exist, so it should be safe either way. New users will get their own dataset, old users will only have a directory in the parent dataset. The userspace quota code in ixnas is smart enough to apply it to the correct dataset on share connect so I don't anticipate any special migration need in your case (if you decide to stick with ixnas:base_user_quota rather than setting the user dataset quota). At this point, these particular features are new and not exposed in the UI. I'm taking feedback and working on best practices.
 

zeztek

Cadet
Joined
Aug 25, 2018
Messages
1
@anodos I had some time to finally move from AFP over to SMB for my Time Machine backups and followed your initial instructions but Time Machine doesn't seem to want to find the share when I go to select backup destinations. My initial thought was that it wasn't advertising; however, when Time Machine attempts to discover, I get the following logs:

Code:
Aug 28 20:59:08 mainnas smbd_audit[4439]: open .com.apple.timemachine.supported (fd 35)

Aug 28 20:59:08 mainnas smbd_audit[4439]: close fd 35

Aug 28 20:59:08 mainnas smbd_audit[4439]: unlink .com.apple.timemachine.supported

Aug 28 20:59:08 mainnas smbd_audit[4439]: open . (fd 35) 


To me, that looks like the Mac managed to find the Time Machine destination but somehow it closed the connection. Not sure if you would have any advice to offer on the subject?

Specs: FreeNAS-11.2-U5 with macOS 10.14.6.
 
Top