pitr

tamram · tamram · commit e27344338fa6 · 2020-05-07T16:00:23.000-04:00
diff --git a/articles/storage/blobs/point-in-time-restore-manage.md b/articles/storage/blobs/point-in-time-restore-manage.md
@@ -7,7 +7,7 @@ author: tamram
 
 ms.service: storage
 ms.topic: how-to
-ms.date: 05/01/2020
+ms.date: 05/06/2020
 ms.author: tamram
 ms.subservice: blobs
 ---
@@ -16,12 +16,10 @@ ms.subservice: blobs
 
 You can use point-in-time restore (preview) to restore block blobs to their state at an earlier point in time. This article describes how to enable point-in-time restore for a storage account with PowerShell. It also shows how to perform a restore operation with PowerShell.
 
-To learn more about point-in-time restore, see [Point-in-time restore for block blobs (preview)](point-in-time-restore-overview.md).
+For more information and to learn how to register for the preview, see [Point-in-time restore for block blobs (preview)](point-in-time-restore-overview.md).
 
 > [!CAUTION]
-> Point-in-time restore supports restoring operations on block blobs only. Operations on containers cannot be restored. If you delete a container from the storage account by calling the [Delete Container](/rest/api/storageservices/delete-container) operation during the point-in-time restore preview, that container cannot be restored with a restore operation.
->
-> During the preview, be careful to delete blobs individually if you may want to restore them. Avoid deleting blobs by deleting their parent container.
+> Point-in-time restore supports restoring operations on block blobs only. Operations on containers cannot be restored. If you delete a container from the storage account by calling the [Delete Container](/rest/api/storageservices/delete-container) operation during the point-in-time restore preview, that container cannot be restored with a restore operation. During the preview, instead of deleting a container, delete individual blobs if you may want to restore them.
 
 > [!IMPORTANT]
 > The point-in-time restore preview is intended for non-production use only. Production service-level agreements (SLAs) are not currently available.
@@ -94,9 +92,20 @@ Get-AzStorageBlobServiceProperty -ResourceGroupName $rgName `
     -StorageAccountName $accountName
 ```
 
-## Restore all containers in the account
+## Perform a restore operation
 
-To restore all containers and blobs in the storage account, call the Restore-AzStorageBlobRange command, specifying a UTC **DateTime** value that indicates the restore point. The following example restores containers in the storage account to their state 12 hours before the present moment:
+To initiate a restore operation, call the Restore-AzStorageBlobRange command, specifying the restore point as a UTC **DateTime** value. You can specify one or more lexicographical ranges of blobs to restore, or omit a range to restore all blobs in all containers in the storage account. The restore operation may take several minutes to complete.
+
+Keep in mind the following rules when specifying a range of blobs to restore:
+
+- The container pattern specified for the start range and end range must include a minimum of three characters. The forward slash (/) that is used to separate a container name from a blob name does not count toward this minimum.
+- Only one range can be specified per restore operation.
+- Wildcard characters are not supported. They are treated as standard characters.
+- You can restore blobs in the `$root` and `$web` containers by explicitly specifying them in a range pass to a restore operation. The `$root` and `$web` containers are not restored unless they are explicitly specified, so they are not restored when a restore operation restores all containers in the storage account. Other system containers cannot restored.
+
+### Restore all containers in the account
+
+To restore all containers and blobs in the storage account, call the Restore-AzStorageBlobRange command, omitting the -BlobRestoreRange parameter. The following example restores containers in the storage account to their state 12 hours before the present moment:
 
 ```powershell
 # Specify -TimeToRestore as a UTC value
@@ -105,9 +114,9 @@ Restore-AzStorageBlobRange -ResourceGroupName $rgName `
     -TimeToRestore (Get-Date).AddHours(-12)
 ```
 
-## Restore a range of block blobs
+### Restore a single range of block blobs
 
-To restore a range of blobs, call the Restore-AzStorageBlobRange command and specify a lexicographical range of container and blob names for the **-BlobRestoreRange** parameter. The start of the range is in inclusive, and the end of the range is exclusive.
+To restore a range of blobs, call the Restore-AzStorageBlobRange command and specify one or more lexicographical ranges of container and blob names for the `-BlobRestoreRange` parameter. The start of the range is in inclusive, and the end of the range is exclusive.
 
 For example, to restore the blobs in a single container named *sample-container*, you can specify a range that starts with *sample-container* and ends with *sample-container1*. There is no requirement for the containers named in the start and end ranges to exist. Because the end of the range is exclusive, even if the storage account includes a container named *sample-container1*, only the container named *sample-container* will be restored by the restore operation:
 
@@ -131,12 +140,19 @@ Restore-AzStorageBlobRange -ResourceGroupName $rgName `
     -TimeToRestore (Get-Date).AddDays(-3)
 ```
 
-Keep in mind the following rules when specifying a range of blobs to restore:
+### Restore multiple ranges of block blobs
 
-- The container pattern specified for the start range and end range must include a minimum of three characters. The forward slash (/) that is used to separate a container name from a blob name does not count toward this minimum.
-- Only one range can be specified per restore operation.
-- Wildcard characters are not supported. They are treated as standard characters.
-- You can restore blobs in the `$root` and `$web` containers by explicitly specifying them in a range pass to a restore operation. The `$root` and `$web` containers are not restored unless they are explicitly specified, so they are not restored when a restore operation restores all containers in the storage account. Other system containers cannot restored.
+To restore multiple ranges of block blobs, specify an array of ranges for the `-BlobRestoreRange` parameter:
+
+```powershell
+$range1 = New-AzStorageBlobRangeToRestore -StartRange container1 -EndRange container2
+$range2 = New-AzStorageBlobRangeToRestore -StartRange container4 -EndRange container5
+
+Restore-AzStorageBlobRange -ResourceGroupName $rgName `
+    -StorageAccountName $accountName `
+    -TimeToRestore (Get-Date).AddMinutes(-30) `
+    -BlobRestoreRange @($range1, $range2)
+```
 
 ## Next steps
 
diff --git a/articles/storage/blobs/point-in-time-restore-overview.md b/articles/storage/blobs/point-in-time-restore-overview.md
@@ -7,7 +7,7 @@ author: tamram
 
 ms.service: storage
 ms.topic: conceptual
-ms.date: 05/01/2020
+ms.date: 05/06/2020
 ms.author: tamram
 ms.subservice: blobs
 ---
@@ -24,15 +24,24 @@ To enable point-in-time restore, you create a management policy for the storage
 
 To initiate a point-in-time restore, call the [Restore Blob Ranges](/rest/api/storagerp/storageaccounts/restoreblobranges) operation and specify a restore point in UTC time. You can specify a lexicographical range of container and blob names to restore, or omit the range to restore all containers in the storage account. The **Restore Blob Ranges** operation returns a restore ID that uniquely identifies the operation.
 
+Azure Storage analyzes all changes that have been made to the specified blobs between the requested restore point, specified in UTC time, and the present moment. The restore operation is atomic, so it either succeeds completely in restoring all changes, or it fails. If there are any blobs that cannot be restored, then the operation fails, and read and write operations to the affected containers resume.
+
 When you request a restore operation, Azure Storage blocks data operations on the blobs in the range being restored for the duration of the operation. Read, write, and delete operations are blocked in the primary location. Read operations from the secondary location may proceed during the restore operation if the storage account is geo-replicated.
 
-Azure Storage analyzes all changes that have been made to the specified blobs between the requested restore point, specified in UTC time, and the present moment. The restore operation is atomic, so it either succeeds completely in restoring all changes, or it fails. If there are any blobs that cannot be restored, then the operation fails, and read and write operations to the affected containers resume.
+To check the status of a point-in-time restore, call the **Get Restore Status** operation with the restore ID returned from the **Restore Blob Ranges** operation.
 
-When the restore operation begins, a system table named `$RestoreTable-{RestoreID}` is created in the storage account. This table is deleted when the restore operation completes successfully, or if it fails.
+Keep in mind the following points about restore operations:
+
+- Only one restore operation can be run on a storage account at a time. A restore operation cannot be canceled once it is in progress, but a second restore operation can be performed to undo the first operation.
+- A block that has been uploaded via [Put Block](/rest/api/storageservices/put-block) or [Put Block from URL](/rest/api/storageservices/put-block-from-url), but not committed via [Put Block List](/rest/api/storageservices/put-block-list), is not part of a blob and so is not restored as part of a restore operation.
+- A blob with an active lease cannot be restored. If a blob with an active lease is included in the range of blobs to restore, the restore operation will fail atomically.
+- Snapshots are not created or deleted as part of a restore operation. Only the base blob is restored to its previous state.
+- If a blob has moved between the hot and cool tiers in the period between the present moment and the restore point, the blob is restored to its previous tier. However, a blob that has moved to the archive tier will not be restored.
 
-To check the status of a point-in-time restore, call the [Get Restore Status](???this is in the spec, but i don't see it in the SRP REST API) operation with the restore ID.
+Point-in-time restore supports restoring operations on block blobs only. Operations on containers cannot be restored.
 
-Only one restore operation can be run on a storage account at a time. A restore operation cannot be canceled once it is in progress, but a second restore operation can be performed to undo the first operation.
+> [!CAUTION]
+> Point-in-time restore supports restoring operations on block blobs only. Operations on containers cannot be restored. If you delete a container from the storage account by calling the [Delete Container](/rest/api/storageservices/delete-container) operation during the point-in-time restore preview, that container cannot be restored with a restore operation. During the preview, instead of deleting a container, delete individual blobs if you may want to restore them.
 
 ### Prerequisites for point-in-time restore
 
@@ -50,38 +59,11 @@ When you enable point-in-time restore for a storage account, you specify a reten
 
 The retention period begins when you enable point-in-time restore. Keep in mind that you cannot restore blobs to a state prior to the beginning of the retention period. For example, if you enabled point-in-time restore on May 1st with a retention of 30 days, then on May 15th you can restore to a maximum of 15 days. On June 1st, you can restore data from between 1 and 30 days.
 
-The retention period for point-in-time restore must be at least one day greater than the retention period specified for soft delete.
+The retention period for point-in-time restore must be at least one day less than the retention period specified for soft delete. For example, if the soft delete retention period is set to 7 days, then the point-in-time restore retention period may be between 1 and 6 days.
 
 ### Permissions for point-in-time restore
 
-To initiate a restore operation, a client must have write permissions to all containers in the storage account. To grant permissions to authorize a restore operation with Azure Active Directory (Azure AD), assign the **Storage Blob Data Contributor** role to the security principal at the level of the storage account, resource group, or subscription.
-
-## Supported operations
-
-Point-in-time restore will restore data affected by the following write operations on block blobs, if these operations have been called during the interval between the restore point and the present moment:
-
-- [Put Blob](/rest/api/storageservices/put-blob)
-- [Put Block List](/rest/api/storageservices/put-block-list)
-- [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata)
-- [Set Blob Properties](/rest/api/storageservices/set-blob-properties)
-- [Copy Blob](/rest/api/storageservices/copy-blob)
-- [Abort Copy Blob](/rest/api/storageservices/abort-copy-blob)
-- [Delete Blob](/rest/api/storageservices/delete-blob)
-- [Undelete Blob](/rest/api/storageservices/undelete-blob)
-
-Keep in mind the following points about restore operations:
-
-- A block that has been uploaded via [Put Block](/rest/api/storageservices/put-block) or [Put Block from URL](/rest/api/storageservices/put-block-from-url), but not committed via [Put Block List](/rest/api/storageservices/put-block-list), is not part of a blob and so is not restored as part of a restore operation.
-- A blob with an active lease cannot be restored. If a blob with an active lease is included in the range of blobs to restore, the restore operation will fail atomically.
-- Only the base blob is restored to its previous state. Snapshots are not created or deleted as part of a restore operation.
-- If a blob has moved between the hot and cool tiers in the period between the present moment and the restore point, the blob is restored to its previous tier. However, a blob that has moved to the archive tier will not be restored.
-
-Point-in-time restore supports restoring operations on block blobs only. Operations on containers cannot be restored.
-
-> [!CAUTION]
-> Point-in-time restore supports restoring operations on block blobs only. Operations on containers cannot be restored. If you delete a container from the storage account by calling the [Delete Container](/rest/api/storageservices/delete-container) operation during the point-in-time restore preview, that container cannot be restored with a restore operation.
->
-> During the preview, be careful to delete blobs individually if you may want to restore them. Avoid deleting blobs by deleting their parent container.
+To initiate a restore operation, a client must have write permissions to all containers in the storage account. To grant permissions to authorize a restore operation with Azure Active Directory (Azure AD), assign the **Storage Account Contributor** role to the security principal at the level of the storage account, resource group, or subscription.
 
 ## About the preview
 
@@ -92,7 +74,6 @@ The following regions support point-in-time restore in preview:
 - Canada Central
 - Canada East
 - France Central
-- France South
 
 The preview includes the following limitations:
 
@@ -131,6 +112,16 @@ Get-AzProviderFeature -ProviderNamespace Microsoft.Storage `
     -FeatureName Changefeed
 ```
 
+## Pricing and billing
+
+Billing for point-in-time restore depends on the quantity of data processed to perform the restore operation. The quantity of data processed is a function of the number of objects in the storage account and the number of changes that occurred between the restore point and the present moment. For example, assuming a relatively constant rate of change to block blob data in a storage account, a restore operation that goes back in time 1 day would cost 1/10th of a restore that goes back in time 10 days.
+
+To estimate the cost of a restore operation, review the change feed log to estimate the quantity of data modified during the restore period. For example, if the retention period for change feed is 30 days, and the size of the change feed is 10 MB, then restoring to a point 10 days earlier for a locally redundant (LRS) storage account would cost approximately one-third of the price listed for an LRS account in that region. To restore to a point that is 27 days earlier, then the cost would be nine-tenths of the price listed.
+
+## Ask questions or provide feedback
+
+To ask questions about the point-in-time restore preview, or to provide feedback, contact Microsoft at pitrdiscussion@microsoft.com.
+
 ## Next steps
 
 - [Enable and manage point-in-time restore for block blobs (preview)](point-in-time-restore-manage.md)
