Contact UsGet started
© 2025 Direct Cursus Technology L.L.C.

Managing backups in Managed Service for MongoDB

Written by
Updated at February 18, 2025

You can create backups and restore clusters from existing backups.

Managed Service for MongoDB also creates automatic daily backups. You can set the backup start time and retention period.

Restoring clusters from backups

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 has insufficient resources to create such a cluster, you will not be able to restore 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 MongoDB backup cannot be restored as a PostgreSQL cluster).

When restored to the current state, the new cluster will match the state of:

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

To restore an existing cluster from a backup:

  1. Go to the folder page and select Managed Service for MongoDB.

  2. Click the name of the cluster you need and select the Backups tab.

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

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

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

    If you do not change the setting, the cluster will be restored to the state it was in when the backup was completed.

  6. Click Restore cluster.

To restore a previously deleted cluster from a backup:

  1. Go to the folder page and select Managed Service for MongoDB.

  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 formatted as <cluster_ID>:<backup_ID>.

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

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

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

    If you do not change the setting, the cluster will be restored to the state it was in when the backup was completed.

  7. Click Restore cluster.

Managed Service for MongoDB will launch the operation to create a cluster from the backup.

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

The folder specified in the CLI profile is used by default. You can specify a different folder through the --folder-name or --folder-id parameter.

To restore a cluster from a backup:

  1. View a description of the CLI restore MongoDB cluster command:

    yc managed-mongodb cluster restore --help

  2. Getting a list of available MongoDB 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 backup completion time is shown in the CREATED AT column of the list of available backups, in yyyy-mm-dd hh:mm:ss format (2020-08-10 12:00:00 in the example above). You can restore a cluster to any point in time starting with the point when the backup is created.

  3. Run the command to create a new cluster from a backup (the example shows only some parameters):

     yc managed-mongodb cluster restore \
    --backup-id <backup_ID> \
    --recovery-target-timestamp <time_point> \
    --mongodb-version <MongoDB_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>

    Where:

    • --recovery-target-timestamp: Time point to restore the MongoDB 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.

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

  1. Get an IAM token for API authentication and put it into the environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. Create a file named body.json and add the following contents to it:

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

    Where:

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

    • backupId: Backup ID. 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 the cluster will be in.

    • recoveryTargetSpec.timestamp: Time point to restore the MongoDB 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: MongoDB version: 5.0, 6.0, or 7.0.

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

        • resources: Cluster resources:

    • hostSpecs: Cluster host settings as an array of elements, one for each host. Each element has the following structure:

      • zoneId: Availability zone.
      • subnetId: Subnet ID.
      • assignPublicIp: Internet access to the host via a public IP address.
      • 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 or hidden.
      • secondaryDelaySecs: Host's lag behind the master.
      • priority: Host priority for assignment as a master if the primary master fails.
      • tags: Host labels.

  3. Use the Cluster.Restore method and send the following request, e.g., via cURL:

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

  1. Get an IAM token for API authentication and put it into the 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 add the following contents to 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": "<MongoDB_version>",
    "mongodb": {
      "<MongoDB_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": <public_host_address:_true_or_false>,
      "type": "<host_type>",
      "shard_name": "<shard_name>",
      "hidden": <host_visibility:_true_or_false>,
      "secondary_delay_secs": "<lag_in_seconds>",
      "priority": "<host_priority_for_assignment_as_master>",
      "tags": "<host_labels>"
    }
  ]
}

    Where:

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

    • backup_id: Backup ID. 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 the cluster will be in.

    • recovery_target_spec.timestamp: Time point to restore the MongoDB 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: MongoDB version: 5.0, 6.0, or 7.0.

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

        • resources: Cluster resources:

    • host_specs: Cluster host settings as an array of elements, one for each 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.
      • 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 or hidden.
      • 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. View the server response to make sure the request was successful.

Creating a backup

  1. Go to the folder page and select Managed Service for MongoDB.
  2. Click the name of the cluster you need and select 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 yet, install and initialize it.

The folder specified in the CLI profile is used by default. You can specify a different folder through the --folder-name or --folder-id parameter.

To create a cluster backup:

  1. View a description of the CLI create MongoDB backup command:

    yc managed-mongodb cluster backup --help

  2. Request a backup to be created by specifying the cluster name or ID:

    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 put it into the environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. Use the Cluster.Backup method and send the following request, e.g., via cURL:

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

  1. Get an IAM token for API authentication and put it into the 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. View the server response to make sure the request was successful.

Warning

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

Getting a list of backups

To get a list of cluster backups:

  1. Go to the folder page and select Managed Service for MongoDB.
  2. Click the name of the cluster you need and select the Backups tab.

To get a list of all backups in a folder:

  1. Go to the folder page and select Managed Service for MongoDB.
  2. In the left-hand panel, select Backups.

These lists contain the following information:

  • Backup name.
  • Source shard.
  • Backup size.
  • Backup type: Automatic (Automated) or manual (Manual).
  • Start time of backup creation in UTC (Coordinated Universal Time).
  • End time of backup creation in UTC.

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

The folder specified in the CLI profile is used by default. You can specify a different folder through the --folder-name or --folder-id parameter.

To get a list of MongoDB cluster backups available in the default folder, run the 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 resulting table contains the following information:

  • ID of the backup.
  • End time of backup creation in UTC (Coordinated Universal Time).
  • ID of the cluster that the backup was created for.
  • Start time of backup creation in UTC.
  • Backup size.
  • Backup type: Automatic (AUTOMATED) or manual (MANUAL).

  1. Get an IAM token for API authentication and put it into the environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. To get a list of cluster backups:

    1. Use the Cluster.ListBackups method and send the following request, e.g., via cURL:

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

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

    1. Use the Backup.List method and send the following request, e.g., via cURL:

      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 request the folder ID with the list of folders in the cloud.

    2. View the server response to make sure the request was successful.

  1. Get an IAM token for API authentication and put it into the 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. View the server response to make sure the request was successful.

  4. To get a list of backups for all the clusters in a 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 request the folder ID with the list of folders in the cloud.

    2. View the server response to make sure the request was successful.

Getting information about backups

To get information about the backup of an existing cluster:

  1. Go to the folder page and select Managed Service for MongoDB.
  2. Click the name of the cluster you need and select the Backups tab.

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

  1. Go to the folder page and select Managed Service for MongoDB.
  2. In the left-hand panel, select Backups.

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

The folder specified in the CLI profile is used by default. You can specify a different folder through the --folder-name or --folder-id parameter.

To get information about a MongoDB cluster backup, run the command:

yc managed-mongodb backup get <backup_ID>

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

  1. Get an IAM token for API authentication and put it into the environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. Use the Backup.Get method and send the following request, e.g., via cURL:

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

    You can request the backup ID together with the list of backups.

  3. View the server response to make sure the request was successful.

  1. Get an IAM token for API authentication and put it into the 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 request the backup ID together with the list of backups.

  4. View the server response to make sure the request was successful.

Setting a retention period for automatic backups

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

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

The folder specified in the CLI profile is used by default. You can specify a different folder through 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 possible values range from 7 to 35. The default value is 7.

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

  1. Open the current Terraform configuration file with an infrastructure plan.

    For more information about creating this file, see Creating clusters.

    For a complete list of available MongoDB cluster configuration fields, see the Terraform provider documentation.

  2. Add a backup_retain_period_days block in the cluster_config section to the MongoDB 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 possible values range from 7 to 35. The default value is 7.

  3. Make sure the settings are correct.

    1. Using the command line, navigate to the folder that contains the up-to-date Terraform configuration files with an infrastructure plan.

    2. Run the command:

      terraform validate

      If there are errors in the configuration files, Terraform will point to them.

  4. Confirm updating the resources.

    1. Run the command to view planned changes:

      terraform plan

      If the resource configuration descriptions are correct, the terminal will display a list of the resources to modify and their parameters. This is a test step. No resources are updated.

    2. If you are happy with the planned changes, apply them:

      1. Run the command:

        terraform apply

      2. Confirm the update of resources.

      3. Wait for the operation to complete.

    Timeouts

    The Terraform provider sets the following timeouts for Managed Service for MongoDB 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 put it into the environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. Use the Cluster.Update method and send the following request, e.g., via cURL:

    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_storage_time_in_days>
              }
            }'

    Where:

    • updateMask: List of parameters to update as a single string, separated by commas.

      Only one parameter is provided in this case.

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

      The 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. View the server response to make sure the request was successful.

  1. Get an IAM token for API authentication and put it into the 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_storage_time_in_days>
          }
        }' \
    mdb.api.cloud.yandex.net:443 \
    yandex.cloud.mdb.mongodb.v1.ClusterService.Update

    Where:

    • update_mask: List of parameters to update as an array of paths[] strings.

      Only one parameter is provided in this case.

    • config_spec.backup_retain_period_days: Automatic backup retention period, in days.

      The 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. View the server response to make sure the request was successful.

Examples

Create a new Managed Service for MongoDB 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.

Run the following 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
Previous
Migrating hosts to a different availability zone
Next
Deleting a cluster