From ff83d5e0c99bb299e718655aa87f50b2cde1bbca Mon Sep 17 00:00:00 2001 From: Tiger Kaovilai Date: Wed, 5 Jul 2023 12:36:07 -0400 Subject: [PATCH] typo: s/inokes/invokes Signed-off-by: Tiger Kaovilai --- site/content/docs/main/file-system-backup.md | 4 ++-- site/content/docs/v1.10/file-system-backup.md | 4 ++-- site/content/docs/v1.11/file-system-backup.md | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/site/content/docs/main/file-system-backup.md b/site/content/docs/main/file-system-backup.md index 89c43ce7b7..be32119a46 100644 --- a/site/content/docs/main/file-system-backup.md +++ b/site/content/docs/main/file-system-backup.md @@ -539,7 +539,7 @@ that it's backing up for the volumes to be backed up using FSB. 5. Meanwhile, each `PodVolumeBackup` is handled by the controller on the appropriate node, which: - has a hostPath volume mount of `/var/lib/kubelet/pods` to access the pod volume data - finds the pod volume's subdirectory within the above volume - - based on the path selection, Velero inokes restic or kopia for backup + - based on the path selection, Velero invokes restic or kopia for backup - updates the status of the custom resource to `Completed` or `Failed` 6. As each `PodVolumeBackup` finishes, the main Velero process adds it to the Velero backup in a file named `-podvolumebackups.json.gz`. This file gets uploaded to object storage alongside the backup tarball. @@ -564,7 +564,7 @@ some reason (i.e. lack of cluster resources), the FSB restore will not be done. - has a hostPath volume mount of `/var/lib/kubelet/pods` to access the pod volume data - waits for the pod to be running the init container - finds the pod volume's subdirectory within the above volume - - based on the path selection, Velero inokes restic or kopia for restore + - based on the path selection, Velero invokes restic or kopia for restore - on success, writes a file into the pod volume, in a `.velero` subdirectory, whose name is the UID of the Velero restore that this pod volume restore is for - updates the status of the custom resource to `Completed` or `Failed` diff --git a/site/content/docs/v1.10/file-system-backup.md b/site/content/docs/v1.10/file-system-backup.md index 6fcd1a33b2..96e861cf3c 100644 --- a/site/content/docs/v1.10/file-system-backup.md +++ b/site/content/docs/v1.10/file-system-backup.md @@ -539,7 +539,7 @@ that it's backing up for the volumes to be backed up using FSB. 5. Meanwhile, each `PodVolumeBackup` is handled by the controller on the appropriate node, which: - has a hostPath volume mount of `/var/lib/kubelet/pods` to access the pod volume data - finds the pod volume's subdirectory within the above volume - - based on the path selection, Velero inokes restic or kopia for backup + - based on the path selection, Velero invokes restic or kopia for backup - updates the status of the custom resource to `Completed` or `Failed` 6. As each `PodVolumeBackup` finishes, the main Velero process adds it to the Velero backup in a file named `-podvolumebackups.json.gz`. This file gets uploaded to object storage alongside the backup tarball. @@ -564,7 +564,7 @@ some reason (i.e. lack of cluster resources), the FSB restore will not be done. - has a hostPath volume mount of `/var/lib/kubelet/pods` to access the pod volume data - waits for the pod to be running the init container - finds the pod volume's subdirectory within the above volume - - based on the path selection, Velero inokes restic or kopia for restore + - based on the path selection, Velero invokes restic or kopia for restore - on success, writes a file into the pod volume, in a `.velero` subdirectory, whose name is the UID of the Velero restore that this pod volume restore is for - updates the status of the custom resource to `Completed` or `Failed` diff --git a/site/content/docs/v1.11/file-system-backup.md b/site/content/docs/v1.11/file-system-backup.md index 881747895c..5022adbcdf 100644 --- a/site/content/docs/v1.11/file-system-backup.md +++ b/site/content/docs/v1.11/file-system-backup.md @@ -539,7 +539,7 @@ that it's backing up for the volumes to be backed up using FSB. 5. Meanwhile, each `PodVolumeBackup` is handled by the controller on the appropriate node, which: - has a hostPath volume mount of `/var/lib/kubelet/pods` to access the pod volume data - finds the pod volume's subdirectory within the above volume - - based on the path selection, Velero inokes restic or kopia for backup + - based on the path selection, Velero invokes restic or kopia for backup - updates the status of the custom resource to `Completed` or `Failed` 6. As each `PodVolumeBackup` finishes, the main Velero process adds it to the Velero backup in a file named `-podvolumebackups.json.gz`. This file gets uploaded to object storage alongside the backup tarball. @@ -564,7 +564,7 @@ some reason (i.e. lack of cluster resources), the FSB restore will not be done. - has a hostPath volume mount of `/var/lib/kubelet/pods` to access the pod volume data - waits for the pod to be running the init container - finds the pod volume's subdirectory within the above volume - - based on the path selection, Velero inokes restic or kopia for restore + - based on the path selection, Velero invokes restic or kopia for restore - on success, writes a file into the pod volume, in a `.velero` subdirectory, whose name is the UID of the Velero restore that this pod volume restore is for - updates the status of the custom resource to `Completed` or `Failed`