Fixes

src/current/_includes/common/upgrade/disable-auto-finalization.md

@@ -1,7 +1,7 @@
 {% if page.path contains 'kubernetes' %}
 
 <section class="filter-content" markdown="1" data-scope="operator">
-For clusters managed by the Operator, auto-finalization is disabled and cannot be enabled. A major version upgrade is not complete until it is manually [finalized](#finalize-a-major-version-upgrade).
+For clusters managed by the Operator, auto-finalization is disabled and cannot be enabled. A major version upgrade is not complete until it is manually [finalized](#finalize-a-major-version-upgrade-manually).
 </section>
 
 <section class="filter-content" markdown="1" data-scope="manual">
@@ -21,7 +21,7 @@ To disable auto-finalization:
 
 1. Set the [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}) `cluster.preserve_downgrade_option` to the cluster's current major version.
 
-Now, to complete a major-version upgrade, you must manually [finalize it](#finalize-a-major-version-upgrade) or [roll it back]({#roll-back-a-major-version-upgrade).
+Now, to complete a major-version upgrade, you must manually [finalize it](#finalize-a-major-version-upgrade-manually) or [roll it back](#roll-back-a-major-version-upgrade).
 
 {{site.data.alerts.callout_info}}
 Previously, to disable automatic finalization and preserve the ability to roll back a major-version upgrade, it was required to set the cluster setting `cluster.preserve_downgrade_option` to the cluster's current major version before beginning the major-version upgrade. This cluster setting does not persist after finalization is complete, but must be set before each major-version upgrade.
@@ -48,7 +48,7 @@ To disable auto-finalization:
 
 1. Set the [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}) `cluster.preserve_downgrade_option` to the cluster's current major version.
 
-Now, to complete a major-version upgrade, you must manually [finalize it](#finalize-a-major-version-upgrade) or [roll it back]({#roll-back-a-major-version-upgrade).
+Now, to complete a major-version upgrade, you must manually [finalize it](#finalize-a-major-version-upgrade-manually) or [roll it back]({#roll-back-a-major-version-upgrade).
 
 {{site.data.alerts.callout_info}}
 Previously, to disable automatic finalization and preserve the ability to roll back a major-version upgrade, it was required to set the cluster setting `cluster.preserve_downgrade_option` to the cluster's current major version before beginning the major-version upgrade. This cluster setting does not persist after finalization is complete, but must be set before each major-version upgrade.
@@ -73,7 +73,7 @@ To disable auto-finalization:
 
 1. Set the [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}) `cluster.auto_upgrade.enabled` to `false`.
 
-Now, to complete a major-version upgrade, you must manually [finalize it](#finalize-a-major-version-upgrade) or [roll it back]({#roll-back-a-major-version-upgrade).
+Now, to complete a major-version upgrade, you must manually [finalize it](#finalize-a-major-version-upgrade-manually) or [roll it back]({#roll-back-a-major-version-upgrade).
 
 {{site.data.alerts.callout_info}}
 Previously, to disable automatic finalization and preserve the ability to roll back a major-version upgrade, it was required to set the cluster setting `cluster.preserve_downgrade_option` to the cluster's current major version before beginning the major-version upgrade. This cluster setting does not persist after finalization is complete, but must be set before each major-version upgrade.

src/current/_includes/common/upgrade/major-version-upgrade-cloud.md

@@ -18,4 +18,4 @@ This section shows how to perform a major-version upgrade for a cluster in Cockr
 1. A CockroachDB {{ site.data.products.standard }} or {{ site.data.products.basic }} cluster remains fully available while it is upgraded. For a multi-node CockroachDB {{ site.data.products.advanced }} cluster, nodes are upgraded one at a time in a rolling fashion so the cluster remains available, with one node unavailable at a time. A single-node {{ site.data.products.advanced }} cluster will be unavailable while the cluster is upgraded and restarted. If necessary, prepare for the upgrade by communicating ahead of time with your users, and plan to begin the upgrade during a time when the impact on the cluster's workload will be minimized.
 1. To begin a major-version upgrade, go back to the dialog in the CockroachDB {{ site.data.products.cloud }} Console. If multiple upgrades are available, select the desired version. Review the details, then click **Start upgrade**. The dialog closes, and the **Version** columnin the **Cluster List** page changes to **Upgrading**. When the upgrade has finished but has not yet been finalized, the **Version** column reports that the new version is **pending**.
 
-The upgrade is not complete until it is [finalized](#finalize-a-major-version-upgrade). After the upgrade is finalized, the cluster can no longer be [rolled back](#roll-back-a-major-version-upgrade) to its previous major version. If you take no action, finalization occurs automatically after approximately 72 hours.
+The upgrade is not complete until it is [finalized](#finalize-a-major-version-upgrade-manually). After the upgrade is finalized, the cluster can no longer be [rolled back](#roll-back-a-major-version-upgrade) to its previous major version. If you take no action, finalization occurs automatically after approximately 72 hours.

src/current/_includes/common/upgrade/major-version-upgrade-kubernetes.md

@@ -29,7 +29,7 @@ To perform a major upgrade:
 
     You can also check the CockroachDB version of each node in the [DB Console]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}#node-details).
 
-1. Before beginning a major-version upgrade, the Operator disables auto-finalization by setting the cluster setting `cluster.preserve_downgrade_option` to the cluster's current major version. Before finalizing an upgrade, follow your organization's testing procedures to decide whether to [finalize](#finalize-a-major-version-upgrade) or [roll back](#roll-back-a-major-version-upgrade) the upgrade. After finalization begins, you can no longer roll back to the cluster's previous major version.
+1. Before beginning a major-version upgrade, the Operator disables auto-finalization by setting the cluster setting `cluster.preserve_downgrade_option` to the cluster's current major version. Before finalizing an upgrade, follow your organization's testing procedures to decide whether to [finalize](#finalize-a-major-version-upgrade-manually) or [roll back](#roll-back-a-major-version-upgrade) the upgrade. After finalization begins, you can no longer roll back to the cluster's previous major version.
 
 </section>
 
@@ -124,7 +124,7 @@ To perform a major upgrade:
     ~~~
 
     You can also check the CockroachDB version of each node in the [DB Console]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}#node-details).
-1. If auto-finalization is disabled, the upgrade is not complete until you [finalize the upgrade](#finalize-a-major-version-upgrade).
+1. If auto-finalization is disabled, the upgrade is not complete until you [finalize the upgrade](#finalize-a-major-version-upgrade-manually).
 
 </section>
 
@@ -259,6 +259,6 @@ To perform a major upgrade:
 
     You can also check the CockroachDB version of each node in the [DB Console]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}#node-details).
 
-1. If auto-finalization is disabled, the upgrade is not complete until you [finalize the upgrade](#finalize-a-major-version-upgrade).
+1. If auto-finalization is disabled, the upgrade is not complete until you [finalize the upgrade](#finalize-a-major-version-upgrade-manually).
 
 </section>

src/current/_includes/common/upgrade/major-version-upgrade-self-hosted.md

@@ -12,4 +12,4 @@ To perform a major upgrade:
         cockroach sql -e 'select 1'
         ~~~
 1. If auto-finalization is enabled (the default), finalization begins as soon as the last node rejoins the cluster with the new binary. When finalization finishes, the upgrade is complete.
-1. If auto-finalization is disabled, follow your organization's testing procedures to decide whether to [finalize the upgrade](#finalize-a-major-version-upgrade) or [roll back](#roll-back-a-major-version-upgrade) the upgrade. After finalization begins, you can no longer roll back to the cluster's previous major version.
+1. If auto-finalization is disabled, follow your organization's testing procedures to decide whether to [finalize the upgrade](#finalize-a-major-version-upgrade-manually) or [roll back](#roll-back-a-major-version-upgrade) the upgrade. After finalization begins, you can no longer roll back to the cluster's previous major version.

src/current/_includes/common/upgrade/prepare-to-upgrade-cloud.md

@@ -1,6 +1,6 @@
 Before beginning a major-version upgrade:
 
-1. **CockroachDB {{ site.data.products.advanced }}**: Verify the overall health of your cluster using the [DB Console]({% link cockroachcloud/tools-page#access-the-db-console.md %}):
+1. **CockroachDB {{ site.data.products.advanced }}**: Verify the overall health of your cluster using the [DB Console]({% link cockroachcloud/tools-page.md %}#access-the-db-console):
     - Under **Node Status**, make sure all nodes that should be live are listed as such. If any nodes are unexpectedly listed as `SUSPECT` or `DEAD`, identify why the nodes are offline and either restart them or [decommission]({% link {{ site.current_cloud_version }}/node-shutdown.md %}?filters=decommission#remove-nodes) them before beginning your upgrade. If there are `DEAD` and non-decommissioned nodes in your cluster, the upgrade cannot be finalized.
 
         If any node is not fully decommissioned, try the following:

src/current/_includes/common/upgrade/rollback-cloud.md

@@ -4,4 +4,4 @@ To roll back to the previous major version before the upgrade is finalized autom
 1. At the top of the page, click **Roll back**.
 
    A CockroachDB {{ site.data.products.standard }} or {{ site.data.products.basic }} cluster remains fully available while it is rolled back. For a multi-node CockroachDB {{ site.data.products.advanced }} cluster, nodes are rolled back one at a time in a rolling fashion so the cluster remains available, with one node unavailable at a time. A single-node CockroachDB {{ site.data.products.advanced }} cluster will be unavailable while the cluster is rolled back and restarted. Like an upgrade, a rollback must be finalized.
-1. Like a major-version upgrade, a rollback must be [finalized](#finalize-a-major-versino-upgrade). When the rollback is finalized, the rollback is complete.
+1. Like a major-version upgrade, a rollback must be [finalized](#finalize-a-major-version-upgrade-manually). When the rollback is finalized, the rollback is complete.

src/current/_includes/common/upgrade/rollback-kubernetes.md

@@ -27,4 +27,4 @@ To roll back to the previous major version before an upgrade is finalized:
 
     You can also check the CockroachDB version of each node in the [DB Console]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}#node-details).
 
-1. Like a major-version upgrade, a rollback must be [finalized](#finalize-a-major-version-upgrade). When the rollback is finalized, the rollback is complete.
+1. Like a major-version upgrade, a rollback must be [finalized](#finalize-a-major-version-upgrade-manually). When the rollback is finalized, the rollback is complete.

src/current/_includes/common/upgrade/rollback-self-hosted.md

@@ -1,4 +1,4 @@
 To roll back a major-version upgrade that has not been finalized:
 
 1. Follow the steps to [perform a major-version upgrade](#perform-a-major-version-upgrade), replacing the `cockroach` binary on each node with binary for the previous major version.
-1. Like a major-version upgrade, a rollback must be [finalized](#finalize-a-major-version-upgrade). When the rollback is finalized, the rollback is complete.
+1. Like a major-version upgrade, a rollback must be [finalized](#finalize-a-major-version-upgrade-manually). When the rollback is finalized, the rollback is complete.

src/current/_includes/common/upgrade/upgrade-high-level.md

@@ -5,4 +5,4 @@ At a high level, a cluster upgrade involves the following steps, which are detai
     1. Restart the `cockroach` process and verify that the node has rejoined the cluster.
 1. When all nodes have rejoined the cluster:
     1. For a patch upgrade within the same major version, the upgrade is complete.
-    1. For a major-version upgrade, the upgrade is not complete until it is [finalized](#finalize-a-major-version-upgrade). Auto-finalization is enabled by default, and begins as soon as all nodes have rejoined the cluster using the new binary. If you need the ability to [roll back a major-version upgrade](#roll-back-a-major-version-upgrade), you can disable auto-finalization and finalize the upgrade manually. Certain features and performance improvements, such as those that require changes to system schemas or objects, are not available until the upgrade is finalized. Refer to the {% if page.path contains 'cockroachcloud' %} [{{ site.current_cloud_version }} Release Notes]({% link releases/{{ page.version.version }}.md %}) {% else %}[{{ page.version.version }} Release Notes]({% link releases/{{ page.version.version }}.md %}).{% endif %}.
+    1. For a major-version upgrade, the upgrade is not complete until it is [finalized](#finalize-a-major-version-upgrade-manually). Auto-finalization is enabled by default, and begins as soon as all nodes have rejoined the cluster using the new binary. If you need the ability to [roll back a major-version upgrade](#roll-back-a-major-version-upgrade), you can disable auto-finalization and finalize the upgrade manually. Certain features and performance improvements, such as those that require changes to system schemas or objects, are not available until the upgrade is finalized. Refer to the {% if page.path contains 'cockroachcloud' %} [{{ site.current_cloud_version }} Release Notes]({% link releases/{{ site.current_cloud_version }}.md %}){% else %}[{{ page.version.version }} Release Notes]({% link releases/{{ page.version.version }}.md %}).{% endif %}.

src/current/_includes/releases/v24.3/upgrade-finalization.md

@@ -1,4 +1,4 @@
 During a major-version upgrade, certain features and performance improvements may not be available until the upgrade is finalized.
 
-- A cluster must have an [Enterprise license]({% link {{ page.version.version }}/licensing-faqs.md %}#set-a-license) or a [trial license]({% link {{ page.version.version }}/licensing-faqs.md %}#obtain-a-license) set before an upgrade to {{ page.version.version }} can be finalized.
-- New clusters that are initialized for the first time on {{ page.version.version }}, and clusters that are upgraded to {{ page.version.version }} will now have a [zone config]({% link {{ page.version.version }}/configure-zone.md %}) defined for the `timeseries` range if it does not already exist, which specifies the value for `gc.ttlseconds`, but inherits all other attributes from the zone config for the `default` range.
+- A cluster must have an [Enterprise license]({% link v24.3/licensing-faqs.md %}#set-a-license) or a [trial license]({% link v24.3/licensing-faqs.md %}#obtain-a-license) set before an upgrade to v24.3 can be finalized.
+- New clusters that are initialized for the first time on v24.3, and clusters that are upgraded to v24.3 will now have a [zone config]({% link v24.3/configure-replication-zones.md %}) defined for the `timeseries` range if it does not already exist, which specifies the value for `gc.ttlseconds`, but inherits all other attributes from the zone config for the `default` range.

src/current/_includes/v24.2/backups/recommend-backups-for-upgrade.md

@@ -1 +1,9 @@
-Because CockroachDB is designed with high fault tolerance, backups are primarily needed for [disaster recovery]({% link {{ page.version.version }}/disaster-recovery-planning.md %}). However, taking regular backups of your data is an operational best practice. When upgrading to a major release, **we recommend [taking a backup]({% link {{ page.version.version }}/backup-and-restore-overview.md %}) of your cluster**.
+{% if page.path contains "cockroachcloud" %}
+[Managed backups]({% link cockroachcloud/managed-backups.md %}) are automated backups of CockroachDB {{ site.data.products.cloud }} clusters that are stored by Cockroach Labs in cloud storage. By default, Cockroach Labs takes and retains managed backups in all Cloud clusters.
+
+When upgrading to a major release, you can optionally [take a self-managed backup]({% link cockroachcloud/take-and-restore-self-managed-backups.md %}) of your cluster to your own cloud storage, as an extra layer of protection in case the upgrade leads to issues.
+{% else %}
+CockroachDB is designed with high fault tolerance. However, taking regular backups of your data is an operational best practice for [disaster recovery]({% link {{ page.version.version }}/disaster-recovery-planning.md %}) planning.
+
+When upgrading to a new major version, **we recommend [taking a self-managed backup]({% link {{ page.version.version }}/backup-and-restore-overview.md %}) of your cluster** so that you can [restore the cluster to the previous version]({% link {{ page.version.version }}/restoring-backups-across-versions.md %}#support-for-restoring-backups-into-a-newer-version) if the upgrade leads to issues.
+{% endif %}

src/current/cockroachcloud/upgrade-cockroach-version.md

@@ -11,7 +11,7 @@ This page describes how major-version and patch upgrades work and shows how to u
 
 {% include common/upgrade/overview.md %}
 
-{% include_cached {{ site.current_cloud_version }}/upgrade_requirements.md %}
+{% include_cached {{ site.current_cloud_version }}/upgrade-requirements.md %}
 
 {% include common/upgrade/upgrade-high-level.md %}
 
@@ -37,16 +37,16 @@ Refer to [Cloud Upgrade Policy]({% link cockroachcloud/upgrade-policy.md %}).
 
 ### Finalize a major-version upgrade manually
 
-{% include_cached finalize-cloud.md %}
+{% include_cached common/upgrade/finalize-cloud.md %}
 
 ### Roll back a major-version upgrade
 
-{% include_cached rollback-cloud.md %}
+{% include_cached common/upgrade/rollback-cloud.md %}
 
 ## Troubleshooting
 
 {% include common/upgrade/troubleshooting-cloud.md %}
 
 ## See also
 
-{% include see-also-cloud.md %}
+{% include common/upgrade/see-also-cloud.md %}

src/current/releases/v24.3.md

@@ -23,6 +23,16 @@ docs_area: releases
 
 {% include releases/whats-new-intro.md major_version=vers %}
 
+{% comment %}Remove this block at GA and add the content to v24.3.0.md instead{% endcomment %}
+<h3 id="backward-incompatible-changes-and-deprecations">Backward-incompatible changes and deprecations</h3>
+
+Until v24.3 is Generally Available, review the backward-incompatible changes and deprecations listed in each testing release.
+
+{% comment %}Remove this block at GA and include the content in v24.3.0.md instead{% endcomment %}
+<h3 id="features-that-require-upgrade-finalization">Features that require upgrade finalization</h3>
+
+{% include releases/v24.3/upgrade-finalization.md %}
+
 {% for r in rel %}
 {% include releases/{{ page.major_version }}/{{ r.release_name }}.md release=r.release_name %}
 {% endfor %}

src/current/v24.2/api-support-policy.md

@@ -23,7 +23,7 @@ This page includes the following information:
 | Unstable | Supported for consumption by humans. Not supported for automation.        | [Backward-incompatible changes](#backward-incompatible-changes) may be introduced in new major and patch versions.                                                                                                 |
 | Reserved | Intended for use by CockroachDB developers. Not supported for public use. | N/A                                                                                                                                                                                                                |
 
-Backward-incompatible changes to **stable APIs** are highlighted in the [release notes]({% link releases/index.md %}#production-releases) for major CockroachDB versions. Users are asked to [consider backward-incompatible changes before upgrading]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#review-breaking-changes) to a new CockroachDB version.
+Backward-incompatible changes to **stable APIs** are highlighted in the [release notes]({% link releases/index.md %}) for major CockroachDB versions. Users are asked to consider backward-incompatible changes before [upgrading]({% link releases/{{ page.version.version}}.md %}) to a new CockroachDB version.
 
 ### Backward-incompatible changes