Azure Database for PostgreSQL flexible server: Point-in-time restore — Encountered failure during restore process

Question

Azure Database for PostgreSQL flexible server: Point-in-time restore — Encountered failure during restore process

GustavoHiga-5354 0

Problem description

I am attempting to perform a point-in-time restore on my Azure Database for PostgreSQL flexible server, but the operation fails consistently. The restore was initiated via Azure CLI, specifying a restore point from September 28, 2026, at 2:25 p.m. ET, and the source server was created on September 14, 2026. The failure occurs with a server-side error, and the activity logs indicate a 'ResourceOperationFailure' with an 'InternalServerError'. I have confirmed that the source server does not have TimescaleDB installed, and the extensions on the server are limited to pg_trgm, pgcrypto, and btree_gist. The server is part of an Elastic Cluster (Citus) with a cluster size of 2 nodes, and the recovery attempt fails within approximately 2 hours and 50 minutes, suggesting a possible internal timeout. Additionally, the target server resources are no longer accessible in the portal, which seems to be a platform issue.

Environment

Azure Database for PostgreSQL flexible server, East US 2 region, source server created on 2026-09-14, no specific SKU or high availability details provided.

What I've already tried

I initiated the restore using Azure CLI 2.83.0 with the --no-wait option. The operation failed twice at similar durations, and I reviewed the activity logs which show a 'Failed' status with an internal server error. I verified that TimescaleDB is not installed on the source server and confirmed the extensions installed. I also checked the backup chain, which is healthy, and the earliest restore point is well within the retention period. No ownership or permission changes have been made to extensions, and the server configuration appears healthy. I also attempted to view the activity logs and resource details, but the target servers no longer exist in the portal, indicating a platform-level issue.

Current status

I am seeking clarification on whether point-in-time restore is supported for Elastic Cluster (Citus) servers, and if so, what the underlying cause of these failures might be. Specifically, I need to understand if there is an internal timeout or platform bug causing the restore failures after approximately 2 hours and 50 minutes, and what alternative recovery procedures are recommended for my scenario.

SIVASANKAR YEDDULA 250 Reputation points Microsoft External Staff Moderator

2026-09-30T00:54:57.3233333+00:00

Hi @GustavoHiga-5354 ,
Thank you for posting your query on Microsoft Q&A platform.

We are looking into this issue and will keep you posted updates.

Thanks,
SIVASANKAR YEDDULA 250 Reputation points Microsoft External Staff Moderator

2026-09-30T00:59:16.9166667+00:00
Hello @GustavoHiga-5354 ,

Thank you for providing the detailed information.

Based on the information provided, this does not currently appear to be a standard PostgreSQL extension or backup-retention issue.
Point-in-time restore support

Azure Database for PostgreSQL Flexible Server supports point-in-time recovery using the automated backup and WAL backup chain. Elastic Clusters are built on Azure Database for PostgreSQL Flexible Server and use Citus for distributed PostgreSQL workloads.

Microsoft documentation for Elastic Cluster migration scenarios also explicitly references point-in-time restore (PITR), so PITR is applicable to Elastic Cluster scenarios.
Assessment of the reported failure

In your case, the important observations are:

The requested restore point, September 28, 2026 at 2:25 PM ET, is within the available retention period.

The backup chain has already been confirmed as healthy.

TimescaleDB is not installed.

The extensions are limited to pg_trgm, pgcrypto, and btree_gist.

Two restore attempts failed after a similar duration.

Azure Activity Log reports ResourceOperationFailure / InternalServerError.

The failed target resources subsequently disappeared from the portal.

Because the Azure control-plane operation is returning InternalServerError, I would not recommend treating this as a client-side Azure CLI problem based on the evidence currently available.

The approximately 2-hour-50-minute duration alone is also not sufficient evidence to conclude that there is a specific PITR timeout. An internal timeout or product defect would need to be confirmed through Azure backend telemetry.
Recommended next steps

At this stage, I recommend opening an Azure support request for backend investigation rather than repeatedly initiating the same restore.

Please provide the support engineer with:

Source Elastic Cluster resource ID.

Subscription ID and resource group.

Region: East US 2.

Exact PITR timestamp requested.

Failed deployment/correlation or operation IDs from Activity Log.

UTC timestamps for both failed restore attempts.

Complete Activity Log failure JSON showing ResourceOperationFailure and InternalServerError.

Names of the failed target servers/resources, even if those resources are no longer visible in the portal.

The support team can then correlate the operation IDs and timestamps with service-side telemetry and determine where the restore workflow failed.
Recovery alternatives

If recovery is urgent, you can also evaluate restoring to the latest available restore point rather than the historical timestamp to determine whether the failure is specific to that recovery path.

If you have Azure Backup configured separately for the PostgreSQL Flexible Server/Elastic Cluster workload, Azure Backup also provides recovery options. However, this should be considered an alternative recovery path and not evidence that the native PITR failure is expected.

I would avoid repeatedly retrying the identical PITR operation until the service-side failure has been investigated, since the two similar InternalServerError results indicate that further backend correlation is appropriate.

Microsoft documentation:

Backup and restore in Azure Database for PostgreSQL Flexible Server: https://learn.microsoft.com/azure/postgresql/backup-restore/concepts-backup-restore

Restore to the latest restore point: https://learn.microsoft.com/azure/postgresql/backup-restore/how-to-restore-latest-restore-point

Elastic Clusters: https://learn.microsoft.com/azure/postgresql/elastic-clusters/concepts-elastic-clusters

I hope this helps clarify the supported recovery path and the next investigation step.

1 answer

Your answer

SIVASANKAR YEDDULA 250 Reputation points Microsoft External Staff Moderator

2026-09-30T00:54:57.3233333+00:00

Hi @GustavoHiga-5354 ,
Thank you for posting your query on Microsoft Q&A platform.

We are looking into this issue and will keep you posted updates.

Thanks,

Answer 1

Hi @GustavoHiga-5354

Based on the information provided, I don't see evidence that Point-in-Time Restore (PITR) is unsupported for Elastic Cluster (Citus). In fact, recent Azure Database for PostgreSQL release notes explicitly reference support for cluster-level PITR scenarios in elastic clusters, which suggests PITR is a supported capability. Azure Database for PostgreSQL flexible server: March 2026 Release

What stands out in your case is:

The restore fails with ResourceOperationFailure / InternalServerError.
Multiple restore attempts fail in a similar manner.
The target restore resource disappears and is no longer accessible afterward.
The source server, backup chain, and restore point appear valid based on your verification.

Those symptoms point more toward a platform-side restore failure than an extension or configuration issue on the source server. I was unable to find any public documentation describing a known ~2h50m timeout threshold or a customer-side action to diagnose an InternalServerError during PITR. Azure Database for PostgreSQL flexible server: March 2026 Release

Given that the failure is occurring inside the managed restore workflow and the target server is not surviving long enough for inspection, my recommendation would be to open an Azure support case and provide:

Subscription ID
Source server name
Failed restore operation IDs
Correlation IDs from Activity Log
Restore timestamp (2026-09-28 14:25 ET)
Region (East US 2)

The PostgreSQL service team can review backend restore logs that aren't exposed through the portal.

Short answer: PITR appears to be supported for Elastic Cluster (Citus), so a repeated InternalServerError combined with disappearing target resources is more indicative of a service-side issue requiring Azure Support investigation than a known configuration problem on the source server. Azure Database for PostgreSQL flexible server: March 2026 Release

**If this helps, please mark it as helpful or accepted so others encountering PITR failures on PostgreSQL Flexible Server can find the guidance more easily.**Hi GustavoHiga-5354,

Based on the information provided, I don't see evidence that Point-in-Time Restore (PITR) is unsupported for Elastic Cluster (Citus). In fact, recent Azure Database for PostgreSQL release notes explicitly reference support for cluster-level PITR scenarios in elastic clusters, which suggests PITR is a supported capability.

What stands out in your case is:

The restore fails with ResourceOperationFailure / InternalServerError.
Multiple restore attempts fail in a similar manner.
The target restore resource disappears and is no longer accessible afterward.
The source server, backup chain, and restore point appear valid based on your verification.

Those symptoms point more toward a platform-side restore failure than an extension or configuration issue on the source server. I was unable to find any public documentation describing a known ~2h50m timeout threshold or a customer-side action to diagnose an InternalServerError during PITR.

Given that the failure is occurring inside the managed restore workflow and the target server is not surviving long enough for inspection, my recommendation would be to open an Azure support case and provide:

Subscription ID
Source server name
Failed restore operation IDs
Correlation IDs from Activity Log
Restore timestamp (2026-09-28 14:25 ET)
Region (East US 2)

The PostgreSQL service team can review backend restore logs that aren't exposed through the portal.

Short answer: PITR appears to be supported for Elastic Cluster (Citus), so a repeated InternalServerError combined with disappearing target resources is more indicative of a service-side issue requiring Azure Support investigation than a known configuration problem on the source server.

If this helps, please mark it as helpful or accepted so others encountering PITR failures on PostgreSQL Flexible Server can find the guidance more easily.