Merge pull request MicrosoftDocs#21057 from dcbrown16/patch-18

TrishaMc · web-flow · commit f6336dcc450c · 2018-12-20T08:17:51.000-08:00
Update backup-azure-vms-introduction.md
diff --git a/articles/backup/backup-azure-vms-introduction.md b/articles/backup/backup-azure-vms-introduction.md
@@ -39,7 +39,7 @@ Azure Backup doesn't encrypt data as a part of the backup process. Azure Backup
 - The BEK(secrets) and KEK(keys) backed up are encrypted so they can be read and used only when restored back to key vault by the authorized users.
 - Since the BEK is also backed up, in scenarios where BEK is lost, authorized users can restore the BEK to the KeyVault and recover the encrypted VM. Keys and secrets of encrypted VMs are backed up in encrypted form, so neither unauthorized users nor Azure can read or use backed up keys and secrets. Only users with the right level of permissions can backup and restore encrypted VMs, as well as keys and secrets.
 
-## Snapshot consistentcy
+## Snapshot consistency
 
 To take snapshots while apps are running, Azure Backup takes app-consistent snapshots.
 - **Windows VMs**: For Windows VMs, the Backup service coordinates with the Volume Shadow Copy Service (VSS) to get a consistent snapshot of the VM disks. 
@@ -61,8 +61,8 @@ The following table explains different types of consistency.
 
 **Snapshot** | **VSS-based** | **Details** | **Recovery**
 --- | --- | --- | ---
-**Application-consistent** | Yes (Windows only) | App-consistent backups capture memory content and pending I/O operations. App-consistent snapshots use VSS writer (or pre/post script for Linux) to that ensure the consistency of app data before a backup occurs. | When recovering with an app-consistent snapshot, the VM boots up. There's no data corruption or loss. The apps start in a consistent state.
-**File system consistent** | Yes (Windows only) |  File consistent backups provide consistent backups of disk files by taking a snapshot of all files at the same time.<br/><br/> Azure Backup recovery points are file consistent for:<br/><br/> -Linux VMs backups that don't have pre/post scripts, or that have script that failed.<br/><br/> - Windows VM backups where VSS failed. | When recovering with a file-consistent snapshot, the VM boots up. There's no data corruption or loss. Apps needs to implement their own "fix-up" mechanism to make sure that restored data is consistent.
+**Application-consistent** | Yes (Windows only) | App-consistent backups capture memory content and pending I/O operations. App-consistent snapshots use VSS writer (or pre/post script for Linux) to ensure that the consistency of app data before a backup occurs. | When recovering with an app-consistent snapshot, the VM boots up. There's no data corruption or loss. The apps start in a consistent state.
+**File system consistent** | Yes (Windows only) |  File consistent backups provide consistent backups of disk files by taking a snapshot of all files at the same time.<br/><br/> Azure Backup recovery points are file consistent for:<br/><br/> -Linux VMs backups that don't have pre/post scripts, or that have script that failed.<br/><br/> - Windows VM backups where VSS failed. | When recovering with a file-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.
 **Crash-consistent** | No | Crash consistency often happens when 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. | There are no guaranteese, but usually the VM boots, and follows with a disk check to fix corruption errors. Any in-memory data or write that weren't transferred to disk are lost. Apps implement their own data verification. For example, for a database app, if a transaction log has entries that aren't in the database, the database software rolls until data is consistent.
 
 
@@ -95,7 +95,7 @@ Backup tries to complete as quickly as possible, consuming as many resources as
 ### Scheduling considerations
 
 Backup scheduling impacts performance.
-- If you configure policies so all VMs are backed up at the same time, you have scheduled a traffic jam, as the the backup process attempts to back up all disks in parallel.
+- If you configure policies so all VMs are backed up at the same time, you have scheduled a traffic jam, as the backup process attempts to back up all disks in parallel.
 - To reduce the backup traffic, back up different VMs at different time of the day, with no overlap.
 
 
@@ -106,7 +106,7 @@ While most backup time is spent reading and copying data, other operations add t
 - **Install backup extension**: Time needed to install or update the backup extension.
 - **Trigger snapshot**: Time taken to trigger a snapshot. Snapshots are triggered close to the scheduled backup time.
 - **Queue wait time**: Since the Backup service processes jobs from multiple customers at the same time, snapshot data may not immediately be copied to the Recovery Services vault. At peak load times, it can take up to eight hours before the backups are processed. However, the total VM backup time is less than 24 hours for daily backup policies.
-- **Initial backup**: Although the total backup time of less than 24 hours is valid for incremental backups, it might not be for the the first backup. Time needed will depend on size of the data and when the backup is taken.
+- **Initial backup**: Although the total backup time of less than 24 hours is valid for incremental backups, it might not be for the first backup. Time needed will depend on size of the data and when the backup is taken.
 - **Data transfer time**: Time needed for backup service to compute the incremental changes from previous backup and transfer those changes to vault storage.
 
 ### Factors affecting backup time
@@ -143,7 +143,7 @@ A restore operation consists of two main tasks: copying data back from the vault
 
 We suggest following these practices while configuring VM backups:
 
-- Don't schedule backups for more than 100 VMs from one vault, at the same time.
+- Don't schedule backups for more than 100 VMs from one vault at the same time.
 - Schedule VM backups during non-peak hours. This way the Backup service uses IOPS for transferring data from the customer storage account to the vault.
 - If you're backing up managed disks, the Azure Backup service handles storage management. If you're backing up unmanaged disks:
     - Make sure to apply a backup policy to VMs spread across multiple storage accounts.
