Restoring a Cluster

1. Restore to a new VPC

Cassandra cluster backups may be used to restore data from a point-in-time to a new cluster, via the Console or using the Provisioning API. Data will be restored to a new cluster.

To restore a cluster from the Console, click on Backup / Restore under the Cluster’s menu on the sidebar. 

Then under the Restore tab, click on the Start Restore button.

In the Backup / Restore tab of your cluster. Then go to the Restore tab. Fill any information about your new cluster that you want, or just leave the text fields blank to get the default. Then press the Start Restore button

 

When restoring a cluster, you may choose to:

  • Restore all data or only selected tables
    • If restoring a subset of tables, the cluster schema will still be restored in its entirety and therefore the schemas for any non-restored keyspaces and tables will still be applied.  However, only backup data for the selected tables will be restored.
  • Restore to a specified point-in-time (Date and Time)
    • The restore process will use the latest backup data for each node, up to the specified date and time specified in the Date field.  If restoring a cluster with Continuous Backup enabled, then commit logs will also be restored.

Once the Restore parameters are submitted, a new cluster will be provisioned under the account with a topology matching the designated point-in-time (e.g. if 3 nodes were added to a 3-node cluster on 01/10/2017 and the restore operation was for a point-in-time of 30/09/2017, then the restored cluster will have 3 nodes).

2. Restore to a target VPC

For customers running in their own Cloud Provider account with Customer Managed Virtual Network Provisioning enabled, they can also choose to restore to a target VPC: 

2.1. SAME_VPC – restores the cluster to the same VPC as the original cluster, for customers running in their own account. 

  • AWS – restore to a new CIDR within the CDC’s network 
  • GCP – For customer-managed network, if the source cluster specifies a host project, it will be restored to that project. If the source cluster specifies a custom subnet, it will be restored to that custom subnet. If nothing is specified, it will restore to a new CIDR within the CDC network. 
  • Azure – currently not supported. 

2.2. CUSTOM_VPC – restores the cluster to a custom VPC for customers running in their own account. Customers need to specify the customVpcSettings including network and vpcId. 

  • AWS – restores the cluster to the network CIDR and VPC specified by the customer 
  • GCP – For customer-managed network, if the vpcId field contains the projects/ pattern, it will be restored to that project. If the vpcId field contains the subnetworks/ pattern, it will be restored to that custom subnet. If nothing is specified, it will restore to a new CIDR within the CDC network. 
  • Azure – restores the cluster to the network CIDR and VNet specified by the customer. 

Selecting the Custom VPC option when restoring a RIYOA cluster, requires the following 2 fields to be filled: Custom VPC ID and Custom VPC Network.