# Check the first-consumer message before treating a restored Container Storage claim as failed

> The documented Elastic SAN snapshot restore can leave its new PVC Pending until a consuming pod is created.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-580-check-the-first-consumer-message-before-treating-a-restored-container-storage/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:22:16+00:00
- Modified: 2026-09-10T02:14:31+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

The documented Elastic SAN snapshot restore can leave its new PVC Pending until a consuming pod is created.

## Potentially affected

Azure Container Storage snapshot restoration using Elastic SAN-backed persistent volumes on AKS.

## DSE recommendation

Read the PVC event message and verify its intended consumer before recreating restore resources.

## Article

## Source facts

Microsoft’s Elastic SAN-backed restore workflow creates a new PVC from a ready volume snapshot. The PVC can show Pending with a message that binding is waiting for its first consumer. The subsequent step creates a pod using that restored claim and verifies the pod is running and the claim is bound.

The restored claim’s storage class must match the original claim’s class, and its data source must name the intended snapshot. This documented snapshot feature does not support local-NVMe ephemeral backing storage. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/container-storage/volume-snapshot-restore).

## Applicability

Confirm the backing storage, snapshot readiness, source snapshot reference and current PVC events. Distinguish the specific waiting-for-consumer message from other reasons a claim might remain Pending.

## DSE recommendation

DSE recommends checking the intended consumer and manifest references before deleting or recreating a restored claim. Keep the original data and recovery point protected while diagnosing the restore. Do not run a write benchmark over valuable restored files merely because the documentation includes a workload-simulation example; choose an approved, non-destructive data-validation method.

## Verification

Create the approved test consumer with the restored claim reference and observe pod and binding status. Validate representative restored data through that mount and investigate any continued Pending state from its actual events. Record snapshot identity, claim, consumer and observed data result separately. A bound claim establishes storage attachment progress, not by itself that the application’s recovery requirements have been met.

## Official references

[Microsoft Learn: Use volume snapshots with Azure Container Storage (version 2.x.x) with Azure Elastic SAN](https://learn.microsoft.com/en-us/azure/storage/container-storage/volume-snapshot-restore). Source retrieved September 9, 2026.

## Primary reference

- Name: Use volume snapshots with Azure Container Storage (version 2.x.x) with Azure Elastic SAN | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/container-storage/volume-snapshot-restore
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Check the first-consumer message before treating a restored Container Storage claim as failed,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-580-check-the-first-consumer-message-before-treating-a-restored-container-storage/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.