[Yandex Cloud documentation](../../index.md) > [Yandex StoreDoc](../index.md) > [Concepts](index.md) > Storage in Yandex StoreDoc # Storage in Yandex StoreDoc Yandex StoreDoc allows you to use network and local storage drives for database clusters. Network drives are based on network blocks, i.e., virtual drives in the Yandex Cloud infrastructure. Local drives are physically located on the database host servers. When creating a cluster, you can select the following disk types for data storage: * **Network HDDs** (`network-hdd`): Most cost-effective option for clusters with low requirements for read and write performance. * **Network SSDs** (`network-ssd`): Compromise solution: slower than local SSDs, network SSDs ensure data integrity in the event of Yandex Cloud hardware failure. * **Non-replicated SSDs** (`network-ssd-nonreplicated`): Network disks with higher performance achieved by eliminating redundancy. You can only expand this type of storage in 93 GB increments. * **Ultra high-speed network SSDs with three replicas** (`network-ssd-io-m3`): Network disks that deliver performance equivalent to non-replicated SSDs while ensuring redundancy. You can only increase the size of these disks in 93 GB increments. * **Local SSDs** (`local-ssd`): Highest-performing disks. You can expand such a storage as follows: * For **Intel Broadwell** and **Intel Cascade Lake**: Only in 100 GB increments. * For **Intel Ice Lake** and **AMD Zen 4**: Only in 368 GB increments. For a list of host classes and corresponding platforms, see [Host classes](instance-types.md). For clusters with hosts residing in the `ru-central1-d` [availability zone](../../overview/concepts/geo-scope.md), local SSD storage is not available if using Intel Cascade Lake. [Block](https://en.wikipedia.org/wiki/Block_(data_storage)) size for all disk types is 4 KB. {% note info %} Up to 5% of disk space is reserved for system use, so the disks may have less available space than indicated when creating a cluster. For more information about sizes and performance of different disk types, see [this Yandex Compute Cloud guide](../../compute/concepts/limits.md#compute-limits-disks). {% endnote %} ## Selecting disk type when creating a cluster {#storage-type-selection} The number of hosts you can create together with a Yandex StoreDoc cluster depends on the selected disk type: * You can create a cluster only with three or more hosts when using the following disk types: * Local SSDs (`local-ssd`) * Non-replicated SSDs (`network-ssd-nonreplicated`) Storage on local SSDs increases your cluster costs: you pay for the cluster even if it is stopped. For more information, see the [pricing policy](../pricing.md). * You can add any number of hosts within the current quota when using the following disk types: * Network HDDs (`network-hdd`) * Network SSDs (`network-ssd`) * Ultra high-speed network SSDs with three replicas (`network-ssd-io-m3`) For more information about limits on the number of hosts per cluster or [shard](sharding.md), see [Quotas and limits](limits.md). ## Disk encryption {#disk-encryption} When creating or restoring a cluster from a backup, you can encrypt the storage disk with a [custom KMS key](../../kms/concepts/key.md). To encrypt a disk of an already created cluster, disable encryption, or encrypt a disk with a different key, create a backup of the cluster and restore it with the new settings. To create an encrypted disk, you need the `kms.keys.user` [role](../../kms/security/index.md#kms-keys-user) or higher. If you deactivate the key used to encrypt a disk, access to the data will be suspended until you reactivate the key. {% note alert %} If you delete the key used to encrypt a disk or its [version](../../kms/concepts/version.md), you will irrevocably lose access to your data. For more information, see [this Key Management Service guide](../../kms/concepts/version.md#version-distruct). {% endnote %} ## Managing disk space {#manage-storage-space} If at least one host in a Yandex StoreDoc cluster runs out of allocated disk space, the Yandex StoreDoc instance on this host will crash and the host will be disabled. If the host was a [`PRIMARY` replica](replication.md), this role will be assigned to one of the `SECONDARY` replicas. As a result of migrating the `PRIMARY` role from one host to another, you may run out of disk space on all hosts in the cluster, which will result in a complete cluster failure. To avoid this, Yandex StoreDoc monitors how much disk space is used and automatically activates _read-only_ mode (using the `db.fsyncLock` method) for those cluster hosts that have: * Less than 500 MB of free disk space left (if the host storage size is less than 600 GB). * Less than 5 GB of free disk space left (if the host storage size is 600 GB or more). After switching to _read-only_ mode: * Write queries stop being allowed on the host. You can only make read queries. * If the host was a [primary replica](replication.md) before switching to _read-only_ mode, this role will be automatically assigned to another cluster host, as the primary replica should be able to write to disk. If the data amount in the cluster keeps growing, all hosts will enter _read-only_ mode one by one and the cluster will eventually stop accepting data for writing. ### Maintaining a cluster in operable condition {#read-only-solutions} To keep your cluster up and running as the host is switching over to _read-only_: * [Increase the disk space on the host](../operations/update.md#change-disk-size). If there is enough space on the host, Yandex Cloud will clear _read-only_ mode automatically. * [Add more shards to the cluster](../operations/shards.md#add-shard). _Read-only_ mode will not be cleared on this host, but the cluster will be able to keep working normally as long as there is free disk space on the other shards. * Ask [support](https://center.yandex.cloud/support) to temporarily suspend _read-only_ mode on this host to manually delete some of the data. {% note alert %} If free disk space drops to zero, Yandex StoreDoc will crash and the cluster will stop operating. {% endnote %} * [Force data synchronization](../operations/hosts.md#resetup) between hosts. This can help when a large amount of data was deleted from the cluster, but the disk space was not released (marked as available for reuse). * Run the `compact` command. First, [add](../operations/cluster-users.md#updateuser) the [mdbDbAdmin role](users-and-roles.md#mdbdbadmin) to the user. ## Use cases {#examples} * [Migrating data to Yandex StoreDoc](../tutorials/data-migration.md) * [Migrating collections from MongoDB to Yandex StoreDoc](../tutorials/storedoc-migration-with-data-transfer.md) * [Migrating a Yandex StoreDoc cluster from version 4.4 to 6.0 using Yandex Data Transfer](../tutorials/storedoc-versions.md) * [MongoDB performance analysis and optimization](../tutorials/profiling.md)