Merge pull request #145 from jhkrug/1.7.0

1.7.0

Author: jhkrug

modules/en/pages/snapshots-backups/system-backups/create-system-backup.adoc

@@ -37,7 +37,7 @@ You can create a Longhorn system backup using the Longhorn UI. Or with the `kube
 
 === Prerequisite
 
-* xref:snapshots-and-backups/backup-and-restore/set-backup-target.adoc[Set the backup target]. Longhorn saves the system backups to the remote backup store. You will see an error during creation when the backup target is unset.
+* xref:snapshots-backups/volume-snapshots-backups/configure-backup-target.adoc[]. Longhorn saves the system backups to the remote backup store. You will see an error during creation when the backup target is unset.
 +
 NOTE: Unsetting the backup target clears the existing `SystemBackup` custom resource. Longhorn syncs to the remote backup store after setting the backup target. Another cluster can also sync to the same list of system backups when the backup target is the same.
 

modules/en/pages/snapshots-backups/system-backups/restore-system.adoc

@@ -3,7 +3,7 @@
 
 == Longhorn System Restore Rollouts
 
-* Longhorn restores the resource from the xref:advanced-resources/system-backup-restore/backup-longhorn-system.adoc#_longhorn_system_backup_bundle[Longhorn System Backup Bundle].
+* Longhorn restores the resource from the xref:snapshots-backups/system-backups/create-system-backup.adoc#_longhorn_system_backup_bundle[Longhorn System Backup Bundle].
 * Longhorn does not restore existing `Volumes` and their associated `PersistentVolume` and `PersistentVolumeClaim`.
 * Longhorn automatically restores a `Volume` from its latest backup.
 * To prevent overwriting eligible settings, Longhorn does not restore the `ConfigMap/longhorn-default-setting`.
@@ -25,7 +25,7 @@ You can restore the Longhorn system using Longhorn UI. Or with the `kubectl` com
 * Set up the `Nodes` and disk tags for `StorageClass`.
 * Have a Longhorn system backup.
 +
-See xref:advanced-resources/system-backup-restore/backup-longhorn-system.adoc#_create_longhorn_system_backup[Backup Longhorn System - Create Longhorn System Backup] for instructions.
+See xref:snapshots-backups/system-backups/create-system-backup.adoc#_create_longhorn_system_backup[Backup Longhorn System - Create Longhorn System Backup] for instructions.
 
 * All existing `Volumes` are detached.
 

modules/en/pages/snapshots-backups/system-backups/restore-to-cluster-using-rancher-snapshot.adoc

@@ -27,7 +27,7 @@ This doc describes what users need to do after restoring the cluster with a Ranc
 * If the following happens after the snapshot and before the cluster restore:
  ** A volume is unchanged: Users don't need to do anything.
  ** The data is updated: Users don't need to do anything typically. Longhorn will automatically fail the replicas that don't contain the latest data.
- ** A new volume is created: This volume will disappear after the restore. Users need to recreate a new volume, launch xref:advanced-resources/data-recovery/export-from-replica.adoc[a single replica volume] based on the replica of the disappeared volume, then transfer the data to the new volume.
+ ** A new volume is created: This volume will disappear after the restore. Users need to recreate a new volume, launch xref:data-integrity-recovery/data-recovery/retrieve-volume-data-from-replica.adoc[a single replica volume] based on the replica of the disappeared volume, then transfer the data to the new volume.
  ** A volume is deleted: Since the data is cleaned up when the volume is removed, the restored volume contains no data. Users may need to re-delete it.
  ** For DR volumes: Users don't need to do anything. Longhorn will redo a full restore.
  ** Some operations are applied for a volume:
@@ -36,7 +36,7 @@ This doc describes what users need to do after restoring the cluster with a Ranc
   *** Replica rebuilding & replica removal:
    **** If there are new replicas rebuilt, those replicas will disappear from the Longhorn system after the restoring. Users need to clean up the replica data manually, or use the data directories of these replicas to export a single replica volume then do data recovery if necessary.
    **** If there are some failed/removed replicas and there is at least one replica keeping healthy, those failed/removed replicas will be back after the restoration. Then Longhorn can detect these restored replicas do not contain any data, and copy the latest data from the healthy replica to these replicas.
-   **** If all replicas are replaced by new replicas after the snapshot, the volume will contain invalid replicas only after the restore. Then users need to export xref:advanced-resources/data-recovery/export-from-replica.adoc[a single replica volume] for the data recovery.
+   **** If all replicas are replaced by new replicas after the snapshot, the volume will contain invalid replicas only after the restore. Then users need to export xref:data-integrity-recovery/data-recovery/retrieve-volume-data-from-replica.adoc[a single replica volume] for the data recovery.
   *** Engine image upgrade: Users need to redo the upgrade.
   *** Expansion: The spec size of the volume will be smaller than the current size. This is like someone requesting volume shrinking but actually Longhorn will refuse to handle it internally. To recover the volume, users need to scale down the workloads and re-do the expansion.
  ** *Notice*: If users don't know how to recover a problematic volume, the simplest way is always restoring a new volume from backup.

modules/en/pages/snapshots-backups/volume-snapshots-backups/create-recurring-backup-snapshot-job.adoc

@@ -14,7 +14,7 @@ You can configure,
 * The number of jobs to run concurrently
 * Any labels that should be applied to the backup or snapshot
 * Parameters that should be applied to the backup
- ** `full-backup-interval`: Number of incremental backups that must be completed before Longhorn performs a full backup. This integer parameter is applied only to the backup. Notice that if the value is 0, Longhorn performs a incremental backup every time. For more information, see <<_periodic_full_backup,Periodic Full Backup>> and xref:snapshots-and-backups/backup-and-restore/create-a-backup.adoc[Create a Backup].
+ ** `full-backup-interval`: Number of incremental backups that must be completed before Longhorn performs a full backup. This integer parameter is applied only to the backup. Notice that if the value is 0, Longhorn performs a incremental backup every time. For more information, see <<_periodic_full_backup,Periodic Full Backup>> and xref:snapshots-backups/volume-snapshots-backups/create-backup.adoc[Create a Backup].
 
 Recurring jobs can be set up using the Longhorn UI, `kubectl`, or by using a Longhorn `RecurringJob`.
 

modules/en/pages/snapshots-backups/volume-snapshots-backups/sync-backup-volumes-manually.adoc

@@ -5,7 +5,7 @@ After creating a backup, Longhorn creates a backup volume that corresponds to th
 
 Earlier Longhorn versions poll and update all backup volumes at a xref:longhorn-system/settings.adoc#_backupstore_poll_interval[fixed interval]. Longhorn v1.6.2 provides a way for you to manually synchronize backup volumes with the backup target.
 
-IMPORTANT: You must set up a xref:snapshots-and-backups/backup-and-restore/set-backup-target.adoc[backup target] and verify that a backup volume was created before attempting to synchronize. Longhorn returns an error when no backup target and backup volume exist.
+IMPORTANT: You must set up a xref:snapshots-backups/volume-snapshots-backups/configure-backup-target.adoc[backup target] and verify that a backup volume was created before attempting to synchronize. Longhorn returns an error when no backup target and backup volume exist.
 
 * Synchronize all backup volumes:
  .. On the Longhorn UI, go to *Backup*.

modules/en/pages/snapshots-backups/volume-snapshots-backups/volume-snapshots-backups.adoc

@@ -13,7 +13,7 @@ Since v1.2.0, Longhorn started using an asynchronous backup operations to resolv
 
 This enhancement is scalable for the backup query to assist with resolving the costly resources caused by the blocking way. This was because all backups are saved as custom resources instead of querying from the remote target directly.
 
-NOTE: After the Longhorn upgrade, if a volume has not been upgraded to the latest Longhorn engine (≥v1.2.0). When creating a backup, it will have the intermediate transition state of the name of the created backup (due to the different backup name handling in the latest longhorn version ≥ v1.2.0). Longhorn will then ensure the backup is synced with the remote backup target and the backup will be updated to the final correct state with the remote backup target is the single source of truth. To upgrade the Longhorn engine, refer to xref:snapshots-and-backups/deploy/upgrade/upgrade-engine.adoc[Manually Upgrade Longhorn Engine] or xref:upgrades/longhorn-components/auto-upgrade-engine.adoc[Automatically Upgrade Longhorn Engine].
+NOTE: After the Longhorn upgrade, if a volume has not been upgraded to the latest Longhorn engine (≥v1.2.0). When creating a backup, it will have the intermediate transition state of the name of the created backup (due to the different backup name handling in the latest longhorn version ≥ v1.2.0). Longhorn will then ensure the backup is synced with the remote backup target and the backup will be updated to the final correct state with the remote backup target is the single source of truth. To upgrade the Longhorn engine, refer to xref:upgrades/longhorn-components/manually-upgrade-engine.adoc[] or xref:upgrades/longhorn-components/auto-upgrade-engine.adoc[].
 ____
 
 * link:./set-backup-target[Setting a Backup Target]

modules/en/pages/upgrades/kubernetes/upgrade-k8s-on-eks.adoc

@@ -5,4 +5,4 @@ In Longhorn, set `replica-replenishment-wait-interval` to `0`.
 
 See https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html[Updating a cluster] for instructions.
 
-NOTE: If you have created xref:advanced-resources/support-managed-k8s-service/manage-node-group-on-eks.adoc#_create_additional_volume[addition disks] for Longhorn, you will need to manually add the path of the mounted disk into the disk list of the upgraded nodes.
+NOTE: If you have created xref:nodes/managed-kubernetes/eks-managed-node-pools.adoc#_create_additional_volume[addition disks] for Longhorn, you will need to manually add the path of the mounted disk into the disk list of the upgraded nodes.

modules/en/pages/upgrades/longhorn-components/auto-upgrade-engine.adoc

@@ -29,7 +29,7 @@ Longhorn automatically does an offline upgrade for detached volume.
 
 . Disaster Recovery Volumes
 +
-Longhorn doesn't automatically upgrade xref:snapshots-and-backups/setup-disaster-recovery-volumes.adoc[disaster recovery volumes] to the new default engine image because it would trigger a full restoration for the disaster recovery volumes.
+Longhorn doesn't automatically upgrade xref:data-integrity-recovery/disaster-recovery-volumes.adoc[disaster recovery volumes] to the new default engine image because it would trigger a full restoration for the disaster recovery volumes.
 The full restoration might affect the performance of other running Longhorn volumes in the system.
 So, Longhorn leaves it to you to decide when it is the good time to manually upgrade the engine for disaster recovery volumes (e.g., when the system is idle or during the maintenance time).
 +

modules/en/pages/upgrades/longhorn-components/manually-upgrade-engine.adoc

@@ -13,7 +13,7 @@ Upgrade the Longhorn manager before upgrading the Longhorn engine.
 
 Follow these steps if the live upgrade is not available, or if the volume is stuck in degraded state:
 
-. Follow xref:nodes-and-volumes/volumes/detaching-volumes.adoc[the detach procedure for relevant workloads].
+. Follow xref:data-integrity-recovery/disaster-recovery-volumes.adoc[the detach procedure for relevant workloads].
 . Select all the volumes using batch selection. Click the batch operation button *Upgrade Engine*, and choose the engine image available in the list. It's the default engine shipped with the manager for this release.
 . Resume all workloads. Any volume not part of a Kubernetes workload must be attached from the Longhorn UI.
 

modules/en/pages/upgrades/longhorn-components/upgrade-longhorn-manager.adoc

@@ -9,7 +9,7 @@ Engine live upgrade is supported from v1.6.x to v{current-version}.
 
 For airgap upgrades when Longhorn is installed as a Rancher app, you will need to modify the image names and remove the registry URL part.
 
-For example, the image `registry.example.com/longhorn/longhorn-manager:v{current-version}` is changed to `longhorn/longhorn-manager:v{current-version}` in Longhorn images section. For more information, see the air gap installation steps xref:deploy/install/airgap.adoc#_using_a_rancher_app[here.]
+For example, the image `registry.example.com/longhorn/longhorn-manager:v{current-version}` is changed to `longhorn/longhorn-manager:v{current-version}` in Longhorn images section. For more information, see the air gap installation steps xref:installation-setup/installation/airgapped-environment.adoc#_using_a_rancher_app[here.]
 
 === Preparing for the Upgrade
 
@@ -127,7 +127,7 @@ Then wait for all the pods to become running and Longhorn UI working. e.g.:
  csi-provisioner-869bdc4b79-sn6zr                      1/1     Running   1 (30s ago)   43s
  longhorn-csi-plugin-b2zzj                             2/2     Running   0             24s
 
-Next, xref:deploy/upgrade/upgrade-engine.adoc[upgrade Longhorn engine.]
+Next, xref:upgrades/longhorn-components/manually-upgrade-engine.adoc[upgrade Longhorn engine.]
 
 == Upgrading from Unsupported Versions
 

modules/en/pages/volumes/backing-images/backing-images.adoc

@@ -17,7 +17,7 @@ You can prepare a backing image using four different kinds of data sources.
 . Download a backing image file (using a URL).
 . Upload a file from your local machine. This option is available to Longhorn UI users.
 . Export an existing in-cluster volume as a backing image.
-. Restore a backing image from the backupstore, For more information, see xref:snapshot-backups/backing-image-backups.adoc[Backing Image Backup].
+. Restore a backing image from the backupstore, For more information, see xref:snapshots-backups/backing-image-backups.adoc[Backing Image Backup].
 . Clone a backing image.
 
 ==== The checksum of a backing image