From 1737a4879af330667667a906e6dc58475240aa0f Mon Sep 17 00:00:00 2001 From: James Munson Date: Tue, 21 Nov 2023 13:05:14 -0700 Subject: [PATCH] Remove mentions of Azure and CIFS backupstore targets in v1.4.x docs. Signed-off-by: James Munson --- content/docs/1.4.0/best-practices.md | 2 +- content/docs/1.4.1/best-practices.md | 2 +- content/docs/1.4.2/best-practices.md | 2 +- content/docs/1.4.3/best-practices.md | 2 +- content/docs/1.4.4/best-practices.md | 2 +- content/docs/1.4.5/best-practices.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/docs/1.4.0/best-practices.md b/content/docs/1.4.0/best-practices.md index fa910754a..5de89dea1 100644 --- a/content/docs/1.4.0/best-practices.md +++ b/content/docs/1.4.0/best-practices.md @@ -94,7 +94,7 @@ If you're using `ext4` as the filesystem of the volume, we recommend adding a li ## Volume Maintenance -Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store (such as S3 and Azure), an NFS server, or an SMB or CIFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. +Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store such as S3, or an NFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. For each volume, schedule at least one recurring backup. If you must run Longhorn in production without a backupstore, then schedule at least one recurring snapshot for each volume. diff --git a/content/docs/1.4.1/best-practices.md b/content/docs/1.4.1/best-practices.md index fa910754a..5de89dea1 100644 --- a/content/docs/1.4.1/best-practices.md +++ b/content/docs/1.4.1/best-practices.md @@ -94,7 +94,7 @@ If you're using `ext4` as the filesystem of the volume, we recommend adding a li ## Volume Maintenance -Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store (such as S3 and Azure), an NFS server, or an SMB or CIFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. +Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store such as S3, or an NFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. For each volume, schedule at least one recurring backup. If you must run Longhorn in production without a backupstore, then schedule at least one recurring snapshot for each volume. diff --git a/content/docs/1.4.2/best-practices.md b/content/docs/1.4.2/best-practices.md index fa910754a..5de89dea1 100644 --- a/content/docs/1.4.2/best-practices.md +++ b/content/docs/1.4.2/best-practices.md @@ -94,7 +94,7 @@ If you're using `ext4` as the filesystem of the volume, we recommend adding a li ## Volume Maintenance -Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store (such as S3 and Azure), an NFS server, or an SMB or CIFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. +Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store such as S3, or an NFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. For each volume, schedule at least one recurring backup. If you must run Longhorn in production without a backupstore, then schedule at least one recurring snapshot for each volume. diff --git a/content/docs/1.4.3/best-practices.md b/content/docs/1.4.3/best-practices.md index f15124480..3570f1720 100644 --- a/content/docs/1.4.3/best-practices.md +++ b/content/docs/1.4.3/best-practices.md @@ -94,7 +94,7 @@ If you're using `ext4` as the filesystem of the volume, we recommend adding a li ## Volume Maintenance -Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store (such as S3 and Azure), an NFS server, or an SMB or CIFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. +Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store such as S3, or an NFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. For each volume, schedule at least one recurring backup. If you must run Longhorn in production without a backupstore, then schedule at least one recurring snapshot for each volume. diff --git a/content/docs/1.4.4/best-practices.md b/content/docs/1.4.4/best-practices.md index f15124480..3570f1720 100644 --- a/content/docs/1.4.4/best-practices.md +++ b/content/docs/1.4.4/best-practices.md @@ -94,7 +94,7 @@ If you're using `ext4` as the filesystem of the volume, we recommend adding a li ## Volume Maintenance -Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store (such as S3 and Azure), an NFS server, or an SMB or CIFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. +Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store such as S3, or an NFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. For each volume, schedule at least one recurring backup. If you must run Longhorn in production without a backupstore, then schedule at least one recurring snapshot for each volume. diff --git a/content/docs/1.4.5/best-practices.md b/content/docs/1.4.5/best-practices.md index f15124480..3570f1720 100644 --- a/content/docs/1.4.5/best-practices.md +++ b/content/docs/1.4.5/best-practices.md @@ -94,7 +94,7 @@ If you're using `ext4` as the filesystem of the volume, we recommend adding a li ## Volume Maintenance -Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store (such as S3 and Azure), an NFS server, or an SMB or CIFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. +Using Longhorn's built-in backup feature is highly recommended. You can save backups to an object store such as S3, or an NFS server. Saving to an object store is preferable, if possible, because it generally has better performance and reliability. There is also the advantage of not having to mount and unmount the target, which can complicate failover and upgrades. For each volume, schedule at least one recurring backup. If you must run Longhorn in production without a backupstore, then schedule at least one recurring snapshot for each volume.