From 8f27f3e7db0c10fa7528d28155153445b4e83c2b Mon Sep 17 00:00:00 2001
From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com>
Date: Wed, 1 Apr 2026 12:38:39 +0530
Subject: [PATCH 1/8] 2.14.0 Release Branch

---
 docs/_templates/pdf_cover_page.tpl | 4 ++--
 mkdocs-base.yml                    | 3 ++-
 variables.yml                      | 5 +++--
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/docs/_templates/pdf_cover_page.tpl b/docs/_templates/pdf_cover_page.tpl
index 218b5f97..fa3fd03f 100644
--- a/docs/_templates/pdf_cover_page.tpl
+++ b/docs/_templates/pdf_cover_page.tpl
@@ -3,8 +3,8 @@
 <p>
 <img src="_images/Percona_Logo_Color.png" />
 </p>
-<h1>Backup for MongoDB 2.13.0</h1>
+<h1>Backup for MongoDB 2.14.0</h1>
 {% if config.site_description %}
 <h1>{{ config.site_description }}</h1>
 {% endif %} 
-<h2>2.13.0 (March 3, 2026)</h2>
\ No newline at end of file
+<h2>2.14.0 (Aril 29, 2026)</h2>
\ No newline at end of file
diff --git a/mkdocs-base.yml b/mkdocs-base.yml
index 55f06498..bb047829 100644
--- a/mkdocs-base.yml
+++ b/mkdocs-base.yml
@@ -284,7 +284,8 @@ nav:
   - Release notes:
       - release-notes.md
       - PBM 2.x:
-        - "{{pbm.full_name}} 2.13.0 ({{date.2_13_0}})": release-notes/2.13.0.md
+        - "{{pbm.full_name}} 2.14.0 ({{date.2_14_0}})": release-notes/2.14.0.md
+        - release-notes/2.13.0.md
         - release-notes/2.12.0.md
         - release-notes/2.11.0.md
         - release-notes/2.10.0.md
diff --git a/variables.yml b/variables.yml
index 30aeb165..bbb63ab1 100644
--- a/variables.yml
+++ b/variables.yml
@@ -1,13 +1,14 @@
 # PBM Variables set for HTML output
 # See also mkdocs.yml plugins.with-pdf.cover_subtitle and output_path
 
-release: '2.13.0'
-version: '2.13'
+release: '2.14.0'
+version: '2.14'
 year: '2026'
 
 pbm:
   full_name: 'Percona Backup for MongoDB'
 date:
+  2_14_0: 2026-04-29
   2_13_0: 2026-03-03
   2_12_0: 2025-11-04
   2_11_0: 2025-09-25

From 1c482775ee9aafafc7504a3640bb09b44a1314b2 Mon Sep 17 00:00:00 2001
From: Rasika Chivate <95711051+rasika-chivate@users.noreply.github.com>
Date: Fri, 24 Apr 2026 18:08:14 +0530
Subject: [PATCH 2/8] PBM-1730 Abort restore when balancer stop fails (#361)

---
 .gitignore                        |  2 +-
 docs/reference/restore-options.md | 33 ++++++++++++++++++++++++++++++-
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 3f55cad0..4da6fc20 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,7 +4,7 @@
 build
 source/ext/__pycache__
 .vscode/
-
+venv/
 
 # Local Netlify folder
 .netlify
diff --git a/docs/reference/restore-options.md b/docs/reference/restore-options.md
index 5682e0be..6747acbe 100644
--- a/docs/reference/restore-options.md
+++ b/docs/reference/restore-options.md
@@ -46,7 +46,7 @@ The number of workers that request data chunks from the storage during the resto
 ### restore.maxDownloadBufferMb
 
 *Type*: int <br>
- 
+*Default*: `numDownloadWorkers * downloadChunkMb * 16` MB when unspecified or set to `0`
 
 The maximum size of the in-memory buffer that is used to download files from the S3 storage. When unspecified or set to 0, the size cannot exceed the value calculated as `numDownloadWorkers * downloadChunkMb * 16` MB. By default, the number of CPU cores * 32 * 16 MB.
 
@@ -69,3 +69,34 @@ The custom path to `mongod` binaries. When undefined, Percona Backup for MongoDB
 *Type*: array of strings
 
 The list of custom paths to `mongod` binaries on every node. Percona Backup for MongoDB uses the values to start the temporary instances required during physical restore. After a physical restore the database is not started automatically.
+
+### restore.timeouts.balancerStop
+
+*Type*: int <br>
+*Default*: 0 (unlimited)
+
+Defines the maximum time (in seconds) that PBM waits for the balancer to stop before starting a logical restore. If set to `0` or not set (default), PBM waits indefinitely until the balancer stops.
+
+PBM stops the balancer to ensure data consistency during restore operations in sharded clusters. The timeout starts when the stop request is issued. If the balancer remains active after the timeout, the restore is aborted.
+
+```yaml
+restore:
+  timeouts:
+    balancerStop: 0
+```
+
+??? example "Example"
+    ```yaml
+    restore:
+      timeouts:
+        balancerStop: 60
+    ```
+
+    In this example, PBM waits up to 60 seconds for the balancer to stop. If the balancer is still running after this period, the restore fails.
+
+
+This is useful when you want to:
+
+- Prevent restore operations from waiting indefinitely
+- Enforce time limits in automated workflows
+- Fail fast if the balancer cannot be stopped
\ No newline at end of file

From f3650b9b94acf29112fb7ac39c1bfd77068c9a68 Mon Sep 17 00:00:00 2001
From: Rasika Chivate <95711051+rasika-chivate@users.noreply.github.com>
Date: Tue, 28 Apr 2026 21:13:21 +0530
Subject: [PATCH 3/8] Release-notes-2.14.0 (#354)

* Release-notes-2.14.0

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* added admo

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* PBM-1167

* PBM-1167

* PBM-1638

* PBM-1639

* PBM-1653

* PBM-1703

* Update 2.14.0.md

* PBM-1345

* PBM-1472

* Update 2.14.0.md

* PBM-1599

* PBM-1609

* PBM-1629

* Update 2.14.0.md

* Update 2.14.0.md

* Update 2.14.0.md

* updated the example

* Update docs/release-notes/2.14.0.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/release-notes/2.14.0.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/release-notes/2.14.0.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/release-notes/2.14.0.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/release-notes/2.14.0.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/release-notes/2.14.0.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/release-notes/2.14.0.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update release-notes.md

* Update 2.14.0.md

* Update 2.14.0.md

* removed PBM-1480

* Update 2.14.0.md

* Update 2.14.0.md

* PBM-1598 Add timeout to admin command _configsvrBalancerStop

* Update backup-options.md

* Update docs/reference/backup-options.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/reference/backup-options.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/reference/backup-options.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update docs/reference/backup-options.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update backup-options.md

* format fix

* Update backup-options.md

* Update backup-options.md

* PBM-1598: Document what value 0 means for backup.timeouts.balancerStop

Agent-Logs-Url: https://github.com/percona/pbm-docs/sessions/9caa47d3-2b9b-413b-a687-bd9155dce31f

Co-authored-by: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com>

* Update docs/reference/backup-options.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update backup-options.md

* Update docs/reference/backup-options.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update pitr-physical.md

* Revert "Update pitr-physical.md"

This reverts commit dbb5e5980c76cbbf520ebdd84894c4ef56be366e.

* PBM-1167

* Reconcile PITR oplog behavior: update sharded-cluster bullet to reflect all-nodes behavior

Agent-Logs-Url: https://github.com/percona/pbm-docs/sessions/5cf9e396-42d9-49db-8902-91496dd3e247

Co-authored-by: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com>

* Update pitr-physical.md

* Update docs/usage/pitr-physical.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Update backup.timeouts.balancerStop description

Clarified the behavior of the balancer timeout setting, specifying that a value of 0 allows for indefinite waiting.

* Remove balancerStop timeout example from documentation

Removed YAML example for balancerStop timeout in backup options.

* remove PBM-1720 from rel notes

* Add PBM-1721

* PBM-1721 Enhance known limitations documentation

Added section on physical backups and restores, detailing limitations for MongoDB instances without authentication. Updated headings for clarity regarding MongoDB version requirements.

* Update release notes for version 2.14.0

Clarified the behavior of physical restores when encountering 'Unauthorized' errors and improved the description of the issue in the release notes.

* Enhance interactive confirmation for multiple commands

Updated the interactive confirmation section to include additional commands and improved clarity on the confirmation process.

* updated features list and a description of confirmation prompt

* Fix ConcurrentStreamParts references and the description of optimized backup uploads

Updated the release notes for version 2.14.0 to clarify the performance improvements for MinIO uploads and added details about the `ConcurrentStreamParts` option.

* Update default value description for balancerStop

Clarified default value description for balancerStop timeout.

* Fix formatting of PBM CLI command options

* PBM-1600 describe confirmation prompt for restore operations

* PBM-1600 add an admonition that there's a confirmation prompt before running a restore command

Co-authored-by: Copilot <copilot@github.com>

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* additional fixes in formating

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* PBM-1600 fix the pbm restore command in multi-storage page and clarify cleanup confirmation

Co-authored-by: Copilot <copilot@github.com>

* PBM-1638 added kmip key identifier to backup metadata (#365)

* PBM-1638 extend the pbm describe-backup command

Co-authored-by: Copilot <copilot@github.com>

* PBM-1638 - add vault to the sample output

Co-authored-by: Copilot <copilot@github.com>

* PBM-1638 fix wrong statement that encryption key is stored, and fix 'e.g.'

Co-authored-by: Copilot <copilot@github.com>

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Fix formatting

* fix table formatting

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* PBM-1638 improve docs

Co-authored-by: Copilot <copilot@github.com>

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* PBM-1638 minor stylistic improvements

---------

Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Radoslaw Szulgo <radoslaw.szulgo@percona.com>

* Fix description of highlights in 2.14.0

Co-authored-by: Copilot <copilot@github.com>

* Update pitr-selective.md

* Fix formatting of limitation on physical restores

* Update physical.md

* Fix formatting for pre-requisites in pitr-selective.md

* Fix formatting and update admonition in documentation

* Duplicate notes in restore-selective.md

* Fix formatting for "Notes" section

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Radoslaw Szulgo <radoslaw.szulgo@percona.com>
Co-authored-by: Copilot <copilot@github.com>
---
 docs/features/known-limitations.md           |   7 +-
 docs/features/multi-storage.md               |   4 +-
 docs/features/physical.md                    |  32 +--
 docs/features/restore-remapping.md           |   5 +-
 docs/reference/backup-options.md             |  43 +++-
 docs/reference/pbm-commands.md               | 217 ++++++++++++++-----
 docs/release-notes.md                        |   1 +
 docs/release-notes/2.14.0.md                 |  82 +++++++
 docs/usage/delete-backup.md                  |  32 ++-
 docs/usage/pitr-physical.md                  |  19 +-
 docs/usage/pitr-selective.md                 |  26 ++-
 docs/usage/pitr-tutorial.md                  |   3 +
 docs/usage/restore-external-agent-restart.md |   9 +-
 docs/usage/restore-external.md               |   6 +
 docs/usage/restore-incremental.md            |   3 +
 docs/usage/restore-physical.md               |   5 +-
 docs/usage/restore-selective.md              |  14 +-
 docs/usage/restore.md                        |   9 +
 18 files changed, 388 insertions(+), 129 deletions(-)
 create mode 100644 docs/release-notes/2.14.0.md

diff --git a/docs/features/known-limitations.md b/docs/features/known-limitations.md
index bf029642..ba603442 100644
--- a/docs/features/known-limitations.md
+++ b/docs/features/known-limitations.md
@@ -14,15 +14,18 @@ PBM supports various backup and restore types. Some of them have known limitatio
 5. System collections in ``admin``, ``config``, and ``local`` databases cannot be backed up and restored selectively. You must make a full backup and restore to include them.
 6. Selective point-in-time recovery is not supported for sharded clusters.
 
+## Physical backups and restores
+Physical restores are not supported for MongoDB instances running without authentication if the PBM agent connects via a non-localhost interface (such as a container hostname or external IP). Because MongoDB restricts the shutdown command to the localhost interface in non-authenticated environments, PBM will be unable to stop the node to perform the restore. To avoid this limitation, ensure that the PBM_MONGODB_URI uses a localhost connection or enable authentication for your MongoDB deployment.
+
 ## Oplog slicing for point-in-time recovery
 
 Oplog slicing is an integral part of the point-in-time recovery routine that enables you to restore from a backup up to a specific moment. Read more about [point-in-time recovery](point-in-time-recovery.md).
 
-**For MongoDB 8.0 and higher versions**
+**MongoDB 8.0 and higher versions**
 
 If you [unshard a collection :octicons-link-external-16:](https://www.mongodb.com/docs/v8.0/reference/command/unshardCollection/), make a fresh backup and re-enable point-in-time recovery oplog slicing to prevent data inconsistency and restore failure.
 
-**For in MongoDB 5.0 and higher versions**
+**MongoDB 5.0 and higher versions**
 
 If you [reshard :octicons-link-external-16:](https://www.mongodb.com/docs/manual/core/sharding-reshard-a-collection/) a collection, make a fresh backup and re-enable point-in-time recovery oplog slicing to prevent data inconsistency and restore failure.
 
diff --git a/docs/features/multi-storage.md b/docs/features/multi-storage.md
index 29e1b364..71b4c0ff 100644
--- a/docs/features/multi-storage.md
+++ b/docs/features/multi-storage.md
@@ -163,9 +163,11 @@ Before you start, make sure that `pbm-agents` have the read permissions to backu
 2. To make a point-in-time restore, you must explicitly pass the backup name for the `pbm restore` command:
 
     ```bash
-    pbm-restore --time=<timestamp> --base-snapshot <backup-name>
+    pbm restore --time=<timestamp> --base-snapshot <backup-name>
     ```
 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
 3. After the restore is complete, do the required post-restore steps depending on the restore type.
 4. Make a fresh backup to serve as the new base for future restores. 
 
diff --git a/docs/features/physical.md b/docs/features/physical.md
index 5eeff7b5..d954b875 100644
--- a/docs/features/physical.md
+++ b/docs/features/physical.md
@@ -30,7 +30,7 @@ During physical backups and restores, ``pbm-agents`` don't export / import data
 
 ## Availability and system requirements
 
-* Percona Server for MongoDB starting from versions 4.2.15-16, 4.4.6-8, 5.0 and higher. 
+* For current Percona Backup for MongoDB versions, physical backups require Percona Server for MongoDB 7.0 or newer. For support on older Percona Server for MongoDB versions, see the compatibility matrix in [Supported versions](../details/versions.md).
 * WiredTiger storage engine, since physical backups heavily rely on the WiredTiger [`$backupCursor` :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/backup-cursor.html) functionality.
 
 !!! warning 
@@ -84,35 +84,22 @@ The physical restore in mixed deployments has no restrictions except the version
 
 !!! admonition "Version added: [2.0.0](../release-notes/2.0.0.md)"
 
-You can back up and restore data which is encrypted at rest. Thereby you ensure data safety and can also comply with security requirements such as GDPR, HIPAA, PCI DSS, or PHI.
+You can back up and restore data that is encrypted at rest. Thereby, you ensure data security and also comply with security requirements such as GDPR, HIPAA, PCI DSS, and PHI. If you use an external KMS such as HashiCorp Vault, OpenBao, or KMIP, you need the master encryption key identifier to restore the data. For security reasons, the encryption key is not stored or shown as part of the backup.
 
-During a backup, Percona Backup for MongoDB stores the encryption settings in the backup metadata. You can verify them using the [`pbm describe-backup`](../reference/pbm-commands.md#pbm-describe-backup) command. Note that the encryption key is not stored nor shown as part of the backup.
+During a backup, Percona Backup for MongoDB stores the encryption settings in the backup metadata. You can verify them using the [`pbm describe-backup`](../reference/pbm-commands.md#pbm-describe-backup) command.
 
-!!! important
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Additionally, PBM stores the encryption key identifier in the backup metadata. You need Percona Server for MongoDB (PSMDB) 7.0.22-12 and 8.0.12-4 or higher to use this feature. If you're using older versions of PSMDB or PBM, you have to store the identifier externally and pass it in the restore configuration.
 
-    Make sure that you know which master encryption key was used and keep it safe, as this key is required for the restore.
+To restore the encrypted data from the backup, you can just configure the same data-at-rest encryption settings on all nodes of your destination cluster or replica set to match the settings of the original cluster where you made the backup.
 
-!!! note
-
-    Starting with [Percona Server for MongoDB version 4.4.19-19 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/4.4/release_notes/4.4.19-19.html), [5.0.15-13 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/5.0/release_notes/5.0.15-13.html), [6.0.5-4 :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/6.0/release_notes/6.0.5-4.html) and higher, the master key rotation for data-at-rest encrypted with HashiCorp Vault has been improved to use the same secret key path on every server in your entire deployment. For the restore with earlier versions of Percona Server for MongoDB and PBM 2.0.5 and earlier, see the [Restore for Percona Server for MongoDB **before** 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault](#restore-for-percona-server-for-mongodb-before-4419-19-5015-13-605-4-using-hashicorpvault) section.
-
-To restore the encrypted data from the backup, configure the same data-at-rest encryption settings on all nodes of your destination cluster or replica set to match the settings of the original cluster where you made the backup.
-
-During the restore, Percona Backup for MongoDB restores the data to all nodes using the same master key. We recommend to rotate the master encryption key afterwards for extra security. 
+During the restore, Percona Backup for MongoDB restores the data to all nodes using the same master key. We recommend rotating the master encryption key afterward for extra security. 
 
 To learn more about master key rotation, refer to the following documentation:
 
 * [Master key rotation in HashiCorp Vault server :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/6.0/vault.html#key-rotation)
 * [KMIP master key rotation :octicons-link-external-16:](https://www.mongodb.com/docs/manual/tutorial/rotate-encryption-key/#kmip-master-key-rotation)
 
-### Restore for Percona Server for MongoDB **before** 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault
-
-In Percona Server for MongoDB version **before** 4.4.19-19, 5.0.15-13, 6.0.5-4 with Vault server used for data-at-rest encryption, the master key rotation with the same key used for 2+ nodes is not supported. If you run these versions of Percona Server for MongoDB and PBM before 2.1.0, consider using the scenario where PBM restores the data on one node of every replica set. The remaining nodes receive the data during the initial sync. 
-
-Configure data-at-rest encryption on one node of every shard in your destination cluster or a replica set.
-
-During the restore, Percona Backup for MongoDB restores the data on the node where the encryption key matches the one with which the backed up data was encrypted. The other nodes are not restored, so the restore has the "partlyDone" status. You can start this node and initiate the replica set. The remaining nodes receive the data as the result of the initial sync from the restored node.  
-
 ## Physical restores with a fallback directory
 
 !!! admonition "Version added: [2.10.0](../release-notes/2.10.0.md)"
@@ -191,7 +178,10 @@ A restore can succeed on most nodes, but it might fail on a few, resulting in a
     ```bash
     pbm restore --time <time> --fallback-enabled=true --allow-partly-done=true
     ```
-       
+
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
 If you allow partial restores (default value), PBM finalizes the restore. Once the cluster is up and running, the failed node receives the necessary data from other members through an initial sync. 
 
 If you deny partial restores, PBM treats a cluster as unhealthy and falls it back to the original state. In this case you must have the `restore.fallbackEnabled` option set to `true` or run the `pbm restore` command with the `--fallback-enabled` flag. Otherwise, a restore won't start.
diff --git a/docs/features/restore-remapping.md b/docs/features/restore-remapping.md
index bc09fbf9..717750a5 100644
--- a/docs/features/restore-remapping.md
+++ b/docs/features/restore-remapping.md
@@ -38,8 +38,11 @@ Configure the replica set name mapping:
     pbm restore <timestamp> --replset-remapping="rsX=rsA,rsY=rsB"
     ```
 
-    The `--replset-remapping` flag is available for the following commands: `pbm restore`, `pbm list`, `pbm status`, `pbm oplog-replay`. 
+    The `--replset-remapping` flag is available for the following commands: `pbm restore`, `pbm list`, `pbm status`, `pbm oplog-replay`.
 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+ 
 !!! note 
 
     Follow the [post-restore steps](../usage/restore.md#post-restore-steps) on the new environment after the restore is complete.
diff --git a/docs/reference/backup-options.md b/docs/reference/backup-options.md
index 543fb639..5f5c052e 100644
--- a/docs/reference/backup-options.md
+++ b/docs/reference/backup-options.md
@@ -15,7 +15,7 @@ backup:
   numParallelCollections: <int>
 ```
 
-### priority
+## priority
 
 *Type*: array of strings
 
@@ -27,7 +27,7 @@ If not set, the replica set nodes have the default priority as follows:
 * secondary nodes - 1.0
 * primary node - 0.5
 
-### backup.compression
+## backup.compression
 
 *Type*: string <br>
 *Default*: s2
@@ -39,7 +39,7 @@ When `none` is specified, backups are made without compression.
 Supported values: `gzip`, `snappy`, `lz4`, `s2`, `pgzip`, `zstd`. Default: `s2`.
 
 <!-- backup-compression-level: -->
-### backup.compressionLevel
+## backup.compressionLevel
 
 *Type*: int
 
@@ -56,9 +56,40 @@ The following table shows available compression levels per compression method:
 
 Note that the greater value you specify, the more time and computing resources it will take to compress the data.
 
+
+## Backup timeouts
+
+Timeout options control how long Percona Backup for MongoDB (PBM) waits for specific conditions during backup operations.
+
+### backup.timeouts.balancerStop
+
+*Type*: int <br>
+*Default*: 0 (unlimited)
+
+Defines the maximum time (in seconds) that PBM waits for the balancer to stop before starting a backup. If set to **0**, PBM waits indefinitely for the balancer to stop.
+
+PBM stops the balancer before starting a backup to ensure consistency in sharded clusters. If the balancer does not stop within the specified timeout, the backup operation fails.
+
+??? example "Example"
+
+    ```yaml
+    backup:
+      timeouts:
+        balancerStop: 60
+    ```
+
+    In this example, PBM waits up to 60 seconds for the balancer to stop. If the balancer is still running after this period, the backup fails.
+
+
+This is useful when you want to:
+
+- Avoid indefinite waits during backup operations
+- Enforce stricter operational time limits in automated environments
+- Detect and fail fast if the balancer cannot be stopped
+
 ### backup.timeouts.startingStatus
 
-*Type*: unit32 <br>
+*Type*: uint32 <br>
 *Default*: 33
 
 The wait time (in seconds) for PBM to start backups. This timeout controls how long PBM waits for the backup to transition from initial state to running status.
@@ -76,13 +107,13 @@ The wait time (in seconds) for PBM to start backups. This timeout controls how l
 
   The 0 (zero) value resets the timeout to the default 33 seconds.
 
-### backup.oplogSpanMin
+## backup.oplogSpanMin
 
 *Type*: float64 <br>
 
 The duration (in minutes) of oplog slices saved with the logical backup snapshot. By default, the duration of backup oplog slices equals to the value defined for the [`pitr.oplogSpanMin`](pitr-options.md#pitroplogspanmin) option (default - 10 minutes). You can reduce the duration in heavy-loaded environments. Note that setting the duration to shorter periods may increase the overall backup execution time. 
 
-### backup.numParallelCollections
+## backup.numParallelCollections
 
 *Type*: int <br>
 *Default*: number of CPU cores / 2
diff --git a/docs/reference/pbm-commands.md b/docs/reference/pbm-commands.md
index a7e22f5d..f1c54b23 100644
--- a/docs/reference/pbm-commands.md
+++ b/docs/reference/pbm-commands.md
@@ -27,7 +27,7 @@ The command accepts the following flags:
 | `--num-parallel-collections`| Sets the number of collections to process in parallel during a specific logical backup. When undefined, `pbm-agent` processes the number of parallel collections defined for the `backup.numParallelCollections` configuration parameter. If that is undefined, the default number of collections to process in parallel is the half of the number of logical CPUs. Available starting with version 2.7.0.|
 | `-o`, `--out=text`    | Shows the output format as either plain text or a JSON object. Supported values: `text`, `json` |
 | `--wait`       | Wait for the backup to finish. The flag blocks the shell session.|
-| `--wait-time`  | The time to wait for PBM to report the status of the command execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
+| `--wait-time`  | The time to wait for PBM to report the status of the command execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
 | `-l`, `--list-files` | For external backups only. Shows the list of files per node to copy.|
 | `--ns="database.collection"`| Makes a logical backup of the specified namespace - the database and collection(s). To back up all collections in the database, specify the value in the `--ns="database.*"` format. Starting with version 2.8.0, you can pass multiple namespaces as a comma-separated list for the backup. The format is `ns=db1.*,db2.coll2,db3.coll1,db3.collX` .|
 
@@ -82,10 +82,10 @@ The command accepts the following flags:
 
 | Flag                     | Description               |
 | ------------------------ | ------------------------- |
-| `--older-than=TIMESTAMP` | Deletes backups older than date / time specified in the format:<br> - `%Y-%M-%DT%H:%M:%S` (e.g. 2020-04-20T13:13:20), <br> - `%Y-%M-%D` (e.g. 2020-04-20), <br> - `XXd` (e.g. 30d). Only days are supported|
+| `--older-than=TIMESTAMP` | Deletes backups older than date / time specified in the format:<br> - `%Y-%M-%DT%H:%M:%S` (for example 2020-04-20T13:13:20), <br> - `%Y-%M-%D` (for example 2020-04-20), <br> - `XXd` (for example 30d). Only days are supported|
 | `--profile=PROFILE_NAME` | Specifies the configuration profile for the storage to clean up. If not specified, cleanup runs on the main storage. Available starting with version 2.13.0|
 | `-w`, `--wait`           | Wait for the cleanup to finish. The flag blocks the shell session|
-| `--wait-time`  | The time to wait for PBM to report the status of the command execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
+| `--wait-time`  | The time to wait for PBM to report the status of the command execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
 | `-y`, `--yes`            | Cleans up the data storage without asking for a user's confirmation|
 | `--dry-run`              | Checks for the old data to be deleted without deleting it. Allows to verify what data to delete| 
 
@@ -110,7 +110,7 @@ The command accepts the following flags:
 | `--set=SET`        | Set a new config option value. Specify the option in the `<key.name=value>` format.                                    |
 | `-o`, `--out=text` | Shows the output format as either plain text or a JSON object. Supported values: text, json                      |
 | `-w`, `--wait`     | Wait for resync of the backup list with the storage to finish. You can only use this flag together with the `--force-resync` flag.|
-| `--wait-time`  | The time to wait for PBM to report the status of the resync execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
+| `--wait-time`  | The time to wait for PBM to report the status of the resync execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
 | `--include-restores`| Resync the full restore metadata history from the storage. Use this flag together with the `--force-resync` flag. Note that retrieving the full restore history may affect resync performance. Available starting with version 2.10.0. |
 
 
@@ -167,7 +167,7 @@ The command accepts the following flags:
 
 | Flag                     | Description             |
 | ------------------------ | ----------------------- |
-| `--older-than=TIMESTAMP` | Deletes backups older than date / time specified in the format:<br> - `%Y-%M-%DT%H:%M:%S` (e.g. 2023-04-20T13:13:20) or <br> - `%Y-%M-%D` (e.g. 2023-04-20)|
+| `--older-than=TIMESTAMP` | Deletes backups older than date / time specified in the format:<br> - `%Y-%M-%DT%H:%M:%S` (for example 2023-04-20T13:13:20) or <br> - `%Y-%M-%D` (for example 2023-04-20)|
 | `--profile=PROFILE_NAME` | Specifies the configuration profile for the storage from which to delete backups. If not specified, deletion runs on the main storage. Available starting with version 2.13.0|
 | `--type=TYPE`           | Deletes backups of the specified type. Must be used together with the `-older-than` flag. Available starting with version 2.4.0|
 | `--force`                | Forcibly deletes backups without asking for user's confirmation. Deprecated. Use the `--yes` flag instead. |
@@ -189,44 +189,29 @@ The command accepts the following flags:
 | Flag                     | Description               |
 | ------------------------ | ------------------------- |
 | `-a`, `--all`            | Deletes all oplog slices. Deprecated. Use the `--older-than flag instead`  |
-| `--older-than=TIMESTAMP` | Deletes oplog slices older than date / time specified in the format: <br> - `%Y-%M-%DT%H:%M:%S` (e.g. 2020-04-20T13:13:20) or <br> - `%Y-%M-%D` (e.g. 2020-04-20) <br><br> When you specify a timestamp, Percona Backup for MongoDB rounds it down to align with the completion time of the closest backup snapshot and deletes oplog slices that precede this time. Thus, extra slices remain. This is done to ensure oplog continuity. To illustrate, the PITR time range is `2021-08-11T11:16:21 - 2021-08-12T08:55:25` and backup snapshots are: <br><br> `2021-08-12T08:49:46Z 13.49MB [restore_to_time: 2021-08-12T08:50:06]` <br> `2021-08-11T11:36:17Z 7.37MB [restore_to_time: 2021-08-11T11:36:38]`<br> <br> Say you specify the timestamp `2021-08-11T19:16:21`. The closest backup is `2021-08-11T11:36:17Z 7.37KB [restore_to_time: 2021-08-11T11:36:38]`. PBM rounds down the timestamp to `2021-08-11T11:36:38` and deletes all slices that precede this time. As a result, your PITR time range is `2021-08-11T11:36:38 - 2021-08-12T09:00:25`. <br><br> **NOTE**: Percona Backup for MongoDB doesn’t delete the oplog slices that follow the most recent backup. This is done to ensure point in time recovery from that backup snapshot. For example, if the snapshot is `2021-07-20T07:05:23Z [restore_to_time: 2021-07-21T07:05:44]` and you specify the timestamp `2021-07-20T07:05:45`, Percona Backup for MongoDB deletes only slices that were made before `2021-07-20T07:05:23Z`.|
+| `--older-than=TIMESTAMP` | Deletes oplog slices older than date / time specified in the format: <br> - `%Y-%M-%DT%H:%M:%S` (for example 2020-04-20T13:13:20) or <br> - `%Y-%M-%D` (for example 2020-04-20) <br><br> When you specify a timestamp, Percona Backup for MongoDB rounds it down to align with the completion time of the closest backup snapshot and deletes oplog slices that precede this time. Thus, extra slices remain. This is done to ensure oplog continuity. To illustrate, the PITR time range is `2021-08-11T11:16:21 - 2021-08-12T08:55:25` and backup snapshots are: <br><br> `2021-08-12T08:49:46Z 13.49MB [restore_to_time: 2021-08-12T08:50:06]` <br> `2021-08-11T11:36:17Z 7.37MB [restore_to_time: 2021-08-11T11:36:38]`<br> <br> Say you specify the timestamp `2021-08-11T19:16:21`. The closest backup is `2021-08-11T11:36:17Z 7.37KB [restore_to_time: 2021-08-11T11:36:38]`. PBM rounds down the timestamp to `2021-08-11T11:36:38` and deletes all slices that precede this time. As a result, your PITR time range is `2021-08-11T11:36:38 - 2021-08-12T09:00:25`. <br><br> **NOTE**: Percona Backup for MongoDB doesn’t delete the oplog slices that follow the most recent backup. This is done to ensure point in time recovery from that backup snapshot. For example, if the snapshot is `2021-07-20T07:05:23Z [restore_to_time: 2021-07-21T07:05:44]` and you specify the timestamp `2021-07-20T07:05:45`, Percona Backup for MongoDB deletes only slices that were made before `2021-07-20T07:05:23Z`.|
 | `--force`                | Forcibly deletes oplog slices without asking a user’s confirmation. Deprecated. Use the `-y`/`--yes` flag instead.  |
 | `-o`, `--out=json`       | Shows the output as either the plain text (default) or a JSON object. Supported values: `text`, `json`.   |
 | `--yes`                  | Deletes backups without asking for user's confirmation |
 | `--dry-run`              | Prints the list of oplog slices to be deleted without deleting them. You can use the flag to check what exactly will be deleted. Available starting with version 2.4.0. | 
 | `-w`, `--wait`          | Wait for the deletion operation to complete. |
-| `--wait-time`  | The time to wait for PBM to report the status of the command execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
-
+| `--wait-time`  | The time to wait for PBM to report the status of the command execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
 
 ## pbm describe-backup
 
 Provides the detailed information about a backup:
 
-- backup name
-- type
-- status
-- namespaces - what was backed up during a selective backup
-- size
-- error message for failed backup
-- last write timestamp 
-- last write time - human-readable indication of the last write 
-- last transition time - the timestamp when a backup changed its status
-- cluster information: the replica set name, the backup status on this replica set, whether it is used as a config server replica set, last write timestamp
-- replica set info: name, backup status, last write timestamp and last transition time, `mongod` security options, if encryption is configured.
-- for snapshot-based backups, provides the list of files being copied
-- for logical and selective backups, provides the list of collections included in the backup. Available with version 2.3.0.
-
 The command has the following syntax:
 
 ```bash
 pbm describe-backup [<backup-name>] [<flags>] 
 ```
 
-| Flag                  | Description                           |
-| --------------------- | ------------------------------------- |
-| `-o`, `--out=text`    | Shows the status as either plain text or a JSON object. Supported values: `text`, `json`|
-| `-l`, `--list-files`  | Shows the list of files being copied for snapshot-based backups |
-| `--with-collections`  | Shows the collections included in the backup. For logical and selective backups only. Available with version 2.3.0.
+| Flag                  | Description                                                                                                         |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `-o`, `--out=text`    | Shows the status as either plain text or a JSON object. Supported values: `text`, `json`                          |
+| `-l`, `--list-files`  | Shows the list of files being copied for snapshot-based backups                                                     |
+| `--with-collections`  | Shows the collections included in the backup. For logical and selective backups only. Available with version 2.3.0. |
 
 ### Output
 
@@ -262,7 +247,24 @@ The output document contains the following fields:
           "last_write_time": "2022-09-30T14:02:49Z",
           "last_transition_time": "2022-09-30T14:02:53Z",
           "configsvr": true,
-          "security": {}
+          "security": {
+            "enableEncryption": true,
+            "kmip": {
+              "serverName": "cosmian",
+              "port": 5696,
+              "clientCertificateFile": "/etc/pykmip/mongod.pem",
+              "serverCAFile": "/etc/pykmip/ca.crt",
+              "keyIdentifier": "cbe0a6b4-7d7a-47c3-aa40-39abfc9a6f96"
+            },
+            "vault": {
+              "serverName": "cosmian",
+              "port": 5696,
+              "tokenFile": "/etc/vault/token",
+              "secret": "secret/data/mongo",
+              "secretVersion": 5,
+              "disableTLSForTesting": false
+            }
+          }
         },
         {...},
         {...}
@@ -270,25 +272,132 @@ The output document contains the following fields:
     }
     ```
 
-| Field       | Description |
-| ----------- | ----------- |
-| `name`      | The backup name |
-| `opid`      | A unique identifier of an operation |
-| `type`      | The backup type. Supported values: logical, physical, incremental, external |
-| `last_write_ts` | The timestamp of the last write |
-| `last_transition_ts` | The timestamp when a backup changed its status |
-| `last_write_time` | The human-readable indication of the last write |
-| `last_transition_time` | The human-readable indication of the time when a backup changed its status|
-| `namespaces` | The list of namespaces included in the backup. Available for selective backup |
-| `mongodb_version` | The MongoDB version |
-| `fcv` | The feature compatibility version |
-| `pbm_version` | The Percona Backup for MongoDB version |
-| `status` | The backup status. Supported values: running, dumpDone, done, copyReady, error, canceled |
-| `size` | The backup size in bytes |
-| `size_h` | The backup size in human-readable format |
-| `error`  | The error message for a failed backup |
-| `replsets` | The list of replica sets included in the backup. Each replica set has the following fields: <br> - `name` - the replica set name <br> - `status` - the backup status on this replica set <br> - `node` - the node name and port <br> - `last_write_ts` - the timestamp of the last write <br> - `last_transition_ts` - the timestamp when a backup changed its status <br> - `last_write_time` - the human-readable indication of the last write <br> - `last_transition_time` - the human-readable indication of the time when a backup changed its status <br> - `security` - the security options of the `mongod` process <br> - `configsvr` - indicates that this is a config server replica set |
-
+<!-- This table uses HTML because it contains an unordered list in a cell. It's easier to maintain than standard Markdown table notation. -->
+
+<table>
+  <thead>
+
+    <tr>
+      <th>Field</th>
+      <th>Description</th>
+    </tr>
+
+  </thead>
+  <tbody>
+
+    <tr>
+      <td> <code>name</code> </td>
+      <td>The backup name</td>
+    </tr>
+    <tr>
+      <td> <code>opid</code> </td>
+      <td>A unique identifier of an operation</td>
+    </tr>
+    <tr>
+      <td> <code>type</code> </td>
+      <td>The backup type. Supported values: logical, physical, incremental, external</td>
+    </tr>
+    <tr>
+      <td> <code>last_write_ts</code> </td>
+      <td>The timestamp of the last write</td>
+    </tr>
+    <tr>
+      <td> <code>last_transition_ts</code> </td>
+      <td>The timestamp when a backup changed its status</td>
+    </tr>
+    <tr>
+      <td> <code>last_write_time</code> </td>
+      <td>The human-readable indication of the last write</td>
+    </tr>
+    <tr>
+      <td> <code>last_transition_time</code> </td>
+      <td>The human-readable indication of the time when a backup changed its status</td>
+    </tr>
+    <tr>
+      <td> <code>namespaces</code> </td>
+      <td>The list of namespaces included in the backup. Available for selective backup</td>
+    </tr>
+    <tr>
+      <td> <code>mongodb_version</code> </td>
+      <td>The MongoDB version</td>
+    </tr>
+    <tr>
+      <td> <code>fcv</code> </td>
+      <td>The feature compatibility version</td>
+    </tr>
+    <tr>
+      <td> <code>pbm_version</code> </td>
+      <td>The Percona Backup for MongoDB version</td>
+    </tr>
+    <tr>
+      <td> <code>status</code> </td>
+      <td>The backup status. Supported values: running, dumpDone, done, copyReady, error, canceled</td>
+    </tr>
+    <tr>
+      <td> <code>size</code> </td>
+      <td>The backup size in bytes</td>
+    </tr>
+    <tr>
+      <td> <code>size_h</code> </td>
+      <td>The backup size in human-readable format</td>
+    </tr>
+    <tr>
+      <td> <code>error</code> </td>
+      <td>The error message for a failed backup</td>
+    </tr>
+    <tr>
+      <td> <code>replsets</code> </td>
+      <td>The list of replica sets included in the backup. Each replica set has the following fields: 
+        <ul>
+          <li> <code>name</code> - the replica set name</li>
+          <li> <code>status</code> - the backup status on this replica set</li>
+          <li> <code>node</code> - the node name and port</li>
+          <li> <code>files</code> - list of backup files (only populated for snapshot-based backups)</li>
+          <li> <code>size</code> - size of the backup in bytes</li>
+          <li> <code>size_h</code> - human-readable size string (for example, "1.5 GiB")</li>
+          <li> <code>size_uncompressed</code> - uncompressed size of the backup in bytes</li>
+          <li> <code>size_uncompressed_h</code> - human-readable uncompressed size string (for example, "1.6 GiB")</li>
+          <li> <code>error</code> - the error message for failed backup</li>
+          <li> <code>last_write_ts</code> - MongoDB Timestamp-style value of the last write operation (for example, <code>1662039300,2</code>)</li>
+          <li> <code>last_transition_ts</code> - MongoDB Timestamp-style value of the last status transition (for example, <code>1662039300,2</code>)</li>
+          <li> <code>last_write_time</code> - the human-readable indication of the last write</li>
+          <li> <code>last_transition_time</code> - the human-readable indication of the time when a backup changed its status</li>
+          <li> <code>security</code> - the security options of the <code>mongod</code> process. Contains the following configuration options:
+            <ul>
+              <li> <code>enableEncryption</code> - boolean flag indicating if encryption at rest is enabled.</li>
+              <li> <code>encryptionCipherMode</code> - cipher mode used for encryption (for example, "AES256-CBC", "AES256-GCM").</li>
+              <li> <code>encryptionKeyFile</code> - path to the local key file for encryption.</li>
+              <li> <code>relaxPermChecks</code> - boolean to relax permission checks on encryption key files.</li>
+              <li> <code>vault</code> - when using HashiCorp Vault as the key management service:
+                <ul>
+                  <li> <code>serverName</code> - Vault server hostname.</li>
+                  <li> <code>port</code> - Vault server port.</li>
+                  <li> <code>tokenFile</code> - path to the file containing the Vault token.</li>
+                  <li> <code>secret</code> - Vault secret name/path.</li>
+                  <li> <code>secretVersion</code> - version number of the Vault secret. Requires Percona Server for MongoDB 7.0.22-12 and 8.0.12-4 or higher.</li>
+                  <li> <code>disableTLSForTesting</code> - flag to disable TLS (testing only).</li>
+                </ul>
+              </li>
+              <li> <code>kmip</code> - when using Key Management Interoperability Protocol (KMIP) as the key management service:
+                <ul>
+                  <li> <code>serverName</code> - KMIP server hostname.</li>
+                  <li> <code>port</code> - KMIP server port.</li>
+                  <li> <code>clientCertificateFile</code> - client certificate for KMIP authentication.</li>
+                  <li> <code>serverCAFile</code> - CA certificate for server verification.</li>
+                  <li> <code>keyIdentifier</code> - unique identifier for the encryption key. Requires Percona Server for MongoDB 7.0.22-12 and 8.0.12-4 or higher.</li>
+                </ul>
+              </li>
+            </ul>
+          </li>
+          <li> <code>configsvr</code> - indicates that this is a config server replica set</li>
+          <li> <code>configshard</code> - indicates that this is a config shard replica set</li>
+          <li> <code>collections</code> - the list of collections included in the backup for logical and selective backups. This field is populated only when <code>--with-collections</code> is used. Available since 2.3.0.</li>
+        </ul>
+      </td>
+    </tr>
+
+  </tbody>
+</table>
 
 ## pbm describe-restore
 
@@ -611,7 +720,7 @@ The command accepts the following flags:
 | `-n`, `--node=NODE`     | Shows logs for a specified node or a replica set.<br> Specify the node in the format `replset[/host:port]` |
 | `-f`, `--follow`        | Follow log output. Allow to view the logs dynamically |
 | `-s`, `--severity=I`    | Shows logs filtered by severity level.<br> Supported levels are (from low to high): D - Debug, I - Info (default), W - Warning, E - Error, F - Fatal.<br><br> The output includes both the specified severity level and all higher ones |
-| `--timezone`=TIMEZONE   | Timezone of the log output. <br>Supported values: `UTC` (default), `local` or the timezone in the [IANA timezone format](https://en.wikipedia.org/wiki/Tz_database) (e.g. `America/New_York`)
+| `--timezone=TIMEZONE`   | Timezone of the log output. <br>Supported values: `UTC` (default), `local` or the timezone in the [IANA timezone format](https://en.wikipedia.org/wiki/Tz_database) (for example `America/New_York`)
 | `-i`, `--opid=OPID`     | Show logs for an operation in progress. The operation is identified by the OpID |
 | `-x`, `--extra`         | Show extra data in the text format |
 
@@ -658,7 +767,7 @@ The command accepts the following flags:
 | `end=timestamp`         | The end time for the oplog replay.   |
 | `--replset-remapping`   | Maps the replica set names for the oplog replay. The value format is `to_name_1=from_name_1,to_name_2=from_name_2`. |
 | `-w`, `--wait`          | Wait for the oplog replay operation to complete. |
-| `--wait-time`  | The time to wait for PBM to report the status of the oplog replay execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
+| `--wait-time`  | The time to wait for PBM to report the status of the oplog replay execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.| 
 
 
 ## pbm profile add
@@ -679,7 +788,7 @@ The command accepts the following flags:
 | ----------------------- | ------------------------------------ |
 | --sync                  | Add a profile defining an external storage and sync the backup list from this storage|
 |--wait                   | Wait for the profile to be added. The flag blocks the shell session.|
-| `--wait-time`  | The time to wait for PBM to report the status of adding the profile and backup sync. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
+| `--wait-time`  | The time to wait for PBM to report the status of adding the profile and backup sync. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
 |-o, --out=text           | Shows the output format as either plain text or a JSON object. Supported values: `text`, `json`|
 
 ??? admonition "Add profile"
@@ -740,7 +849,7 @@ The command accepts the following flags:
 | Flag                    | Description                          |
 | ----------------------- | ------------------------------------ |
 | `--wait`                | Wait for the profile to be removed. The flag blocks the shell session.|
-| `--wait-time`  | The time to wait for PBM to report the status of the profile removal. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
+| `--wait-time`  | The time to wait for PBM to report the status of the profile removal. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
 | `-o`, `--out=text`      | Shows the output format as either plain text or a JSON object. Supported values: `text`, `json` |
 
 ??? admonition "Delete profile"
@@ -799,7 +908,7 @@ The command accepts the following flags:
 | `--all`                 | Syncs backup lists from all the storages.|
 | `--clear`               | Clears the backup list from the storage. To clear the backup list from a specific storage, pass the profile name. When used with `--all`, clears backup lists from all storages. |
 | `--wait`                | Wait for the profile to be synced. The flag blocks the shell session.|
-| `--wait-time`  | The time to wait for PBM to report the status of the profile sync. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
+| `--wait-time`  | The time to wait for PBM to report the status of the profile sync. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
 | `-o`, `--out=text`      | Shows the output format as either plain text or a JSON object. Supported values: `text`, `json` |
 
 
@@ -823,7 +932,7 @@ The command accepts the following flags:
 | `--external`        | Indicates the backup as the one made outside PBM (for example, snapshot-based)       |
 | `--time=TIME`       | Restores the database to the specified point in time. Available for logical restores and if [Point-in-time recovery](../features/point-in-time-recovery.md) is enabled. |
 | `-w`                | Wait for the restore to finish. The flag blocks the shell session. |
-| `--wait-time`  | The time to wait for PBM to report the status of the restore execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (e.g. 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
+| `--wait-time`  | The time to wait for PBM to report the status of the restore execution. Use this flag together with the `--wait` flag. You can specify the duration in minutes or hours (for example 5m, 1h). <br><br>When not set, PBM waits till the command executes. <br><br>If it takes longer than the defined waiting time to execute the command, PBM prints the `Operation is in progress. Check pbm status and logs` error message and unblocks the shell session. The `pbm-agent` continues to execute the command enabling you to track its progress via the `pbm status` command. Available starting with version 2.6.0.|
 | `-o`, `--out=text`  | Shows the output format as either plain text or a JSON object. Supported values: `text`, `json` |
 | `--base-snapshot`   | Restores the database from a specified backup to the specified point in time. Without this flag, the most recent backup preceding the timestamp is used for point in recovery. <br><br> In version 2.3.0, this flag is optional for [point-in-time recovery from physical backups](../usage/pitr-physical.md). <br><br> In version 2.2.0, this flag is mandatory for making a [point-in-time recovery from physical backups](../usage/pitr-physical.md). Without it, PBM looks for a logical backup to restore from.|
 | `--replset-remapping`| Maps the replica set names for the data restore / oplog replay. The value format is `to_name_1=from_name_1,to_name_2=from_name_2`|
@@ -836,6 +945,7 @@ The command accepts the following flags:
 | `--ns-to`="database.collection" | Specifies the new name for the collection you are restoring from the original one. Available starting with version 2.8.0.|
 | `--fallback-enabled` | Enables the use of fallback directory for a physical restore. At the restore start, PBM copies the contents of the `dbPath` to a special `.fallback` directory. If a restore is successful, PBM deletes the `.fallback` directory. If the restore ends with an error, PBM triggers the fallback procedure, deleting the downloaded backup files from `dbPath` and copying files from the  `.fallback` directory back, thus reverting the cluster to its initial state before the restore. Disabled by default. Available starting with version 2.10.0|
 | `--allow-partly-done` | Instructs how PBM handles restores with the "partlyDone" status. When enabled, PBM considers restore successful and the failed nodes receive the data via the initial sync. At least one node on each shard must restore successfully to serve as the data source for the remaining nodes. When all nodes within a replica set fail to restore, the restore is considered as failed. <br>When disabled, PBM starts the fallback operation if you use  `--allow-partly-done` together with `--fallback-enabled`. Otherwise, the restore won't start. <br><br>Enabled by default. Available starting with version 2.10.0. <br><br> Note that when you restore from backups made with PBM versions before 2.10.0, you must not set the `--allow-partly-done` flag to `false`: PBM automatically disables the `--fallback-enabled` setting, if it is enabled, and cannot start the restore at all because these two flags cannot be disabled simultaneously |
+| `-y`, `--yes`            | Restores from a backup without asking for the user's confirmation. Available starting with version 2.14.0. |
 
 
 ??? "Restore output"
@@ -1035,4 +1145,3 @@ The command accepts the following flags:
       "GoVersion": "go1.16.6"
     }
     ```
-
diff --git a/docs/release-notes.md b/docs/release-notes.md
index 8a804220..16d13361 100644
--- a/docs/release-notes.md
+++ b/docs/release-notes.md
@@ -1,4 +1,5 @@
 # {{pbm.full_name}} release notes
+* [{{pbm.full_name}} 2.14.0](release-notes/2.14.0.md)
 * [{{pbm.full_name}} 2.13.0](release-notes/2.13.0.md)
 * [{{pbm.full_name}} 2.12.0](release-notes/2.12.0.md)
 * [{{pbm.full_name}} 2.11.0](release-notes/2.11.0.md)
diff --git a/docs/release-notes/2.14.0.md b/docs/release-notes/2.14.0.md
new file mode 100644
index 00000000..9eee47f6
--- /dev/null
+++ b/docs/release-notes/2.14.0.md
@@ -0,0 +1,82 @@
+# Percona Backup for MongoDB 2.14.0 ({{date.2_14_0}})
+
+[Installation](../installation.md){.md-button}
+
+
+Percona Backup for MongoDB (PBM) is a distributed, low-impact solution for creating consistent backups of MongoDB sharded clusters and replica sets, and restoring them to a specific point in time.
+
+## Release highlights
+
+### ⚡ Concurrent streaming for faster uploads to remote storage via MinIO SDK
+This release significantly improves the performance of uploading files to S3-compatible custom storage providers through MinIO SDK. By enabling concurrent part uploads, large file transfers can achieve improved throughput and efficiency.
+
+To ensure reliability, PBM includes built‑in optimizations and fallbacks:
+
+* **Small files:** If the file is smaller than the upload part size, concurrent upload is automatically disabled (since it’s unnecessary).
+* **Empty streams:** If the MinIO library reports an unexpected error for empty streams, PBM will retry the request with ConcurrentStreamParts disabled.
+
+These safeguards ensure that concurrent uploads deliver performance benefits without compromising stability.
+
+To learn more and get started, follow [MinIO and S3-compatible storage](../details/minio.md) page.
+
+### 🖥️ Interactive confirmation for the restore command
+
+!!! warning "Breaking change"
+
+    Since an interactive prompt is now printed, automation and scripts must use the `-y` or `--yes` flag to bypass this confirmation.
+
+The `pbm restore` operation includes now an interactive confirmation prompt to reduce the risk of executing it accidentally. The command now requires explicit user approval before an operation is executed. With the new confirmation step, restores are safer and less prone to human error. See some examples below:
+
+```bash
+$ pbm restore --time 2026-03-31T13:23:00 
+  Restore: 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z' 
+  Are you sure you want to start the restore? [y/N] y 
+  Starting restore 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z'................................ 
+```
+
+For users who are automating PBM operations, PBM CLI introduces `-y` and `--yes` to force the execution of a given command without a confirmation prompt. See details in [`pbm` commands](../reference/pbm-commands.md#pbm-restore) reference.
+
+## Changelog
+
+### New features
+
+- [PBM-1598](https://perconadev.atlassian.net/browse/PBM-1598): Added a new configuration file setting for restore - `backup.timeouts.balancerStop` that defines a timeout value in seconds, to control how long PBM waits for the MongoDB balancer to stop when executing the admin command `_configsvrBalancerStop`. This change prevents backup and restore operations from hanging indefinitely due to extended chunk migrations.
+
+- [PBM-1600](https://perconadev.atlassian.net/browse/PBM-1600): We have added an interactive confirmation prompt to the `pbm restore` command. Before the restore starts, you will now have to explicitly confirm the action. This change is intended to reduce the risk of unintentionally running a restore operation.
+
+- [PBM-1730](https://perconadev.atlassian.net/browse/PBM-1730): Previously, if the balancer was not stopped before initiating a restore, PBM would only log an error followed by a warning from the subsequent balancer status check. While this behavior was generally acceptable for physical restores (since `mongod` is shut down later in the process), it could lead to issues during logical restores. PBM now provides clearer handling of balancer state during restore operations, reducing the risk of restore inconsistencies and improving reliability for logical restore workflows.
+
+### Improvement
+
+- [PBM-1167](https://perconadev.atlassian.net/browse/PBM-1167): Physical restore with Point-in-Time Recovery (PITR) has been enhanced to provide more consistent and flexible recovery behavior across replica set nodes. PITR oplog entries are now applied to all nodes, not just the former Primary, ensuring that all nodes have identical data files and oplog history after restore.
+
+- [PBM-1638](https://perconadev.atlassian.net/browse/PBM-1638): Percona Backup for MongoDB (PBM) now provides enhanced support for a backup of database with data-at-rest encryption enabled and using external KMS providers, such as KMIP or Vault. During backup operations, PBM automatically captures and stores the master encryption key identifier (for example, `security.kmip.keyIdentifier`) in the backup metadata. This enables seamless and automated restore workflows without requiring users to manually track or store the encryption key identifier externally.
+
+- [PBM-1639](https://perconadev.atlassian.net/browse/PBM-1639): Previously, physical restore operations were stuck if Percona Backup for MongoDB (PBM) ignored a shutdown command failure during restore. This issue has been addressed, and PBM now properly handles shutdown command failures, ensuring that restore workflows complete as expected without hanging.
+
+- [PBM-1653](https://perconadev.atlassian.net/browse/PBM-1653): Improved file upload performance for MinIO-compatible storage by enabling the MinIO SDK `ConcurrentStreamParts` option for parallel uploads.
+
+- [PBM-1703](https://perconadev.atlassian.net/browse/PBM-1703): Previously, PBM generated repeated 404 error messages in S3 storage related to `.pbm.init.pbmpart.1` objects. While these messages did not affect backup integrity, they cluttered logs and consumed storage space. PBM now suppresses these redundant error messages, resulting in cleaner S3 logs and more efficient storage usage during backup initialization.
+
+- [PBM-1721](https://perconadev.atlassian.net/browse/PBM-1721): Improved physical restores behavior when a restore would hang indefinitely if PBM encountered an "Unauthorized" error while attempting to shut down a `mongod` node via a non-localhost connection interface. The restore process now correctly detects this error and terminates with a descriptive message, clarifying that localhost connections are required for node shutdown when running MongoDB without authentication. This use case was added to [Known limitations for backups and restores](../features/known-limitations.md).
+
+## Fixed bugs
+
+- [PBM-1345](https://perconadev.atlassian.net/browse/PBM-1345): Fixed an issue where a PITR slicer failure on one replica set did not stop the overall PITR process. PBM now correctly stops the PITR operation when a slicer fails on any replica set, preventing incomplete or inconsistent PITR execution.
+
+- [PBM-1472](https://perconadev.atlassian.net/browse/PBM-1472): Fixed an issue where an extra slash in the bucket or prefix configuration caused PBM to fail to save or locate backups in storage. PBM now correctly handles such paths, ensuring reliable backup storage and discovery.
+
+- [PBM-1586](https://perconadev.atlassian.net/browse/PBM-1586): During backup operations, if the PBM agent crashed, the CLI process continued to wait indefinitely without returning control to the user. This behavior caused stalled sessions and required manual intervention. The issue has now been resolved.
+
+- [PBM-1599](https://perconadev.atlassian.net/browse/PBM-1599): Fixed an issue where the `pbm-agent` took longer to start a backup, causing `pbm-cli` to timeout and exit prematurely. Now, `pbm-cli` correctly waits for the agent to begin the backup process before proceeding.
+
+- [PBM-1609](https://perconadev.atlassian.net/browse/PBM-1609): Resolved an issue in restores with PITR enabled where the log incorrectly displayed “**oplog slicer disabled**” while PBM continued attempting to upload oplog slices. The restore process now correctly reflects the PITR state and avoids unnecessary oplog slice uploads.
+
+- [PBM-1629](https://perconadev.atlassian.net/browse/PBM-1629): Resolved an issue where backups failed because PBM miscalculated collection size when `backup.compression` was set to `none`. Backups now complete successfully with compression disabled.
+
+- [PBM-1648](https://perconadev.atlassian.net/browse/PBM-1648): Resolved an issue with `pbm backup --wait` where the command continued waiting even after the backup had failed, and did not return a non-zero error code. The command now correctly exits with a non-zero code when a backup failure is detected.
+
+- [PBM-1657](https://perconadev.atlassian.net/browse/PBM-1657): Resolved an issue in the PBM CLI that prevented the correct parsing of `mongodb+srv` URIs and returned an inaccurate error message stating “**unescaped colon in password**”, although no colon was present. The CLI now properly parses `mongodb+srv` URIs and provides an accurate error message.
+
+- [PBM-1683](https://perconadev.atlassian.net/browse/PBM-1683): Fixed an issue where `pbm describe-backup` reported an incorrect, inflated value for `size_uncompressed_h` on non-base incremental backups. This field now accurately reflects the uncompressed size of the incremental data rather than cumulative or bloated values.
+
diff --git a/docs/usage/delete-backup.md b/docs/usage/delete-backup.md
index a71c646a..d9cb9bb8 100644
--- a/docs/usage/delete-backup.md
+++ b/docs/usage/delete-backup.md
@@ -14,16 +14,18 @@ The timestamp you specify for the `--older-than` flag must be in the following f
 * `%Y-%M-%D` (2023-04-20)
 * `XXd` (1d or 30d). Only days are supported.
 
-During the cleanup, you see the backups and oplog slices to be deleted and are asked to confirm the action. To bypass it, add the `--yes` flag:
+Before the execution of the cleanup, you are asked to confirm the action. Then, you can see backup and oplog slices to be deleted.  
 
 ```bash
-pbm cleanup --older-than=`%Y-%M-%D --yes
+pbm cleanup --older-than="2023-04-20"
 ```
 
+You can bypass the confirmation prompt by adding the `-y` or `--yes` flag.
+
 Starting with version 2.13.0, you can clean up backups from [external storages](../features/multi-storage.md) by specifying the `--profile` flag:
 
 ```bash
-pbm cleanup --older-than 30d --profile=minio --yes
+pbm cleanup --older-than 30d --profile=minio
 ```
 
 When you run cleanup on the main storage, PBM automatically updates the metadata without requiring a manual resync.
@@ -155,6 +157,9 @@ You can delete either a specified backup snapshot or all backup snapshots older
      pbm delete-backup <backup_name>
      ```
 
+     Before a delete operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
+
 === "Backups older than the specified time"
     
     To delete backups that were created before the specified time, pass the `--older-than` flag to the `pbm delete-backup` command. Include the `--profile` flag to delete backups from an [external storage](../features/multi-storage.md). 
@@ -198,7 +203,7 @@ You can delete either a specified backup snapshot or all backup snapshots older
     To delete backups created before the specified time from external storages, use the `--older-than` and the `--profile` flags:
 
     ```bash
-    pbm delete-backup --older-than 30d --profile=minio --yes
+    pbm delete-backup --older-than 30d --profile=minio
     ```
 
     Read more about deleting backups from external storages in the [Delete backups from external storages](../features/multi-storage.md#delete-backups) section.
@@ -231,7 +236,7 @@ You can delete either a specified backup snapshot or all backup snapshots older
     You wish to delete all physical backups that are older than 10:00 a.m.
 
     ```bash
-    pbm delete-backup --older-than="2024-02-26T10:00:00" -t physical -y
+    pbm delete-backup --older-than="2024-02-26T10:00:00" -t physical
     ```
 
     There are two physical backup snapshots, but only `2024-02-26T09:56:18Z 961.68MB <physical> [restore_to_time: 2024-02-26T09:56:20Z]` snapshot passes in the specified timestamp. Therefore, PBM deletes this one only:
@@ -261,23 +266,11 @@ You can delete either a specified backup snapshot or all backup snapshots older
     To delete backups of the specified type from an external storage, add the `--profile` flag:
     
     ```bash
-    pbm delete-backup --older-than="2024-02-26T10:00:00" -t physical  --profile=minio -y
+    pbm delete-backup --older-than="2024-02-26T10:00:00" -t physical  --profile=minio
     ```
 
-
-By default, the ``pbm delete-backup`` command asks for your confirmation to proceed with the deletion. To bypass it, add the `-y` or
- `--yes` flag.
-
- ```bash
- pbm delete-backup --yes 2023-04-20T13:45:59Z
- ```
-
-
-
 ## Delete oplog slices
 
-!!! admonition "Version added: [1.6.0](../release-notes/1.6.0.md)"
-
 You can delete oplog slices saved before the specified time or all slices altogether. By deleting old and/or unnecessary slices, you can save storage space. 
 
 ### Behavior
@@ -292,6 +285,9 @@ To view oplog slices, run the [`pbm list`](../reference/pbm-commands.md#pbm-list
     pbm delete-pitr --all
     ```
 
+    Before a delete operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
+
 === "Earlier than the specified timestamp" 
     
     To delete slices that are made earlier than the specified time, run the `pbm delete-pitr` command with the `--older-than` flag and pass the timestamp for it. The timestamp must be in the following format:
diff --git a/docs/usage/pitr-physical.md b/docs/usage/pitr-physical.md
index b2a20700..81f1636c 100644
--- a/docs/usage/pitr-physical.md
+++ b/docs/usage/pitr-physical.md
@@ -14,7 +14,10 @@ To restore a database from a physical backup, specify the time for the [`pbm res
 pbm restore --time <timestamp> 
 ```    
 
-Percona Backup for MongoDB recognizes if it is a full or an incremental backup and restores the database from it up to the specified time.     
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
+Percona Backup for MongoDB uses a full or an incremental backup (if available) and restores the database from it up to the specified time.     
 
 You can [track the restore progress](restore-progress.md) using the `pbm describe-restore` command. Don't run any other commands since they may interrupt the restore flow and cause the issues with the database.
 
@@ -34,7 +37,8 @@ pbm describe-restore <restore_name> -c pbm_config.yaml
 
 ### Post-restore steps
 
-After the point-in-time recovery is complete, perform these post-restore steps:   
+After the point-in-time recovery is complete, perform these post-restore steps:
+{.power-number}
 
 1. Restart all `mongod` nodes.    
 
@@ -62,8 +66,15 @@ After the point-in-time recovery is complete, perform these post-restore steps:
 
 ### Implementation specifics
 
-1. Due to the physical restore logic and flow, PBM replays oplog events on the primary node of every shard when Percona Server for MongoDB is shut down. After the database start, the remaining nodes receive the data during the initial sync.
-2. When doing point-in-time recovery for deployments with sharded collections, PBM only writes data to existing ones and doesn’t support creating new collections. Therefore, whenever you create a new sharded collection, make a new backup for it to be included there.
+During a physical restore with point-in-time recovery (PITR), PBM applies oplog entries to all nodes in each replica set. As a result, all nodes contain the same restored data files when the restore completes, allowing replica set members to be started in any order.
+
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Previously, PITR entries were applied only on the primary node, and secondary nodes received the updated data after startup through replication catchup. This required starting the former primary node first to ensure correct data propagation. This limitation no longer applies.
+**PITR behavior and limitations in sharded clusters**
+
+- Due to the physical restore logic and flow, PBM replays oplog events on all nodes of every shard when Percona Server for MongoDB is shut down, allowing replica set members to be started in any order.
+
+- When performing point-in-time recovery for deployments with sharded collections, PBM writes data only to existing collections and does not create new collections. If you create a new sharded collection, make a new backup to ensure it is included in subsequent restore operations.
 
 
 ## Useful links
diff --git a/docs/usage/pitr-selective.md b/docs/usage/pitr-selective.md
index 3ffe1fbb..eb5748a1 100644
--- a/docs/usage/pitr-selective.md
+++ b/docs/usage/pitr-selective.md
@@ -8,28 +8,30 @@
 
 Before you start:
 {.power-number}
+  
+  1. Read [known limitations for selective backups and restores](../features/known-limitations.md#selective-backups-and-restores).
+  2. Check that you [have made a full backup](backup-selective.md) because it serves as the base for point-in-time recovery. Any selective backup is ignored.
 
-1. Ensure the following:
+## Restore the specified database or collection to a designated point in time
 
-    1. Read [known limitations for selective backups and restores](../features/known-limitations.md#selective-backups-and-restores).
-    2. Check that you [have made a full backup](backup-selective.md) because it serves as the base for point-in-time recovery. Any selective backup is ignored.
-
-2. To restore the desired database or a collection to a point in time, run the ``pbm restore`` command as follows:
+Run the restore command as follows:
 
     ```bash
     pbm restore --base-snapshot <backup_name> --time <timestamp> \
     --ns <db.collection>
     ```
 
-    You can specify the selective backup as the base snapshot for the Point-in-time restore. In this case, Percona Backup for MongoDB restores only the namespace(s) included in this backup to the specified time.    
-
-    Alternatively, you can use a full backup snapshot and restore the desired namespaces (databases or collections) up to the specific time from it. Specify them as the comma-separated list for the `pbm restore` command.    
-
-    When point-in-time recovery is started, Percona Backup for MongoDB uses the provided base snapshot, restores the specified namespace(s) and replays oplog on top of it up to the specified time. If no base snapshot is provided, Percona Backup for MongoDB uses the most recent full backup snapshot.
-
-3. To restore the desired database to a point in time, **along with users and roles**:
+To restore the desired database to a point in time, **along with users and roles** run:
 
     ```bash
     pbm restore --time <timestamp> --ns "db.*" --with-users-and-roles
     ```
 
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+        
+You can specify the selective backup as the base snapshot for the Point-in-time restore. In this case, Percona Backup for MongoDB restores only the namespace(s) included in this backup to the specified time.    
+
+Alternatively, you can use a full backup snapshot and restore the desired namespaces (databases or collections) up to the specific time from it. Specify them as the comma-separated list for the `pbm restore` command.    
+
+When point-in-time recovery is started, Percona Backup for MongoDB uses the provided base snapshot, restores the specified namespace(s) and replays oplog on top of it up to the specified time. If no base snapshot is provided, Percona Backup for MongoDB uses the most recent full backup snapshot.
diff --git a/docs/usage/pitr-tutorial.md b/docs/usage/pitr-tutorial.md
index fb823a4f..deece0ba 100644
--- a/docs/usage/pitr-tutorial.md
+++ b/docs/usage/pitr-tutorial.md
@@ -10,6 +10,9 @@ Run [`pbm restore`](../reference/pbm-commands.md#pbm-restore) and specify the ti
 pbm restore --time="2022-12-14T14:27:04"
 ```    
 
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+      
 The timestamp you specify for the restore must be within the time ranges in the PITR section of `pbm list` output. Percona Backup for MongoDB automatically selects the most recent backup among logical, physical and incremental in relation to the specified timestamp and uses that as the base for the restore.    
 
 To illustrate this behavior, let’s use the following `pbm list` output as the example.     
diff --git a/docs/usage/restore-external-agent-restart.md b/docs/usage/restore-external-agent-restart.md
index bffcb5cb..c652a465 100644
--- a/docs/usage/restore-external-agent-restart.md
+++ b/docs/usage/restore-external-agent-restart.md
@@ -19,6 +19,9 @@ This workflow lets you pause an external restore at `copyReady`, restart `pbm-ag
     - Without the `--exit` flag, agents wait at `copyReady` until data files appear.
     - With the `--exit` flag, each agent exits automatically when it reaches `copyReady`.
 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+        
 2. After files are in place, start `pbm-agent` on every node.
 
     !!! note
@@ -38,10 +41,8 @@ This workflow lets you pause an external restore at `copyReady`, restart `pbm-ag
     - `<restore_name>` (required): used to find temporary restore data on backup storage.
     - `-c/--config` (required): PBM config to access backup storage.
     - `--rs, --node` (required): identify the node without connecting to mongod.
-    - `--db-config` (optional): required only when you use encryption-at-rest (PBM does not store encryption options in metadata).
-
-
-
+    - `--db-config` (optional): required only when you restore from an externally taken backup (without PBM) of a database with encryption at rest (in that case, PBM does not store encryption options in metadata). In that case, you have to provide MongoDB configuration manually via this parameter. The configuration must match the configuration from the node from which the backup was taken, not the current one. For external backups assisted by PBM, you can skip that parameter. PBM creates metadata file within `dbPath` with all necessary `mongod` options, so for the external restore PBM can read this file and provide the options to `pbm-agent restore-finish` automatically.
+  
     This is the configuration file that PBM will use during the restore. It should contain the [security options :octicons-link-external-16:](https://www.mongodb.com/docs/manual/reference/configuration-options/#security-options)                
 
     ```bash
diff --git a/docs/usage/restore-external.md b/docs/usage/restore-external.md
index 45b7e8ac..6fc93f58 100644
--- a/docs/usage/restore-external.md
+++ b/docs/usage/restore-external.md
@@ -20,6 +20,9 @@ The following procedure describes the restore process from backups [made through
     pbm restore --external 
     ```    
 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
     Percona Backup for MongoDB stops the database, cleans up data directories on all nodes, provides the restore name and prompts you to copy the data:    
 
     ```{.text .no-copy}
@@ -104,6 +107,9 @@ To restore from a backup, do the following:
     pbm restore --external -c </path/to/mongod.conf> --ts 
     ```
 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
     If the path to the source cluster `mongod.conf` is undefined, PBM tries to retrieve the required configuration options from the `mongod.conf` of the target cluster.    
 
     If the timestamp to restore to is undefined, PBM looks into the actual data during the restore and defines the most recent common cluster time across all shards. PBM restores the database up to this time.
diff --git a/docs/usage/restore-incremental.md b/docs/usage/restore-incremental.md
index b6dbab26..57f3f7ca 100644
--- a/docs/usage/restore-incremental.md
+++ b/docs/usage/restore-incremental.md
@@ -34,6 +34,9 @@ Restore flow from an incremental backup is the same as the restore from a full p
 pbm restore 2022-11-25T14:13:43Z
 ```
 
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
 Percona Backup for MongoDB recognizes the backup type, finds the base incremental backup, restores the data from it and then restores the modified data from applicable incremental backups.
 
 ### Post-restore steps
diff --git a/docs/usage/restore-physical.md b/docs/usage/restore-physical.md
index f24ad412..9b8c7569 100644
--- a/docs/usage/restore-physical.md
+++ b/docs/usage/restore-physical.md
@@ -50,7 +50,10 @@
     pbm restore <backup_name>
     ```
 
-    During the physical restore, `pbm-agent` processes stop the `mongod` nodes, clean up the data directory and copy the data from the storage onto every node. During this process, the database is restarted several times. 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+    
+    After that, `pbm-agent` processes stop `mongod` nodes, clean up the data directory and copy the data from the storage onto every node. During this process, the database is restarted several times. 
 
 3. [Track the restore progress](restore-progress.md) using the `pbm describe-restore` command. Don't run any other commands since they may interrupt the restore flow and cause the issues with the database.
 
diff --git a/docs/usage/restore-selective.md b/docs/usage/restore-selective.md
index 08d48ef5..011a7b24 100644
--- a/docs/usage/restore-selective.md
+++ b/docs/usage/restore-selective.md
@@ -28,11 +28,12 @@ Percona Backup for MongoDB allows you to perform selective restore of databases
     pbm restore --ns="mydb.*" --with-users-and-roles <backup-name>
     ```
 
-    - To restore without the users and roles, skip the `--with-users-and-roles` flag.
-
-     - You can specify several namespaces as a comma-separated list for the `--ns` flag: `<db1.*>,<db2.*>`. For example, `--ns=customers.*,invoices.*`.
-
-    - During the restore, Percona Backup for MongoDB retrieves the file for the specified database/collection and restores it.
+    Note:
+   
+      - Starting with version [2.14.0](../release-notes/2.14.0.md), before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+      - To restore without the users and roles, skip the `--with-users-and-roles` flag.
+      - You can specify several namespaces as a comma-separated list for the `--ns` flag: `<db1.*>,<db2.*>`. For example, `--ns=customers.*,invoices.*`.
+      - During the restore, Percona Backup for MongoDB retrieves the file for the specified database/collection and restores it.
     
     **Where:**
 
@@ -87,6 +88,9 @@ You can restore a collection under a new name up to the specified time. Instead
 pbm restore --time=<timestamp> --ns-from <database.collection> --ns-to <database.collection_new>
 ```
 
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
 ## Post-restore steps
 
 After the restore is complete, do the following:
diff --git a/docs/usage/restore.md b/docs/usage/restore.md
index a86e31d5..ade91b63 100644
--- a/docs/usage/restore.md
+++ b/docs/usage/restore.md
@@ -48,6 +48,9 @@
     pbm restore <backup_name>
     ```
 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
     Note that you can restore a sharded backup only into a sharded environment. It can be your existing cluster or a new one. To learn how to restore a backup into a new environment, see [Restoring a backup into a new environment](../features/restore-new-env.md).
 
 ### Post-restore steps
@@ -77,6 +80,9 @@ Starting with version 2.8.0, you can override the number of insertion workers pe
 pbm restore <backup_name>  --num-insertion-workers-per-collection 4 --num-parallel-collections 8
 ```
 
+!!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
 Increasing the number may increase the restore speed. However, it may also lead to unexpectedly high disk and CPU usage. Consider the trade-offs carefully before making adjustments to ensure optimal performance without overloading resources.
 
 ## Restore from a logical backup made on previous major version of Percona Server for MongoDB
@@ -117,6 +123,9 @@ The following example illustrates the restore from a backup made on Percona Serv
     pbm restore 2023-04-10T10:51:28Z
     ```
 
+    !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
+        Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
 4. Set the Feature Compatibility Version value to 5.0
 
     ```javascript

From c7676f613078f28a0ebf5024125129e89c99ab5c Mon Sep 17 00:00:00 2001
From: Radoslaw Szulgo <radoslaw.szulgo@percona.com>
Date: Tue, 28 Apr 2026 17:58:44 +0200
Subject: [PATCH 4/8] Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---
 docs/_templates/pdf_cover_page.tpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/_templates/pdf_cover_page.tpl b/docs/_templates/pdf_cover_page.tpl
index 735ae27e..126ea86e 100644
--- a/docs/_templates/pdf_cover_page.tpl
+++ b/docs/_templates/pdf_cover_page.tpl
@@ -7,4 +7,4 @@
 {% if config.site_description %}
 <h1>{{ config.site_description }}</h1>
 {% endif %} 
-<h2>2.14.0 (Aril 29, 2026)</h2>
\ No newline at end of file
+<h2>2.14.0 (April 29, 2026)</h2>
\ No newline at end of file

From e5689c64a5968a8e6a60f86781ece7404f5a501e Mon Sep 17 00:00:00 2001
From: Radoslaw Szulgo <radoslaw.szulgo@percona.com>
Date: Tue, 28 Apr 2026 18:39:22 +0200
Subject: [PATCH 5/8] Apply suggestions from code review

Co-authored-by: Radoslaw Szulgo <radoslaw.szulgo@percona.com>
---
 docs/release-notes/2.14.0.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/release-notes/2.14.0.md b/docs/release-notes/2.14.0.md
index 9eee47f6..9cd680dc 100644
--- a/docs/release-notes/2.14.0.md
+++ b/docs/release-notes/2.14.0.md
@@ -28,7 +28,7 @@ To learn more and get started, follow [MinIO and S3-compatible storage](../detai
 The `pbm restore` operation includes now an interactive confirmation prompt to reduce the risk of executing it accidentally. The command now requires explicit user approval before an operation is executed. With the new confirmation step, restores are safer and less prone to human error. See some examples below:
 
 ```bash
-$ pbm restore --time 2026-03-31T13:23:00 
+    pbm restore --time 2026-03-31T13:23:00 
   Restore: 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z' 
   Are you sure you want to start the restore? [y/N] y 
   Starting restore 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z'................................ 

From 644672586a5957ad2794fa365eb22768ec8ef9d5 Mon Sep 17 00:00:00 2001
From: Anastasia Alexadrova <anastasia.alexandrova@percona.com>
Date: Tue, 28 Apr 2026 18:47:48 +0200
Subject: [PATCH 6/8] Separated command from the output for better usability

---
 docs/release-notes/2.14.0.md | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/docs/release-notes/2.14.0.md b/docs/release-notes/2.14.0.md
index 9cd680dc..93f4f9af 100644
--- a/docs/release-notes/2.14.0.md
+++ b/docs/release-notes/2.14.0.md
@@ -8,11 +8,12 @@ Percona Backup for MongoDB (PBM) is a distributed, low-impact solution for creat
 ## Release highlights
 
 ### ⚡ Concurrent streaming for faster uploads to remote storage via MinIO SDK
+
 This release significantly improves the performance of uploading files to S3-compatible custom storage providers through MinIO SDK. By enabling concurrent part uploads, large file transfers can achieve improved throughput and efficiency.
 
 To ensure reliability, PBM includes built‑in optimizations and fallbacks:
 
-* **Small files:** If the file is smaller than the upload part size, concurrent upload is automatically disabled (since it’s unnecessary).
+* **Small files:** If the file is smaller than the upload part size, concurrent upload is automatically disabled (since it's unnecessary).
 * **Empty streams:** If the MinIO library reports an unexpected error for empty streams, PBM will retry the request with ConcurrentStreamParts disabled.
 
 These safeguards ensure that concurrent uploads deliver performance benefits without compromising stability.
@@ -28,13 +29,18 @@ To learn more and get started, follow [MinIO and S3-compatible storage](../detai
 The `pbm restore` operation includes now an interactive confirmation prompt to reduce the risk of executing it accidentally. The command now requires explicit user approval before an operation is executed. With the new confirmation step, restores are safer and less prone to human error. See some examples below:
 
 ```bash
-    pbm restore --time 2026-03-31T13:23:00 
-  Restore: 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z' 
-  Are you sure you want to start the restore? [y/N] y 
-  Starting restore 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z'................................ 
+pbm restore --time 2026-03-31T13:23:00
 ```
 
-For users who are automating PBM operations, PBM CLI introduces `-y` and `--yes` to force the execution of a given command without a confirmation prompt. See details in [`pbm` commands](../reference/pbm-commands.md#pbm-restore) reference.
+??? example "Sample output"
+
+    ```text
+    Restore: 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z' 
+    Are you sure you want to start the restore? [y/N] y 
+    Starting restore 2026-03-31T13:37:06.852575976Z to point-in-time 2026-03-31T13:23:00 from '2026-03-31T13:22:06Z'................................ 
+    ```
+
+For users who are automating PBM operations, PBM CLI introduces the `-y` and `--yes` flags to force the execution of a given command without a confirmation prompt. See details in [`pbm` commands](../reference/pbm-commands.md#pbm-restore) reference.
 
 ## Changelog
 

From fad2ff0ff943ae3adc949ac9308808d739980b41 Mon Sep 17 00:00:00 2001
From: Radoslaw Szulgo <radoslaw.szulgo@percona.com>
Date: Wed, 29 Apr 2026 11:37:40 +0200
Subject: [PATCH 7/8] Revise release notes for version 2.14.0

Updated release notes for version 2.14.0 to reflect changes in concurrent streaming and interactive confirmation for the restore command.
---
 docs/release-notes/2.14.0.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/release-notes/2.14.0.md b/docs/release-notes/2.14.0.md
index 93f4f9af..48b16892 100644
--- a/docs/release-notes/2.14.0.md
+++ b/docs/release-notes/2.14.0.md
@@ -7,7 +7,7 @@ Percona Backup for MongoDB (PBM) is a distributed, low-impact solution for creat
 
 ## Release highlights
 
-### ⚡ Concurrent streaming for faster uploads to remote storage via MinIO SDK
+### Concurrent streaming for faster uploads to remote storage via MinIO SDK
 
 This release significantly improves the performance of uploading files to S3-compatible custom storage providers through MinIO SDK. By enabling concurrent part uploads, large file transfers can achieve improved throughput and efficiency.
 
@@ -20,7 +20,7 @@ These safeguards ensure that concurrent uploads deliver performance benefits wit
 
 To learn more and get started, follow [MinIO and S3-compatible storage](../details/minio.md) page.
 
-### 🖥️ Interactive confirmation for the restore command
+### Interactive confirmation for the restore command
 
 !!! warning "Breaking change"
 

From 0995f71271ce80df4a22334f779b386914de039b Mon Sep 17 00:00:00 2001
From: Anastasia Alexadrova <anastasia.alexandrova@percona.com>
Date: Wed, 29 Apr 2026 12:09:28 +0200
Subject: [PATCH 8/8] Last fixes

---
 docs/features/known-limitations.md |  3 ++-
 docs/features/multi-storage.md     |  3 ++-
 docs/features/physical.md          | 12 +++++++-----
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/docs/features/known-limitations.md b/docs/features/known-limitations.md
index ba603442..5de45b14 100644
--- a/docs/features/known-limitations.md
+++ b/docs/features/known-limitations.md
@@ -15,7 +15,8 @@ PBM supports various backup and restore types. Some of them have known limitatio
 6. Selective point-in-time recovery is not supported for sharded clusters.
 
 ## Physical backups and restores
-Physical restores are not supported for MongoDB instances running without authentication if the PBM agent connects via a non-localhost interface (such as a container hostname or external IP). Because MongoDB restricts the shutdown command to the localhost interface in non-authenticated environments, PBM will be unable to stop the node to perform the restore. To avoid this limitation, ensure that the PBM_MONGODB_URI uses a localhost connection or enable authentication for your MongoDB deployment.
+
+Physical restores are not supported for MongoDB instances running without authentication if the PBM agent connects via a non-localhost interface (such as a container hostname or external IP). Because MongoDB restricts the shutdown command to the localhost interface in non-authenticated environments, PBM will be unable to stop the node to perform the restore. To avoid this limitation, ensure that the `PBM_MONGODB_URI` uses a `localhost` connection or enable authentication for your MongoDB deployment.
 
 ## Oplog slicing for point-in-time recovery
 
diff --git a/docs/features/multi-storage.md b/docs/features/multi-storage.md
index 71b4c0ff..908cd1a7 100644
--- a/docs/features/multi-storage.md
+++ b/docs/features/multi-storage.md
@@ -33,7 +33,7 @@ To choose which storage a command should use, pass the `--profile` flag.
 
 #### Commands that support `--profile`
 
-These PBM commands accept `--profile` flag:
+These PBM commands accept the `--profile` flag:
 
 - `pbm backup`
 
@@ -56,6 +56,7 @@ You can set `--profile` to one of the following:
 - `--profile=<profile_name>` **→** Use an external storage identified by an existing configuration profile name.
 
 ??? example "Examples"
+
 	```bash
 	# List backups from main storage
 	pbm list --profile=main
diff --git a/docs/features/physical.md b/docs/features/physical.md
index b43567ac..617ff947 100644
--- a/docs/features/physical.md
+++ b/docs/features/physical.md
@@ -68,20 +68,21 @@ The physical restore in mixed deployments has no restrictions except the version
 
 !!! admonition "Version added: [2.0.0](../release-notes/2.0.0.md)"
 
-You can back up and restore data that is encrypted at rest. Thereby, you ensure data security and also comply with security requirements such as GDPR, HIPAA, PCI DSS, and PHI. If you use an external KMS such as HashiCorp Vault, OpenBao, or KMIP, you need the master encryption key identifier to restore the data. For security reasons, the encryption key is not stored or shown as part of the backup.
+You can back up and restore data that is encrypted at rest. Thereby, you ensure data security and also comply with security requirements such as GDPR, HIPAA, PCI DSS, and PHI. If you use an external Key Management Service (KMS) such as HashiCorp Vault, OpenBao, or KMIP, you need the master encryption key identifier to restore the data. For security reasons, the encryption key is not stored or shown as part of the backup.
 
 During a backup, Percona Backup for MongoDB stores the encryption settings in the backup metadata. You can verify them using the [`pbm describe-backup`](../reference/pbm-commands.md#pbm-describe-backup) command.
 
 !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
-    Additionally, PBM stores the encryption key identifier in the backup metadata. You need Percona Server for MongoDB (PSMDB) 7.0.22-12 and 8.0.12-4 or higher to use this feature. If you're using older versions of PSMDB or PBM, you have to store the identifier externally and pass it in the restore configuration.
 
-To restore the encrypted data from the backup, you can just configure the same data-at-rest encryption settings on all nodes of your destination cluster or replica set to match the settings of the original cluster where you made the backup.
+    Additionally, PBM stores the encryption key identifier in the backup metadata. You need Percona Server for MongoDB 7.0.22-12 and 8.0.12-4 or higher to use this feature. If you're using older versions of Percona Server for MongoDB or PBM, you have to store the identifier externally and pass it in the restore configuration.
+
+To restore the encrypted data from the backup, you can configure the same data-at-rest encryption settings on all nodes of your destination cluster or replica set to match the settings of the original cluster where you made the backup.
 
 During the restore, Percona Backup for MongoDB restores the data to all nodes using the same master key. We recommend rotating the master encryption key afterward for extra security. 
 
 To learn more about master key rotation, refer to the following documentation:
 
-* [Master key rotation in HashiCorp Vault server :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/6.0/vault.html#key-rotation)
+* [Master key rotation in HashiCorp Vault server :octicons-link-external-16:](https://docs.percona.com/percona-server-for-mongodb/latest/vault.html#key-rotation)
 * [KMIP master key rotation :octicons-link-external-16:](https://www.mongodb.com/docs/manual/tutorial/rotate-encryption-key/#kmip-master-key-rotation)
 
 ## Physical restores with a fallback directory
@@ -164,7 +165,8 @@ A restore can succeed on most nodes, but it might fail on a few, resulting in a
     ```
 
 !!! admonition "Version added: [2.14.0](../release-notes/2.14.0.md)"
-    Before a restore operation is executed you have to confirm the action (to bypass it, add the `-y` or `--yes` flag).
+
+    Before a restore operation is executed you have to confirm the action. To bypass the confirmation, add the `-y` or `--yes` flag.
 
 If you allow partial restores (default value), PBM finalizes the restore. Once the cluster is up and running, the failed node receives the necessary data from other members through an initial sync.