Yandex Cloud
Search
Contact UsGet started
  • Pricing
  • Customer Stories
  • Documentation
  • Blog
  • All Services
  • System Status
    • Featured
    • Infrastructure & Network
    • Data Platform
    • Containers
    • Developer tools
    • Serverless
    • Security
    • Monitoring & Resources
    • AI for business
    • Business tools
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
  • Pricing
  • Customer Stories
  • Documentation
  • Blog
© 2025 Direct Cursus Technology L.L.C.
Yandex StoreDoc
  • Getting started
    • All guides
      • Information about existing clusters
      • Creating a cluster
      • Updating cluster settings
      • Yandex StoreDoc version upgrade
      • Stopping and starting a cluster
      • Managing cluster hosts
      • Migrating hosts to a different availability zone
      • Managing backups
      • Deleting a cluster
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • Public materials
  • Release notes

In this article:

  • Restoring a cluster from a backup
  • Creating a backup
  • Getting a list of backups
  • Getting backup info
  • Setting a retention period for automatic backups
  • Examples
  1. Step-by-step guides
  2. Clusters
  3. Managing backups

Managing backups in Yandex StoreDoc

Written by
Yandex Cloud
Updated at November 26, 2025
  • Restoring a cluster from a backup
  • Creating a backup
  • Getting a list of backups
  • Getting backup info
  • Setting a retention period for automatic backups
  • Examples

You can create backups and use the existing backups to restore clusters.

Additionally, Yandex StoreDoc creates automatic daily backups. You can set the backup start time and retention period.

Restoring a cluster from a backupRestoring a cluster from a backup

The Point-in-Time Recovery (PITR) technology allows you to restore your cluster to any state in the time interval between the oldest backup and the archiving of the most recent oplog collection. For more information, see Backups.

For example, if the backup operation ended on August 10, 2020 at 12:00:00 UTC, the current date is August 15, 2020, 19:00:00 UTC, and the most recent oplog collection was saved on August 15, 2020, 18:50:00 UTC, the cluster can be restored to any state between August 10, 2020, 12:00:01 UTC and August 15, 2020, 18:50:00 UTC, inclusive.

Warning

PITR is not supported for clusters with sharding enabled. Such clusters can only be restored to the time point of the selected backup.

When you restore a cluster from a backup, you create a new cluster with the backup data. If the folder lacks resources to create such a cluster, data will not be restored from the backup. The average backup recovery speed is 10 MBps.

For a new cluster, you should set all the parameters required during creation, except for cluster type (a Yandex StoreDoc backup cannot be restored as a PostgreSQL cluster).

When restored to the current point in time, the new cluster will reflect the state of:

  • Existing cluster at the time of recovery.
  • Deleted cluster at the time of archiving the last oplog.

Before you begin, assign to your Yandex Cloud account the managed-mongodb.restorer role or higher for the backup folder and the new cluster folder.

Management console
CLI
REST API
gRPC API

To restore an existing cluster from a backup:

  1. Navigate to the folder dashboard and select Yandex StoreDoc.

  2. Click the name of your cluster and open the Backups tab.

  3. Click for the backup you need and then click Restore cluster.

    To recover a sharded cluster, use a sharded backup. Such backups are larger in size.

  4. Configure the new cluster. You can select a folder for the new cluster from the Folder list.

  5. To restore the cluster state to a specific point in time after the backup was created, configure Date and time of recovery (UTC) accordingly. You can either enter the date manually or select it from the drop-down calendar.

    If you leave this setting as is, the cluster will be restored to the state it had when the backup was completed.

  6. Click Restore cluster.

To restore a previously deleted cluster from a backup:

  1. Navigate to the folder dashboard and select Yandex StoreDoc.

  2. In the left-hand panel, select Backups.

  3. Find the backup you need using the backup creation time and cluster ID. The ID column contains IDs in <cluster_ID>:<backup_ID> format.

    If you want to recover a sharded cluster, find its sharded backup. Such backups are larger in size.

  4. Click for the backup you need and then click Restore cluster.

  5. Configure the new cluster. You can select a folder for the new cluster from the Folder list.

  6. To restore the cluster state to a specific point in time after the backup was created, configure Date and time of recovery (UTC) accordingly. You can either enter the date manually or select it from the drop-down calendar.

    If you leave this setting as is, the cluster will be restored to the state it had when the backup was completed.

  7. Click Restore cluster.

Yandex StoreDoc will initiate the process of creating a new cluster from the backup.

If you do not have the Yandex Cloud CLI installed yet, install and initialize it.

By default, the CLI uses the folder specified when creating the profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id parameter.

To restore a cluster from a backup:

  1. See the description of the CLI command for restoring a Yandex StoreDoc cluster:

    yc managed-mongodb cluster restore --help
    
  2. Get the list of available Yandex StoreDoc cluster backups:

    yc managed-mongodb backup list
    

    Result:

    +--------------------------+---------------------+----------------------+---------------------+--------+-----------+
    |            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 |
    | ...                                                                                         |                    |
    +--------------------------+---------------------+----------------------+---------------------+--------+-----------+
    

    The CREATED AT column in the list of available backups shows the backup completion time in yyyy-mm-dd hh:mm:ss format (2020-08-10 12:00:00 in the example above). You can restore your cluster to the state it was in at any point in time after the backup was created.

  3. Run the command to create a new cluster from a backup. The examples below do not include all parameters.

    For a non-sharded cluster:

    yc managed-mongodb cluster restore \
       --backup-id <backup_ID> \
       --recovery-target-timestamp <time_point> \
       --mongodb-version <Yandex_StoreDoc_version> \
       --name <new_cluster_name> \
       --environment <environment> \
       --network-name <network_name> \
       --host zone-id=<availability_zone>,`
             `subnet-id=<subnet_ID> \
       --mongod-resource-preset <host_class> \
       --mongod-disk-size <storage_size_in_GB> \
       --mongod-disk-type <disk_type> \
       --performance-diagnostics=<enable_diagnostics>
    

    For a sharded cluster:

    yc managed-mongodb cluster restore \
       --backup-id <backup_ID> \
       --recovery-target-timestamp <time_point> \
       --mongodb-version <Yandex_StoreDoc_version> \
       --name <new_cluster_name> \
       --environment <environment> \
       --network-name <network_name> \
       --host zone-id=<availability_zone>,`
             `subnet-id=<subnet_ID>,`
             `type=mongod,`
             `shard-name=<shard_name> \
       --mongod-resource-preset <host_class> \
       --mongod-disk-size <storage_size_in_GB> \
       --mongod-disk-type <disk_type> \
       --host zone-id=<availability_zone>,`
             `subnet-id=<subnet_ID>,`
             `type=<host_type> \
       ...
       --host zone-id=<availability_zone>,`
             `subnet-id=<subnet_ID>,`
             `type=<host_type> \
       --<host_type>-resource-preset <host_class> \
       --<host_type>-disk-size <storage_size_in_GB> \
       --<host_type>-disk-type <disk_type> \
       --performance-diagnostics=<enable_diagnostics>
    

    Where:

    • --backup-id: Backup ID. To recover a sharded cluster, specify the sharded backup ID. Such backups are larger in size. To find out the ID, get a list of folder backups.

    • --recovery-target-timestamp: Time point to restore the Yandex StoreDoc cluster to, in UNIX time format. If you omit this parameter, the cluster state will be restored to the backup completion time.

    • --environment: Environment, PRESTABLE or PRODUCTION.

    • --mongod-disk-type: Disk type, network-hdd, network-ssd, or network-ssd-io-m3.

    • --<host_type>-resource-preset, --<host_type>-disk-size, --<host_type>-disk-type: Host parameters that manage sharding in the cluster. The possible <host_type> values are mongoinfra, mongocfg, or mongos.

    • --performance-diagnostics: Enables cluster performance diagnostics, true or false.

  1. Get an IAM token for API authentication and set it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Create a file named body.json and paste the following code into it:

    {
      "folderId": "<folder_ID>",
      "backupId": "<backup_ID>",
      "name": "<new_cluster_name>",
      "environment": "<environment>",
      "networkId": "<network_ID>",
      "recoveryTargetSpec": {
        "timestamp": "<time>"
      },
      "configSpec": {
        "version": "<Yandex_StoreDoc_version>",
        "mongodb": {
          "<Yandex_StoreDoc_host_type>": {
            "resources": {
              "resourcePresetId": "<host_class>",
              "diskSize": "<storage_size_in_bytes>",
              "diskTypeId": "<disk_type>"
            }
          },
          ...
          "<Yandex_StoreDoc_host_type>": {
            "resources": {
              "resourcePresetId": "<host_class>",
              "diskSize": "<storage_size_in_bytes>",
              "diskTypeId": "<disk_type>"
            }
          }
        }
      },
      "hostSpecs": [
        {
          "zoneId": "<availability_zone>",
          "subnetId": "<subnet_ID>",
          "assignPublicIp": <allow_public_access_to_host>,
          "type": "<host_type>",
          "shardName": "<shard_name>",
          "hidden": <hide_host>,
          "secondaryDelaySecs": "<lag_in_seconds>",
          "priority": "<host_priority_for_assignment_as_master>",
          "tags": "<host_labels>"
        }
      ]
    }
    

    Where:

    • folderId: Folder ID. You can get it with the list of folders in the cloud.

    • backupId: Backup ID. To recover a sharded cluster, specify the sharded backup ID. Such backups are larger in size. To find out the ID, get a list of folder backups.

    • name: Name of the new cluster.

    • environment: Cluster environment, PRODUCTION or PRESTABLE.

    • networkId: ID of the network where the cluster will be deployed.

    • recoveryTargetSpec.timestamp: Time point to restore the Yandex StoreDoc cluster to, in UNIX time format. If you omit this parameter, the cluster state will be restored to the backup completion time.

    • configSpec: Cluster settings:

      • version: Yandex StoreDoc version, 5.0, 6.0, or 7.0.

      • Yandex StoreDoc host type depends on the sharding type. Possible values: mongod, mongocfg, mongos, and mongoinfra. For a non-sharded cluster, use mongod.

        • resources: Cluster resources:

          • resourcePresetId: Host class.
          • diskSize: Disk size, in bytes.
          • diskTypeId: Disk type.
    • hostSpecs: Cluster host settings as an array of elements, one per host. Each element has the following structure:

      • zoneId: Availability zone.
      • subnetId: Subnet ID.
      • 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: The host will either be visible (false) or hidden (true).
      • secondaryDelaySecs: Host's lag behind the master.
      • priority: Host priority for assignment as a master if the primary master fails.
      • tags: Host labels.
  3. Call the Cluster.Restore method, e.g., via the following cURL request:

    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"
    
  4. Check the server response to make sure your request was successful.

  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Clone the cloudapi repository:

    cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
    

    Below, we assume the repository contents are stored in the ~/cloudapi/ directory.

  3. Create a file named body.json and paste the following code into it:

    {
      "folder_id": "<folder_ID>",
      "backup_id": "<backup_ID>",
      "name": "<new_cluster_name>",
      "environment": "<environment>",
      "network_id": "<network_ID>",
      "recovery_target_spec": {
        "timestamp": "<time>"
      },
      "config_spec": {
        "version": "<Yandex_StoreDoc_version>",
        "mongodb": {
          "<Yandex_StoreDoc_host_type>": {
            "resources": {
              "resource_preset_id": "<host_class>",
              "disk_size": "<storage_size_in_bytes>",
              "disk_type_id": "<disk_type>"
            }
          },
          ...
          "<Yandex_StoreDoc_host_type>": {
            "resources": {
              "resource_preset_id": "<host_class>",
              "disk_size": "<storage_size_in_bytes>",
              "disk_type_id": "<disk_type>"
            }
          }
        }
      },
      "host_specs": [
        {
          "zone_id": "<availability_zone>",
          "subnet_id": "<subnet_ID>",
          "assign_public_ip": <allow_public_access_to_host>,
          "type": "<host_type>",
          "shard_name": "<shard_name>",
          "hidden": <hide_host>,
          "secondary_delay_secs": "<lag_in_seconds>",
          "priority": "<host_priority_for_assignment_as_master>",
          "tags": "<host_labels>"
        }
      ]
    }
    

    Where:

    • folder_id: Folder ID. You can get it with the list of folders in the cloud.

    • backup_id: Backup ID. To recover a sharded cluster, specify the sharded backup ID. Such backups are larger in size. To find out the ID, get a list of folder backups.

    • name: Name of the new cluster.

    • environment: Cluster environment, PRODUCTION or PRESTABLE.

    • network_id: ID of the network where the cluster will be deployed.

    • recovery_target_spec.timestamp: Time point to restore the Yandex StoreDoc cluster to, in UNIX time format. If you omit this parameter, the cluster state will be restored to the backup 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. Possible values: mongod, mongocfg, mongos, and mongoinfra. For a non-sharded cluster, use mongod.

        • resources: Cluster resources:

          • resource_preset_id: Host class.
          • disk_size: Disk size, in bytes.
          • disk_type_id: Disk type.
    • host_specs: Cluster host settings as an array of elements, one per host. Each element has the following structure:

      • zone_id: Availability zone.
      • subnet_id: Subnet ID.
      • 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: The host will either be visible (false) or hidden (true).
      • secondary_delay_secs: Host's lag behind the master.
      • priority: Host priority for assignment as a master if the primary master fails.
      • tags: Host labels.
  4. Use the ClusterService.Restore call and send the following request, e.g., via gRPCurl:

    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
    
  5. Check the server response to make sure your request was successful.

Creating a backupCreating a backup

Management console
CLI
REST API
gRPC API
  1. Navigate to the folder dashboard and select Yandex StoreDoc.
  2. Click the name of your cluster and open the Backups tab.
  3. Click Create backup.

The service will start creating a backup without an additional confirmation.

If you do not have the Yandex Cloud CLI installed yet, install and initialize it.

By default, the CLI uses the folder specified when creating the profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id parameter.

To create a cluster backup:

  1. See the description of the CLI command for creating a Yandex StoreDoc backup:

    yc managed-mongodb cluster backup --help
    
  2. Send the following request to create a backup, specifying the cluster ID or name:

    yc managed-mongodb cluster backup <cluster_name_or_ID>
    

    You can get the cluster ID and name with the list of clusters.

  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Call the Cluster.Backup method, e.g., via the following cURL request:

    curl \
        --request POST \
        --header "Authorization: Bearer $IAM_TOKEN" \
        --header "Content-Type: application/json" \
        --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters/<cluster_ID>:backup'
    

    You can request the cluster ID with the list of clusters in the folder.

  3. Check the server response to make sure your request was successful.

  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Clone the cloudapi repository:

    cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
    

    Below, we assume the repository contents are stored in the ~/cloudapi/ directory.

  3. Use the ClusterService.Backup call and send the following request, e.g., via gRPCurl:

    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": "<cluster_ID>"
            }' \
        mdb.api.cloud.yandex.net:443 \
        yandex.cloud.mdb.mongodb.v1.ClusterService.Backup
    

    You can request the cluster ID with the list of clusters in the folder.

  4. Check the server response to make sure your request was successful.

Warning

While you are creating your backup, the cluster performance might degrade.

Getting a list of backupsGetting a list of backups

Management console
CLI
REST API
gRPC API

To get the list of cluster backups:

  1. Navigate to the folder dashboard and select Yandex StoreDoc.
  2. Click the name of your cluster and open the Backups tab.

To get the list of all backups in the folder:

  1. Navigate to the folder dashboard and select Yandex StoreDoc.
  2. In the left-hand panel, select 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).

If you do not have the Yandex Cloud CLI installed yet, install and initialize it.

By default, the CLI uses the folder specified when creating the profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id parameter.

To get the list of Yandex StoreDoc cluster backups available in the default folder, run this command:

yc managed-mongodb backup list

Result:

+--------------------------+---------------------+----------------------+---------------------+--------+-----------+
|            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 table in the command output contains the following information:

  • Backup ID.
  • Backup end time (UTC).
  • ID of the backed up cluster.
  • Start time of backup creation in UTC.
  • Backup size.
  • Backup type: AUTOMATED or MANUAL.
  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. To get a list of cluster backups:

    1. Call the Cluster.ListBackups method, e.g., via the following cURL request:

      curl \
         --request GET \
         --header "Authorization: Bearer $IAM_TOKEN" \
         --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters/<cluster_ID>/backups'
      

      You can request the cluster ID with the list of clusters in the folder.

    2. Check the server response to make sure your request was successful.

  3. To get the list of backups for all clusters in the folder:

    1. Call the Backup.List method, e.g., via the following cURL request:

      curl \
         --request GET \
         --header "Authorization: Bearer $IAM_TOKEN" \
         --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/backups'
         --url-query folderId=<folder_ID>
      

      You can get the folder ID with the list of folders in the cloud.

    2. Check the server response to make sure your request was successful.

  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Clone the cloudapi repository:

    cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
    

    Below, we assume the repository contents are stored in the ~/cloudapi/ directory.

  3. To get a list of cluster backups:

    1. Use the ClusterService.ListBackups call and send the following request, e.g., via gRPCurl:

      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": "<cluster_ID>"
              }' \
          mdb.api.cloud.yandex.net:443 \
          yandex.cloud.mdb.mongodb.v1.ClusterService.ListBackups
      

      You can request the cluster ID with the list of clusters in the folder.

    2. Check the server response to make sure your request was successful.

  4. To get the list of backups for all clusters in the folder:

    1. Use the BackupService.List call and send the following request, e.g., via gRPCurl:

      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": "<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.

    2. Check the server response to make sure your request was successful.

Getting backup infoGetting backup info

Management console
CLI
REST API
gRPC API

To get information about a backup of an existing cluster:

  1. Navigate to the folder dashboard and select Yandex StoreDoc.
  2. Click the name of your cluster and open the Backups tab.

To get information about a backup of a previously deleted cluster:

  1. Navigate to the folder dashboard and select Yandex StoreDoc.
  2. In the left-hand panel, select Backups.

If you do not have the Yandex Cloud CLI installed yet, install and initialize it.

By default, the CLI uses the folder specified when creating the profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id parameter.

To get information about an Yandex StoreDoc cluster backup, run this command:

yc managed-mongodb backup get <backup_ID>

You can get the backup ID with the list of backups.

  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Call the Backup.Get method, e.g., via the following cURL request:

    curl \
       --request GET \
       --header "Authorization: Bearer $IAM_TOKEN" \
       --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/backups/<backup_ID>'
    

    You can get the backup ID with the list of backups.

  3. Check the server response to make sure your request was successful.

  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Clone the cloudapi repository:

    cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
    

    Below, we assume the repository contents are stored in the ~/cloudapi/ directory.

  3. Use the BackupService.Get call and send the following request, e.g., via gRPCurl:

    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": "<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.

  4. Check the server response to make sure your request was successful.

Setting a retention period for automatic backupsSetting a retention period for automatic backups

Management console
CLI
Terraform
REST API
gRPC API

In the management console, you can set the retention period for automatic backups when creating or updating the cluster.

If you do not have the Yandex Cloud CLI installed yet, install and initialize it.

By default, the CLI uses the folder specified when creating the profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id parameter.

To set the retention period for automatic backups, provide the required value in the --backup-retain-period-days argument of the cluster update command:

yc managed-mongodb cluster update <cluster_name_or_ID> \
   --backup-retain-period-days=<retention_period_in_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.

  1. Open the current Terraform configuration file describing your infrastructure.

    For information on how to create this file, see Creating a cluster.

    For a complete list of configurable Yandex StoreDoc cluster fields, refer to the Terraform provider guides.

  2. Add the backup_retain_period_days block to the cluster_config section of the Yandex StoreDoc cluster description:

      resource "yandex_mdb_mongodb_cluster" "<cluster_name>" {
        ...
        cluster_config {
          ...
          backup_retain_period_days = <retention_period_in_days>
          }
          ...
        }
        ...
    

    Where backup_retain_period_days is the automatic backup retention period.

    The valid values range from 7 to 35. The default value is 7.

  3. 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.

    2. Run this command:

      terraform validate
      

      Terraform will show any errors found in your configuration files.

  4. Confirm updating the resources.

    1. Run this command to view the planned changes:

      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.

    2. If everything looks correct, apply the changes:

      1. Run this command:

        terraform apply
        
      2. Confirm updating the resources.

      3. Wait for the operation to complete.

    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.

    How do I change these limits?

    Add the timeouts block to the cluster description, for example:

    resource "yandex_mdb_mongodb_cluster" "<cluster_name>" {
      ...
      timeouts {
        create = "1h30m" # An hour and a half
        update = "2h"    # Two hours
      }
    }
    
  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Call the Cluster.Update method, e.g., via the following cURL request:

    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.

    curl \
        --request PATCH \
        --header "Authorization: Bearer $IAM_TOKEN" \
        --header "Content-Type: application/json" \
        --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters/<cluster_ID>' \
        --data '{
                  "updateMask": "configSpec.backupRetainPeriodDays",
                  "configSpec": {
                    "backupRetainPeriodDays": <backup_retention_in_days>
                  }
                }'
    

    Where:

    • updateMask: Comma-separated list of settings you want to update.

      Here, we provide only one setting.

    • configSpec.backupRetainPeriodDays: Automatic backup retention period, in days.

      The valid values range from 7 to 35. The default value is 7.

    You can request the cluster ID with the list of clusters in the folder.

  3. Check the server response to make sure your request was successful.

  1. Get an IAM token for API authentication and save it as an environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Clone the cloudapi repository:

    cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
    

    Below, we assume the repository contents are stored in the ~/cloudapi/ directory.

  3. Use the ClusterService.Update call and send the following request, e.g., via gRPCurl:

    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.

    Format for listing settings
    "update_mask": {
        "paths": [
            "<setting_1>",
            "<setting_2>",
            ...
            "<setting_N>"
        ]
    }
    
    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": "<cluster_ID>",
              "update_mask": {
                "paths": [
                  "config_spec.backup_retain_period_days"
                ]
              },
              "config_spec": {
                "backup_retain_period_days": <backup_retention_in_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: Automatic backup retention period, in days.

      The valid values range from 7 to 35. The default value is 7.

    You can request the cluster ID with the list of clusters in the folder.

  4. Check the server response to make sure your request was successful.

ExamplesExamples

Create a new Yandex StoreDoc cluster from a backup with the following test characteristics:

  • Recovery backup: c9qlk4v13uq7********:....
  • Time point to recover to: 1597060810 (2020-08-10 12:00:10).
  • Version: 6.0.
  • Name of the new cluster: 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.
  • With databases and users that existed in the cluster at the time of recovery.
CLI

Run this command:

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

Was the article helpful?

Previous
Migrating hosts to a different availability zone
Next
Deleting a cluster
© 2025 Direct Cursus Technology L.L.C.