.png?height=120&name=Kasten-logo-2022-final-blue%20(3).png){kind=logo}
This article provides overview of few use cases where out of schedule restorePoints are created. How to identify such restorepoints and remove them.
With K10, there are multiple ways to take backups & exports.
- A manual backup/export from the application menu.
- A manual policy run with the `Run Once` button.
- A scheduled policy run
Outcome of all the above workflows are the same, a local and exported restorePoint are created in K10 respectively. However, the retention is different for each approach.
A manual backup/export run or a manual policy run is retained forever until it is deleted manually.
Any restorePoints created as a part of scheduled policy runs follow default retention mentioned in the policy.
There might be use cases where Backup/exports are created before a change in the application or upgrade of infrastructure components. In such situations, these restorePoints would not be retired unless it is manually deleted.
So this needs a handling as removal of restorepoints over a duration of time is easily missed which might potentially cause capacity issues in the storage.
This article explains how to identify such restorepoints and remove them.Retiring the manual backup/export from the application menu
After a successful backup/export, K10 creates the restorePoint with a label `k10.kasten.io/policyName` including the name of the policy that created it.
However, manual backup/export here doesn’t include a policy. So this annotation would not be there in the restorePoint. We will be using this label to filter such restorepoints.
Below command can be used to filter restorePointContents without the policyName label.
kubectl get restorepointcontents -l \!"k10.kasten.io/policyName"
NAME CREATED AT
jai-manualbackup-45zg2 2022-05-19T10:34:26Z
Output of the above command also has a creation timestamp which can be used to find the old ones and delete them.
Retiring the restorepoints from manual policy run with the `Run Once` button.
Above label with the policyName cannot be used to filter this because these restorepoints are associated with a Policy.
However, K10 adds one more label (k10.kasten.io/isRunNow) for the restorepoints which are created using the run once button.
kubectl get restorepointcontents -l k10.kasten.io/isRunNow=true
NAME CREATED AT
kasten-io-scheduled-b6rkr 2022-05-05T09:16:31Z
Above output of restorePoints can be used to retire them in a timely manner.
Tech Tip
A CronJob can be created with these commands to regularly retire the manually created restorepoints.
Below command lists and delete the manual restorepoints that are more than a month old.
kubectl get restorepointcontents -l \!"k10.kasten.io/policyName" |awk '$2 <= "'$(date -d 'last month' -Ins --utc | sed 's/+00:00/Z/')'" { print $1 }' | xargs kubectl delete restorepointcontents