This message was deleted.

Hmm recurring jobs are cool. Only caveat is the lack of e.g. specifying to the jobs that the the snapshots deleted or cleaned should be older than x. This is useful when one have a backup system like kasten or Velero in use and a Schedule where the backups are deleted after a certain date. If then tracking of certain snapshots where lost for some reason they won’t be deleted and it would therefore be easier than calculating an arbitrary

Retain

number.

1. You can used

kubectl

with filters against labels or spec/status fields to achieve batch operations for backups/snapshots 2. In the future there may be more factors to determine if a backup/snapshot should be deleted. We will discussion this kind of improvement later.

Ah yes .. filters on labels .. what about the finalizers on the snapshots and backups? I kinda always bump into these being an issue … where I have to patch … it seems that the Longhorn internal code handles these finalizers.

The finalizers should be cleaned up by Longhorn. Since the actual snapshot/backup data deletion would take some time, Longhorn cannot allow the corresponding Kubernetes object/CR removal before the cleanup is done.

Makes sense … how can I handle that by using the longhorn sdk .. is it even possible?