Postgresql reploy failed

We triggered a “Redeploy” of that environment: https://console.qovery.com/organization/12e0c625-6fb8-434b-adeb-041614fa7a46/project/a7f79a8f-8c0e-46a5-8748-1ba9846481c9/environment/55cce4d1-3212-4012-a7b0-8e77692580b9/services/general

All the services have been redeployed except “PostgreSQL”. We tried to redeploy only that one but still got a “Deployment error” status.
The logs are not very helpful:

Do you have any suggestions on what happened and how to solve it?

Hello @jmeiss,

Seems this managed DB faced an issue during redeploy:

InvalidParameterValue: Your RDS instance z04867f66-postgresql is associated with an AWS Backup resource with id arn:aws:backup:eu-west-3:****8585:recovery-point:continuous:db-mkf6ce5vmnd54eplehtp4rrvci-3a85baa2. You can leave BackupRetentionPeriod blank, or you can specify it only with the current value 7. For more details, see the AWS Backup documentation.

Did you manaually changed anything on the DB from AWS console side (anything around backup / recovery)?

Cheers

Thanks Benjamin for providing more info. Is there a link where I could have seen it by myself?

Yes, I set up Point-in-time recovery https://aws.amazon.com/blogs/storage/point-in-time-recovery-and-continuous-backup-for-amazon-rds-with-aws-backup/ to enable continuous backup.

Should I remove the DB form the assigned resources before redeploying the DB and then re-enable it?

We will improve our logging on this front, just created a task to handle it on our end.

Regarding your change, for now Qovery supports a very common use case when it comes to managed DB, and you should not change anything on the DB instance AWS side without doing it via Qovery unless it creates configuration drift and prevent your DB from further deploys as you can see.

This configuration drift can be acceptable in the sense your DB is still running, but Qovery lost the opportunity to deploy it (db or the whole env) leading to deployment error.

To unlock your DB and allow deploys Qovery side, you should remove your custom setting AWS side, and it should be ok.

We have no plan as of yet to support the Point-in-time recovery, maybe at some point we will but I have no ETA.
If you need more flexibility than Qovery can affords on managed DB, I advise you to use a lifecycle job to manage the DB, otherwise, you won’t be able to set all advanced params Qovery doesn’t support.

You can have a look at this documentation to use lifecycle jobs to manage DBs => How To Use Lifecycle Job To Deploy Any Kind Of Resources | Qovery

Let me know if I can help.

Cheers

Alright, thanks a lot for your help and the explanation.

If there’s a voice I can give somewhere to give more weight to such a feature, I would love it.

For now, I disabled Pit recovery, deployed the DB, and re-enabled Pit recovery. It works for now and it’s the simplest solution for us.

Cheers

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.