diff --git a/docs/features/incremental-backup.md b/docs/features/incremental-backup.md
index afc9ceb7..265a19dd 100644
--- a/docs/features/incremental-backup.md
+++ b/docs/features/incremental-backup.md
@@ -25,9 +25,13 @@ graph LR
 
 ## Implementation specifics
 
-Percona Backup for MongoDB tracks the backup history only on the node where the base incremental backup was taken. This means that subsequent incremental backups must always be run on that very node. To make this happen, Percona Backup for MongoDB tries to schedule backups on that same node.
+1. Percona Backup for MongoDB tracks the backup history only on the node where the base incremental backup was taken. This means that subsequent incremental backups must always be run on that very node. To make this happen, Percona Backup for MongoDB tries to schedule backups on that same node.
 
-If the node with the base incremental backup is down or unavailable, you must start the incremental backup chain anew on another node.
+    If the node with the base incremental backup is down or unavailable, you must start the incremental backup chain anew on another node.
+
+2. Adjusting node priorities for backup interferes with the default behaviour described above. If only a subset of nodes is listed for the priority, the remaining nodes receive the default priority 1 and it may happen that the incremental backup is taken not from the node where the base backup was taken. 
+
+    To avoid this, make sure to either list all nodes in the priority list or  least one node from every replica set .
 
 [Make a backup](../usage/start-backup.md){ .md-button .md-button }
 [Restore a backup](../usage/restore.md){ .md-button .md-button }
diff --git a/docs/usage/start-backup.md b/docs/usage/start-backup.md
index 645338ea..7644b59a 100644
--- a/docs/usage/start-backup.md
+++ b/docs/usage/start-backup.md
@@ -199,6 +199,11 @@ If you haven’t listed any nodes for the `priority` option in the config, the n
 
     As soon as you adjust node priorities in the configuration file, it is assumed that you take manual control over them. The default rule to prefer secondary nodes over primary stops working.
 
+    Adjusting node priority interferes the default flow for incremental backups, where PBM tries to schedule the incremental backup on happen on the same node that made the base backup. If you list only a subset of nodes in the priority list, the remaining nodes receive the default priority 1.0. This may result in the incremental backup being taken from a node that didn't make the base backup. 
+
+    To workaround it, list either all nodes or at least a single node from every replica set in the priorities list.
+
+
 This ability to adjust node priority helps you manage your backup strategy by selecting specific nodes or nodes from preferred data centers. In geographically distributed infrastructures, you can reduce network latency by making backups from nodes in geographically closest locations.
 
 ## Next steps