![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(310.4, 85%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDZ%3C/text%3E%3C/svg%3E)
Azure Database for PostgreSQL
An Azure managed PostgreSQL database service for app development and deployment.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(16, 2%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMK%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 4%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESS%3C/text%3E%3C/svg%3E)
Hello Danylo Zemlianyi,
Welcome to the Microsoft Q&A and thank you for posting your questions here.
I understand that you are having persistent failures while attempting to restore a PostgreSQL Flexible Server from an automated backup in Azure, particularly with Point-in-Time Restore (PITR) operations in the East US region.
This isn’t just about a successful restore eventually completing on November 3rd, but about addressing the broader issue: multiple failed attempts with InternalServerError, tracking IDs, and the lack of transparency around the root cause.
Therefore, it’s important to validate that the new server is not only created but also operational. You should confirm the server’s status in the Azure Portal under Overview, ensure it shows “Ready,” and check performance metrics like CPU and memory under Monitoring. If you’re unable to connect, it’s likely due to post-restore configuration issues such as firewall rules, DNS resolution, or authentication mismatches.
To resolve this, go to Networking > Firewall rules on the new server and add your client IP or App Service IP. Also, ensure that your application is using the correct FQDN (e.g., newserver.postgres.database.azure.com) and not an IP address, as IP-based connections can lead to DNS resolution failures. Use the correct username format (username@servername) and verify that SSL settings are properly configured. For more guidance, check [Azure’s official troubleshooting guide - https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-troubleshoot-common-connection-issues
Additionally, it’s critical to validate the integrity of the restored data. Connect using psql or pgAdmin, list tables with \dt, and run sample queries to ensure data consistency. This step ensures that the backup was not only restored but also usable.
If you still need clarity on the original InternalServerError and failed attempts, escalate the issue to Microsoft Support with your tracking IDs (e.g., 115fa1f2-a031-4137-b459-1197eed61976) and request a Post-Incident Report (PIR) via your Azure Portal or contact Priority Customer Support - PCS: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/priority-community-support
I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.
Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.