With Veeam Kasten for Kubernetes, there are multiple ways to take backups & exports.
The outcome of all the above workflows is the same: a local and exported restorePoint is created inVeeam Kasten for Kubernetes, respectively. However, retention is different for each approach.
It is recommended to set expiration time whenever a manual backup/export or policy run is triggered, as it avoids manual intervention.
There might be situations where backup/exports are created before a change in the application or upgrade of infrastructure components. In such situations, these restorePoints would only be retired if manually deleted or the expiration time is elapsed. This needs handling as removing restorepoints over time is easily missed, which could cause capacity issues in the storage.
Consider the following regarding the methods used to label restorepoints:
The examples below demonstrate how to use what is known about labeling to accurately identify restorepointcontens that need to be removed.
The command below can be used to filter restorePointContents without a policyName and without an expiresAt label.
Example output:
NAME CREATED AT mysql-manualbackup-45zg2 2022-05-19T10:34:26Z
The output of the above command also has a creation timestamp that can be used to find the old ones and delete them.
We can use the labels k10.kasten.io/isRunNow and k10.kasten.io/expiresAt to filter the restorepointcontents that were run manually without an expiration date.
Example output:
NAME CREATED AT kasten-io-scheduled-b6rkr 2022-05-05T09:16:31Z
The output of restorepointcontents can be used to retire them in a timely manner.
The following command can be used to delete the restorepointcontents that were manually created:
The example below can be used in a cronjob to regularly delete such manual restorepoints that are more than a month old.
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case