chore: update docs fixing anchors

Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>

Author: leonardoce

docs/appendixes/backup_barmanobjectstore.md

@@ -106,7 +106,7 @@ segment to be archived.
     By default, CloudNativePG sets `archive_timeout` to `5min`, ensuring
     that WAL files, even in case of low workloads, are closed and archived
     at least every 5 minutes, providing a deterministic time-based value for
-    your Recovery Point Objective ([RPO](../before_you_start.md#rpo)). Even though you change the value
+    your Recovery Point Objective ([RPO](../before_you_start.md#postgresql-terminology)). Even though you change the value
     of the [`archive_timeout` setting in the PostgreSQL configuration](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT),
     our experience suggests that the default value set by the operator is
     suitable for most use cases.

docs/architecture.md

@@ -375,10 +375,10 @@ only write inside a single Kubernetes cluster, at any time.
 
 However, for business continuity objectives it is fundamental to:
 
-- reduce global **recovery point objectives** ([RPO](before_you_start.md#rpo))
+- reduce global **recovery point objectives** ([RPO](before_you_start.md#postgresql-terminology))
   by storing PostgreSQL backup data in multiple locations, regions and possibly
   using different providers (Disaster Recovery)
-- reduce global **recovery time objectives** ([RTO](before_you_start.md#rto))
+- reduce global **recovery time objectives** ([RTO](before_you_start.md#postgresql-terminology))
   by taking advantage of PostgreSQL replication beyond the primary Kubernetes
   cluster (High Availability)
 

docs/backup.md

@@ -90,7 +90,7 @@ as they can simply rely on the WAL archive to synchronize across long
 distances, extending disaster recovery goals across different regions.
 
 When you [configure a WAL archive](wal_archiving.md), CloudNativePG provides
-out-of-the-box an [RPO](before_you_start.md#rpo) ≤ 5 minutes for disaster
+out-of-the-box an [RPO](before_you_start.md#postgresql-terminology) ≤ 5 minutes for disaster
 recovery, even across regions.
 
 :::info[Important]
@@ -169,7 +169,7 @@ Consider the following factors:
 - **Database size**: For very large databases (VLDBs), **volume snapshots are
   generally preferred** as they enable faster recovery due to copy-on-write
   technology—this significantly improves your
-  [Recovery Time Objective (RTO)](before_you_start.md#rto).
+  [Recovery Time Objective (RTO)](before_you_start.md#postgresql-terminology).
 - **Data mobility**: Object store–based backups may offer greater flexibility
   for replicating or storing backups across regions or environments.
 - **Operational familiarity**: Choose the method that aligns best with your
@@ -247,7 +247,7 @@ since seconds are not supported.
 
 :::tip[Hint]
     The frequency of your backups directly impacts your **Recovery Time Objective**
-    ([RTO](before_you_start.md#rto)).
+    ([RTO](before_you_start.md#postgresql-terminology)).
 :::
 
 To optimize your disaster recovery strategy based on continuous backup:

docs/connection_pooling.md

@@ -458,7 +458,7 @@ Go runtime (with the prefix `go_*`).
 
 :::info
     You can inspect the exported metrics on a pod running PgBouncer. For instructions, see
-    [How to inspect the exported metrics](monitoring.md/#how-to-inspect-the-exported-metrics).
+    [How to inspect the exported metrics](monitoring.md#how-to-inspect-the-exported-metrics).
     Make sure that you use the correct IP and the `9127` port.
 :::
 
@@ -731,4 +731,4 @@ is to explicitly list the options that can be configured by users.
     use cases. It leaves room for the future implementation of a separate
     operator for PgBouncer to complete the gamma with more advanced and customized
     scenarios.
-:::
+:::

docs/failover.md

@@ -55,8 +55,8 @@ During the time the failing primary is being shut down:
 
 ## RTO and RPO impact
 
-Failover may result in the service being impacted ([RTO](before_you_start.md#rto))
-and/or data being lost ([RPO](before_you_start.md#rpo)):
+Failover may result in the service being impacted ([RTO](before_you_start.md#postgresql-terminology))
+and/or data being lost ([RPO](before_you_start.md#postgresql-terminology)):
 
 1. During the time when the primary has started to fail, and before the controller
    starts failover procedures, queries in transit, WAL writes, checkpoints and

docs/faq.md

@@ -459,7 +459,7 @@ single cluster, namely:
 - storage: use dedicated storage for each worker node running Postgres
 
 Use at least one standby, preferably at least two, so that you can configure
-synchronous replication in the cluster, introducing [RPO](before_you_start.md#rpo)=0
+synchronous replication in the cluster, introducing [RPO](before_you_start.md#postgresql-terminology)=0
 for high availability.
 
 If you do not have availability zones - normally the case of on-premise

docs/imagevolume_extensions.md

@@ -19,7 +19,7 @@ volume inside a running pod at a known filesystem path.
 If the extension requires one or more shared libraries to be pre-loaded at server
 start, you can add them via the [`shared_preload_libraries` option](postgresql_conf.md#shared-preload-libraries).
 Also, if your extension requires being created at the database level through
-the `CREATE EXTENSION` command, you can use the [`Database` resource’s declarative extension management](declarative_database_management.md/#managing-extensions-in-a-database)
+the `CREATE EXTENSION` command, you can use the [`Database` resource’s declarative extension management](declarative_database_management.md#managing-extensions-in-a-database)
 to ensure consistent, automated extension setup within your PostgreSQL databases.
 
 ## Benefits
@@ -161,7 +161,7 @@ Once mounted, CloudNativePG will automatically configure PostgreSQL by appending
 This ensures that the PostgreSQL container is ready to serve the `foo`
 extension when requested by a database, as described in the next section. The
 `CREATE EXTENSION foo` command, triggered automatically during the
-[reconciliation of the `Database` resource](declarative_database_management.md/#managing-extensions-in-a-database),
+[reconciliation of the `Database` resource](declarative_database_management.md#managing-extensions-in-a-database),
 will work without additional configuration, as PostgreSQL will locate:
 
 - the extension control file at `/extensions/foo/share/extension/foo.control`

docs/instance_manager.md

@@ -368,7 +368,7 @@ seconds.
 
 :::info[Important]
     In order to avoid any data loss in the Postgres cluster, which impacts
-    the database [RPO](before_you_start.md#rpo), don't delete the Pod where
+    the database [RPO](before_you_start.md#postgresql-terminology), don't delete the Pod where
     the primary instance is running. In this case, perform a switchover to
     another instance first.
 :::
@@ -386,8 +386,8 @@ the  time given to the former primary to shut down gracefully and archive all
 the WAL files. By default it is set to `3600` (1 hour).
 
 :::warning
-    The `.spec.switchoverDelay` option affects the [RPO](before_you_start.md#rpo)
-    and [RTO](before_you_start.md#rto) of your PostgreSQL database. Setting it to
+    The `.spec.switchoverDelay` option affects the [RPO](before_you_start.md#postgresql-terminology)
+    and [RTO](before_you_start.md#postgresql-terminology) of your PostgreSQL database. Setting it to
     a low value, might favor RTO over RPO but lead to data loss at cluster level
     and/or backup level. On the contrary, setting it to a high value, might remove
     the risk of data loss while leaving the cluster without an active primary for a

docs/kubectl-plugin.md

@@ -1061,7 +1061,7 @@ to request an online/hot backup or an offline/cold one: additionally, you can
 also tune online backups by explicitly setting the `--immediate-checkpoint` and
 `--wait-for-archive` options.
 
-The ["Backup" section](./backup.md#backup) contains more information about
+The ["Backup" section](./backup.md) contains more information about
 the configuration settings.
 
 ### Launching psql

docs/operator_capability_levels.md

@@ -358,7 +358,7 @@ continuity and scalability.
 
 *Disaster recovery* is a business continuity component that requires
 that both backup and recovery of a database work correctly. While as a
-starting point, the goal is to achieve [RPO](before_you_start.md#rpo) < 5
+starting point, the goal is to achieve [RPO](before_you_start.md#postgresql-terminology) < 5
 minutes, the long-term goal is to implement RPO=0 backup solutions. *High
 availability* is the other important component of business continuity. Through
 PostgreSQL native physical replication and hot standby replicas, it allows the
@@ -425,7 +425,7 @@ Both volume snapshots and CNPG-I-based backups support:
 ### Backups from a standby
 
 The operator supports offloading base backups onto a standby without impacting
-the [RPO](before_you_start.md#rpo) of the database. This allows resources to
+the [RPO](before_you_start.md#postgresql-terminology) of the database. This allows resources to
 be preserved on the primary, in particular I/O, for standard database
 operations.
 
@@ -486,7 +486,7 @@ switchover across data centers remains necessary.)
 
 Additionally, the flexibility extends to creating delayed replica clusters
 intentionally lagging behind the primary cluster. This intentional lag aims to
-minimize the Recovery Time Objective ([RTO](before_you_start.md#rto)) in the
+minimize the Recovery Time Objective ([RTO](before_you_start.md#postgresql-terminology)) in the
 event of unintended errors, such as incorrect `DELETE` or `UPDATE` SQL operations.
 
 ### Distributed Database Topologies