diff --git a/src/current/_includes/common/sql/incremental-location-warning.md b/src/current/_includes/common/sql/incremental-location-warning.md
new file mode 100644
index 00000000000..9c685ed5178
--- /dev/null
+++ b/src/current/_includes/common/sql/incremental-location-warning.md
@@ -0,0 +1,3 @@
+{{site.data.alerts.callout_danger}}
+The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
+{{site.data.alerts.end}}
diff --git a/src/current/_includes/v23.1/backups/backup-options-for-schedules.md b/src/current/_includes/v23.1/backups/backup-options-for-schedules.md
index e69925fe403..dba29de09c9 100644
--- a/src/current/_includes/v23.1/backups/backup-options-for-schedules.md
+++ b/src/current/_includes/v23.1/backups/backup-options-for-schedules.md
@@ -5,4 +5,4 @@
`detached` | [`BOOL`]({% link {{ page.version.version }}/bool.md %}) / None | **Note:** Backups running on a schedule have the `detached` option applied implicitly. Therefore, you cannot modify this option for scheduled backups.
When a backup runs in `detached` mode, it will execute asynchronously. The job ID will be returned after the backup [job creation]({% link {{ page.version.version }}/backup-architecture.md %}#job-creation-phase) completes. Note that with `detached` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example]({% link {{ page.version.version }}/backup.md %}#run-a-backup-asynchronously). To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement.
New in v23.1: `EXECUTION LOCALITY` | Key-value pairs | Restricts the execution of the backup to nodes that match the defined locality filter requirements. For example, `WITH EXECUTION LOCALITY = 'region=us-west-1a,cloud=aws'`.
Refer to [Take Locality-restricted backups]({% link {{ page.version.version }}/take-locality-restricted-backups.md %}) for usage and reference detail.
`kms` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | The URI of the cryptographic key stored in a key management service (KMS), or a comma-separated list of key URIs, used to [take and restore encrypted backups]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples). Refer to [URI Formats]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#uri-formats). The key or keys are used to encrypt the manifest and data files that the `BACKUP` statement generates and to decrypt them during a [restore]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples) operation, and to list the contents of the backup when using [`SHOW BACKUP`]({% link {{ page.version.version }}/show-backup.md %}).
AWS KMS, Google Cloud KMS, and Azure Key Vault are supported.
-`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
\ No newline at end of file
+`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
**Warning:** The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
\ No newline at end of file
diff --git a/src/current/_includes/v23.2/backups/backup-options-for-schedules.md b/src/current/_includes/v23.2/backups/backup-options-for-schedules.md
index 391c4dcf968..dda6b9a877a 100644
--- a/src/current/_includes/v23.2/backups/backup-options-for-schedules.md
+++ b/src/current/_includes/v23.2/backups/backup-options-for-schedules.md
@@ -5,4 +5,4 @@
`detached` | [`BOOL`]({% link {{ page.version.version }}/bool.md %}) / None | **Note:** Backups running on a schedule have the `detached` option applied implicitly. Therefore, you cannot modify this option for scheduled backups.
When a backup runs in `detached` mode, it will execute asynchronously. The job ID will be returned after the backup [job creation]({% link {{ page.version.version }}/backup-architecture.md %}#job-creation-phase) completes. Note that with `detached` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example]({% link {{ page.version.version }}/backup.md %}#run-a-backup-asynchronously). To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement.
`EXECUTION LOCALITY` | Key-value pairs | Restricts the execution of the backup to nodes that match the defined locality filter requirements. For example, `WITH EXECUTION LOCALITY = 'region=us-west-1a,cloud=aws'`.
Refer to [Take Locality-restricted backups]({% link {{ page.version.version }}/take-locality-restricted-backups.md %}) for usage and reference detail.
`kms` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | The URI of the cryptographic key stored in a key management service (KMS), or a comma-separated list of key URIs, used to [take and restore encrypted backups]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples). Refer to [URI Formats]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#uri-formats). The key or keys are used to encrypt the manifest and data files that the `BACKUP` statement generates and to decrypt them during a [restore]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples) operation, and to list the contents of the backup when using [`SHOW BACKUP`]({% link {{ page.version.version }}/show-backup.md %}).
AWS KMS, Google Cloud KMS, and Azure Key Vault are supported.
-`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
\ No newline at end of file
+`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
**Warning:** The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
\ No newline at end of file
diff --git a/src/current/_includes/v24.1/backups/backup-options-for-schedules.md b/src/current/_includes/v24.1/backups/backup-options-for-schedules.md
index 391c4dcf968..dda6b9a877a 100644
--- a/src/current/_includes/v24.1/backups/backup-options-for-schedules.md
+++ b/src/current/_includes/v24.1/backups/backup-options-for-schedules.md
@@ -5,4 +5,4 @@
`detached` | [`BOOL`]({% link {{ page.version.version }}/bool.md %}) / None | **Note:** Backups running on a schedule have the `detached` option applied implicitly. Therefore, you cannot modify this option for scheduled backups.
When a backup runs in `detached` mode, it will execute asynchronously. The job ID will be returned after the backup [job creation]({% link {{ page.version.version }}/backup-architecture.md %}#job-creation-phase) completes. Note that with `detached` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example]({% link {{ page.version.version }}/backup.md %}#run-a-backup-asynchronously). To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement.
`EXECUTION LOCALITY` | Key-value pairs | Restricts the execution of the backup to nodes that match the defined locality filter requirements. For example, `WITH EXECUTION LOCALITY = 'region=us-west-1a,cloud=aws'`.
Refer to [Take Locality-restricted backups]({% link {{ page.version.version }}/take-locality-restricted-backups.md %}) for usage and reference detail.
`kms` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | The URI of the cryptographic key stored in a key management service (KMS), or a comma-separated list of key URIs, used to [take and restore encrypted backups]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples). Refer to [URI Formats]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#uri-formats). The key or keys are used to encrypt the manifest and data files that the `BACKUP` statement generates and to decrypt them during a [restore]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples) operation, and to list the contents of the backup when using [`SHOW BACKUP`]({% link {{ page.version.version }}/show-backup.md %}).
AWS KMS, Google Cloud KMS, and Azure Key Vault are supported.
-`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
\ No newline at end of file
+`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
**Warning:** The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
\ No newline at end of file
diff --git a/src/current/_includes/v24.3/backups/backup-options-for-schedules.md b/src/current/_includes/v24.3/backups/backup-options-for-schedules.md
index 391c4dcf968..dda6b9a877a 100644
--- a/src/current/_includes/v24.3/backups/backup-options-for-schedules.md
+++ b/src/current/_includes/v24.3/backups/backup-options-for-schedules.md
@@ -5,4 +5,4 @@
`detached` | [`BOOL`]({% link {{ page.version.version }}/bool.md %}) / None | **Note:** Backups running on a schedule have the `detached` option applied implicitly. Therefore, you cannot modify this option for scheduled backups.
When a backup runs in `detached` mode, it will execute asynchronously. The job ID will be returned after the backup [job creation]({% link {{ page.version.version }}/backup-architecture.md %}#job-creation-phase) completes. Note that with `detached` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example]({% link {{ page.version.version }}/backup.md %}#run-a-backup-asynchronously). To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement.
`EXECUTION LOCALITY` | Key-value pairs | Restricts the execution of the backup to nodes that match the defined locality filter requirements. For example, `WITH EXECUTION LOCALITY = 'region=us-west-1a,cloud=aws'`.
Refer to [Take Locality-restricted backups]({% link {{ page.version.version }}/take-locality-restricted-backups.md %}) for usage and reference detail.
`kms` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | The URI of the cryptographic key stored in a key management service (KMS), or a comma-separated list of key URIs, used to [take and restore encrypted backups]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples). Refer to [URI Formats]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#uri-formats). The key or keys are used to encrypt the manifest and data files that the `BACKUP` statement generates and to decrypt them during a [restore]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples) operation, and to list the contents of the backup when using [`SHOW BACKUP`]({% link {{ page.version.version }}/show-backup.md %}).
AWS KMS, Google Cloud KMS, and Azure Key Vault are supported.
-`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
\ No newline at end of file
+`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
**Warning:** The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
\ No newline at end of file
diff --git a/src/current/_includes/v25.2/backups/backup-options-for-schedules.md b/src/current/_includes/v25.2/backups/backup-options-for-schedules.md
index 391c4dcf968..dda6b9a877a 100644
--- a/src/current/_includes/v25.2/backups/backup-options-for-schedules.md
+++ b/src/current/_includes/v25.2/backups/backup-options-for-schedules.md
@@ -5,4 +5,4 @@
`detached` | [`BOOL`]({% link {{ page.version.version }}/bool.md %}) / None | **Note:** Backups running on a schedule have the `detached` option applied implicitly. Therefore, you cannot modify this option for scheduled backups.
When a backup runs in `detached` mode, it will execute asynchronously. The job ID will be returned after the backup [job creation]({% link {{ page.version.version }}/backup-architecture.md %}#job-creation-phase) completes. Note that with `detached` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example]({% link {{ page.version.version }}/backup.md %}#run-a-backup-asynchronously). To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement.
`EXECUTION LOCALITY` | Key-value pairs | Restricts the execution of the backup to nodes that match the defined locality filter requirements. For example, `WITH EXECUTION LOCALITY = 'region=us-west-1a,cloud=aws'`.
Refer to [Take Locality-restricted backups]({% link {{ page.version.version }}/take-locality-restricted-backups.md %}) for usage and reference detail.
`kms` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | The URI of the cryptographic key stored in a key management service (KMS), or a comma-separated list of key URIs, used to [take and restore encrypted backups]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples). Refer to [URI Formats]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#uri-formats). The key or keys are used to encrypt the manifest and data files that the `BACKUP` statement generates and to decrypt them during a [restore]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples) operation, and to list the contents of the backup when using [`SHOW BACKUP`]({% link {{ page.version.version }}/show-backup.md %}).
AWS KMS, Google Cloud KMS, and Azure Key Vault are supported.
-`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
\ No newline at end of file
+`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
**Warning:** The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
\ No newline at end of file
diff --git a/src/current/_includes/v25.3/backups/backup-options-for-schedules.md b/src/current/_includes/v25.3/backups/backup-options-for-schedules.md
index 391c4dcf968..dda6b9a877a 100644
--- a/src/current/_includes/v25.3/backups/backup-options-for-schedules.md
+++ b/src/current/_includes/v25.3/backups/backup-options-for-schedules.md
@@ -5,4 +5,4 @@
`detached` | [`BOOL`]({% link {{ page.version.version }}/bool.md %}) / None | **Note:** Backups running on a schedule have the `detached` option applied implicitly. Therefore, you cannot modify this option for scheduled backups.
When a backup runs in `detached` mode, it will execute asynchronously. The job ID will be returned after the backup [job creation]({% link {{ page.version.version }}/backup-architecture.md %}#job-creation-phase) completes. Note that with `detached` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example]({% link {{ page.version.version }}/backup.md %}#run-a-backup-asynchronously). To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement.
`EXECUTION LOCALITY` | Key-value pairs | Restricts the execution of the backup to nodes that match the defined locality filter requirements. For example, `WITH EXECUTION LOCALITY = 'region=us-west-1a,cloud=aws'`.
Refer to [Take Locality-restricted backups]({% link {{ page.version.version }}/take-locality-restricted-backups.md %}) for usage and reference detail.
`kms` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | The URI of the cryptographic key stored in a key management service (KMS), or a comma-separated list of key URIs, used to [take and restore encrypted backups]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples). Refer to [URI Formats]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#uri-formats). The key or keys are used to encrypt the manifest and data files that the `BACKUP` statement generates and to decrypt them during a [restore]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples) operation, and to list the contents of the backup when using [`SHOW BACKUP`]({% link {{ page.version.version }}/show-backup.md %}).
AWS KMS, Google Cloud KMS, and Azure Key Vault are supported.
-`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
\ No newline at end of file
+`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
**Warning:** The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
\ No newline at end of file
diff --git a/src/current/_includes/v25.4/backups/backup-options-for-schedules.md b/src/current/_includes/v25.4/backups/backup-options-for-schedules.md
index 391c4dcf968..dda6b9a877a 100644
--- a/src/current/_includes/v25.4/backups/backup-options-for-schedules.md
+++ b/src/current/_includes/v25.4/backups/backup-options-for-schedules.md
@@ -5,4 +5,4 @@
`detached` | [`BOOL`]({% link {{ page.version.version }}/bool.md %}) / None | **Note:** Backups running on a schedule have the `detached` option applied implicitly. Therefore, you cannot modify this option for scheduled backups.
When a backup runs in `detached` mode, it will execute asynchronously. The job ID will be returned after the backup [job creation]({% link {{ page.version.version }}/backup-architecture.md %}#job-creation-phase) completes. Note that with `detached` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example]({% link {{ page.version.version }}/backup.md %}#run-a-backup-asynchronously). To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement.
`EXECUTION LOCALITY` | Key-value pairs | Restricts the execution of the backup to nodes that match the defined locality filter requirements. For example, `WITH EXECUTION LOCALITY = 'region=us-west-1a,cloud=aws'`.
Refer to [Take Locality-restricted backups]({% link {{ page.version.version }}/take-locality-restricted-backups.md %}) for usage and reference detail.
`kms` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | The URI of the cryptographic key stored in a key management service (KMS), or a comma-separated list of key URIs, used to [take and restore encrypted backups]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples). Refer to [URI Formats]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#uri-formats). The key or keys are used to encrypt the manifest and data files that the `BACKUP` statement generates and to decrypt them during a [restore]({% link {{ page.version.version }}/take-and-restore-encrypted-backups.md %}#examples) operation, and to list the contents of the backup when using [`SHOW BACKUP`]({% link {{ page.version.version }}/show-backup.md %}).
AWS KMS, Google Cloud KMS, and Azure Key Vault are supported.
-`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
\ No newline at end of file
+`incremental_location` | [`STRING`]({% link {{ page.version.version }}/string.md %}) | Create an incremental backup in a different location than the default incremental backup location.
`WITH incremental_location = 'explicit_incrementals_URI'`
See [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) for usage.
**Warning:** The `incremental_location` parameter is deprecated in versions 25.4 and later. If needed, you can continue to work with already existing backups that use a custom `incremental_location` , but this ability will be removed in version 26.2.
\ No newline at end of file
diff --git a/src/current/v23.1/alter-backup-schedule.md b/src/current/v23.1/alter-backup-schedule.md
index 8e1128b97e3..017b1d953cc 100644
--- a/src/current/v23.1/alter-backup-schedule.md
+++ b/src/current/v23.1/alter-backup-schedule.md
@@ -154,6 +154,8 @@ Full backups are implicitly of `backup_type` `0`, and so does not display in the
### Apply different options to scheduled backups
+{% include common/sql/incremental-location-warning.md %}
+
You can modify the behavior of your backup schedule and the backup jobs with `SET SCHEDULE OPTION` and `SET WITH`. See the [Schedule options](#schedule-options) table and the [Backup options](#backup-options) table for a list of the available options.
This statement changes the default `wait` value for the `on_previous_running` schedule option to `start`. If a previous backup started by the schedule is still running, the scheduled job will now start the new backup anyway, rather than waiting. The backup option [`incremental_location`]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) modifies the storage location for incremental backups:
diff --git a/src/current/v23.1/backup.md b/src/current/v23.1/backup.md
index 0432a6aa0eb..c2eb03a827b 100644
--- a/src/current/v23.1/backup.md
+++ b/src/current/v23.1/backup.md
@@ -308,6 +308,8 @@ See [Name Resolution]({% link {{ page.version.version }}/sql-name-resolution.md
### Create incremental backups
+{% include common/sql/incremental-location-warning.md %}
+
When a `BACKUP` statement specifies an existing subdirectory in the collection, explicitly or via the `LATEST` keyword, an incremental backup will be added to the default `/incrementals` directory at the root of the [collection]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#backup-collections) storage location.
To take an incremental backup using the `LATEST` keyword:
diff --git a/src/current/v23.1/restore.md b/src/current/v23.1/restore.md
index aebc3066ad9..f78885b94eb 100644
--- a/src/current/v23.1/restore.md
+++ b/src/current/v23.1/restore.md
@@ -572,6 +572,8 @@ After it's restored into a new database, you can write the restored `users` tabl
#### Restore from incremental backups in a different location
+{% include common/sql/incremental-location-warning.md %}
+
To restore an incremental backup that was taken using the [`incremental_location` option]({% link {{ page.version.version }}/backup.md %}#incr-location), you must run the `RESTORE` statement with both:
- the collection URI of the full backup
diff --git a/src/current/v23.1/take-and-restore-locality-aware-backups.md b/src/current/v23.1/take-and-restore-locality-aware-backups.md
index bdff82ab7c5..39b78bebb6d 100644
--- a/src/current/v23.1/take-and-restore-locality-aware-backups.md
+++ b/src/current/v23.1/take-and-restore-locality-aware-backups.md
@@ -164,6 +164,8 @@ There is different syntax for taking an incremental backup depending on where yo
For more detail on using the `incremental_location` option, see [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations).
+ {% include common/sql/incremental-location-warning.md %}
+
## Restore from an incremental locality-aware backup
A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`]({% link {{ page.version.version }}/restore.md %}).
diff --git a/src/current/v23.1/take-full-and-incremental-backups.md b/src/current/v23.1/take-full-and-incremental-backups.md
index c390c9bfbe7..5c9c350246b 100644
--- a/src/current/v23.1/take-full-and-incremental-backups.md
+++ b/src/current/v23.1/take-full-and-incremental-backups.md
@@ -220,6 +220,8 @@ RESTORE FROM '2023/03/23-213101.37' IN 's3://bucket/path?AUTH=implicit';
### Incremental backups with explicitly specified destinations
+{% include common/sql/incremental-location-warning.md %}
+
To explicitly control where your incremental backups go, use the [`incremental_location`]({% link {{ page.version.version }}/backup.md %}#options) option. By default, incremental backups are stored in the `/incrementals` subdirectory at the root of the collection. However, there are some advanced cases where you may want to store incremental backups in a different storage location.
In the following examples, the `{collectionURI}` specifies the storage location containing the full backup. The `{explicit_incrementalsURI}` is the alternative location that you can store an incremental backup:
diff --git a/src/current/v23.2/alter-backup-schedule.md b/src/current/v23.2/alter-backup-schedule.md
index 8e1128b97e3..017b1d953cc 100644
--- a/src/current/v23.2/alter-backup-schedule.md
+++ b/src/current/v23.2/alter-backup-schedule.md
@@ -154,6 +154,8 @@ Full backups are implicitly of `backup_type` `0`, and so does not display in the
### Apply different options to scheduled backups
+{% include common/sql/incremental-location-warning.md %}
+
You can modify the behavior of your backup schedule and the backup jobs with `SET SCHEDULE OPTION` and `SET WITH`. See the [Schedule options](#schedule-options) table and the [Backup options](#backup-options) table for a list of the available options.
This statement changes the default `wait` value for the `on_previous_running` schedule option to `start`. If a previous backup started by the schedule is still running, the scheduled job will now start the new backup anyway, rather than waiting. The backup option [`incremental_location`]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) modifies the storage location for incremental backups:
diff --git a/src/current/v23.2/backup.md b/src/current/v23.2/backup.md
index 63f387f5ed6..3ce13a06744 100644
--- a/src/current/v23.2/backup.md
+++ b/src/current/v23.2/backup.md
@@ -306,6 +306,8 @@ See [Name Resolution]({% link {{ page.version.version }}/sql-name-resolution.md
### Create incremental backups
+{% include common/sql/incremental-location-warning.md %}
+
When a `BACKUP` statement specifies an existing subdirectory in the collection, explicitly or via the `LATEST` keyword, an incremental backup will be added to the default `/incrementals` directory at the root of the [collection]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#backup-collections) storage location.
To take an incremental backup using the `LATEST` keyword:
diff --git a/src/current/v23.2/restore.md b/src/current/v23.2/restore.md
index 6cec43931bd..9c855a8e41a 100644
--- a/src/current/v23.2/restore.md
+++ b/src/current/v23.2/restore.md
@@ -570,6 +570,8 @@ After it's restored into a new database, you can write the restored `users` tabl
#### Restore from incremental backups in a different location
+{% include common/sql/incremental-location-warning.md %}
+
To restore an incremental backup that was taken using the [`incremental_location` option]({% link {{ page.version.version }}/backup.md %}#incr-location), you must run the `RESTORE` statement with both:
- the collection URI of the full backup
diff --git a/src/current/v23.2/take-and-restore-locality-aware-backups.md b/src/current/v23.2/take-and-restore-locality-aware-backups.md
index bdff82ab7c5..39b78bebb6d 100644
--- a/src/current/v23.2/take-and-restore-locality-aware-backups.md
+++ b/src/current/v23.2/take-and-restore-locality-aware-backups.md
@@ -164,6 +164,8 @@ There is different syntax for taking an incremental backup depending on where yo
For more detail on using the `incremental_location` option, see [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations).
+ {% include common/sql/incremental-location-warning.md %}
+
## Restore from an incremental locality-aware backup
A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`]({% link {{ page.version.version }}/restore.md %}).
diff --git a/src/current/v23.2/take-full-and-incremental-backups.md b/src/current/v23.2/take-full-and-incremental-backups.md
index 10c76de39ba..5d0c0711c5e 100644
--- a/src/current/v23.2/take-full-and-incremental-backups.md
+++ b/src/current/v23.2/take-full-and-incremental-backups.md
@@ -220,6 +220,8 @@ RESTORE FROM '2023/03/23-213101.37' IN 's3://bucket/path?AUTH=implicit';
### Incremental backups with explicitly specified destinations
+{% include common/sql/incremental-location-warning.md %}
+
To explicitly control where your incremental backups go, use the [`incremental_location`]({% link {{ page.version.version }}/backup.md %}#options) option. By default, incremental backups are stored in the `/incrementals` subdirectory at the root of the collection. However, there are some advanced cases where you may want to store incremental backups in a different storage location.
In the following examples, the `{collectionURI}` specifies the storage location containing the full backup. The `{explicit_incrementalsURI}` is the alternative location that you can store an incremental backup:
diff --git a/src/current/v24.1/alter-backup-schedule.md b/src/current/v24.1/alter-backup-schedule.md
index cf7ea571321..198797e444a 100644
--- a/src/current/v24.1/alter-backup-schedule.md
+++ b/src/current/v24.1/alter-backup-schedule.md
@@ -155,6 +155,8 @@ Full backups are implicitly of `backup_type` `0`, and so does not display in the
### Apply different options to scheduled backups
+{% include common/sql/incremental-location-warning.md %}
+
You can modify the behavior of your backup schedule and the backup jobs with `SET SCHEDULE OPTION` and `SET WITH`. See the [Schedule options](#schedule-options) table and the [Backup options](#backup-options) table for a list of the available options.
This statement changes the default `wait` value for the `on_previous_running` schedule option to `start`. If a previous backup started by the schedule is still running, the scheduled job will now start the new backup anyway, rather than waiting. The backup option [`incremental_location`]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) modifies the storage location for incremental backups:
diff --git a/src/current/v24.1/backup.md b/src/current/v24.1/backup.md
index e622c5cc8da..608a91354a6 100644
--- a/src/current/v24.1/backup.md
+++ b/src/current/v24.1/backup.md
@@ -311,6 +311,8 @@ See [Name Resolution]({% link {{ page.version.version }}/sql-name-resolution.md
### Create incremental backups
+{% include common/sql/incremental-location-warning.md %}
+
When a `BACKUP` statement specifies an existing subdirectory in the collection, explicitly or via the `LATEST` keyword, an incremental backup will be added to the default `/incrementals` directory at the root of the [collection]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#backup-collections) storage location.
To take an incremental backup using the `LATEST` keyword:
diff --git a/src/current/v24.1/restore.md b/src/current/v24.1/restore.md
index 2be5b2b3140..2eef00cb962 100644
--- a/src/current/v24.1/restore.md
+++ b/src/current/v24.1/restore.md
@@ -570,6 +570,8 @@ After it's restored into a new database, you can write the restored `users` tabl
#### Restore from incremental backups in a different location
+{% include common/sql/incremental-location-warning.md %}
+
To restore an incremental backup that was taken using the [`incremental_location` option]({% link {{ page.version.version }}/backup.md %}#incr-location), you must run the `RESTORE` statement with both:
- the collection URI of the full backup
diff --git a/src/current/v24.1/take-and-restore-locality-aware-backups.md b/src/current/v24.1/take-and-restore-locality-aware-backups.md
index 516d53f3c52..178e074d242 100644
--- a/src/current/v24.1/take-and-restore-locality-aware-backups.md
+++ b/src/current/v24.1/take-and-restore-locality-aware-backups.md
@@ -166,6 +166,8 @@ There is different syntax for taking an incremental backup depending on where yo
For more detail on using the `incremental_location` option, see [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations).
+ {% include common/sql/incremental-location-warning.md %}
+
## Restore from an incremental locality-aware backup
A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`]({% link {{ page.version.version }}/restore.md %}).
diff --git a/src/current/v24.1/take-full-and-incremental-backups.md b/src/current/v24.1/take-full-and-incremental-backups.md
index f815d8e51c5..1a71fbc8aec 100644
--- a/src/current/v24.1/take-full-and-incremental-backups.md
+++ b/src/current/v24.1/take-full-and-incremental-backups.md
@@ -220,6 +220,8 @@ RESTORE FROM '2023/03/23-213101.37' IN 's3://bucket/path?AUTH=implicit';
### Incremental backups with explicitly specified destinations
+{% include common/sql/incremental-location-warning.md %}
+
To explicitly control where your incremental backups go, use the [`incremental_location`]({% link {{ page.version.version }}/backup.md %}#options) option. By default, incremental backups are stored in the `/incrementals` subdirectory at the root of the collection. However, there are some advanced cases where you may want to store incremental backups in a different storage location.
In the following examples, the `{collectionURI}` specifies the storage location containing the full backup. The `{explicit_incrementalsURI}` is the alternative location that you can store an incremental backup:
diff --git a/src/current/v24.3/alter-backup-schedule.md b/src/current/v24.3/alter-backup-schedule.md
index 0e969c05e5f..e10afd3a3d3 100644
--- a/src/current/v24.3/alter-backup-schedule.md
+++ b/src/current/v24.3/alter-backup-schedule.md
@@ -155,6 +155,8 @@ Full backups are implicitly of `backup_type` `0`, and so does not display in the
### Apply different options to scheduled backups
+{% include common/sql/incremental-location-warning.md %}
+
You can modify the behavior of your backup schedule and the backup jobs with `SET SCHEDULE OPTION` and `SET WITH`. See the [Schedule options](#schedule-options) table and the [Backup options](#backup-options) table for a list of the available options.
This statement changes the default `wait` value for the `on_previous_running` schedule option to `start`. If a previous backup started by the schedule is still running, the scheduled job will now start the new backup anyway, rather than waiting. The backup option [`incremental_location`]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) modifies the storage location for incremental backups:
diff --git a/src/current/v24.3/backup.md b/src/current/v24.3/backup.md
index e51f7c26ea4..36499e11eab 100644
--- a/src/current/v24.3/backup.md
+++ b/src/current/v24.3/backup.md
@@ -307,6 +307,8 @@ See [Name Resolution]({% link {{ page.version.version }}/sql-name-resolution.md
### Create incremental backups
+{% include common/sql/incremental-location-warning.md %}
+
When a `BACKUP` statement specifies an existing subdirectory in the collection, explicitly or via the `LATEST` keyword, an incremental backup will be added to the default `/incrementals` directory at the root of the [collection]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#backup-collections) storage location.
To take an incremental backup using the `LATEST` keyword:
diff --git a/src/current/v24.3/restore.md b/src/current/v24.3/restore.md
index f5335313da8..2203310bc05 100644
--- a/src/current/v24.3/restore.md
+++ b/src/current/v24.3/restore.md
@@ -570,6 +570,8 @@ After it's restored into a new database, you can write the restored `users` tabl
#### Restore from incremental backups in a different location
+{% include common/sql/incremental-location-warning.md %}
+
To restore an incremental backup that was taken using the [`incremental_location` option]({% link {{ page.version.version }}/backup.md %}#incr-location), you must run the `RESTORE` statement with both:
- the collection URI of the full backup
diff --git a/src/current/v24.3/show-backup.md b/src/current/v24.3/show-backup.md
index fe1849f69e1..ec8bdf29c9a 100644
--- a/src/current/v24.3/show-backup.md
+++ b/src/current/v24.3/show-backup.md
@@ -13,6 +13,8 @@ The `SHOW BACKUP` syntax **without** the `IN` keyword has been removed from Cock
For guidance on the syntax for `SHOW BACKUP FROM`, refer to the [Synopsis](#synopsis) and [examples](#examples) on this page.
{{site.data.alerts.end}}
+{% include common/sql/incremental-location-warning.md %}
+
## Required privileges
`SHOW BACKUP` requires read permissions to its target destination.
diff --git a/src/current/v24.3/take-and-restore-locality-aware-backups.md b/src/current/v24.3/take-and-restore-locality-aware-backups.md
index 0a75073cc1b..c86e24b057e 100644
--- a/src/current/v24.3/take-and-restore-locality-aware-backups.md
+++ b/src/current/v24.3/take-and-restore-locality-aware-backups.md
@@ -166,6 +166,8 @@ There is different syntax for taking an incremental backup depending on where yo
For more detail on using the `incremental_location` option, see [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations).
+ {% include common/sql/incremental-location-warning.md %}
+
## Restore from an incremental locality-aware backup
A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`]({% link {{ page.version.version }}/restore.md %}).
diff --git a/src/current/v24.3/take-full-and-incremental-backups.md b/src/current/v24.3/take-full-and-incremental-backups.md
index bea1d1cb7b2..27a9e4f3dc1 100644
--- a/src/current/v24.3/take-full-and-incremental-backups.md
+++ b/src/current/v24.3/take-full-and-incremental-backups.md
@@ -220,6 +220,8 @@ RESTORE FROM '2023/03/23-213101.37' IN 's3://bucket/path?AUTH=implicit';
### Incremental backups with explicitly specified destinations
+{% include common/sql/incremental-location-warning.md %}
+
To explicitly control where your incremental backups go, use the [`incremental_location`]({% link {{ page.version.version }}/backup.md %}#options) option. By default, incremental backups are stored in the `/incrementals` subdirectory at the root of the collection. However, there are some advanced cases where you may want to store incremental backups in a different storage location.
In the following examples, the `{collectionURI}` specifies the storage location containing the full backup. The `{explicit_incrementalsURI}` is the alternative location that you can store an incremental backup:
diff --git a/src/current/v25.2/alter-backup-schedule.md b/src/current/v25.2/alter-backup-schedule.md
index 0e969c05e5f..e10afd3a3d3 100644
--- a/src/current/v25.2/alter-backup-schedule.md
+++ b/src/current/v25.2/alter-backup-schedule.md
@@ -155,6 +155,8 @@ Full backups are implicitly of `backup_type` `0`, and so does not display in the
### Apply different options to scheduled backups
+{% include common/sql/incremental-location-warning.md %}
+
You can modify the behavior of your backup schedule and the backup jobs with `SET SCHEDULE OPTION` and `SET WITH`. See the [Schedule options](#schedule-options) table and the [Backup options](#backup-options) table for a list of the available options.
This statement changes the default `wait` value for the `on_previous_running` schedule option to `start`. If a previous backup started by the schedule is still running, the scheduled job will now start the new backup anyway, rather than waiting. The backup option [`incremental_location`]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) modifies the storage location for incremental backups:
diff --git a/src/current/v25.2/backup.md b/src/current/v25.2/backup.md
index 725189f2e7d..a4479d010fe 100644
--- a/src/current/v25.2/backup.md
+++ b/src/current/v25.2/backup.md
@@ -310,6 +310,8 @@ See [Name Resolution]({% link {{ page.version.version }}/sql-name-resolution.md
### Create incremental backups
+{% include common/sql/incremental-location-warning.md %}
+
When a `BACKUP` statement specifies an existing subdirectory in the collection, explicitly or via the `LATEST` keyword, an incremental backup will be added to the default `/incrementals` directory at the root of the [collection]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#backup-collections) storage location.
To take an incremental backup using the `LATEST` keyword:
diff --git a/src/current/v25.2/restore.md b/src/current/v25.2/restore.md
index 162b6787a56..e4b16df70f2 100644
--- a/src/current/v25.2/restore.md
+++ b/src/current/v25.2/restore.md
@@ -568,6 +568,8 @@ After it's restored into a new database, you can write the restored `users` tabl
#### Restore from incremental backups in a different location
+{% include common/sql/incremental-location-warning.md %}
+
To restore an incremental backup that was taken using the [`incremental_location` option]({% link {{ page.version.version }}/backup.md %}#incr-location), you must run the `RESTORE` statement with both:
- the collection URI of the full backup
diff --git a/src/current/v25.2/show-backup.md b/src/current/v25.2/show-backup.md
index fe1849f69e1..ec8bdf29c9a 100644
--- a/src/current/v25.2/show-backup.md
+++ b/src/current/v25.2/show-backup.md
@@ -13,6 +13,8 @@ The `SHOW BACKUP` syntax **without** the `IN` keyword has been removed from Cock
For guidance on the syntax for `SHOW BACKUP FROM`, refer to the [Synopsis](#synopsis) and [examples](#examples) on this page.
{{site.data.alerts.end}}
+{% include common/sql/incremental-location-warning.md %}
+
## Required privileges
`SHOW BACKUP` requires read permissions to its target destination.
diff --git a/src/current/v25.2/take-and-restore-locality-aware-backups.md b/src/current/v25.2/take-and-restore-locality-aware-backups.md
index fad14e6aed0..3d6908ec718 100644
--- a/src/current/v25.2/take-and-restore-locality-aware-backups.md
+++ b/src/current/v25.2/take-and-restore-locality-aware-backups.md
@@ -166,6 +166,8 @@ There is different syntax for taking an incremental backup depending on where yo
For more detail on using the `incremental_location` option, see [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations).
+ {% include common/sql/incremental-location-warning.md %}
+
## Restore from an incremental locality-aware backup
A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`]({% link {{ page.version.version }}/restore.md %}).
diff --git a/src/current/v25.2/take-full-and-incremental-backups.md b/src/current/v25.2/take-full-and-incremental-backups.md
index bea1d1cb7b2..27a9e4f3dc1 100644
--- a/src/current/v25.2/take-full-and-incremental-backups.md
+++ b/src/current/v25.2/take-full-and-incremental-backups.md
@@ -220,6 +220,8 @@ RESTORE FROM '2023/03/23-213101.37' IN 's3://bucket/path?AUTH=implicit';
### Incremental backups with explicitly specified destinations
+{% include common/sql/incremental-location-warning.md %}
+
To explicitly control where your incremental backups go, use the [`incremental_location`]({% link {{ page.version.version }}/backup.md %}#options) option. By default, incremental backups are stored in the `/incrementals` subdirectory at the root of the collection. However, there are some advanced cases where you may want to store incremental backups in a different storage location.
In the following examples, the `{collectionURI}` specifies the storage location containing the full backup. The `{explicit_incrementalsURI}` is the alternative location that you can store an incremental backup:
diff --git a/src/current/v25.3/alter-backup-schedule.md b/src/current/v25.3/alter-backup-schedule.md
index 0e969c05e5f..e10afd3a3d3 100644
--- a/src/current/v25.3/alter-backup-schedule.md
+++ b/src/current/v25.3/alter-backup-schedule.md
@@ -155,6 +155,8 @@ Full backups are implicitly of `backup_type` `0`, and so does not display in the
### Apply different options to scheduled backups
+{% include common/sql/incremental-location-warning.md %}
+
You can modify the behavior of your backup schedule and the backup jobs with `SET SCHEDULE OPTION` and `SET WITH`. See the [Schedule options](#schedule-options) table and the [Backup options](#backup-options) table for a list of the available options.
This statement changes the default `wait` value for the `on_previous_running` schedule option to `start`. If a previous backup started by the schedule is still running, the scheduled job will now start the new backup anyway, rather than waiting. The backup option [`incremental_location`]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) modifies the storage location for incremental backups:
diff --git a/src/current/v25.3/backup.md b/src/current/v25.3/backup.md
index 725189f2e7d..a4479d010fe 100644
--- a/src/current/v25.3/backup.md
+++ b/src/current/v25.3/backup.md
@@ -310,6 +310,8 @@ See [Name Resolution]({% link {{ page.version.version }}/sql-name-resolution.md
### Create incremental backups
+{% include common/sql/incremental-location-warning.md %}
+
When a `BACKUP` statement specifies an existing subdirectory in the collection, explicitly or via the `LATEST` keyword, an incremental backup will be added to the default `/incrementals` directory at the root of the [collection]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#backup-collections) storage location.
To take an incremental backup using the `LATEST` keyword:
diff --git a/src/current/v25.3/restore.md b/src/current/v25.3/restore.md
index 162b6787a56..e4b16df70f2 100644
--- a/src/current/v25.3/restore.md
+++ b/src/current/v25.3/restore.md
@@ -568,6 +568,8 @@ After it's restored into a new database, you can write the restored `users` tabl
#### Restore from incremental backups in a different location
+{% include common/sql/incremental-location-warning.md %}
+
To restore an incremental backup that was taken using the [`incremental_location` option]({% link {{ page.version.version }}/backup.md %}#incr-location), you must run the `RESTORE` statement with both:
- the collection URI of the full backup
diff --git a/src/current/v25.3/show-backup.md b/src/current/v25.3/show-backup.md
index fe1849f69e1..ec8bdf29c9a 100644
--- a/src/current/v25.3/show-backup.md
+++ b/src/current/v25.3/show-backup.md
@@ -13,6 +13,8 @@ The `SHOW BACKUP` syntax **without** the `IN` keyword has been removed from Cock
For guidance on the syntax for `SHOW BACKUP FROM`, refer to the [Synopsis](#synopsis) and [examples](#examples) on this page.
{{site.data.alerts.end}}
+{% include common/sql/incremental-location-warning.md %}
+
## Required privileges
`SHOW BACKUP` requires read permissions to its target destination.
diff --git a/src/current/v25.3/take-and-restore-locality-aware-backups.md b/src/current/v25.3/take-and-restore-locality-aware-backups.md
index 0a75073cc1b..c86e24b057e 100644
--- a/src/current/v25.3/take-and-restore-locality-aware-backups.md
+++ b/src/current/v25.3/take-and-restore-locality-aware-backups.md
@@ -166,6 +166,8 @@ There is different syntax for taking an incremental backup depending on where yo
For more detail on using the `incremental_location` option, see [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations).
+ {% include common/sql/incremental-location-warning.md %}
+
## Restore from an incremental locality-aware backup
A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`]({% link {{ page.version.version }}/restore.md %}).
diff --git a/src/current/v25.3/take-full-and-incremental-backups.md b/src/current/v25.3/take-full-and-incremental-backups.md
index bea1d1cb7b2..27a9e4f3dc1 100644
--- a/src/current/v25.3/take-full-and-incremental-backups.md
+++ b/src/current/v25.3/take-full-and-incremental-backups.md
@@ -220,6 +220,8 @@ RESTORE FROM '2023/03/23-213101.37' IN 's3://bucket/path?AUTH=implicit';
### Incremental backups with explicitly specified destinations
+{% include common/sql/incremental-location-warning.md %}
+
To explicitly control where your incremental backups go, use the [`incremental_location`]({% link {{ page.version.version }}/backup.md %}#options) option. By default, incremental backups are stored in the `/incrementals` subdirectory at the root of the collection. However, there are some advanced cases where you may want to store incremental backups in a different storage location.
In the following examples, the `{collectionURI}` specifies the storage location containing the full backup. The `{explicit_incrementalsURI}` is the alternative location that you can store an incremental backup:
diff --git a/src/current/v25.4/alter-backup-schedule.md b/src/current/v25.4/alter-backup-schedule.md
index 0e969c05e5f..e10afd3a3d3 100644
--- a/src/current/v25.4/alter-backup-schedule.md
+++ b/src/current/v25.4/alter-backup-schedule.md
@@ -155,6 +155,8 @@ Full backups are implicitly of `backup_type` `0`, and so does not display in the
### Apply different options to scheduled backups
+{% include common/sql/incremental-location-warning.md %}
+
You can modify the behavior of your backup schedule and the backup jobs with `SET SCHEDULE OPTION` and `SET WITH`. See the [Schedule options](#schedule-options) table and the [Backup options](#backup-options) table for a list of the available options.
This statement changes the default `wait` value for the `on_previous_running` schedule option to `start`. If a previous backup started by the schedule is still running, the scheduled job will now start the new backup anyway, rather than waiting. The backup option [`incremental_location`]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations) modifies the storage location for incremental backups:
diff --git a/src/current/v25.4/backup.md b/src/current/v25.4/backup.md
index 725189f2e7d..a4479d010fe 100644
--- a/src/current/v25.4/backup.md
+++ b/src/current/v25.4/backup.md
@@ -310,6 +310,8 @@ See [Name Resolution]({% link {{ page.version.version }}/sql-name-resolution.md
### Create incremental backups
+{% include common/sql/incremental-location-warning.md %}
+
When a `BACKUP` statement specifies an existing subdirectory in the collection, explicitly or via the `LATEST` keyword, an incremental backup will be added to the default `/incrementals` directory at the root of the [collection]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#backup-collections) storage location.
To take an incremental backup using the `LATEST` keyword:
diff --git a/src/current/v25.4/restore.md b/src/current/v25.4/restore.md
index 162b6787a56..e4b16df70f2 100644
--- a/src/current/v25.4/restore.md
+++ b/src/current/v25.4/restore.md
@@ -568,6 +568,8 @@ After it's restored into a new database, you can write the restored `users` tabl
#### Restore from incremental backups in a different location
+{% include common/sql/incremental-location-warning.md %}
+
To restore an incremental backup that was taken using the [`incremental_location` option]({% link {{ page.version.version }}/backup.md %}#incr-location), you must run the `RESTORE` statement with both:
- the collection URI of the full backup
diff --git a/src/current/v25.4/show-backup.md b/src/current/v25.4/show-backup.md
index fe1849f69e1..ec8bdf29c9a 100644
--- a/src/current/v25.4/show-backup.md
+++ b/src/current/v25.4/show-backup.md
@@ -13,6 +13,8 @@ The `SHOW BACKUP` syntax **without** the `IN` keyword has been removed from Cock
For guidance on the syntax for `SHOW BACKUP FROM`, refer to the [Synopsis](#synopsis) and [examples](#examples) on this page.
{{site.data.alerts.end}}
+{% include common/sql/incremental-location-warning.md %}
+
## Required privileges
`SHOW BACKUP` requires read permissions to its target destination.
diff --git a/src/current/v25.4/take-and-restore-locality-aware-backups.md b/src/current/v25.4/take-and-restore-locality-aware-backups.md
index 0a75073cc1b..c86e24b057e 100644
--- a/src/current/v25.4/take-and-restore-locality-aware-backups.md
+++ b/src/current/v25.4/take-and-restore-locality-aware-backups.md
@@ -166,6 +166,8 @@ There is different syntax for taking an incremental backup depending on where yo
For more detail on using the `incremental_location` option, see [Incremental backups with explicitly specified destinations]({% link {{ page.version.version }}/take-full-and-incremental-backups.md %}#incremental-backups-with-explicitly-specified-destinations).
+ {% include common/sql/incremental-location-warning.md %}
+
## Restore from an incremental locality-aware backup
A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`]({% link {{ page.version.version }}/restore.md %}).
diff --git a/src/current/v25.4/take-full-and-incremental-backups.md b/src/current/v25.4/take-full-and-incremental-backups.md
index bea1d1cb7b2..27a9e4f3dc1 100644
--- a/src/current/v25.4/take-full-and-incremental-backups.md
+++ b/src/current/v25.4/take-full-and-incremental-backups.md
@@ -220,6 +220,8 @@ RESTORE FROM '2023/03/23-213101.37' IN 's3://bucket/path?AUTH=implicit';
### Incremental backups with explicitly specified destinations
+{% include common/sql/incremental-location-warning.md %}
+
To explicitly control where your incremental backups go, use the [`incremental_location`]({% link {{ page.version.version }}/backup.md %}#options) option. By default, incremental backups are stored in the `/incrementals` subdirectory at the root of the collection. However, there are some advanced cases where you may want to store incremental backups in a different storage location.
In the following examples, the `{collectionURI}` specifies the storage location containing the full backup. The `{explicit_incrementalsURI}` is the alternative location that you can store an incremental backup: