Web App for Containers: Backup Failure Due to Storage Conflict — Investigation Needed

Question

Web App for Containers: Backup Failure Due to Storage Conflict — Investigation Needed

Kit-3249 0

Problem description

I am experiencing backup failures on two Linux site containers within the Web App for Containers service. The backups, which were successful until September 4, 2026, now fail with a storage 409 Conflict error. The failures seem related to an orphaned or inconsistent backup state, but the exact cause remains unclear.

Environment

Web App for Containers, Linux site containers, region not specified in case information.

What I've already tried

I created a new container with a fresh SAS token and pointed backups at it, but the issue persists. I have also confirmed that no backup configurations exist on either site, as backups are initiated manually via POST requests with inline storage URLs. No scheduled backups are used.

Current status

I am seeking assistance to understand the root cause of the storage 409 Conflict during backup finalization and to identify whether provider-side cleanup is required to resolve the orphaned backup state.

Ajay Rathod 445 Reputation points Microsoft External Staff Moderator

2026-09-23T18:07:11.9666667+00:00

Hi @Kit-3249

Thanks for reaching out to Q&A, we are looking into this and we will keep you posted for any updates.
Likhitha Sulake 105 Reputation points Microsoft External Staff Moderator

2026-09-27T16:52:27.99+00:00
Hi @Kit-3249 ,

Thank you for reporting this action and providing detailed information.
Could you please try below steps:

Capture the exact 409** response **body, timestamp, backup operation/correlation ID, App Service name, resource group, subscription ID, and region.

Verify the SAS URL is valid and has the required storage permissions.

Check the target container for conflicting/incomplete backup artifacts.

Reproduce once with a new container/SAS and capture the full POST request/response.

Since the issue persists with fresh storage, will check provider-side cleanup is required.

If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

Hope this helps. Please let us know if you have any further questions. Thank you.
Likhitha Sulake 105 Reputation points Microsoft External Staff Moderator

2026-09-28T15:02:54.88+00:00

Hi @Kit-3249 ,
Following up to see if you had a chance to check my previous response and if it was helpful. Please do let me know if you're still facing the issue and need any further assistance on this.
Kit-3249 0 Reputation points

2026-09-29T05:49:46.5233333+00:00

Hi Likhitha,
All of the details you asked were attached to the original Microsoft ticket, but are not suitable for posting to a public forum.
Regards your suggestions 3/4 that was already done.

At the moment, the standing Microsoft Ticketing system AI-bot response on the ticket is not to attempt another backup until Microsoft have had a chance to investigate.
Kind regards,

Kit

1 answer

Your answer

Ajay Rathod 445 Reputation points Microsoft External Staff Moderator

2026-09-23T18:07:11.9666667+00:00

Hi @Kit-3249

Thanks for reaching out to Q&A, we are looking into this and we will keep you posted for any updates.
Likhitha Sulake 105 Reputation points Microsoft External Staff Moderator

2026-09-27T16:52:27.99+00:00

Hi @Kit-3249 ,

Thank you for reporting this action and providing detailed information.
Could you please try below steps:

Capture the exact 409** response **body, timestamp, backup operation/correlation ID, App Service name, resource group, subscription ID, and region.

Verify the SAS URL is valid and has the required storage permissions.

Check the target container for conflicting/incomplete backup artifacts.

Reproduce once with a new container/SAS and capture the full POST request/response.

Since the issue persists with fresh storage, will check provider-side cleanup is required.

If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

Hope this helps. Please let us know if you have any further questions. Thank you.
Likhitha Sulake 105 Reputation points Microsoft External Staff Moderator

2026-09-28T15:02:54.88+00:00

Hi @Kit-3249 ,
Following up to see if you had a chance to check my previous response and if it was helpful. Please do let me know if you're still facing the issue and need any further assistance on this.
Kit-3249 0 Reputation points

2026-09-29T05:49:46.5233333+00:00

Hi Likhitha,
All of the details you asked were attached to the original Microsoft ticket, but are not suitable for posting to a public forum.
Regards your suggestions 3/4 that was already done.

At the moment, the standing Microsoft Ticketing system AI-bot response on the ticket is not to attempt another backup until Microsoft have had a chance to investigate.
Kind regards,

Kit

Answer 1

Hello,

Since the same 409 Conflict occurs with a newly created storage container and a new SAS URL, this makes a simple stale-container or SAS configuration issue less likely.

App Service backup is initiated against the storage container supplied in the backup request, and the backup API exposes the backup status, log, correlation ID, and storage URL for each backup operation.

I would check the following before assuming that provider-side cleanup is required:

Query the app's backup history and check whether there are any InProgress, Failed, DeleteInProgress, or DeleteFailed backup records.

Capture the backup ID, correlation ID, timestamp, HTTP status, and complete error message from the failed operation.

Confirm that the SAS URL points to the intended container and has the permissions required for App Service backup. App Service custom backups require SAS-based access to the storage account.

Repeat the test with the newly created container and record whether the 409 occurs at the same stage of the operation.

Check the storage account's diagnostic/resource logs around the exact failure timestamp to determine whether the 409 is being returned by Azure Storage or by the App Service backup service.

The important distinction is where the 409 originates. A 409 returned directly by Azure Storage can have storage-specific causes, while a 409 returned by the App Service backup workflow may indicate a conflicting backup operation/state.

If the backup history shows a stale InProgress/deletion state, or the operation fails during App Service-side finalization even with a completely new storage account/container and valid SAS, then this is reasonable evidence for an App Service backend issue. The public documentation does not establish that an "orphaned backup state" can be manually cleared by the customer, so I would not recommend deleting or modifying internal backup records.

At that point, an Azure support case should include the subscription ID, affected app names, region, backup IDs/correlation IDs, UTC timestamps, request/response error details, and confirmation that a fresh storage container/SAS was tested. Microsoft can then correlate the failed operation with the App Service backend logs and determine whether provider-side cleanup is required.

Do not post SAS URLs, storage account keys, or other credentials in the Q&A thread.