Context
Azure Blob object replication asynchronously copies selected block blobs between accounts. It is a policy-driven copy workflow, not an immediate mirror of every storage object. A destination missing a blob can reflect rule selection, prerequisites, a failed operation or work that has not finished.
Prerequisites are source and destination account IDs, containers, replication policy and a specific blob identity. Obtain read access to both policy configurations and relevant object properties. Confirm the accounts support the feature, including the documented namespace and protocol limitations.
1. Compare the policy pair and prerequisites
Read the policy on both accounts and compare policy IDs, source and destination account references, rule IDs and container names. The paired policy identifiers must match. A destination-only configuration is not sufficient evidence that the source is participating.
Verify versioning on both accounts and change feed on the source. Check whether the destination container still exists and remains in the policy. Preserve the current policy before making corrections. Avoid disabling prerequisites as a troubleshooting experiment because they also underpin retained history and other features.
2. Check whether the blob is selected
Compare the exact source name with rule prefix filters and any replication start boundary. A policy configured only for newer content does not automatically backfill every historical blob. Record the source version, creation or modification timeline and selected rule.
Inspect access tier, encryption and immutability interactions using current documentation. Archived blobs and some protected or customer-provided-key scenarios can prevent the expected copy. Separate an unsupported feature combination from an ordinary authorization issue; broad role grants do not make unsupported data operations eligible.
3. Read progress from the source
Inspect source-side object replication properties. Microsoft's documentation notes that properties appear when replication completes or fails; an absent completion property is not a reliable percentage-progress indicator. Correlate the specific object with the policy's pending operations and pending bytes metrics where enabled.
For a failed object, verify destination state and the documented failure conditions. For a growing backlog, examine age buckets and the workload's size or change pattern. Do not repeatedly recreate policies simply because copying is asynchronous. Establish the expected recovery lag and investigate evidence against that requirement.
Diagnostic checkpoints
| Observation | Possible cause | Next evidence |
|---|---|---|
| Whole container never copies | Policy pair or prerequisite | IDs, versioning and change feed |
| Only old objects absent | Rule start boundary | Object timestamps and selection |
| Source status reports failure | Destination or feature conflict | Container, tier and protection |
| Pending work ages steadily | Replication backlog | Age buckets and change volume |
Illustrative scenario
A hypothetical archive team enables a policy for newly created export blobs and expects historical files to appear immediately. New exports copy, while older files remain absent. Comparing the rule's selection boundary with object timestamps explains the difference before any policy recreation. This fictional example makes no claim about a measured replication delay.
Verification and replication SOP
Verify a selected test object by its business identity, content checksum and expected properties at the destination. Include an excluded object to check that filters remain narrow. Confirm the source reports completion and record the observed interval without treating it as a universal guarantee.
Maintain policy pairing, prerequisite ownership and tolerated lag in the SOP. Monitor pending work by age alongside failed object status. Revalidate after changing lifecycle tiers, immutability or encryption settings. A second account is useful only when the recovery plan also explains how to identify usable replicated data and safely route applications to it.
Explore Clouvenix backup disaster recovery for implementation and operational handover.
Technical reference
Replication configuration, behavior and limitations, and pending-work metrics.