[Yandex Cloud documentation](../../index.md) > [Yandex StoreDoc](../index.md) > [Step-by-step guides](index.md) > Clusters > Managing backups # Managing backups in Yandex StoreDoc You can [back up](../concepts/backup.md) your clusters and restore them using existing backups. Yandex StoreDoc automatically takes a daily backup as well. For this backup, you can [configure the start time and retention period](update.md#change-additional-settings). ## Restoring a cluster from a backup {#restore} {% note warning %} For clusters running an unsupported DBMS version, restoring from backups is not available. {% endnote %} Before you begin, [assign](../../iam/operations/roles/grant.md) the [managed-mongodb.restorer](../../iam/roles-reference.md#managed-mongodb-restorer) or higher role to your Yandex Cloud account for both the backup folder and the new cluster folder. {% list tabs group=instructions %} - Management console {#console} To restore an existing cluster from a backup: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. Click the name of your cluster and select the ![image](../../_assets/console-icons/archive.svg) **Backups** tab. 1. Click the ![image](../../_assets/console-icons/ellipsis.svg) icon in the backup row and select **Restore cluster**. To restore a sharded cluster, use a [sharded backup](../concepts/backup.md#size). Such backups are larger in size. 1. Configure the new cluster. You can select a folder for the new cluster from the **Folder** list. 1. To restore the cluster’s state to a specific point in time after the backup was created, configure **Date and time of recovery (UTC)** accordingly. You can either specify the date manually or select it using the date picker. If you leave this setting unchanged, the cluster will be restored to the state when the backup was completed. 1. Click **Restore cluster**. To restore a previously deleted cluster from a backup: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. In the left-hand panel, select ![image](../../_assets/console-icons/archive.svg) **Backups**. 1. Find the backup you need using its creation time and cluster ID. The **ID** column contains IDs in `:` format. If you want to restore a sharded cluster, find its [sharded backup](../concepts/backup.md#size). Such backups are larger in size. 1. Click the ![image](../../_assets/console-icons/ellipsis.svg) icon in the backup row and select **Restore cluster**. 1. Configure the new cluster. You can select a folder for the new cluster from the **Folder** list. 1. To restore the cluster’s state to a specific point in time after the backup was created, configure **Date and time of recovery (UTC)** accordingly. You can either specify the date manually or select it using the date picker. If you leave this setting unchanged, the cluster will be restored to the state when the backup was completed. 1. Click **Restore cluster**. Yandex StoreDoc will start creating the cluster from the backup. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To restore a cluster from a backup: 1. View the description of the CLI command for restoring a Yandex StoreDoc cluster: ```bash yc managed-mongodb cluster restore --help ``` 1. Get the list of available Yandex StoreDoc cluster backups: ```bash yc managed-mongodb backup list ``` Result: ```text +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ | ID | CREATED AT | SOURCE CLUSTER ID | STARTED AT | SIZE | TYPE | +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ | c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 | 3.3 KB | AUTOMATED | | ... | | +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ ``` You can see the backup completion time in the `CREATED AT` column of the available backups list. It is formatted as `yyyy-mm-dd hh:mm:ss`, e.g., `2020-08-10 12:00:00` in the example above. You can restore your cluster to any point in time since the backup was created. 1. Run the command below to create a new cluster from a backup. Note that these examples do not show all available command options. For a non-sharded cluster: ```bash yc managed-mongodb cluster restore \ --backup-id \ --recovery-target-timestamp \ --mongodb-version \ --name \ --environment \ --network-name \ --host zone-id=,` `subnet-id= \ --mongod-resource-preset \ --mongod-disk-size \ --mongod-disk-type \ --disk-size-autoscaling mongod-disk-size-limit=,` `mongod-planned-usage-threshold=,` `mongod-emergency-usage-threshold= \ --maintenance-window type=,` `day=,` `hour= \ --performance-diagnostics= ``` For a sharded cluster: ```bash yc managed-mongodb cluster restore \ --backup-id \ --recovery-target-timestamp \ --mongodb-version \ --name \ --environment \ --network-name \ --host zone-id=,` `subnet-id=,` `type=mongod,` `shard-name= \ --mongod-resource-preset \ --mongod-disk-size \ --mongod-disk-type \ --host zone-id=,` `subnet-id=,` `type= \ ... --host zone-id=,` `subnet-id=,` `type= \ ---resource-preset \ ---disk-size \ ---disk-type \ --disk-size-autoscaling mongod-disk-size-limit=,` `mongod-planned-usage-threshold=,` `mongod-emergency-usage-threshold=,` ... `-disk-size-limit=,` `-planned-usage-threshold=,` `-emergency-usage-threshold= \ --maintenance-window type=,` `day=,` `hour= \ --performance-diagnostics= ``` Where: * `--backup-id`: Backup ID. To restore a sharded cluster, specify the [sharded backup](../concepts/backup.md#size) ID. Such backups are larger in size. To find out the ID, [get a list of backups in the folder](#list-backups). * `--recovery-target-timestamp`: Target recovery time for the Yandex StoreDoc cluster, in [UNIX time](https://en.wikipedia.org/wiki/Unix_time) format. If you omit this argument, the cluster will be restored to its state at the time of backup completion. * `--mongodb-version`: Yandex StoreDoc version. * `--name`: New cluster’s name. * `--environment`: Environment, `PRESTABLE` or `PRODUCTION`. * `--network-name`: Name of the [network](../../vpc/concepts/network.md#network) the cluster will be deployed in. * `--mongod-resource-preset`: MONGOD [ host class](../concepts/instance-types.md). * `--mongod-disk-size`: Storage size for MONGOD hosts, GB. * `--mongod-disk-type`: Disk type for MONGOD hosts: `network-hdd`, `network-ssd`, or `network-ssd-io-m3`. * `---resource-preset`, `---disk-size`, `---disk-type`: Host parameters controlling cluster sharding. The possible `` values are `mongoinfra`, `mongocfg`, or `mongos`. * `--disk-size-autoscaling`: Storage autoscaling settings. The `` can take the following values: `mongod` for sharded and non-sharded clusters; `mongoinfra`, `mongocfg`, or `mongos` only for sharded clusters. * `-planned-usage-threshold`: Storage usage percentage to trigger a storage expansion during the next [maintenance window](../concepts/maintenance.md#maintenance-window). Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. If you specified a value greater than `0`, configure the maintenance schedule. * `-emergency-usage-threshold`: Storage usage percentage to trigger an immediate storage expansion. Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. The value of this setting must be greater than or equal to `-planned-usage-threshold`. * `-disk-size-limit`: Maximum storage size, in GB, that can be set if the usage percentage reaches one of the specified thresholds. If you set it to `0`, automatic storage expansion will be disabled. * `--maintenance-window`: [Maintenance](../concepts/maintenance.md) window settings, applying to both running and stopped clusters. In `--maintenance-window`, provide one of these two values: * `anytime`: Any time (default). * `weekly`: On a schedule. For this value, also specify the following: * `day`: Day of week, i.e., `MON`, `TUE`, `WED`, `THU`, `FRI`, `SAT`, or `SUN`. * `hour`: Sequence number of UTC hour interval, from `1` to `24`. > For example, `1` stands for the interval from `00:00` to `01:00`, and `5`, from `04:00` to `05:00`. * `--performance-diagnostics`: Enables cluster performance diagnostics, `true` or `false`. - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Create a file named `body.json` and paste the following code into it: ```json { "folderId": "", "backupId": "", "name": "", "environment": "", "networkId": "", "recoveryTargetSpec": { "timestamp": "" }, "configSpec": { "version": "", "mongodb": { "": { "resources": { "resourcePresetId": "", "diskSize": "", "diskTypeId": "" }, "diskSizeAutoscaling": { "plannedUsageThreshold": "", "emergencyUsageThreshold": "", "diskSizeLimit": "" } }, ... "": { "resources": { "resourcePresetId": "", "diskSize": "", "diskTypeId": "" }, "diskSizeAutoscaling": { "plannedUsageThreshold": "", "emergencyUsageThreshold": "", "diskSizeLimit": "" } } } }, "hostSpecs": [ { "zoneId": "", "subnetId": "", "assignPublicIp": , "type": "", "shardName": "", "hidden": , "secondaryDelaySecs": "", "priority": "", "tags": "" } ], "maintenanceWindow": { "weeklyMaintenanceWindow": { "day": "", "hour": "" } } } ``` Where: * `folderId`: Folder ID. You can get it from the [list of your cloud folders](../../resource-manager/operations/folder/get-id.md). * `backupId`: Backup ID. To restore a sharded cluster, specify the [sharded backup](../concepts/backup.md#size) ID. Such backups are larger in size. To learn the ID, [get the list of backups in the folder](cluster-backups.md#list-backups). * `name`: New cluster’s name. * `environment`: Cluster environment, `PRODUCTION` or `PRESTABLE`. * `networkId`: ID of the [network](../../vpc/concepts/network.md#network) where the cluster will be deployed. * `recoveryTargetSpec.timestamp`: Target recovery time for the Yandex StoreDoc cluster, in [UNIX time](https://en.wikipedia.org/wiki/Unix_time) format. If you omit this argument, the cluster will be restored to its state at the time of backup completion. * `configSpec`: Cluster settings: * `version`: Yandex StoreDoc version, 5.0, 6.0, or 7.0. * Yandex StoreDoc host type depends on the [sharding type](../concepts/sharding.md). The possible values are `mongod`, `mongocfg`, `mongos`, and `mongoinfra`. For a non-sharded cluster, use `mongod`. * `resources`: Cluster resources: * `resourcePresetId`: [Host class](../concepts/instance-types.md). * `diskSize`: Disk size in bytes. * `diskTypeId`: [Disk type](../concepts/storage.md). * `diskSizeAutoscaling`: Storage autoscaling settings: * `plannedUsageThreshold`: Storage usage percentage to trigger a storage expansion during the next [maintenance window](../concepts/maintenance.md#maintenance-window). Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. If you specified a value greater than `0`, configure the maintenance schedule. * `emergencyUsageThreshold`: Storage usage percentage to trigger an immediate storage expansion. Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. The value of this setting must be greater than or equal to `plannedUsageThreshold`. * `diskSizeLimit`: Maximum storage size, in bytes, that can be set when storage usage reaches one of the specified thresholds. If you set it to `0`, automatic storage expansion will be disabled. * `hostSpecs`: Cluster host settings as an array of elements, one per host. Each element has the following structure: * `zoneId`: [Availability zone](../../overview/concepts/geo-scope.md). * `subnetId`: [Subnet ID](../../vpc/concepts/network.md#subnet). * `assignPublicIp`: Internet access to the host via a public IP address, `true` or `false`. * `type`: Host type in a sharded cluster, `MONGOD`, `MONGOINFRA`, `MONGOS`, or `MONGOCFG`. For a non-sharded cluster, use `MONGOD`. * `shardName`: Shard name in a sharded cluster. * `hidden`: Specifies whether to hide (`true`) or display (`false`) the host. * `secondaryDelaySecs`: Host’s replication lag behind the master. * `priority`: Host priority for master promotion during [failover](../concepts/replication.md#master-failover). * `tags`: Host tags. * `maintenanceWindow`: Maintenance window settings, applying to both running and stopped clusters. In `maintenanceWindow`, provide one of these two values: * `anytime`: Maintenance takes place at any time. * `weeklyMaintenanceWindow`: Maintenance takes place once a week at the specified time: * `day`: Day of week in `DDD` format, i.e., `MON`, `TUE`, `WED`, `THU`, `FRI`, `SAT`, or `SUN`. * `hour`: Hour of the day, in `HH` format. Allowed values range from `1` to `24` hours. 1. Call the [Cluster.Restore](../api-ref/Cluster/restore.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request POST \ --header "Authorization: Bearer $IAM_TOKEN" \ --header "Content-Type: application/json" \ --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters:restore' \ --data "@body.json" ``` 1. Check the [server response](../api-ref/Cluster/restore.md#yandex.cloud.operation.Operation) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Create a file named `body.json` and paste the following code into it: ```json { "folder_id": "", "backup_id": "", "name": "", "environment": "", "network_id": "", "recovery_target_spec": { "timestamp": "" }, "config_spec": { "version": "", "mongodb": { "": { "resources": { "resource_preset_id": "", "disk_size": "", "disk_type_id": "" }, "disk_size_autoscaling": { "planned_usage_threshold": "", "emergency_usage_threshold": "", "disk_size_limit": "" } }, ... "": { "resources": { "resource_preset_id": "", "disk_size": "", "disk_type_id": "" }, "disk_size_autoscaling": { "planned_usage_threshold": "", "emergency_usage_threshold": "", "disk_size_limit": "" } } } }, "host_specs": [ { "zone_id": "", "subnet_id": "", "assign_public_ip": , "type": "", "shard_name": "", "hidden": , "secondary_delay_secs": "", "priority": "", "tags": "" } ], "maintenance_window": { "weekly_maintenance_window": { "day": "", "hour": "" } } } ``` Where: * `folder_id`: Folder ID. You can get it with the [list of folders in the cloud](../../resource-manager/operations/folder/get-id.md). * `backup_id`: Backup ID. To restore a sharded cluster, specify the [sharded backup](../concepts/backup.md#size) ID. Such backups are larger in size. To learn the ID, [get the list of backups in the folder](cluster-backups.md#list-backups). * `name`: New cluster’s name. * `environment`: Cluster environment, `PRODUCTION` or `PRESTABLE`. * `network_id`: ID of the [network](../../vpc/concepts/network.md#network) where the cluster will be deployed. * `recovery_target_spec.timestamp`: Target recovery time for the Yandex StoreDoc cluster, in [UNIX time](https://en.wikipedia.org/wiki/Unix_time) format. If you omit this setting, the cluster will be restored to the backup’s completion time. * `config_spec`: Cluster settings: * `version`: Yandex StoreDoc version, 5.0, 6.0, or 7.0. * Yandex StoreDoc host type depends on the [sharding type](../concepts/sharding.md). The possible values are `mongod`, `mongocfg`, `mongos`, and `mongoinfra`. For a non-sharded cluster, use `mongod`. * `resources`: Cluster resources: * `resource_preset_id`: [Host class](../concepts/instance-types.md). * `disk_size`: Disk size in bytes. * `disk_type_id`: [Disk type](../concepts/storage.md). * `disk_size_autoscaling`: Storage autoscaling settings: * `planned_usage_threshold`: Storage usage percentage to trigger a storage expansion during the next [maintenance window](../concepts/maintenance.md#maintenance-window). Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. If you specified a value greater than `0`, configure the maintenance schedule. * `emergency_usage_threshold`: Storage usage percentage to trigger an immediate storage expansion. Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. The value of this setting must be greater than or equal to `planned_usage_threshold`. * `disk_size_limit`: Maximum storage size, in bytes, that can be set when storage usage reaches one of the specified thresholds. If you set it to `0`, automatic storage expansion will be disabled. * `host_specs`: Cluster host settings as an array of elements, one per host. Each element has the following structure: * `zone_id`: [Availability zone](../../overview/concepts/geo-scope.md). * `subnet_id`: [Subnet ID](../../vpc/concepts/network.md#subnet). * `assign_public_ip`: Internet access to the host via a public IP address, `true` or `false`. * `type`: Host type in a sharded cluster, `MONGOD`, `MONGOINFRA`, `MONGOS`, or `MONGOCFG`. For a non-sharded cluster, use `MONGOD`. * `shard_name`: Shard name in a sharded cluster. * `hidden`: Specifies whether to hide (`true`) or display (`false`) the host. * `secondary_delay_secs`: Host’s replication lag behind the master. * `priority`: Host priority for master promotion during [failover](../concepts/replication.md#master-failover). * `tags`: Host tags. * `maintenance_window`: Maintenance window settings, applying to both running and stopped clusters. In `maintenance_window`, provide one of these two values: * `anytime`: Maintenance takes place at any time. * `weekly_maintenance_window`: Maintenance takes place once a week at the specified time: * `day`: Day of week in `DDD` format, i.e., `MON`, `TUE`, `WED`, `THU`, `FRI`, `SAT`, or `SUN`. * `hour`: Hour of the day, in `HH` format. Allowed values range from `1` to `24` hours. 1. Call the [ClusterService.Restore](../api-ref/grpc/Cluster/restore.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d @ \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mongodb.v1.ClusterService.Restore \ < body.json ``` 1. Check the [server response](../api-ref/grpc/Cluster/restore.md#yandex.cloud.operation.Operation) to make sure your request was successful. {% endlist %} ## Restoring individual databases and collections from a backup {#restore-database} {% list tabs group=instructions %} - Management console {#console} To restore databases and collections of an existing cluster: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. Click the name of your cluster and select the ![image](../../_assets/console-icons/archive.svg) **Backups** tab. 1. Click the ![image](../../_assets/console-icons/ellipsis.svg) icon in the backup row and select **Restore cluster**. To restore a sharded cluster, use a [sharded backup](../concepts/backup.md#size). Such backups are larger in size. 1. Configure the new cluster. You can select a folder for the new cluster from the **Folder** list. 1. To restore the cluster’s state to a specific point in time after the backup was created, configure **Date and time of recovery (UTC)** accordingly. You can either specify the date manually or select it using the date picker. If you leave this setting unchanged, the cluster will be restored to the state when the backup was completed. 1. Enable **Partial recovery** and configure the additional settings: 1. Click **Restore** and specify the list of databases or collections to restore. 1. Click **Exclude** and specify a list of databases or collections to exclude from recovery. Database names have to be entered manually. You can select collections from a dropdown list or enter them manually in this format: `.`. Examples: `db1`, `db2.collection1`. You can specify databases and collections either for one action only or for both actions at once. For example, if you have databases specified for restoration, you can exclude individual collections from those databases. If only the **Exclude** action is selected, all databases and collections will be restored except those specified for exclusion. Databases and collections selected for restoration are shown in green; those selected for exclusion are shown in gray. 1. For clusters with autoscaling, set the [maintenance window](../concepts/maintenance.md) under **Maintenance** (day and hour in UTC). 1. Click **Restore cluster**. To restore databases and collections of a previously deleted cluster: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. In the left-hand panel, select ![image](../../_assets/console-icons/archive.svg) **Backups**. 1. Find the backup you need using its creation time and cluster ID. The **ID** column contains IDs in `:` format. If you want to restore a sharded cluster, find its [sharded backup](../concepts/backup.md#size). Such backups are larger in size. 1. Click the ![image](../../_assets/console-icons/ellipsis.svg) icon in the backup row and select **Restore cluster**. 1. Configure the new cluster. You can select a folder for the new cluster from the **Folder** list. 1. To restore the cluster’s state to a specific point in time after the backup was created, configure **Date and time of recovery (UTC)** accordingly. You can either specify the date manually or select it using the date picker. If you leave this setting unchanged, the cluster will be restored to the state when the backup was completed. 1. Enable **Partial recovery** and configure the additional settings: 1. Click **Restore** and specify the list of databases or collections to restore. 1. Click **Exclude** and specify a list of databases or collections to exclude from recovery. Database names have to be entered manually. You can select collections from a dropdown list or enter them manually in this format: `.`. Examples: `db1`, `db2.collection1`. You can specify databases and collections either for one action only or for both actions at once. For example, if you have databases specified for restoration, you can exclude individual collections from those databases. If only the **Exclude** action is selected, all databases and collections will be restored except those specified for exclusion. Databases and collections selected for restoration are shown in green; those selected for exclusion are shown in gray. 1. For clusters with autoscaling, set the [maintenance window](../concepts/maintenance.md) under **Maintenance** (day and hour in UTC). 1. Click **Restore cluster**. Yandex StoreDoc will start creating the cluster from the backup. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To restore individual databases and collections from a backup: 1. View the description of the CLI command for restoring a Yandex StoreDoc cluster: ```bash yc managed-mongodb cluster restore --help ``` 1. Get the list of available Yandex StoreDoc cluster backups: ```bash yc managed-mongodb backup list ``` Result: ```text +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ | ID | CREATED AT | SOURCE CLUSTER ID | STARTED AT | SIZE | TYPE | +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ | c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 | 3.3 KB | AUTOMATED | | ... | | +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ ``` You can see the backup completion time in the `CREATED AT` column of the available backups list. It is formatted as `yyyy-mm-dd hh:mm:ss`, e.g., `2020-08-10 12:00:00` in the example above. You can restore your cluster to any point in time since the backup was created. 1. Run the command to create a new cluster from a backup. Use `--whitelist` to specify which databases and collections to restore, or `--blacklist` to define exclusions. For a non-sharded cluster: ```bash yc managed-mongodb cluster restore \ --backup-id \ --recovery-target-timestamp \ --mongodb-version \ --name \ --environment \ --network-name \ --host zone-id=,` `subnet-id= \ --mongod-resource-preset \ --mongod-disk-size \ --mongod-disk-type \ --disk-size-autoscaling mongod-disk-size-limit=,` `mongod-planned-usage-threshold=,` `mongod-emergency-usage-threshold= \ --maintenance-window type=,` `day=,` `hour= \ --performance-diagnostics= \ --whitelist \ --blacklist ``` For a sharded cluster: ```bash yc managed-mongodb cluster restore \ --backup-id \ --recovery-target-timestamp \ --mongodb-version \ --name \ --environment \ --network-name \ --host zone-id=,` `subnet-id=,` `type=mongod,` `shard-name= \ --mongod-resource-preset \ --mongod-disk-size \ --mongod-disk-type \ --host zone-id=,` `subnet-id=,` `type= \ ... --host zone-id=,` `subnet-id=,` `type= \ ---resource-preset \ ---disk-size \ ---disk-type \ --disk-size-autoscaling mongod-disk-size-limit=,` `mongod-planned-usage-threshold=,` `mongod-emergency-usage-threshold=,` ... `-disk-size-limit=,` `-planned-usage-threshold=,` `-emergency-usage-threshold= \ --maintenance-window type=,` `day=,` `hour= \ --performance-diagnostics= --whitelist \ --blacklist ``` Where: * `--backup-id`: Backup ID. To restore a sharded cluster, specify the [sharded backup](../concepts/backup.md#size) ID. Such backups are larger in size. To find out the ID, [get a list of backups in the folder](#list-backups). * `--recovery-target-timestamp`: Target recovery time for the Yandex StoreDoc cluster, in [UNIX time](https://en.wikipedia.org/wiki/Unix_time) format. If you omit this argument, the cluster will be restored to its state at the time of backup completion. * `--mongodb-version`: Yandex StoreDoc version. * `--name`: New cluster’s name. * `--environment`: Environment, `PRESTABLE` or `PRODUCTION`. * `--network-name`: Name of the [network](../../vpc/concepts/network.md#network) the cluster will be deployed in. * `--mongod-resource-preset`: MONGOD [ host class](../concepts/instance-types.md). * `--mongod-disk-size`: Storage size for MONGOD hosts, GB. * `--mongod-disk-type`: Disk type for MONGOD hosts: `network-hdd`, `network-ssd`, or `network-ssd-io-m3`. * `---resource-preset`, `---disk-size`, `---disk-type`: Host parameters controlling cluster sharding. The possible `` values are `mongoinfra`, `mongocfg`, or `mongos`. * `--disk-size-autoscaling`: Storage autoscaling settings. The `` can take the following values: `mongod` for sharded and non-sharded clusters; `mongoinfra`, `mongocfg`, or `mongos` only for sharded clusters. * `-planned-usage-threshold`: Storage usage percentage to trigger a storage expansion during the next [maintenance window](../concepts/maintenance.md#maintenance-window). Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. If you specified a value greater than `0`, configure the maintenance schedule. * `-emergency-usage-threshold`: Storage usage percentage to trigger an immediate storage expansion. Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. The value of this setting must be greater than or equal to `-planned-usage-threshold`. * `-disk-size-limit`: Maximum storage size, in GB, that can be set if the usage percentage reaches one of the specified thresholds. If you set it to `0`, automatic storage expansion will be disabled. * `--maintenance-window`: [Maintenance](../concepts/maintenance.md) window settings, applying to both running and stopped clusters. In `--maintenance-window`, provide one of these two values: * `anytime`: Any time (default). * `weekly`: On a schedule. For this value, also specify the following: * `day`: Day of week, i.e., `MON`, `TUE`, `WED`, `THU`, `FRI`, `SAT`, or `SUN`. * `hour`: Sequence number of UTC hour interval, from `1` to `24`. > For example, `1` stands for the interval from `00:00` to `01:00`, and `5`, from `04:00` to `05:00`. * `--performance-diagnostics`: Enables cluster performance diagnostics, `true` or `false`. * Settings for restoring individual databases and collections: * `--whitelist`: List of databases and collections to restore, e.g., `"db1","db2.collection1"`. * `--blacklist`: List of databases and collections to exclude from restoring, e.g., `"db1.collection1"`. If you specify databases under `--whitelist`, you can use `--blacklist` to exclude specific collections within those databases. If the `--whitelist` parameter is not specified, all databases and collections will be restored except those specified under `--blacklist`. - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Create a file named `body.json` and paste the following code into it: ```json { "folderId": "", "backupId": "", "name": "", "environment": "", "networkId": "", "recoveryTargetSpec": { "timestamp": "" }, "configSpec": { "version": "", "mongodb": { "": { "resources": { "resourcePresetId": "", "diskSize": "", "diskTypeId": "" }, "diskSizeAutoscaling": { "plannedUsageThreshold": "", "emergencyUsageThreshold": "", "diskSizeLimit": "" } }, ... "": { "resources": { "resourcePresetId": "", "diskSize": "", "diskTypeId": "" }, "diskSizeAutoscaling": { "plannedUsageThreshold": "", "emergencyUsageThreshold": "", "diskSizeLimit": "" } } } }, "hostSpecs": [ { "zoneId": "", "subnetId": "", "assignPublicIp": , "type": "", "shardName": "", "hidden": , "secondaryDelaySecs": "", "priority": "", "tags": "" } ], "maintenanceWindow": { "weeklyMaintenanceWindow": { "day": "", "hour": "" } }, "partialRestoreSpec": { "whitelist": [], "blacklist": [] } } ``` Where: * `folderId`: Folder ID. You can get it from the [list of your cloud folders](../../resource-manager/operations/folder/get-id.md). * `backupId`: Backup ID. To restore a sharded cluster, specify the [sharded backup](../concepts/backup.md#size) ID. Such backups are larger in size. To learn the ID, [get the list of backups in the folder](cluster-backups.md#list-backups). * `name`: New cluster’s name. * `environment`: Cluster environment, `PRODUCTION` or `PRESTABLE`. * `networkId`: ID of the [network](../../vpc/concepts/network.md#network) where the cluster will be deployed. * `recoveryTargetSpec.timestamp`: Target recovery time for the Yandex StoreDoc cluster, in [UNIX time](https://en.wikipedia.org/wiki/Unix_time) format. If you omit this argument, the cluster will be restored to its state at the time of backup completion. * `configSpec`: Cluster settings: * `version`: Yandex StoreDoc version, 5.0, 6.0, or 7.0. * Yandex StoreDoc host type depends on the [sharding type](../concepts/sharding.md). The possible values are `mongod`, `mongocfg`, `mongos`, and `mongoinfra`. For a non-sharded cluster, use `mongod`. * `resources`: Cluster resources: * `resourcePresetId`: [Host class](../concepts/instance-types.md). * `diskSize`: Disk size in bytes. * `diskTypeId`: [Disk type](../concepts/storage.md). * `diskSizeAutoscaling`: Storage autoscaling settings: * `plannedUsageThreshold`: Storage usage percentage to trigger a storage expansion during the next [maintenance window](../concepts/maintenance.md#maintenance-window). Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. If you specified a value greater than `0`, configure the maintenance schedule. * `emergencyUsageThreshold`: Storage usage percentage to trigger an immediate storage expansion. Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. The value of this setting must be greater than or equal to `plannedUsageThreshold`. * `diskSizeLimit`: Maximum storage size, in bytes, that can be set when storage usage reaches one of the specified thresholds. If you set it to `0`, automatic storage expansion will be disabled. * `hostSpecs`: Cluster host settings as an array of elements, one per host. Each element has the following structure: * `zoneId`: [Availability zone](../../overview/concepts/geo-scope.md). * `subnetId`: [Subnet ID](../../vpc/concepts/network.md#subnet). * `assignPublicIp`: Internet access to the host via a public IP address, `true` or `false`. * `type`: Host type in a sharded cluster, `MONGOD`, `MONGOINFRA`, `MONGOS`, or `MONGOCFG`. For a non-sharded cluster, use `MONGOD`. * `shardName`: Shard name in a sharded cluster. * `hidden`: Specifies whether to hide (`true`) or display (`false`) the host. * `secondaryDelaySecs`: Host’s replication lag behind the master. * `priority`: Host priority for master promotion during [failover](../concepts/replication.md#master-failover). * `tags`: Host tags. * `maintenanceWindow`: Maintenance window settings, applying to both running and stopped clusters. In `maintenanceWindow`, provide one of these two values: * `anytime`: Maintenance takes place at any time. * `weeklyMaintenanceWindow`: Maintenance takes place once a week at the specified time: * `day`: Day of week in `DDD` format, i.e., `MON`, `TUE`, `WED`, `THU`, `FRI`, `SAT`, or `SUN`. * `hour`: Hour of the day, in `HH` format. Allowed values range from `1` to `24` hours. * `partialRestoreSpec`: Settings for restoring individual databases and collections: * `whitelist`: List of databases and collections to restore. For example: `["db1", "db2.collection1"]`. * `blacklist`: List of databases and collections to exclude from restoring, e.g., `["db1.collection1"]`. If you specify databases under `whitelist`, you can use `blacklist` to exclude specific collections within those databases. If the `whitelist` parameter is not specified, all databases and collections will be restored except those specified under `blacklist`. 1. Call the [Cluster.Restore](../api-ref/Cluster/restore.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request POST \ --header "Authorization: Bearer $IAM_TOKEN" \ --header "Content-Type: application/json" \ --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters:restore' \ --data "@body.json" ``` 1. Check the [server response](../api-ref/Cluster/restore.md#yandex.cloud.operation.Operation) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Create a file named `body.json` and paste the following code into it: ```json { "folder_id": "", "backup_id": "", "name": "", "environment": "", "network_id": "", "recovery_target_spec": { "timestamp": "" }, "config_spec": { "version": "", "mongodb": { "": { "resources": { "resource_preset_id": "", "disk_size": "", "disk_type_id": "" }, "disk_size_autoscaling": { "planned_usage_threshold": "", "emergency_usage_threshold": "", "disk_size_limit": "" } }, ... "": { "resources": { "resource_preset_id": "", "disk_size": "", "disk_type_id": "" }, "disk_size_autoscaling": { "planned_usage_threshold": "", "emergency_usage_threshold": "", "disk_size_limit": "" } } } }, "host_specs": [ { "zone_id": "", "subnet_id": "", "assign_public_ip": , "type": "", "shard_name": "", "hidden": , "secondary_delay_secs": "", "priority": "", "tags": "" } ], "maintenance_window": { "weekly_maintenance_window": { "day": "", "hour": "" } }, "partial_restore_spec": { "whitelist": [], "blacklist": [] } } ``` Where: * `folder_id`: Folder ID. You can get it with the [list of folders in the cloud](../../resource-manager/operations/folder/get-id.md). * `backup_id`: Backup ID. To restore a sharded cluster, specify the [sharded backup](../concepts/backup.md#size) ID. Such backups are larger in size. To learn the ID, [get the list of backups in the folder](cluster-backups.md#list-backups). * `name`: New cluster’s name. * `environment`: Cluster environment, `PRODUCTION` or `PRESTABLE`. * `network_id`: ID of the [network](../../vpc/concepts/network.md#network) where the cluster will be deployed. * `recovery_target_spec.timestamp`: Target recovery time for the Yandex StoreDoc cluster, in [UNIX time](https://en.wikipedia.org/wiki/Unix_time) format. If you omit this setting, the cluster will be restored to the backup’s completion time. * `config_spec`: Cluster settings: * `version`: Yandex StoreDoc version, 5.0, 6.0, or 7.0. * Yandex StoreDoc host type depends on the [sharding type](../concepts/sharding.md). The possible values are `mongod`, `mongocfg`, `mongos`, and `mongoinfra`. For a non-sharded cluster, use `mongod`. * `resources`: Cluster resources: * `resource_preset_id`: [Host class](../concepts/instance-types.md). * `disk_size`: Disk size in bytes. * `disk_type_id`: [Disk type](../concepts/storage.md). * `disk_size_autoscaling`: Storage autoscaling settings: * `planned_usage_threshold`: Storage usage percentage to trigger a storage expansion during the next [maintenance window](../concepts/maintenance.md#maintenance-window). Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. If you specified a value greater than `0`, configure the maintenance schedule. * `emergency_usage_threshold`: Storage usage percentage to trigger an immediate storage expansion. Use a value between `0` and `100`%. The default value is `0`, i.e., automatic expansion is disabled. The value of this setting must be greater than or equal to `planned_usage_threshold`. * `disk_size_limit`: Maximum storage size, in bytes, that can be set when storage usage reaches one of the specified thresholds. If you set it to `0`, automatic storage expansion will be disabled. * `host_specs`: Cluster host settings as an array of elements, one per host. Each element has the following structure: * `zone_id`: [Availability zone](../../overview/concepts/geo-scope.md). * `subnet_id`: [Subnet ID](../../vpc/concepts/network.md#subnet). * `assign_public_ip`: Internet access to the host via a public IP address, `true` or `false`. * `type`: Host type in a sharded cluster, `MONGOD`, `MONGOINFRA`, `MONGOS`, or `MONGOCFG`. For a non-sharded cluster, use `MONGOD`. * `shard_name`: Shard name in a sharded cluster. * `hidden`: Specifies whether to hide (`true`) or display (`false`) the host. * `secondary_delay_secs`: Host’s replication lag behind the master. * `priority`: Host priority for master promotion during [failover](../concepts/replication.md#master-failover). * `tags`: Host tags. * `maintenance_window`: Maintenance window settings, applying to both running and stopped clusters. In `maintenance_window`, provide one of these two values: * `anytime`: Maintenance takes place at any time. * `weekly_maintenance_window`: Maintenance takes place once a week at the specified time: * `day`: Day of week in `DDD` format, i.e., `MON`, `TUE`, `WED`, `THU`, `FRI`, `SAT`, or `SUN`. * `hour`: Hour of the day, in `HH` format. Allowed values range from `1` to `24` hours. * `partial_restore_spec`: Settings for restoring individual databases and collections: * `whitelist`: List of databases and collections to restore, e.g., `["db1", "db2.collection1"]`. * `blacklist`: List of databases and collections to exclude from restoring, e.g., `["db1.collection1"]`. If you specify databases under `whitelist`, you can use `blacklist` to exclude specific collections within those databases. If the `whitelist` parameter is not specified, all databases and collections will be restored except those specified under `blacklist`. 1. Call the [ClusterService.Restore](../api-ref/grpc/Cluster/restore.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d @ \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mongodb.v1.ClusterService.Restore \ < body.json ``` 1. Check the [server response](../api-ref/grpc/Cluster/restore.md#yandex.cloud.operation.Operation) to make sure your request was successful. {% endlist %} ## Creating a backup {#create-backup} {% list tabs group=instructions %} - Management console {#console} 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. Click the name of your cluster and select the ![image](../../_assets/console-icons/archive.svg) **Backups** tab. 1. Click **Create backup**. This will initiate creating a backup without any additional confirmation. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To create a cluster backup: 1. View the description of the CLI command for creating a Yandex StoreDoc backup: ```bash yc managed-mongodb cluster backup --help ``` 1. To create a backup, send the following request, providing the cluster ID or name: ```bash yc managed-mongodb cluster backup ``` You can get the cluster name and ID from the [list of clusters](cluster-list.md#list-clusters). - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Call the [Cluster.Backup](../api-ref/Cluster/backup.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request POST \ --header "Authorization: Bearer $IAM_TOKEN" \ --header "Content-Type: application/json" \ --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters/:backup' ``` You can get the cluster ID with the [list of clusters in the folder](cluster-list.md#list-clusters). 1. Check the [server response](../api-ref/Cluster/backup.md#yandex.cloud.operation.Operation) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Call the [ClusterService.Backup](../api-ref/grpc/Cluster/backup.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "cluster_id": "" }' \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mongodb.v1.ClusterService.Backup ``` You can get the cluster ID with the [list of clusters in the folder](cluster-list.md#list-clusters). 1. Check the [server response](../api-ref/grpc/Cluster/backup.md#yandex.cloud.operation.Operation) to make sure your request was successful. {% endlist %} While you are creating a backup, the cluster performance may degrade. ## Getting a list of backups {#list-backups} {% list tabs group=instructions %} - Management console {#console} To get a list of cluster backups: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. Click the name of your cluster and select the ![image](../../_assets/console-icons/archive.svg) **Backups** tab. To get a list of all backups in your folder: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. In the left-hand panel, select ![image](../../_assets/console-icons/archive.svg) **Backups**. These lists contain the following information: * Backup name. * Source shard. * Backup size. * Backup type: `Automated` or `Manual`. * Backup start time (UTC). * Backup end time (UTC). - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To get a list of Yandex StoreDoc cluster backups in the default folder, run this command: ```bash yc managed-mongodb backup list ``` Result: ```text +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ | ID | CREATED AT | SOURCE CLUSTER ID | STARTED AT | SIZE | TYPE | +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ | c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 | 3.3 KB | AUTOMATED | | c9qpm90p3pcg********:... | 2020-08-09 22:01:04 | c9qpm90p3pcg******** | 2020-08-09 21:30:00 | 30 KB | MANUAL | +--------------------------+---------------------+----------------------+---------------------+--------+-----------+ ``` The output table contains the following information: * Backup ID. * Backup end time (UTC). * ID of the backed up cluster. * Backup start time (UTC). * Backup size. * Backup type: `AUTOMATED` or `MANUAL`. - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. To get a list of cluster backups: 1. Call the [Cluster.ListBackups](../api-ref/Cluster/listBackups.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request GET \ --header "Authorization: Bearer $IAM_TOKEN" \ --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters//backups' ``` You can get the cluster ID with the [list of clusters in the folder](cluster-list.md#list-clusters). 1. Check the [server response](../api-ref/Cluster/listBackups.md#yandex.cloud.mdb.mongodb.v1.ListClusterBackupsResponse) to make sure your request was successful. 1. To list backups for all clusters in your folder: 1. Call the [Backup.List](../api-ref/Backup/list.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request GET \ --header "Authorization: Bearer $IAM_TOKEN" \ --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/backups' --url-query folderId= ``` You can get the folder ID from the [list of your cloud folders](../../resource-manager/operations/folder/get-id.md). 1. Check the [server response](../api-ref/Backup/list.md#yandex.cloud.mdb.mongodb.v1.ListBackupsResponse) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. To get a list of cluster backups: 1. Call the [ClusterService.ListBackups](../api-ref/grpc/Cluster/listBackups.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "cluster_id": "" }' \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mongodb.v1.ClusterService.ListBackups ``` You can get the cluster ID with the [list of clusters in the folder](cluster-list.md#list-clusters). 1. Check the [server response](../api-ref/grpc/Cluster/listBackups.md#yandex.cloud.mdb.mongodb.v1.ListClusterBackupsResponse) to make sure your request was successful. 1. To list backups for all clusters in your folder: 1. Call the [BackupService.List](../api-ref/grpc/Backup/list.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/backup_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "folder_id": "" }' \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mongodb.v1.BackupService.List ``` You can get the folder ID with the [list of folders in the cloud](../../resource-manager/operations/folder/get-id.md). 1. Check the [server response](../api-ref/grpc/Backup/list.md#yandex.cloud.mdb.mongodb.v1.ListBackupsResponse) to make sure your request was successful. {% endlist %} ## Getting backup details {#get-backup} {% list tabs group=instructions %} - Management console {#console} To get backup details for an existing cluster: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. Click the name of your cluster and select the ![image](../../_assets/console-icons/archive.svg) **Backups** tab. To get backup details for a previously deleted cluster: 1. Open the [folder dashboard](https://console.yandex.cloud). 1. Navigate to **Yandex StoreDoc**. 1. In the left-hand panel, select ![image](../../_assets/console-icons/archive.svg) **Backups**. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To get backup details for a Yandex StoreDoc cluster, run this command: ```bash yc managed-mongodb backup get ``` You can get the backup ID with the [list of backups](#list-backups). - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Call the [Backup.Get](../api-ref/Backup/get.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request GET \ --header "Authorization: Bearer $IAM_TOKEN" \ --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/backups/' ``` You can get the backup ID with the [list of backups](#list-backups). 1. Check the [server response](../api-ref/Backup/get.md#yandex.cloud.mdb.mongodb.v1.Backup) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Call the [BackupService.Get](../api-ref/grpc/Backup/get.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/backup_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "backup_id": "" }' \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mongodb.v1.BackupService.Get ``` You can get the backup ID with the [list of backups](#list-backups). 1. Check the [server response](../api-ref/grpc/Backup/get.md#yandex.cloud.mdb.mongodb.v1.Backup) to make sure your request was successful. {% endlist %} ## Setting a retention period for automatic backups {#set-backup-retain} {% list tabs group=instructions %} - Management console {#console} You can set the retention period for automatic backups when you [create](cluster-create.md) or [update](update.md) the cluster via the [management console](https://console.yandex.cloud). - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To set the retention period for automatic backups, provide the required value for the `--backup-retain-period-days` argument of the `cluster update` command: ```bash yc managed-mongodb cluster update \ --backup-retain-period-days= ``` The valid values range from `7` to `35`. The default value is `7`. You can get the cluster ID and name with the [list of clusters in the folder](cluster-list.md#list-clusters). - Terraform {#tf} 1. Open the current Terraform configuration file with the infrastructure plan. For more on how to create such a file, see [Creating a cluster](cluster-create.md). For a complete list of configurable Yandex StoreDoc cluster fields, see [this Terraform provider guide](../../terraform/resources/mdb_mongodb_cluster.md). 1. Add the `backup_retain_period_days` block to the `cluster_config` section of the Yandex StoreDoc cluster description: ```hcl resource "yandex_mdb_mongodb_cluster" "" { ... cluster_config { ... backup_retain_period_days = } ... } ... ``` Where `backup_retain_period_days` is the retention period for automatic backups. The valid values range from `7` to `35`. The default value is `7`. 1. Make sure the settings are correct. 1. In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure. 1. Run this command: ```bash terraform validate ``` Terraform will show any errors found in your configuration files. 1. Confirm updating the resources. 1. Run this command to view the planned changes: ```bash terraform plan ``` If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources. 1. If everything looks correct, apply the changes: 1. Run this command: ```bash terraform apply ``` 1. Confirm updating the resources. 1. Wait for the operation to complete. {% note warning "Timeouts" %} The Terraform provider sets the following timeouts for Yandex StoreDoc cluster operations: * Creating a cluster, including by restoring one from a backup: 30 minutes. * Editing a cluster: 60 minutes. Operations exceeding the set timeout are interrupted. {% cut "How do I change these limits?" %} Add the `timeouts` block to the cluster description, for example: ```hcl resource "yandex_mdb_mongodb_cluster" "" { ... timeouts { create = "1h30m" # An hour and a half update = "2h" # Two hours } } ``` {% endcut %} {% endnote %} - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Call the [Cluster.Update](../api-ref/Cluster/update.md) method, e.g., via the following [cURL](https://curl.se/) request: {% note warning %} The API method will assign default values to all the parameters of the object you are modifying unless you explicitly provide them in your request. To avoid this, list the settings you want to change in the `updateMask` parameter as a single comma-separated string. {% endnote %} ```bash curl \ --request PATCH \ --header "Authorization: Bearer $IAM_TOKEN" \ --header "Content-Type: application/json" \ --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters/' \ --data '{ "updateMask": "configSpec.backupRetainPeriodDays", "configSpec": { "backupRetainPeriodDays": } }' ``` Where: * `updateMask`: Comma-separated string of settings to update. Here, we provide only one setting. * `configSpec.backupRetainPeriodDays`: Retention period for automatic backups, in days. The valid values range from `7` to `35`. The default value is `7`. You can get the cluster ID with the [list of clusters in the folder](cluster-list.md#list-clusters). 1. Check the [server response](../api-ref/Cluster/update.md#yandex.cloud.operation.Operation) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Call the [ClusterService.Update](../api-ref/grpc/Cluster/update.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: {% note warning %} The API method will assign default values to all the parameters of the object you are modifying unless you explicitly provide them in your request. To avoid this, list the settings you want to change in the `update_mask` parameter as an array of `paths[]` strings. {% cut "Format for listing settings" %} ```yaml "update_mask": { "paths": [ "", "", ... "" ] } ``` {% endcut %} {% endnote %} ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "cluster_id": "", "update_mask": { "paths": [ "config_spec.backup_retain_period_days" ] }, "config_spec": { "backup_retain_period_days": } }' \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mongodb.v1.ClusterService.Update ``` Where: * `update_mask`: List of settings you want to update as an array of strings (`paths[]`). Here, we provide only one setting. * `config_spec.backup_retain_period_days`: Retention period for automatic backups, in days. The valid values range from `7` to `35`. The default value is `7`. You can get the cluster ID with the [list of clusters in the folder](cluster-list.md#list-clusters). 1. Check the [server response](../api-ref/grpc/Cluster/update.md#yandex.cloud.mongodb.v1.Cluster) to make sure your request was successful. {% endlist %} ## Examples {#examples} Create a new Yandex StoreDoc cluster from a backup with the following test specifications: * Source backup for recovery: `c9qlk4v13uq7********:...`. * Recovery timestamp: `1597060810` (`2020-08-10 12:00:10`). * Version: `6.0`. * New cluster’s name: `mynewmg`. * Environment: `PRODUCTION`. * Network: `default`. * One `s2.micro` host in the `ru-central1-a` availability zone and `b0rcctk2rvtr********` subnet. * Network SSD storage (`network-ssd`): 20 GB. * Databases and users that existed in the cluster at the time of recovery. {% list tabs group=instructions %} - CLI {#cli} Run this command: ```bash yc managed-mongodb cluster restore \ --backup-id c9qlk4v13uq7********:... \ --recovery-target-timestamp 1597060810 \ --mongodb-version 6.0 \ --name mynewmg \ --environment PRODUCTION \ --network-name default \ --host zone-id=ru-central1-a,subnet-id=b0rcctk2rvtr8efcch64 \ --mongod-resource-preset s2.micro \ --mongod-disk-size 20 \ --mongod-disk-type network-ssd ``` {% endlist %}