aapltm-<time> Snaps: Just grow, or?

[ler]

I note with TrueNAS-Core-12-BETA1, there are snaps of the form:
/mnt/data/<share>@aapltm-<unixepochtime>
do these just accumulate or is there a cleanup of some sort at some point?

These are SMB shares in my case used for Time Machine backups of a couple of boxes.

 

[anodos]

These snapshots are taken when a time machine session completes normally. Default of 7 day rentention.

 

[anodos]

It's a function of vfs_tmprotect. Idea is that if a time machine backup gets corrupted you can restore previous version of sparsebundle.

 

[ler]

Oh Cool! I assume there will be documentation at some point?

 

[anodos]

Two relevant parameters in this case are:

Code:

        retention = lp_parm_int(SNUM(handle->conn),
                                TMPROTECT_MODULE,
                                "retention", 7);

        min_snaps = lp_parm_int(SNUM(handle->conn),
                                TMPROTECT_MODULE,
                                "min_snaps", 24);

tmprotect:retention = <int> [how long to retain snapshots in days. default 7 days.]
tmprotect:min_snaps = <int> [minimum number of snapshots before we start deleting.]
^^^ auxiliary parameters

Generally speaking, this module works best if you have separate ZFS datasets for each Mac being backed up. (Hence the share's path having %U suffix). It will automatically generate a new dataset based on the account that time machine uses to authenticate to the SMB server. I may end up changing to hostname of the server though.[/code]

 

[ler]

freenas# cd /mnt/data/smb-tm
freenas# ls
.DS_Store Larry’s MacBook Pro.backupbundle
.windows ler-imac.backupbundle
freenas#

Should I be changing anything here to make this work better?

 

[anodos]

Remove the auto-rollback aux parameter.

 

[anodos]

Any auxiliary parameters you place in the GUI will override selections in the form.

 

[ler]

Done, do I need to change the purpose? And how can I migrate to separate DS's per Mac? (Both Mac's have good TM backups there at the moment)

 

[interplanetary]

It seems that these snapshots won't be allowed for PULL replication, as the naming schema REQUIRES %Y, whereas these appear to follow the schema aapltm-%s

File a bug report?

 

[anodos]

The module creates snapshots with unix timestamps. This was to keep snapshot names relatively short because of mountpoint length limitations prior to FreeBSD 12.0.

 

[spitfire]

The module creates snapshots with unix timestamps. This was to keep snapshot names relatively short because of mountpoint length limitations prior to FreeBSD 12.0.

Since it's not a problem anymore can we get the naming scheme that can be used for replication?

 

[anodos]

Since it's not a problem anymore can we get the naming scheme that can be used for replication?

We'll expand the permitted naming schemes to allow %s.

 

[tommythorn]

I found this thread because I have a Big Sur MacBook Air M1 which has been backing up for several days at a snails pace. I noticed I have 319 of those snapshots, but suspect they are a symptom more than a cause. Any suggestions how do troubleshoot this (FWIW, my other non-BigSur boxen use Time Machine fine AFAICT).

 

[fillg1]

I've two MacBook Pro backuped on a regular basis. The snapshot cleanup only works for one machine but not for the other, both TimeMachine share use the default parameters.

The oldest one for the first MacBook, there are a total of 34 snapshots
Sat Oct 23 19:40 2021 Data/TimeMachine/TM-Bardioc/fillg1@aapltm-1635010849

and for the second (non working), total 48 snaphots, I already deleted some manually
Wed Oct 13 9:11 2021 Data/TimeMachine/TM-Temp/fillg1@aapltm-1634109084

any idea?