issue 6734: spread backup pod evenly

Signed-off-by: Lyndon-Li <lyonghui@vmware.com>

site/content/docs/main/csi-snapshot-data-movement.md

@@ -326,7 +326,7 @@ Velero backs up resources for CSI snapshot data movement backup in the same way
 - CSI plugin checks if a data movement is required, if so it creates a `DataUpload` CR and then returns to Velero backup.  
 - Velero now is able to back up other resources, including other PVC objects.  
 - Velero backup controller periodically queries the data movement status from CSI plugin, the period is configurable through the Velero server parameter `--item-operation-sync-frequency`, by default it is 10s. On the call, CSI plugin turns to check the phase of the `DataUpload` CRs.  
-- When all the `DataUpload` CRs come to a terminal state (i.e., `Completed`, `Failed` or `Cancelled`), Velero backup perists all the necessary information and finish the backup.  
+- When all the `DataUpload` CRs come to a terminal state (i.e., `Completed`, `Failed` or `Cancelled`), Velero backup persists all the necessary information and finish the backup.  
 
 - CSI plugin expects a data mover to handle the `DataUpload` CR. If no data mover is configured for the backup, Velero built-in data mover will handle it.  
 - If the `DataUpload` CR does not reach to the terminal state with in the given time, the `DataUpload` CR will be cancelled. You can set the timeout value per backup through the `--item-operation-timeout` parameter, the default value is `4 hours`.  

site/content/docs/v0.5.0/faq.md

@@ -6,7 +6,7 @@ layout: docs
 ## When is it appropriate to use Ark instead of etcd's built in backup/restore?
 
 Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For
-example, it is a good idea to take a backup of etcd prior to upgrading etcd istelf. For more
+example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more
 sophisticated management of your Kubernetes cluster backups and restores, we feel that Ark is
 generally a better approach. It gives you the ability to throw away an unstable cluster and restore
 your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up

site/content/docs/v0.6.0/faq.md

@@ -6,7 +6,7 @@ layout: docs
 ## When is it appropriate to use Ark instead of etcd's built in backup/restore?
 
 Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For
-example, it is a good idea to take a backup of etcd prior to upgrading etcd istelf. For more
+example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more
 sophisticated management of your Kubernetes cluster backups and restores, we feel that Ark is
 generally a better approach. It gives you the ability to throw away an unstable cluster and restore
 your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up

site/content/docs/v0.7.0/faq.md

@@ -6,7 +6,7 @@ layout: docs
 ## When is it appropriate to use Ark instead of etcd's built in backup/restore?
 
 Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For
-example, it is a good idea to take a backup of etcd prior to upgrading etcd istelf. For more
+example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more
 sophisticated management of your Kubernetes cluster backups and restores, we feel that Ark is
 generally a better approach. It gives you the ability to throw away an unstable cluster and restore
 your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up

site/content/docs/v0.7.1/faq.md

@@ -6,7 +6,7 @@ layout: docs
 ## When is it appropriate to use Ark instead of etcd's built in backup/restore?
 
 Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For
-example, it is a good idea to take a backup of etcd prior to upgrading etcd istelf. For more
+example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more
 sophisticated management of your Kubernetes cluster backups and restores, we feel that Ark is
 generally a better approach. It gives you the ability to throw away an unstable cluster and restore
 your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up

site/content/docs/v0.8.0/faq.md

@@ -6,7 +6,7 @@ layout: docs
 ## When is it appropriate to use Ark instead of etcd's built in backup/restore?
 
 Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For
-example, it is a good idea to take a backup of etcd prior to upgrading etcd istelf. For more
+example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more
 sophisticated management of your Kubernetes cluster backups and restores, we feel that Ark is
 generally a better approach. It gives you the ability to throw away an unstable cluster and restore
 your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up

site/content/docs/v0.8.1/faq.md

@@ -6,7 +6,7 @@ layout: docs
 ## When is it appropriate to use Ark instead of etcd's built in backup/restore?
 
 Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For
-example, it is a good idea to take a backup of etcd prior to upgrading etcd istelf. For more
+example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more
 sophisticated management of your Kubernetes cluster backups and restores, we feel that Ark is
 generally a better approach. It gives you the ability to throw away an unstable cluster and restore
 your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up

site/content/docs/v1.12/csi-snapshot-data-movement.md

@@ -339,7 +339,7 @@ Velero backs up resources for CSI snapshot data movement backup in the same way
 - CSI plugin checks if a data movement is required, if so it creates a `DataUpload` CR and then returns to Velero backup.  
 - Velero now is able to back up other resources, including other PVC objects.  
 - Velero backup controller periodically queries the data movement status from CSI plugin, the period is configurable through the Velero server parameter `--item-operation-sync-frequency`, by default it is 10s. On the call, CSI plugin turns to check the phase of the `DataUpload` CRs.  
-- When all the `DataUpload` CRs come to a terminal state (i.e., `Completed`, `Failed` or `Cancelled`), Velero backup perists all the necessary information and finish the backup.  
+- When all the `DataUpload` CRs come to a terminal state (i.e., `Completed`, `Failed` or `Cancelled`), Velero backup persists all the necessary information and finish the backup.  
 
 - CSI plugin expects a data mover to handle the `DataUpload` CR. If no data mover is configured for the backup, Velero built-in data mover will handle it.  
 - If the `DataUpload` CR does not reach to the terminal state with in the given time, the `DataUpload` CR will be cancelled. You can set the timeout value per backup through the `--item-operation-timeout` parameter, the default value is `4 hours`.  

site/content/docs/v1.5/restic.md

@@ -10,7 +10,7 @@ the supported cloud providers’ block storage offerings (Amazon EBS Volumes, Az
 It also provides a plugin model that enables anyone to implement additional object and block storage backends, outside the
 main Velero repository.
 
-The restic intergation was added to give you an out-of-the-box solution for backing up and restoring almost any type of Kubernetes volume. This integration is an addition to Velero's capabilities, not a replacement for existing functionality. If you're running on AWS, and taking EBS snapshots as part of your regular Velero backups, there's no need to switch to using restic. However, if you need a volume snapshot plugin for your storage platform, or if you're using EFS, AzureFile, NFS, emptyDir,
+The restic integration was added to give you an out-of-the-box solution for backing up and restoring almost any type of Kubernetes volume. This integration is an addition to Velero's capabilities, not a replacement for existing functionality. If you're running on AWS, and taking EBS snapshots as part of your regular Velero backups, there's no need to switch to using restic. However, if you need a volume snapshot plugin for your storage platform, or if you're using EFS, AzureFile, NFS, emptyDir,
 local, or any other volume type that doesn't have a native snapshot concept, restic might be for you.
 
 Restic is not tied to a specific storage platform, which means that this integration also paves the way for future work to enable