Renaming znapzend‐made snapshots to prevent data milestones from rotating away

During the course of system administration you can find it useful to retain certain historic snapshots, consistently named to your liking, perhaps even between the backed-up system and the offline destination storage.

NOTE-1: Sufficiently old ZFS snapshots which are not eventually trimmed (e.g. automatically as it happens for those managed with a znapzend schedule) would over time become the final resting point for data blocks un-referenced from other datasets and snapshots as those get deleted, and would appear to "consume" space as your live system marches on. You may have to remove them eventually, and do it manually.

NOTE-2: Examples below use the non-default znapzend timestamp format, used on author's systems specifically to help tell znapzend-made snapshots from others: org.znapzend:tsformat='znapzend-auto-%Y-%m-%dT%H:%M:%SZ'

Using some naming pattern other than the one you have configured with znapzendzetup can help avoid those snapshots rotating away automatically, as well as being destroyed by a fellow sysadmin as they are frantically trying to free up ZFS pool space by grepping for dates long gone, e.g.: zfs list -tall -Honame -r rpool/export | grep -E '@znapzend-auto-202[0123]-' | while read Z ; do zfs destroy $Z & done

Having such "milestone" snapshots may be useful to commemorate important data states, but you would likely have them handled by zfs snapshot -r pool/dataset@snapname anyway (or a program would do it for you, such as OS integration for root or container filesystem updates). They can also be helpful specifically to have restore points you can restart synchronization from in case some later snapshots get corrupted (e.g. on a single-disk backup pool) or somehow removed in a way that you do not have znapzend-made snapshots.

There are znapzend options (such as --features=sendIntermediates(,...)) which you can use in your service/daemon configuration or in single runs (such as --sinceForced=x) to ensure that snapshots with naming patterns made not by znapzend are also replicated to the remote backup locations.

However, there is an inverse approach possible: to use the existing snapshots made by znapzend and rename them, so as to get them out of its auto-removal scope. Pick a relatively old snapshot (e.g. one dated at a recent midnight) to help ensure that it is not "encumbered" by additional znapzend ZFS properties, such as the mark for "being the last snapshot replicated to dst_0", and that it exists throughout your dataset tree (unlike the recent-minute snapshots that may be still in the process of creation/replication).

• Select the snapshot names on your backed-up origin and on the remote destination systems, e.g.:

# origin
:; zfs list -Honame -tall -r rpool | grep @znapzend-auto-2024-03-10T00:00:00Z | tee /tmp/snaps-20240310

# target
:; zfs list -Honame -tall -r backups/server1/rpool | grep @znapzend-auto-2024-03-10T00:00:00Z | tee /tmp/snaps-20240310

• Compare the two lists (at least wc -l /tmp/snaps-20240310), investigate any discrepancies to avoid or address surprises (e.g. snapshots of datasets exempt from auto-creation and so not replicated offsite)
• If all is ok, rename the lot:

:; eval `awk -F@ '{print "zfs rename "$1"@"$2" "$1"@20240310-01 ; "}' < /tmp/snaps-20240310`