How are Periodic Snapshots marked for deletion?

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,702
The point is: there are no separate tasks.
Which just got me thinking... maybe there are... how do snapshots get deleted for the snapshot tasks locally on each end? I think it's the snapshot job that controls that one, so maybe it's the complicating factor in the cases where people aren't thinking about any of those they have active.
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
Pretty sure the task that creates the snapshot expires old ones afterwards if necessary ... and of course you would never set up a snaphot-only task on the destination of a replication, would you? :wink:
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,702
Pretty sure the task that creates the snapshot expires old ones afterwards if necessary
The key with that being how it identifies snapshots to work on... naming seems to be it, since manually created snaps over that age are left alone and I don't see any metadata to flag the auto-generated ones in zfs (but i could be missing something).

and of course you would never set up a snaphot-only task on the destination of a replication, would you?
Well, I wouldn't, but I'm trying to figure out why strange things are happening to other people. ;)
 

SMnasMAN

Contributor
Joined
Dec 2, 2018
Messages
177
I have this exact same question - (ie how is the auto deletion of "expired" snapshots handled on TN , mainly in terms of replication to a different system).

Ive read this entire thread twice, and im not clear on what conclusion @sretalla and @Patrick M. Hausen settled upon.
(my best guess is their conclusion: is that the last part of the snapshots name defines how long the snap should be retained? right?)

Im in agreement- that my own scripts/experience shows that TrueNas is making use of zettarepl (https://github.com/truenas/zettarepl).

I recently setup a offsite TN server that is only doing PULL type replication (its pulling from) my main TN server, and have noticed that snaps are not getting deleted in sync with my main TN server. (however i think this maybe the correct behavior, as whatever itis that determines when to delete a snap, is based upon when that snap is created/replicated, so im going to wait a few more weeks to see if this is true before assuming that something is wrong).

i did notice this line in the zettarepl readme:
Code:
    # This is a very important parameter that defines how your snapshots would
    # be named depending on their creation date.
    # zettarepl does not readsnapshot creation date from metadata (this can be
    # very slow for reasonably big amount of snapshots), instead it relies
    # solely on their names to parse their creation date.
 
Joined
Oct 22, 2019
Messages
3,589
Been a while since I started this thread, and here's what I've come to learn and discover:

1. Handling snapshot tasks (even expirations) under TrueNAS is exclusively based on the snapshot's name. Not metadata. Not a separate database / table. Just the names.

2. The minimum naming requirement is that it has a parseable Unix-time format down to the "day" (I believe). So YYYY-MM-DD works, for example. Zettarepl tries to interpret which number is the day or month, depending on the pattern used.

3. If a date string is not in the snapshot's name, Zettarepl ignores it. (This usually won't be an issue, since creating a Periodic Snapshot Task by default uses a Unix time string.)

4. Any existing snapshots (created by a periodic task) will be skipped/ignored when Zettarepl does its pruning of expired snapshots, if you rename the the snapshot task, even by a single character. (Snapshots created as "auto-YYYY-MM-DD" will never be pruned if you later rename the task to "autosnap-YYYY-MM-DD". This is because the task now instructs Zettarepl to search for and parse "autosnap-YYYY-MM-DD", rather than the existing snapshots of "auto-YYYY-MM-DD".)

5. Point #4 is how snapshots created automatically under a Periodic Snapshot Task will become "immortal" and never pruned. You can also manually intervene to exploit this method to "indefinitely save" an automatic snapshot by renaming it from "auto-2022-01-15" to "saved-2022-01-15" for example.) Zettarepl will skip it, even if it is "expired". Because in the eyes of Zettarepl, "expired" actually means "Snapshot names that match the string of this particular snapshot task, of which the date string within the name is older than the set expiration length, shall be removed."

6. All the above, and how Zettarepl handles this, can also be dangerous. The short summary is: you can accidentally have long-term snapshots destroyed and not even know it! Simply by using the GUI to manage your snapshot tasks, you can inadvertently have Zettarepl delete what you believed were long-term snapshots. :oops:

I explain point #6 in more detail in this post.

As for the role and behavior of Zettarepl with the local-remote relation, I stopped trying to figure it out.
 
Last edited:
Top