Local Backup to SATA or USB HDD

Feature Requests
,
22

The lifetime of four weeks was just an example.
Having long snapshot lifetimes could serve as a workaround, but it wouldn’t truly solve the issue.

Let’s say I create a snapshot task with a lifetime of six months. To perform a backup, I run a replication task that replicates it to my backup drive.
Now, suppose I don’t perform a backup for seven months for whatever reason (not recommended). When I return to do another backup, the snapshot on the source no longer exists.
As a result, there are no common snapshots between the source and target, and incremental replication won’t be possible.

The method you described is slightly different from the one I mentioned in the original feature request.
I used that approach for a while, but I didn’t like how all the snapshots were replicated and how they cluttered everything.
More importantly, it replicates periodic snapshot tasks.

I prefer to replicate snapshots taken at specific times, since I shut down containers and VMs before creating them to avoid corrupting running databases, causing synchronization issues between files on the filesystem and the state in the database or similar issues.
When using a periodic snapshot task, those containers and VMs are likely still running when the snapshot is taken.

Suggested Improvements to better support such a manual approach and a brief recap

If the fully automated solution I originally proposed takes too much time to implement, it would still be very helpful to at least have the following features:
This would make the manual approach etorix described a more viable option.
(A fully automated solution with scripts could also be implemented more easily with these features and wouldn’t have to rely on 3rd party software)

  • Manual Snapshot Task

    • A manually triggered snapshot task that doesn’t require a schedule.
    • Allows defining snapshot retention based on the number of snapshots.
    • Example: A lifetime of 4 means a maximum of four snapshots are kept. When there are 4 snapshots and a fifth one is taken, the oldest one is deleted.

  • Attach Manual Snapshot Task to Replication

    • The ability to link a manual snapshot task to a replication task.

  • Replication Task Snapshot Retention Policy by Count

    • Support retention policies in the replication task based on the number of snapshots, not just their age.

  • Clarify Retention Policy Help Text in the replication task UI
    The current Help text states:

    “Same as Source: use the Snapshot Lifetime from the source periodic snapshot task.”

    This implies that snapshots are deleted based on age.
    However, the zettarepl documentation (apparantly used by TrueNAS for snapshot creation and replication?) says:

     # How to delete snapshots on target. "source" means "delete snapshots
 # that are no more present on source", more policies documented
 # below
 retention-policy: source

    I interpret this as deleting snapshots based on if they are present on the source or not.
    Right now this only really matters for snapshots which were replicated not because they belong to a snapshot task, but because they match a naming scheme. This disctinction would become more significant if a manual snapshot task feature were implemented.

Alternative Approach

Another possible implementation could use bookmarks and holds, similar to how zrepl does it.
Zrepl seems to already support a process similar to the one we’re describing, and they provide an example in their documentation:

Zrepl: Backup to External Disk (Quickstart Guide)