diff --git a/qdrant-landing/content/documentation/cloud/backups.md b/qdrant-landing/content/documentation/cloud/backups.md
index 5fb1eec91..4baae580b 100644
--- a/qdrant-landing/content/documentation/cloud/backups.md
+++ b/qdrant-landing/content/documentation/cloud/backups.md
@@ -14,10 +14,15 @@ For less critical use-cases you can make use of one of the available options.
 Qdrant engine offers a snapshot API that allows to create a snapshot of a particular collection or even the whole storage.
 Please refer to the [snapshot documentation](../../snapshots/) for details.
 
-In case of a single node cluster, simply call the snapshot endpoint on the exposed url.
-In case of a multi node cluster you’d need to take a snapshot on each node that the collection resides upon. 
-To achieve this, you simply prepend `node-{num}-` to your cluster url and call the snapshot endpoint on the individual hosts, starting with node 0 up to the number of nodes minus one.
-You can recover snapshots the same way via api.
+A quick recipe for successfully snapshotting and recovering a collection:
+
+1. Take a snapshot
+   - In case of a single node cluster, simply call the snapshot endpoint on the exposed url. 
+   - In case of a multi node cluster you’d need to take a snapshot on each node that the collection resides upon. To achieve this, you simply prepend `node-{num}-` to your cluster url and call the [snapshot endpoint](../..//snapshots/#create-snapshot) on the individual hosts, starting with node 0 up to the number of nodes minus one.
+   - In the response you'll get the name of the snapshot taken.
+2. Delete and recreate the collection.
+3. Recover the snapshot
+   - Call the [recover endpoint](../../snapshots/#recover-in-cluster-deployment) with location pointing to the snapshot file (`file:///qdrant/snapshots/{collection_name}/{snapshot_file_name}`) you got for each host.
 
 
 ## Automatic backups
diff --git a/qdrant-landing/content/documentation/storage.md b/qdrant-landing/content/documentation/storage.md
index 0eeeb196a..96bc5345c 100644
--- a/qdrant-landing/content/documentation/storage.md
+++ b/qdrant-landing/content/documentation/storage.md
@@ -27,26 +27,8 @@ The choice has to be made between the search speed and the size of the RAM used.
 **Memmap storage** -  creates a virtual address space associated with the file on disk. [Wiki](https://en.wikipedia.org/wiki/Memory-mapped_file).
 Mmapped files are not directly loaded into RAM. Instead, they use page cache to access the contents of the file.
 This scheme allows flexible use of available memory. With sufficient RAM, it is almost as fast as in-memory storage.
-
-<!--
 However, dynamically adding vectors to the mmap file is fairly complicated and is not implemented in Qdrant.
 Thus, segments using mmap storage are `non-appendable` and can only be construed by the optimizer.
-But it only matters for internal operations, so you can safely ignore this fact.
-If you update a vector in a segment with mmap storage, the vector will be moved to appendable segment first, and then the old vector will be deleted from the mmap segment. 
--->
-
-### Configuring Memmap storage
-
-To configure usage of mmap storage, you need to specify the threshold after which the segment will be converted to mmap storage.
-There are two ways to do this:
-
-1. You can set the threshold globally in the [configuration file](../configuration/). The parameter is called `memmap_threshold_kb`.
-2. You can set the threshold for each collection separately during [creation](../collections/#create-collection) or [update](../collections/#update-collection-parameters).
-
-
-In addition, you can use mmap storage not only for vectors, but also for HNSW index.
-To enable this, you need to set the `hnsw_config.on_disk` parameter to `true` during [creation](../collections/#create-collection) of the collection.
-
 
 ### Configuring Memmap storage