[GitHub] [ignite] Silberfuchs1 commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages

[GitBox <gi...@apache.org>]

Silberfuchs1 commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484335614



##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will

Review comment:
       'for each node' maybe? The data is stored on disk in files for each node?

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except

Review comment:
       At runtime, you can create multiple snapshots of all configured persistent cache groups.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions

Review comment:
       don't understand, where 'procedure' goes... Is 'triggering the link' the procedure?
   
   

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.

Review comment:
       '... finished...' ---> '...are finished...'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;

Review comment:
       encrypted caches are not supported and will be ignored;

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.

Review comment:
       in order to recover the data from a particular snapshot, you need to start the same cluster with the same configuration...
   
   'configuration on these files.' - which files? Data files? Then maybe 'in these files'? Or 'of these files'?

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored

Review comment:
       'stored' ---> 'is stored'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created

Review comment:
       '...will be also fully consistent...' ---> '...will also be fully consistent...'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.

Review comment:
       'ids' ---> 'IDs'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the

Review comment:
       '... achieved...' ---> 'is achieved'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of

Review comment:
       '...you created' ---> 'you've created'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will

Review comment:
       '...(cache group partition files, configuration files, binary metadata), the snapshot will...'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:

Review comment:
       '...with your own production environment:'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.

Review comment:
       'will require'? Why not 'requires' or 'may require', or 'might require'?

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;

Review comment:
       in-memory caches will not be included into a snapshot;

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will

Review comment:
       Didn't understand the sentence. what does '... as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory.' mean?

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.

Review comment:
       This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.

Review comment:
       A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved

Review comment:
       'The **consistency of local system files** (e.g. cache group partition files, binary metadata files, configuration files) **is** achieved....'
   or
   'The **local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency**  **is** achieved....'
   Otherwise, the types of local system files are away from the definition itself, and the reader could get confused.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;

Review comment:
       you can start only one snapshot operation at a time;
   
   My question is: is the snapshot operation started automatically, or it can be started manually?
   
   If the answer is 'automatically', then you need to say: 'only one snapshot operation can be started at once' or 
   'only one snapshot operation at a time can be started'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;

Review comment:
       Didn't understand the sentence. Looks like it's not finished.
   Maybe like this: 'snapshot recovery is performed at the same baseline topology with the same node consistent Id.'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;

Review comment:
       ...leaves the cluster

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;

Review comment:
       taking a snapshot of a particular cache or cache group is not supported;

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;

Review comment:
       Copy all snapshot files from the snapshot related to `{node_id}` to the `$IGNITE_HOME/work/{node_id}` directory;

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.

Review comment:
       The destination snapshot can be configured via `IgniteConfiguration`.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)

Review comment:
       It'd be better to name this section like 'Cluster restoring from a snapshot (manual)'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to

Review comment:
       '...act like a tool...'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.

Review comment:
       NOTE: Removing data from the `$IGNITE_HOME/work` directory is performed at your own risk.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.

Review comment:
       started ---> initiated maybe?

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:

Review comment:
       '...currently running one via...'

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;

Review comment:
       ...a consistent id of a node you work with;

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:

Review comment:
       Here are some options:

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,

Review comment:
       ... the data recovery procedure...

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process will
+require the cluster to be rebalanced and SQL indexes to be rebuilt which may take a long time.
+|m > n | Currently, not supported.

Review comment:
       Currently, it is not supported.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;

Review comment:
       Locate the snapshot you've created by name;

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.

Review comment:
       Use the same baseline and configuration.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process will
+require the cluster to be rebalanced and SQL indexes to be rebuilt which may take a long time.

Review comment:
       The process will require the cluster to be rebalanced and SQL indexes to be rebuilt. These operations may take a long time.

##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+    └── backup23012020
+        ├── binary_meta
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        ├── db
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest0
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-3.bin
+        │   │       ├── part-4.bin
+        │   │       └── part-6.bin
+        │   ├── snapshot_IgniteClusterSnapshotSelfTest1
+        │   │   └── cache-txCache
+        │   │       ├── cache_data.dat
+        │   │       ├── part-1.bin
+        │   │       ├── part-5.bin
+        │   │       └── part-7.bin
+        │   └── snapshot_IgniteClusterSnapshotSelfTest2
+        │       └── cache-txCache
+        │           ├── cache_data.dat
+        │           ├── part-0.bin
+        │           └── part-2.bin
+        └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:

Review comment:
       To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org