How to Handle Point-in-Time Restore with Azure PostgreSQL and Terraform?

Question

Hello,

I'm using an Azure PostgreSQL database and need to perform a point-in-time restore (PITR) as part of a disaster recovery drill. I can successfully restore the database to a new server and update my application to point to this new server. However, I have a few concerns and would love some advice:

I'm deploying the database server using Infrastructure as Code (Terraform). After performing a PITR, I end up with a new server that is not represented in my Terraform code.

Is there a way to properly replace the existing server with the point-in-time data state while keeping my Terraform code in sync?

What do you think is the best approach to handle this situation? Any insights or best practices would be greatly appreciated!

Thanks in advance!

Answer 1

@Kamal Rathnayake Welcome to Microsoft Q&A thanks for posting your question.

While there are no specific guidelines on keeping Terraform code in sync after a PITR operation, a common practice is to manually update the Terraform state file after the restore operation with terraform import. However, I will check with my Internal team and get back on this.

Regards

Geetha

Answer 2

@Kamal Rathnayake Azure currently does not support in-place restores using the Point-in-Time Recovery feature of Azure PSQL Flexible server, so you have to always initially create a standalone flexible server resource. There is no one-click way to get Terraform to recognize this newly restored server without adding it to your Terraform code first and then using Terraform import commands. Deleting the original server will not address any state management issues.

The other alternative outside of imports would be to add some additional complexity to your Terraform code to conditionally create the restored server and manage in-line import blocks. Given that approach requires a bit of a deep dive I wrote an article here for further review.