PBM-907 Doc: Don't stop PITR during backup

docs/features/point-in-time-recovery.md

@@ -36,28 +36,24 @@ To start saving [oplog slices](../reference/glossary.md#oplog), the following pr
 
 === "Logical backups"
 
-    * A full logical backup snapshot is required. Make sure that a [backup exists](../usage/list-backup.md). See the [Make a backup](../usage/start-backup.md) guide to make a backup snapshot.
+    * A full backup snapshot is required. Starting with version [2.3.0](../release-notes/2.3.0.md), it can be a logical, a physical or an incremental backup. Make sure that a [backup exists](../usage/list-backup.md). See the [Make a backup](../usage/start-backup.md) guide to make a backup snapshot.
     * Point-in-time recovery routine is [enabled](#enable-point-in-time-recovery). 
 
 === "Physical backups"
 
-    Enable point-in-time recovery routine and configure it to save oplog slices without the base backup.
-
-    ```yaml
-    pitr:
-       enabled: true
-       oplogOnly: true
-    ```
+    Point-in-time recovery routine is [enabled](#enable-point-in-time-recovery). 
 
 
-If you just enabled point-in-time recovery, it requires 10 minutes for the first chunk to appear in the [`pbm list`](../reference/pbm-commands.md#pbm-list) output.
+If you just enabled point-in-time recovery, it requires 10 minutes for the first slice to appear in the [`pbm list`](../reference/pbm-commands.md#pbm-list) output.
 
 !!! important
 
     **For in MongoDB 5.0 and higher versions**
 
     If you [reshard](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.
 
+Starting with version [2.4.0](../release-notes/2.4.0.md), oplog slicing runs in parallel with a backup snapshot operation. Thereby if a backup snapshot is large and takes hours to make, all oplog events are saved for it ensuring point-in-time recovery to any timestamp.
+
 ### Oplog duration
 
 !!! admonition "Version added: [1.6.0](../release-notes/1.6.0.md)"

docs/reference/backup-options.md

@@ -11,6 +11,7 @@ backup:
   compressionLevel: <int>
   timeouts:
     startingStatus: 60
+  oplogSpanMin: <float64>
 ```
 
 ### priority
@@ -61,4 +62,10 @@ Note that the greater value you specify, the more time and computing resources i
 
 The wait time (in seconds) for PBM to start physical backups on all shards. Increasing this value is useful when it takes longer than usual to open the `$backupCursor`.
 
-The 0 (zero) value resets the timeout to the default 33 seconds. 
+The 0 (zero) value resets the timeout to the default 33 seconds. 
+
+### 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. 

docs/usage/restore.md

@@ -8,7 +8,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re
 
     1. While the restore is running, prevent clients from accessing the database. The data will naturally be incomplete while the restore is in progress, and writes the clients make cause the final restored data to differ from the backed-up data.
 
-    2. If you enabled [Point-in-time recovery](../features/point-in-time-recovery.md), disable it before running `pbm restore`. This is because Point-in-Time Recovery oplog slicing and restore are incompatible operations and cannot be run together.
+    2. For versions 2.3.1 and earlier, disable [Point-in-time recovery](../features/point-in-time-recovery.md) before running `pbm restore`. This is because Point-in-Time recovery oplog slicing and restore are incompatible operations and cannot be run together.
 
     3. Backups made with Percona Backup for MongoDB prior to v1.5.0 are incompatible for restore with Percona Backup for MongoDB v1.5.0 and later. This is because processing of system collections `Users` and `Roles` has changed: in v1.5.0, `Users` and `Roles` are copied to temporary collection during backup and must be present in the backup during restore. In earlier versions of Percona Backup for MongoDB, `Users` and `Roles` are copied to a temporary collection during restore. Therefore, restoring from these backups with Percona Backup for MongoDB v1.5.0 isn’t possible.
 
@@ -37,7 +37,7 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re
 
     2. Shut down all `mongos` nodes to stop clients from accessing the database while restore is in progress. This ensures that the final restored data doesn’t differ from the backed-up data.
 
-    3. Disable point-in-time recovery if it is enabled. To learn more about point-in-time recovery, see [Point-in-time recovery](../features/point-in-time-recovery.md).
+    3. For PBM version 2.3.1 and earlier, manually disable point-in-time recovery if it is enabled. To learn more about point-in-time recovery, see [Point-in-time recovery](../features/point-in-time-recovery.md).
 
 === "Physical"
 
@@ -77,6 +77,8 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re
 
     1. Start the balancer and all `mongos` nodes to reload the sharding metadata. 
     2. We recommend to make a fresh backup to serve as the new base for future restores. 
+    3. [Enable point-in-time recovery](../features/point-in-time-recovery.md#enable-point-in-time-recovery) if required.
+
 
     ### Adjust memory consumption
 
@@ -182,7 +184,9 @@ To restore a backup, use the [`pbm restore`](../reference/pbm-commands.md#pbm-re
 
     4. Start the balancer and start `mongos` nodes.
 
-    5. Make a fresh backup to serve as the new base for future restores. 
+    5. We recommend to make a fresh backup to serve as the new base for future restores.
+    6. [Enable point-in-time recovery](../features/point-in-time-recovery.md#enable-point-in-time-recovery) if required.
+
 
     ### Define a `mongod` binary location
 

docs/usage/start-backup.md

@@ -31,7 +31,9 @@
      $ pbm backup --type=physical
      ```
 
-     During a *physical* backup, Percona Backup for MongoDB stops [point-in-time recovery oplog slicing](../features/point-in-time-recovery.md#oplog-slicing) if it's enabled, copies the contents of the `dbpath` directory (data and metadata files, indexes, journal and logs) from every shard and config server replica set to the backup storage.
+     During a *physical* backup, Percona Backup for MongoDB  copies the contents of the `dbpath` directory (data and metadata files, indexes, journal and logs) from every shard and config server replica set to the backup storage. 
+
+     Starting with [2.4.0](../release-notes/2.4.0.md), PBM doesn't stop [point-in-time recovery oplog slicing](../features/point-in-time-recovery.md#oplog-slicing), if it's enabled, but runs it in parallel. This ensures [point-in-time recovery](pitr-tutorial.md) to any timestamp if it takes too long (e.g. hours) to make a backup snapshot.
 
 === "Selective"
 

mkdocs-pdf.yml

@@ -9,3 +9,8 @@ markdown_extensions:
   pymdownx.tabbed: {}
   admonition: {}
 
+extra_css:
+  - https://unicons.iconscout.com/release/v3.0.3/css/line.css
+  - https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.4.0/css/font-awesome.min.css
+  - css/percona.css
+  - css/extra.css