32 TB disk support

David Curwin · David Curwin · commit 1b8537965835 · 2019-12-04T12:54:52.000+02:00
diff --git a/articles/backup/backup-azure-vms-introduction.md b/articles/backup/backup-azure-vms-introduction.md
@@ -74,7 +74,7 @@ The following table explains the different types of snapshot consistency:
 --- | --- | --- | ---
 **Application-consistent** | App-consistent backups capture memory content and pending I/O operations. App-consistent snapshots use a VSS writer (or pre/post scripts for Linux) to ensure the consistency of the app data before a backup occurs. | When you're recovering a VM with an app-consistent snapshot, the VM boots up. There's no data corruption or loss. The apps start in a consistent state. | Windows: All VSS writers succeeded<br/><br/> Linux: Pre/post scripts are configured and succeeded
 **File-system consistent** | File-system consistent backups provide consistency by taking a snapshot of all files at the same time.<br/><br/> | When you're recovering a VM with a file-system consistent snapshot, the VM boots up. There's no data corruption or loss. Apps need to implement their own "fix-up" mechanism to make sure that restored data is consistent. | Windows: Some VSS writers failed <br/><br/> Linux: Default (if pre/post scripts aren't configured or failed)
-**Crash-consistent** | Crash-consistent snapshots typically occur if an Azure VM shuts down at the time of backup. Only the data that already exists on the disk at the time of backup is captured and backed up.<br/><br/> A crash-consistent recovery point doesn't guarantee data consistency for the operating system or the app. | Although there are no guarantees, the VM usually boots, and then it starts a disk check to fix corruption errors. Any in-memory data or write operations that weren't transferred to disk before the crash are lost. Apps implement their own data verification. For example, a database app can use its transaction log for verification. If the transaction log has entries that aren't in the database, the database software rolls transactions back until the data is consistent. | VM is in shutdown state
+**Crash-consistent** | Crash-consistent snapshots typically occur if an Azure VM shuts down at the time of backup. Only the data that already exists on the disk at the time of backup is captured and backed up. | Starts with the VM boot process followed by a disk check to fix corruption errors. Any in-memory data or write operations that weren't transferred to disk before the crash are lost. Apps implement their own data verification. For example, a database app can use its transaction log for verification. If the transaction log has entries that aren't in the database, the database software rolls transactions back until the data is consistent. | VM is in shutdown (stopped/ deallocated) state.
 
 ## Backup and restore considerations
 
@@ -130,16 +130,6 @@ Data disk 2 | 4095 GB | 0 GB
 
 The actual size of the VM in this case is 17 GB + 30 GB + 0 GB = 47 GB. This protected-instance size (47 GB) becomes the basis for the monthly bill. As the amount of data in the VM grows, the protected-instance size used for billing changes to match.
 
-<a name="limited-public-preview-backup-of-vm-with-disk-sizes-up-to-30tb"></a>
-
-## Public Preview: Backup of VM with disk sizes up to 30 TB
-
-Azure Backup now supports public preview of larger and more powerful [Azure Managed Disks](https://azure.microsoft.com/blog/larger-more-powerful-managed-disks-for-azure-virtual-machines/) of up to 30 TB in size. This preview provides production-level support for managed virtual machines.
-
-The backups for your virtual machines with each disk size up to 30 TB and a maximum of 256 TB combined for all disks in a VM should work seamlessly without impacting your existing backups. There is no user action required to get the backups running for the large sized disks, if the virtual machine is already configured with Azure Backup.
-
-All Azure Virtual Machines with large disks having backup configured should be successfully backed up.
-
 ## Next steps
 
 Now, [prepare for Azure VM backup](backup-azure-arm-vms-prepare.md).
diff --git a/articles/backup/backup-instant-restore-capability.md b/articles/backup/backup-instant-restore-capability.md
@@ -16,7 +16,7 @@ The new model for Instant Restore provides the following feature enhancements:
 
 * Ability to use snapshots taken as part of a backup job that is available for recovery without waiting for data transfer to the vault to finish. It reduces the wait time for snapshots to copy to the vault before triggering restore.
 * Reduces backup and restore times by retaining snapshots locally, for two days by default. This default snapshot retention value is configurable to any value between 1 to 5 days.
-* Supports disk sizes up to 4 TB. Resizing of disks is not recommended by Azure Backup. To sign up for a limited public preview of Azure Backup large disk support for disks greater than 4 TB and up to 30 TB in size, see [Backup of VM with disk sizes up to 30 TB](backup-azure-vms-introduction.md#limited-public-preview-backup-of-vm-with-disk-sizes-up-to-30tb).
+* Supports disk sizes up to 32 TB. Resizing of disks is not recommended by Azure Backup.
 * Supports Standard SSD disks along with Standard HDD disks and Premium SSD disks.
 * Ability to use an unmanaged VMs original storage accounts (per disk), when restoring. This ability exists even when the VM has disks that are distributed across storage accounts. It speeds up restore operations for a wide variety of VM configurations.
 * For backup of VMs that are using premium storage, with Instant Restore, we recommend allocating *50%* free space of the total allocated storage space, which is required **only** for the first backup. The 50% free space is not a requirement for backups after the first backup is complete.
diff --git a/includes/azure-backup-limits.md b/includes/azure-backup-limits.md
@@ -2,11 +2,11 @@
 title: "include file"
 description: "include file"
 services: backup
-author: rayne-wiselman
+author: dcurwin
 ms.service: backup
 ms.topic: "include"
 ms.date: 12/07/2018
-ms.author: raynew
+ms.author: dacurwin
 ms.custom: "include file"
 ---
 
@@ -20,4 +20,4 @@ The following limits apply to Azure Backup.
 | Backup vaults in an Azure subscription. |500 vaults per region. |
 | Schedule daily backups. |Windows Server/Client: Three a day.<br/> System Center DPM: Two a day. <br/> IaaS VMs: Once a day.  |
 | Data disks attached to an Azure VM for backup. | 16 |
-| Individual data disk attached to Azure VM for backup.| 4,095 GB|
+| Individual data disk attached to Azure VM for backup.| 32 TB|
diff --git a/includes/virtual-machines-managed-disks-overview.md b/includes/virtual-machines-managed-disks-overview.md
@@ -32,7 +32,7 @@ Managed disks support [Availability Zones](../articles/availability-zones/az-ove
 
 ### Azure Backup support
 
-To protect against regional disasters, [Azure Backup](../articles/backup/backup-overview.md) can be used to create a backup job with time-based backups and backup retention policies. This allows you to perform easy VM restorations at will. Currently Azure Backup supports disk sizes up to four tebibyte (TiB) disks.  Azure Backup supports backup and restore of managed disks. [Learn more](../articles/backup/backup-support-matrix-iaas.md) about Azure VM backup support.
+To protect against regional disasters, [Azure Backup](../articles/backup/backup-overview.md) can be used to create a backup job with time-based backups and backup retention policies. This allows you to perform easy VM restorations at will. Azure Backup supports backup and restore of managed disks. [Learn more](../articles/backup/backup-support-matrix-iaas.md) about Azure VM backup support.
 
 ### Granular access control
 
