Backup Retention

Is there a way to specify the retention period for database clusters managed by Everest?

It looks like the PerconaPGCluster and underlying PostgresCluster CRDs supports configuring this value, but it appears to effectively be hardcoded to 9999999 full backups.

I haven’t noticed a similar setting for PerconaServerMongoDB yet (though I haven’t done a ton of digging here).

What options do we have to correctly deal with retention? Is the expectation that we set lifecycle rules on the S3 buckets?

Hi @JayV,

Currently, you’re not able to customize this from the Percona Everest UI. This feature is in our roadmap and it’s expected to be delivered in 0.10.0 which will be released at the end of April.

Our API already supports this, so if you really need it right now you may update the Database Cluster spec to match your needs.
You can do this with a PUT to /namespaces/{namespace}/database-clusters/{name}. This request’s payload shall include the complete Database Cluster spec.
In that payload, you can find a field .spec.backup.schedules[0].retentionCopies that you can customize to you needs. Bear in mind that 0 is a special value that means infinite copies. In PostgreSQL (PGBackRest actually), we can’t really have an infinite value so the everest operator translates this 0 to 9999999.

2 Likes

Thanks for the response! It looks like this retentionCopies setting works well for our PostgreSQL cluster. I set the same value for a MongoDB cluster, but it does not look like older backups are being pruned from the bucket. Is this expected? Is there a better way to set retention for MongoDB clusters?

Hi @JayV, thank you so much for letting us know about this.
We have done some internal testing and we can confirm this is indeed a bug in our everest operator. We have created this ticket to address this issue.
I’ll let you know once the fix is released

1 Like

Fantastic! Thank you for digging into the behavior and confirming that I’m not crazy (at least in this singular regard!).