Rehydrate blob data from the archive tier
While a blob is in the archive access tier, it's considered offline and can't be read or modified. The blob metadata remains online and available, allowing you to list the blob and its properties. Reading and modifying blob data is only available with online tiers such as hot or cool. There are two options to retrieve and access data stored in the archive access tier.
- Rehydrate an archived blob to an online tier - Rehydrate an archive blob to hot or cool by changing its tier using the Set Blob Tier operation.
- Copy an archived blob to an online tier - Create a new copy of an archive blob by using the Copy Blob operation. Specify a different blob name and a destination tier of hot or cool.
For more information on tiers, see Azure Blob storage: hot, cool, and archive access tiers.
Rehydrate an archived blob to an online tier
To read data in archive storage, you must first change the tier of the blob to hot or cool. This process is known as rehydration and can take hours to complete. We recommend large blob sizes for optimal rehydration performance. Rehydrating several small blobs concurrently may add additional time. There are currently two rehydrate priorities, High and Standard, which can be set via the optional x-ms-rehydrate-priority property on a Set Blob Tier or Copy Blob operation.
- Standard priority: The rehydration request will be processed in the order it was received and may take up to 15 hours.
- High priority: The rehydration request will be prioritized over Standard requests and may finish in under 1 hour for objects under ten GB in size.
Standard priority is the default rehydration option for archive. High priority is a faster option that will cost more than Standard priority rehydration and is usually reserved for use in emergency data restoration situations.
High priority may take longer than 1 hour, depending on blob size and current demand. High priority requests are guaranteed to be prioritized over Standard priority requests.
Once a rehydration request is initiated, it cannot be canceled. During the rehydration process, the x-ms-access-tier blob property will continue to show as archive until rehydration is completed to an online tier. To confirm rehydration status and progress, you may call Get Blob Properties to check the x-ms-archive-status and the x-ms-rehydrate-priority blob properties. The archive status can read "rehydrate-pending-to-hot" or "rehydrate-pending-to-cool" depending on the rehydrate destination tier. The rehydrate priority will indicate the speed of "High" or "Standard". Upon completion, the archive status and rehydrate priority properties are removed, and the access tier blob property will update to reflect the selected hot or cool tier.
Rehydrating a blob doesn't change it's
Last-Modified time. Using the lifecycle management feature can create a scenario where a blob is rehydrated, then a lifecycle management policy moves the blob back to archive because the
Last-Modified time is beyond the threshold set for the policy. To avoid this scenario, use the Copy an archived blob to an online tier method. The copy method creates a new instance of the blob with an updated
Last-Modified time and won't trigger the lifecycle management policy.
Monitor rehydration progress
During rehydration, use the get blob properties operation to check the Archive Status attribute and confirm when the tier change is complete. The status reads "rehydrate-pending-to-hot" or "rehydrate-pending-to-cool" depending on the destination tier. Upon completion, the archive status property is removed, and the Access Tier blob property reflects the new hot or cool tier.
Copy an archived blob to an online tier
If you don't want to rehydrate your archive blob, you can choose to do a Copy Blob operation. Your original blob will remain unmodified in archive while a new blob is created in the online hot or cool tier for you to work on. In the Copy Blob operation, you may also set the optional x-ms-rehydrate-priority property to Standard or High to specify the priority at which you want your blob copy created.
Copying a blob from archive can take hours to complete depending on the rehydrate priority selected. Behind the scenes, the Copy Blob operation reads your archive source blob to create a new online blob in the selected destination tier. The new blob may be visible when you list blobs but the data is not available until the read from the source archive blob is complete and data is written to the new online destination blob. The new blob is as an independent copy and any modification or deletion to it does not affect the source archive blob.
Do not delete the the source blob until the copy is completed successfully at the destination. If the source blob is deleted then the destination blob may not complete copying and will be empty. You may check the x-ms-copy-status to determine the state of the copy operation.
Archive blobs can only be copied to online destination tiers within the same storage account. Copying an archive blob to another archive blob is not supported. The following table shows the capabilities of a Copy Blob operation.
|Hot tier source||Cool tier source||Archive tier source|
|Hot tier destination||Supported||Supported||Supported within the same account; pending rehydrate|
|Cool tier destination||Supported||Supported||Supported within the same account; pending rehydrate|
|Archive tier destination||Supported||Supported||Unsupported|
Pricing and billing
Rehydrating blobs out of archive into hot or cool tiers are charged as read operations and data retrieval. Using High priority has higher operation and data retrieval costs compared to standard priority. High priority rehydration shows up as a separate line item on your bill. If a high priority request to return an archive blob of a few gigabytes takes over 5 hours, you won't be charged the high priority retrieval rate. However, standard retrieval rates still apply as the rehydration was prioritized over other requests.
Copying blobs from archive into hot or cool tiers are charged as read operations and data retrieval. A write operation is charged for the creation of the new blob copy. Early deletion fees don't apply when you copy to an online blob because the source blob remains unmodified in the archive tier. High priority retrieval charges do apply if selected.
Blobs in the archive tier should be stored for a minimum of 180 days. Deleting or rehydrating archived blobs before 180 days will incur early deletion fees.
Rehydrate an archive blob to an online tier
Sign in to the Azure portal.
In the Azure portal, search for and select All Resources.
Select your storage account.
Select your container and then select your blob.
In the Blob properties, select Change tier.
Select the Hot or Cool access tier.
Select a Rehydrate Priority of Standard or High.
Select Save at the bottom.
Copy an archive blob to a new blob with an online tier
The following PowerShell script can be used to copy an archive blob to a new blob within the same storage account. The
$rgName variable must be initialized with your resource group name. The
$accountName variable must be initialized with your storage account name. The
$destContainerName variables must be initialized with your container names. The
$destBlobName variables must be initialized with your blob names.
#Initialize the following with your resource group, storage account, container, and blob names $rgName = "" $accountName = "" $srcContainerName = "" $destContainerName = "" $srcBlobName = "" $destBlobName = "" #Select the storage account and get the context $storageAccount =Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName $ctx = $storageAccount.Context #Copy source blob to a new destination blob with access tier hot using standard rehydrate priority Start-AzStorageBlobCopy -SrcContainer $srcContainerName -SrcBlob $srcBlobName -DestContainer $destContainerName -DestBlob $destBlobName -StandardBlobTier Hot -RehydratePriority Standard -Context $ctx