PBM-1715 Parallel file processing for backups and restores

docs/reference/backup-options.md

@@ -121,3 +121,21 @@ The duration (in minutes) of oplog slices saved with the logical backup snapshot
 The number of parallel collections to process during a logical backup. By default, the number of parallel collections is half of the number of CPU cores. By setting the value for this option you define the new default.
 Available starting with version 2.7.0.
 
+
+## backup.numParallelFiles
+
+*Type*: int <br>
+*Default*: 1 <br>
+*Storage*: Filesystem only <br>
+*Backup type:* Physical only
+
+The number of files to copy in parallel during a physical backup 
+to filesystem or NFS storage.
+
+The default value of `1` copies files sequentially. If parameter is not specified, files will be uploaded/downloaded sequentially.
+
+
+
+
+
+

docs/reference/restore-options.md

@@ -99,4 +99,21 @@ 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
+- Fail fast if the balancer cannot be stopped
+
+
+## restore.numParallelFiles
+
+*Type*: int <br>
+*Default*: 1 <br>
+*Storage*: Filesystem only <br>
+*Restore type:* Physical only
+
+The number of files to copy in parallel during a physical restore 
+from filesystem or NFS storage.
+
+The default value of `1` copies files sequentially. If parameter is not specified, files will be uploaded/downloaded sequentially.
+
+
+
+

docs/usage/backup-physical.md

@@ -18,6 +18,30 @@ pbm backup --type=physical
 
 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.
 
+## Improve backup performance on filesystem storage
+
+For physical backups stored on a filesystem, you can control how many files PBM processes in parallel during backup and restore operations. Increasing parallelism can improve performance by allowing multiple files to be transferred or copied simultaneously.
+
+
+To copy files in parallel, set `backup.numParallelFiles` in the 
+PBM configuration:
+
+```yaml
+backup:
+  numParallelFiles: 4
+```
+
+Or pass `--num-parallel-files`
+
+```sh
+pbm backup --num-parallel-files=4
+```
+
+!!! note
+    Parallel file copy applies to **physical backups to filesystem 
+    or NFS storage only**. It has no effect on logical backups or 
+    on S3-compatible storage.
+
 ## Next steps
 
 [List backups](../usage/list-backup.md){.md-button}

docs/usage/restore-physical.md

@@ -151,6 +151,28 @@ restore:
 * `maxDownloadBufferMb` - the maximum size of memory buffer to store the downloaded data chunks for decompression and ordering. It is calculated as `numDownloadWorkers * downloadChunkMb * 16`
 * `downloadChunkMb` is the size of the data chunk to download (by default, 32 MB)
 
+## Improve restore performance on filesystem storage
+
+For physical restores from filesystem storage, you can control how many files PBM copies in parallel during the restore operation. Increasing the number of parallel file copies can reduce restore time by allowing multiple files to be processed simultaneously, depending on the available system and storage resources.
+
+To copy files in parallel, set `restore.numParallelFiles` in the 
+PBM configuration:
+
+```yaml
+restore:
+  numParallelFiles: 4
+```
+
+Or pass `--num-parallel-files`:
+
+```sh
+pbm restore <backup_name> --num-parallel-files=4
+```
+
+!!! note
+    Parallel file copy applies to **physical restores from 
+    filesystem or NFS storage only**. It has no effect on logical 
+    restores or on S3-compatible storage.
 
 ## Next steps