If you restore data from a backup set to a source ApsaraDB for Redis instance, the data in the source instance is overwritten and cannot be restored. As a result, data loss may occur. ApsaraDB for Redis allows you to create an instance from a specified backup set. The data in the new instance is the same as that in the backup set. This feature can be applied in scenarios such as data recovery, quick workload deployment, and data verification.



In this example, an ApsaraDB for Redis instance is created, and you are charged for the ApsaraDB for Redis instance. For more information, see Billing items and pricing.


  1. Log on to the ApsaraDB for Redis console.
  2. In the top navigation bar of the page, select the region where the instance is deployed.
  3. On the Instances page, click the ID of the instance.
  4. In the left-side navigation pane, click Backup and Recovery.
  5. Find the backup set that you want to manage and click Recovery in the Actions column.
    Figure 1. Instance restoration
    Instance restoration
    Note You can also filter backup sets by time range.
  6. In the message that appears, read the content and click OK.
  7. On the Clone Instance page, configure the following parameters.
    Parameter Description
    Clone Source Type Set the value to Backup Set.
    Clone Backup Set Select the backup set that you want to manage from the drop-down list.
    Region The region where the source ApsaraDB for Redis instance is deployed is automatically selected and cannot be changed.
    Zone Select a zone within the region. Each region has multiple isolated locations that are known as zones. Each zone has its own independent power supply and network. To minimize the network latency between an ECS instance and an ApsaraDB for Redis instance that are deployed in the same zone, connect them through an internal network.
    Note To implement zone-disaster recovery, you can deploy the ApsaraDB for Redis instance across multiple zones.
    Network Type
    • VPC: A virtual private cloud (VPC) is an isolated network with higher security and better performance than a classic network. We recommend that you select a VPC.
    • Classic Network: Cloud services in a classic network are not isolated. Access to cloud services within a classic network is controlled by security groups or whitelists of these cloud services.
    • The ApsaraDB for Redis instance must be of the same network type as the ECS instance to be connected. Otherwise, these instances cannot communicate over an internal network.
    • If the network type for both the ECS instance and the ApsaraDB for Redis instance is VPC, these instances must be deployed in the same VPC. Otherwise, they cannot communicate with each other through an internal network.
    • You can switch the network type of an ApsaraDB for Redis instance from classic network to VPC. However, you cannot switch the network type of an ApsaraDB for Redis instance from VPC to classic network. For more information, see Change the network type from classic network to VPC.
    VPC Select a VPC in which you want to create the ApsaraDB for Redis instance. For more information about VPCs, see .
    VSwitch Select a vSwitch for the VPC. If no vSwitches are created for the VPC in the current zone, see Work with vSwitches.
    • Community Edition: This edition is compatible with the Redis protocol and provides database solutions that use both memory and disks.
    • Enhanced Edition: This edition is developed based on the ApsaraDB for Redis Community Edition and is optimized for performance, storage, and data schemas. For more information, see Overview.
    Series Enhanced Performance: uses a multi-threading model. This parameter is available only if Edition is set to Enhanced Edition. The performance of this series is three times that of a Community Edition instance of the same specification. It also provides multiple data schema modules to simplify development. For more information, see Performance-enhanced instances.
    Version The major version of the ApsaraDB for Redis database engine.
    Note The instances that use Redis 2.8 are to be phased out. We recommend that you create an instance that uses the latest version to use more features and achieve stable performance.
    Architecture Type
    • Cluster: eliminates the performance bottleneck that is caused by a single-threading model. You can use the instances to process large-capacity or high-performance workloads.
    • Standard: runs in a master-replica architecture, provides high-performance caching services, and ensures high data reliability.
    • Read/Write Splitting: ensures high availability and high performance, and supports multiple specifications. The read/write splitting architecture allows a large number of concurrent requests to read hot data from read replicas. This reduces the loads on the master node and minimizes the cost of operations and maintenance.
    For more information, see Overview.
    Shards Specifies the number of shards for the Redis cluster instance. Data is distributed across the shards in the cluster instance.
    Note This parameter is supported only when you set Architecture Type to Cluster.
    Node Type
    • If you set Architecture Type to Cluster or Standard, the Node Type parameter must be set to Master-Replica. This creates a dual-node hot-standby architecture that provides data persistence with high data reliability and availability.
    • If you set Architecture Type to Read-Write Splitting, you can choose the node type based on the number of read replicas.
    Instance Class Each instance type contains a group of configurations, such as the memory capacity, maximum number of concurrent connections, and maximum internal bandwidth. For more information, see Overview.
    Note The database metadata is generated after you create an ApsaraDB for Redis instance. The size of the metadata on each shard of cluster instances is 30 MB to 50 MB. The total size of the metadata for a cluster equals the sum of metadata on all shards of the cluster.
    Password Setting
    • Later: Set a password after the instance is created. For more information, see Change or reset the password.
    • Now: Enter a password for the instance.
      • The password must be 8 to 32 characters in length.
      • The password must contain at least three of the following types of characters: uppercase letters, lowercase letters, digits, and special characters.
      • Supported special characters include !@ # $ % ^ & * ( ) _ + - =.
    Instance Name Enter a name for the instance. We recommend that you use an informative name for easy identification.
    Duration Select a subscription duration for the instance. You can select one to nine months for a monthly subscription or select one to three years for an annual subscription.
    Note This parameter is applicable to only subscription instances.
  8. Read and select ApsaraDB for KVStore (Subscription) Agreement of Service.
  9. Click Buy Now.
    After the payment is complete, wait for one to five minutes. Then, you can find the new ApsaraDB for Redis instance in the ApsaraDB for Redis console.

What to do next

When the new instance is created, you can connect to the new instance to verify the data. If the instance passes the verification, you can use the new instance to restore your workloads. If you no longer need the source instance, you can release the instance. For more information, see Release instances.

Related API operations

API operation Description
CreateInstance Creates an instance and restores data in the specified backup set to the new instance.