CPM offers several options for data recovery. Since all CPM backup is based on AWS’s snapshot technology, CPM can offer rapid recovery of instances, volumes, and databases. When you click Recover for a certain backup, you are directed to the recovery panel screen. The recovery panel screen includes:
- Links to recover the backed-up instances
- Links to recover independent volumes and databases
- Outputs of any backup scripts and VSS if it exists. These reference outputs may be important during a recovery operation.
If this backup includes DR to another region, there will be a drop-down menu to choose in which region to perform the recovery.
If you have cross-account functionality enabled for your CPM license, there are two other drop-down menus:
- Restore to Account list where you can choose to restore the resources to another account.
- If you defined cross-account DR for this policy, you will have the Restore from Account list for choosing from which account to perform recovery.
Note: All the choices about regions and accounts you make in the recovery panel apply to all the recovery operations that you initiate from this screen.
Recommendation: N2W Software strongly recommends that you perform recovery drills occasionally to make sure your recovery scenarios work. It is not recommended to try it for the first time when your servers are down. Each policy on the policy screen shows the last time recovery was performed on it. Use the last recovery time data to track recovery drills.
All recovery screens have a check box at the bottom labelled Use account AWS Credentials. By default, the AWS credentials used for backup will be used for recovery operations also. You can deselect it and fill in different credentials for recovery. This can be useful if you want to use IAM-created backup credentials that do not have permissions for recovery. See section 14.3. When using custom credentials, CPM verifies that these credentials actually belong to the recovery account.
To use custom credentials:
- Clear the Use account AWS Credentials check box. The custom credential boxes appear.
- In the AWS Access Key box, enter your access key.
- In the AWS Secret Key box, enter your secret key.
With Instance recovery, you can recover a complete instance with its data for purposes, such as:
- An instance crashed or is corrupted and you need to create a new one
- Creating an instance in a different AZ
- Creating an instance in a different region (see section 10.5.1)
- Creating an instance from a frozen image
When you recover an instance, by default, you recover it with its configuration, tags, and data, as they were at the time of the backup. However, you can change these elements:
- Instance type
- User data, etc.
You can also choose how to recover the system itself:
- For Linux EBS-based instances: if you have a snapshot of the boot device, you will, by default, use this snapshot to create the boot device of the new instance. You can, however, choose to create the new instance from its original image or a different one.
- For instance-store-based: you will only have the image option. This means you cannot use the snapshot of the instance’s root device to launch a new instance.
- For EBS-based Windows Servers: there is a limitation in AWS, prohibiting launching a new instance from a snapshot, as opposed to from an AMI.
CPM knows how to overcome this limitation. You can recover an instance from a snapshot, but you also need an AMI for the recovery process. By default, CPM will create an initial AMI for any Windows instance it backs up and use that AMI for the recovery process. Usually, you do not need to change anything to recover a Windows instance.
Your data EBS volumes will be recovered by default to create a similar instance as the source. However, you can choose:
- To recover some or none of the volumes.
- To enlarge volume capacity, change their device name, or IOPS value.
- To preserve tags related to the instance and/or data volumes, or not.
- The instance recovery screen is divided to Basic Options and Advanced Options.
The basic options, shown in Figure 9-2, are:
- Launch From – Whether to launch the boot device (image) from an existing image or a snapshot. The snapshot option is available only if this is an EBS-based instance, and a snapshot of the boot device is available in this backup.
- AMI Handling – This option is relevant only if Launch From is set to snapshot.
- If this instance is launched from a snapshot, a new AMI image will be registered and defined as follows:
- De-Register after Recovery – This is the default. The image will only be used for this recovery operation and will be automatically de-registered at the end. This option will not leave any images behind after the recovery is complete.
- Leave Registered after Recovery – The new created image will be left after recovery. This option is useful if you want to hold on to this image to create future instances. The snapshots the image is based on will not be deleted by the automatic retention process. However, if you want to keep this image and use it in the future, move the whole backup to the Freezer (see section 8.3).
- Create AMI without Recovery – This option creates and keeps the image but does not launch an instance from it. This is useful if you want to launch the instance/s from outside CPM. If you wish to keep using this image, move the backup to the Freezer.
- Image ID – This is only relevant if Launch From is set to image or if you are recovering a Windows instance. By default, this will contain the initial AMI that CPM created, or if it does not exist, the original AMI ID from which the backed-up instance was launched. You can type or paste a different AMI ID here, but you cannot search AMIs from within CPM. You can search for it with the AWS Management Console.
- Instances to Launch – Specifies how many instances to launch from the image. The default is one, which is the sensible choice for production servers. However, in a clustered environment you may want to launch more than one. It is not guaranteed that all the requested instances will launch. Check the message at the end of the recovery operation to see how many instances were launched, and their IDs.
- Key – The key (or key pair) you want to launch the instance with. The default is the key that the backed-up instance was created with. You can choose a different one from the list. Keys are typically needed to connect to the instance using SSH (Linux), or to decrypt the Administrator password (Windows).
- Instance volumes – All data volumes in the policy except the boot device are listed here. Their default configuration is the same as it was in the backed-up instance at the time of the backup. You can make adjustments to the volumes, as follows:
- To exclude a volume, deselect Recover.
- Enlarge capacity of the volume.
- Change the device.
- Change IOPS.
- Exclude any tags associated with the volume, such as its name
- For instances recovered from a snapshot, delete the volume on termination of the instance ().
Advanced options include the remaining options as shown in Figure 9-3:
Ephemeral Storage – Add ephemeral drives to the new instance. The number of ephemeral storage devices you can use depends on the instance type. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
Add Ephemeral storage in the format <device name>:<virtual name>, for example: xvdb:ephemeral10.
Add a new line for each device.
Architecture – Options are:
i386 – which is X86 – 32-bit
x86_64 – which is X86 – 64-bit
The default will be the architecture of the backed-up instance.
Note: Changing the architecture may result in an error if the image is incompatible with the requested architecture. For example, if your image is a native 64-bit image and you choose i386, the recovery operation will fail.
Placement – Determines what will be the placement of the instance. By default, it will be the same placement as the backed-up instance. An instance can be placed using three methods which are not all necessarily available.
By Availability Zone – This is the most basic type and the only one which is always available. You can choose in which AZ to launch the instance.
Additional options are:
- You can choose a different AZ from the backed-up instance.
- By default, if the backed-up instance was not in a VPC, it will have the same zone as the backed-up instance. Choose a different AZ from the list.
- By VPC Subnet – If you have VPC subnets defined in your account, this option is available.
- VPC –You choose the VPC the instance is to be recovered to. By default, it will contain the VPC the original instance belonged to.
- VPC Subnet ID –This will hold all the subnets in the currently selected VPC.
- VPC Assign IP – If the backed-up instance was in a VPC subnet, the default value will be the IP assigned to the original instance.
- If the assigned IP is still taken, it can fail the recovery operation. You can type a different IP here. When you begin recovery, CPM will verify the IP belongs to the chosen subnet.
- If this field is empty, an IP address from the subnet will be automatically allocated for the new instance.
- By Placement Group – If you have placement groups defined, this option is available. This is an instance type that can be placed in a placement group. See AWS documentation for details.
- Placement Group – Choose the placement group from the list.
- Availability Zone – This option is only visible if you chose By Availability Zone in Placement. By default, if the backed-up instance was not in a VPC, it will have the same zone as the backed-up instance. However, you can choose a different one from the list.
- Auto-assign Public IP = Whether to assign a public IP to the new instance. This is for public subnets. By default, it will behave as the subnet defines.
- Security Groups – Which security groups will be applied with the new instance. This is a multiple-choice field. By default, the security groups of the backed-up instance will be chosen.
Note: Security groups for VPC instances are different than groups of non-VPC instances. Every time you toggle the Placement option between By Availability Zone and By VPC Subnet, the list of security groups will be updated, and the previous selected items will not be saved. This field also has a filter to help you find the security group that you need.
- Enable User Data – Whether to use user data for this instance launch. If selected, another option appears: User Data.
- User Data – The text of the user data. Special encoding or using a file as the source is not currently supported from within CPM.
- Preserve Tags – By default, all the tags that were associated with the backed-up instance at the time of the backup, such as the instance’s name, will also be associated with the new instance/s.
- Instance Type – Choose the instance type of the new instance/s. The instance type of the backed-up instance is the default. If you choose an instance type that is incompatible with the image or placement method, the recovery operation will fail.
- Shutdown Behavior – The value of the original instance is the default. If the recovered instance is instance-store-based, this option is not used. The choices are:
- stop – If the instance is shut down, it will not be terminated and will just move to stopped state.
- terminate – If the instance is shut down it will also be terminated.
- API Termination – Whether terminating the new instance by API is enabled or not. The backed-up instance value is the default.
- Kernel – Will hold the Kernel ID of the backed-up instance. You can type or paste a different one. However, you cannot search for a kernel ID from within CPM. Change this option only if you know exactly which kernel you need. Choosing the wrong one will result in a failure.
- RAM disk – Will hold the RAM Disk ID of the backed-up instance. You can type or paste a different one. However, you cannot search for a RAM Disk ID from within CPM. Change this option only if you know exactly which RAM Disk you need. Choosing the wrong one will result in a failure.
- Allow Monitoring – Select if monitoring should be allowed for the new instance. The value in the backed-up instance is the default.
- Instance Profile ARN – The ARN of the instance role (IAM Role) for the instance. To find the ARN, click the Role name in IAM Management Console and click the Summary tab. The default will be the instance role of the backed-up instance if it had one.
- EBS Optimized –Select to launch an EBS Optimized instance. The value from the backed-up instance is the default.
Tenancy – Choose the tenancy option for this instance.
To complete the recovery operation, click Recover Instance and then confirm. If there are errors that CPM detects in your choices, you will return to the recover instance screen with error messages. Otherwise, you will be redirected back to the recovery panel screen, and a message will be displayed regarding the success or failure of the operation.
The AMI Assistant is a feature that lets you view the details of the AMI used to launch your instance, as well as find similar AMIs. CPM will record the details of the AMI when you start backing up the instance. If the AMI is deleted sometime after the instance started backing up, CPM will remember the details of the original AMI.
After clicking the AMI Assistant button in the instance recovery screen, you will see these details:
- AMI ID
- Image Name
- Image Description
- Root Device
To find AMIs with properties that are exactly like the original, click find exact matches.
If the find exact matches search does not find matches, click perform fuzzy search which will search for AMIs similar to the original.
AMI Assistant searches can be useful in the following scenarios:
- You want to recover an instance by launching it from an image, but the original AMI is no longer available.
- You want to recover an instance by launching it from an image, but you want to find a newer version of the image. The fuzzy search will help you.
- You are using DR (see chapter 10) and you need to recover the instance in a different region. You may want to find the matching AMI in the target region to use it to launch the instance, or you may need its kernel ID or ram disk ID to launch the instance from a snapshot.
Volume recovery means creating EBS volumes out of snapshots. In CPM, you can recover volumes that were part of an instance’s backup or recover EBS volumes that were added to a policy as an independent volume. The recovery process is basically the same.
To recover volumes belonging to an instance:
- Go to the Recovery Panel screen.
- Next to an instance backup, click Volumes Only. The screen in Figure 9‑5 opens.
Change the fields as needed:
- Recover – Selected by default. Deselect if you do not want that volume recovered.
- Zone – AZ. The default is the original zone of the backed-up volume.
- Capacity – Enlarge the capacity of a volume. You cannot make it smaller than the size of the original volume, which is the default.
- Type – Type of the EBS volume.
- IOPS – Number of IOPS. This field is used only if the type of volume you chose is Provisioned IOPS SSD. The default will be the setting from the original volume. Values for IOPS should be at least 100, and the volume size needs to be at least 1/10 that number in GiBs. For example, if you want to create a 100 IOPS volume, its size needs to be at least 10 GiB. If you will not abide to this rule, the recovery operation will fail.
- Device – Which device it will be attached as. This is only used if you choose to automatically attach the recovered volume to an instance. If the device is not free or not correct, the attach operation will fail.
- Preserve Tags – Whether to associate the same tags, such as the volume name, to the recovered volume. The default is yes.
- Attach to Instance – Whether to attach the newly recovered volume to an instance. Start typing in the list to initiate a filter. The list holds instances that are in the same AZ as the volume. Changing Zone will refresh the content of this list.
- Attach Behavior – This applies to all the volumes you are recovering, if you choose to attach them to an instance:
Attach only if Device is Free – If the requested device is already taken in the target instance, the attach operation will fail. You will get a message saying the new volume was created but was not attached.
Switch Attached Volumes – This option will work only if the target instance is in stopped state. If the instance is running, you will get an error message. CPM will not try to forcefully detach volumes from a running instance, since this can cause systems to crash.
Switch Attached Volumes and Delete Old Ones – This option will work only on stopped instances. This option will also delete the old volumes that are detached from the instance.
Important: If you choose Switch Attached Volumes and Delete Old Ones, make sure you do not need the old volumes. CPM will delete them after detaching them from the target instance.
As with other recovery screens, you can choose to use different AWS credentials for the recovery operation. After clicking Recover Volumes and confirming, if there was a logical error in a field that CPM detected, you will be returned to the screen with an error notification. If not, you will be redirected back to the recovery panel screen with a message regarding the status of the operation.
To recover independent volumes:
- Click the Recover Independent Volumes button above the table.
A similar recover volumes screen with instance volumes opens.
When a backup includes snapshots of RDS databases, the button Recover Databases appears on the top right corner of the recovery panel screen.
Click the Recover Databases button to bring you to the RDS Database Recovery screen, as shown in Figure 9‑8.
In this screen you will see a list of all RDS databases in the current backup. You can change the following options:
- Recover – Deselect the check box to not recover the current database.
- Zone – The AZ of the database. By default, it will be the zone of the backed-up database, but this can be changed. Currently, recovering a database into a VPC subnet is not supported by CPM. You can recover from the snapshot using AWS Management Console.
- DB Instance ID – The default is the ID of the original database. If the original database still exists, the recovery operation will fail. To recover a new database, type a new ID.
- DB Snapshot ID – Displays the snapshot ID.
- DB Instance Class – The default is the original class, but you can choose another.
- Port –The default is the port of the original backed-up database, but you can choose another.
- Multi AZ – Whether to launch the database in a multi AZ configuration or not. The default is the value from the original backed-up database.
- Subnet Group – Whether to launch the database in a VPC subnet or not, and to which subnet group. The default will be the value from the original backed-up database. You can recover a database from outside a VPC to a VPC subnet group, but the other way around is not supported and will return an error.
As in other types of recovery, you can choose to use different AWS credentials by clearing the check box and entering your keys.
Aurora recovery is similar to RDS recovery, with a few important differences.
Aurora introduces the concept of clusters to RDS. You no longer launch and manage a DB instance, but rather a DB cluster that contains DB instances.
An Aurora cluster may be created in a single AZ deployment, and the cluster will contain one instance.
Or, as in production deployments, the cluster will be created in a multi-AZ deployment, and the cluster will have reader and writer DB instances.
When recovering an Aurora cluster, CPM will recover the DB cluster and then will create the DB instances for it.
In the Recovery Panel, click the highlighted Recover Aurora Clusters button to reach the Aurora Clusters Recovery screen:
In this screen all Aurora clusters that were backed up are listed. You can change the following options:
- Recover – Deselect to not recover the current Aurora cluster.
- RDS Cluster ID – The default will be the ID of the original cluster. If the original cluster still exists, the recovery operation will fail, unless you change the ID.
- RDS Instance ID – The default will the ID of the original instance. If the original instance still exists, the recovery operation will fail.
Type a new ID to recover a new database. CPM will use this instance ID for the writer, and in the case of multi-AZ, it will create the reader with this name with _reader added at the end.
- RDS Cluster Snapshot ID – Displays the snapshot ID.
- Instance Type – The type or class of the DB instances.
- Port – The port of the database. The default is the port of the original backed-up database.
- Zone – The AZ of the cluster in case of single AZ. If using a subnet group, leave as is.
- Subnet Group – Whether to launch the cluster in a VPC subnet or not, and to which subnet group. The default is the value from the original backed-up cluster.
- Publicly Access – Whether the cluster will be publicly accessible or not. The default is the access from the original backed-up instance.
In the Recovery Panel, click the Recover Redshift Clusters button to open the Redshift Cluster Recovery screen, as shown in Figure 9-10.
All Redshift clusters in the current backup are listed. You can change the following options:
- Recover – Deselect to not recover the current cluster.
- Zone – The AZ of the cluster. By default, it will be the zone of the backed-up cluster, but this can be changed.
- Currently, recovering a cluster into a VPC subnet is not supported by CPM. You can always recover from the snapshot using AWS Management Console.
- Cluster ID – The default will the ID of the original cluster. If the original cluster still exists, the recovery operation will fail. To recover a new cluster, type a new ID.
- Cluster Snapshot ID– Displays the snapshot ID.
- Node Type and Nodes – For information only. Changing these fields is not supported by AWS.
- Port – The port of the cluster. The default is the port of the original backed-up cluster.
- Subnet Group – Whether to launch the cluster in a VPC subnet or not, and to which subnet group. The default will be the value from the original backed-up cluster. You can recover a cluster from outside a VPC to a VPC subnet group, but the other way around is not supported.
As in other types of recovery, you can choose to use different AWS credentials by clearing the check box and entering your keys.
When a backup includes DynamoDB Table backups, the Recover DynamoDB Tables button above the table is highlighted.
Note: If you reach the limit of the number of tables that can be recovered at one time, you will need to wait until they have completed before starting the recovery of additional tables.
In the Recovery Panel, click the Recover DynamoDB Tables button to open the DynamoDB Table Recovery screen.
All DynamoDB tables in the current backup are listed. You can change the following options:
- Recover – Deselect to not recover the current table.
- Region – The Region where the table will be recovered, which is the same region as the backup.
- Table Name – The default will the Name of the original table. However, if the original table still exists, the recovery operation will fail. To recover to a new table, type a new Name.
- Backup Name – Displays the name of the backup.
During backup, CPM retains the DynamoDB tags at the table level and the Time To Live (TTL) metadata and enables these attributes on recovery.
During the recovery process, a confirmation message appears with a reminder to recreate the following settings on the restored DynamoDB tables MANUALLY: Auto Scaling policies, IAM policies, CloudWatch metrics and alarms.