# Restore a backup by resource type
## How to restore
For console restore instructions and links to documentation for each AWS Backup-supported resource type, see the links at the bottom of this page.
To restore a backup programmatically, use the [StartRestoreJob](API_StartRestoreJob.md) API operation.
The configuration values ("restore metadata") that you need to restore your resource varies depending on the resource that you want to restore. To get the configuration metadata that your backup was created with, you can call [GetRecoveryPointRestoreMetadata](API_GetRecoveryPointRestoreMetadata.md). Restore metadata examples are also available in the links at the bottom of this page.
Restoring from cold storage typically takes 4 hours more than restoring from warm storage.
For each restore, a restore job is created with a unique job ID—for example, `1323657E-2AA4-1D94-2C48-5D7A423E7394`.
**Note**
AWS Backup does not provide any service-level agreements (SLAs) for a restore time. Restore times can vary based upon system load and capacity, even for restores containing the same resources.
## Non-destructive restores
When you use AWS Backup to restore a backup, it creates a new resource with the backup that you are restoring. This is to protect your existing resources from being destroyed by your restore activity.
## Restore testing
You can conduct tests on your resources to simulate a restore experience. This helps determine if you meet your organizational Restore Time Objective (RTO) and helps prepare for future restore needs.
For more information, see [Restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html).
## Copy tags during a restore
**Note**
Restores of Amazon DynamoDB, Amazon S3, SAP HANA on Amazon EC2 instances, virtual machines, and Amazon Timestream resources currently do not have this feature available.
### Introduction
You can copy tags as you restore a resource if the tags belonged to the protected resource at the time of backup. Tags, which are labels containing a key and value pair, can help you identify and search for resources. When you start a restore job, tags that belonged to the original backed-up resources can be added to the resource being restored.
When you choose to include tags during a restore job, this step can replace the overhead and labor of manually applying tags to resources after a restore job is completed. Note this is distinct from adding new tags to restored resources.
When you restore a backup in the console flow, your source tags will be copied by default. In the console, uncheck the box if you wish to opt out of copying tags to a restored resource
In the API operation `StartRestoreJob`, the parameter `CopySourceTagsToRestoredResource` is set to `false` by default, which will exclude the original source tags from the resource you are restoring. If you wish to *include* tags from the original source, set this to `True`.
### Considerations
+ A resource can have up to 50 tags, including restored resources. Please see [Tagging your AWS resources ](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) for more information about tag limits.
+ Ensure the correct permissions are present in the role used for restores to copy tags. The default role for restores contains the necessary permissions. A custom role must include additional permissions to tag resources.
+ The following resources are not currently supported for restore tag inclusion: VMware Cloud™ on AWS, VMware Cloud™ on AWS Outposts, on-premises systems, SAP HANA on Amazon EC2 instances, Timestream, DynamoDB, Advanced DynamoDB, and Amazon S3.
+ For continuous backups, the tags on the original resource as of the most recent backup will be copied to the restored resource.
+ Tags will not be copied for item-level restores.
+ Tags that were added to a backup after the backup job was completed but were not present on the original resource prior to the backup will not be copied to the restored resource. Only Backups created after May 22, 2023 are eligible for tag copy on restore.
### Tag interaction with specific resources
+ **Amazon EC2**
+ Tags applied to restored **Amazon EC2** instances are also applied to the attached restored **Amazon EBS** volumes.
+ Tags applied to the EBS volumes attached to source instances are not copied to the volumes attached to restored instances. If you have IAM policies that allow or deny users access to EBS volumes based on their tags, you must manually reassign the required tags to the restored volumes to ensure your policies remain in effect.
+ When you restore an **Amazon EFS** resource, it must be copied to a new file system. Restorations to an existing file system cannot have tags copied to it.
+ **Amazon RDS**
+ If the RDS cluster that was backed up is still active, tags from this cluster will be copied.
+ If the original cluster is no longer active, tags from the snapshot of the cluster will be copied instead.
+ Tags which were present on the resource at the time of the backup will be copied during the restore regardless if the Boolean parameter for `CopySourceTagsToRestoredResource` is set to `True` or `False`. However, if the snapshot does not contain tags, then the above Boolean setting will be used.
+ **Amazon Redshift** clusters, by default, always include tags during a restore job.
### Copy tags via the console
1. Open the [AWS Backup console](https://console.aws.amazon.com/backup/)
1. In the navigation pane, choose **Protected resources**, and select the Amazon S3 resource ID that you want to restore.
1. On the **Resource details** page, you will see a list of recovery points for the selected resource ID. To restore a resource:
1. In the **Backup** pane, choose the recovery point ID of the resource.
1. In the upper-right corner of the pane, choose **Restore** (alternatively, you can go to the backup vault, find the recovery point, and then click **Actions** then click **Restore**).
1. On the **Restore backup page**, locate the panel named Restore with tags. To include all tags from the original resource, retain the check the box (note in the console this box is checked by default).
1. Click **Restore backup** after you have selected all your preferred settings and roles.
### To include tags programmatically
Use the API operation `StartRestoreJob` . Ensure the following Boolean parameter is set to `True`:
```
CopySourceTagsToRestoredResource = true
```
If the boolean parameter `CopySourceTagsToRestoredResource` = `True`, the restore job will copy the tags from the original resource(s) to the restored material.
**Important**
The restore job will fail if this parameter is included for an unsupported resource (VMware, AWS Outposts, on-premises systems, SAP HANA on EC2 instances, Timestream, DynamoDB, Advanced DynamoDB, and Amazon S3).
```
{
"RecoveryPointArn": "arn:aws:ec2:us-east-1::image/ami-1234567890a1b234",
"Metadata": {
"InstanceInitiatedShutdownBehavior": "stop",
"DisableApiTermination": "false",
"EbsOptimized": "false",
"InstanceType": "t1.micro",
"SubnetId": "subnet-123ab456cd7efgh89",
"SecurityGroupIds": "[\"sg-0a1bc2d345ef67890\"]",
"Placement": "{\"GroupName\":null,\"Tenancy\":\"default\"}",
"HibernationOptions": "{\"Configured\":false}",
"IamInstanceProfileName": "UseBackedUpValue",
"aws:backup:request-id": "1a2345b6-cd78-90e1-2345-67f890g1h2ij"
},
"IamRoleArn": "arn:aws:iam::123456789012:role/EC2Restore",
"ResourceType": "EC2",
"IdempotencyToken": "34ab5678-9012-3c4d-5678-efg9h01f23i4",
"CopySourceTagsToRestoredResource": true
}
```
### Troubleshoot tag restore issues
**ERROR:** Insufficient Permissions
**REMEDY:** Ensure you have the necessary permissions in your restore role so you can include tags on your restored resource. The default [AWS managed](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#aws-managed-policies) service role policy for restores, [AWSBackupServiceRolePolicyForRestores](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores$jsonEditor), contains the necessary permissions for this task.
If you choose to use a custom role, ensure the following permissions are present:
+ `elasticfilesystem:TagResource`
+ `storagegateway:AddTagsToResource`
+ `rds:AddTagsToResource`
+ `ec2:CreateTags`
+ `cloudformation:TagResource`
For more information, see [API permissions](https://docs.aws.amazon.com/aws-backup/latest/devguide/access-control.html#backup-api-permissions-ref).
## Restore job statuses
You can view the status of a restore job on the **Jobs** page of the AWS Backup console. Restore job statuses include **pending**, **running**, **completed**, **aborted**, and **failed**.
**Topics**
+ [How to restore](#how-to-restore)
+ [Non-destructive restores](#non-destructive-restores)
+ [Restore testing](#restore-testing-intro)
+ [Copy tags during a restore](#tag-on-restore)
+ [Restore job statuses](#restore-job-statuses)
+ [Restoring an Amazon Aurora cluster](restoring-aur.md)
+ [Amazon Aurora DSQL restore](restore-auroradsql.md)
+ [Restore CloudFormation stacks](restore-application-stacks.md)
+ [Restoring a DocumentDB cluster](restoring-docdb.md)
+ [Restore a Amazon DynamoDB table](restoring-dynamodb.md)
+ [Restore an Amazon EBS volume](restoring-ebs.md)
+ [Restore an Amazon EC2 instance](restoring-ec2.md)
+ [Restore an Amazon EFS file system](restoring-efs.md)
+ [Restore an Amazon EKS cluster](restoring-eks.md)
+ [Restore an FSx file system](restoring-fsx.md)
+ [Restore a Neptune cluster](restoring-nep.md)
+ [Restore an RDS database](restoring-rds.md)
+ [Restore an Amazon Redshift cluster](redshift-restores.md)
+ [Amazon Redshift Serverless restore](redshift-serverless-restore.md)
+ [Restore an SAP HANA database on an Amazon EC2 instance](saphana-restore.md)
+ [Restore S3 data using AWS Backup](restoring-s3.md)
+ [Restore a Storage Gateway volume](restoring-storage-gateway.md)
+ [Restore an Amazon Timestream table](timestream-restore.md)
+ [Restore a virtual machine using AWS Backup](restoring-vm.md)
# Restoring an Amazon Aurora cluster
## Use the AWS Backup console to restore Aurora recovery points
AWS Backup restores your Aurora cluster; it does not create or attach an Amazon RDS instance to your cluster. In the following steps, you will create and attach an Amazon RDS instance to your restored Aurora cluster using the CLI.
Restoring an Aurora cluster requires that you specify multiple restore options. For information about these options, see [Overview of Backing Up and Restoring an Aurora DB Cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html) in the *Amazon Aurora User Guide*. Specifications for the restore options can be found in the API guide for [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html).
**To restore an Amazon Aurora cluster**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and the Aurora resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. In the **Instance specifications** pane, accept the defaults or specify the options for the **DB engine**, **DB engine version**, and **Capacity type** settings.
**Note**
If **Serverless** capacity type is selected, a **Capacity settings** pane appears. Specify the options for the **Minimum Aurora capacity unit** and **Maximum Aurora capacity unit** settings, or choose different options from the **Additional scaling configuration** section.
1. In the **Settings** pane, specify a name that is unique for all DB cluster instances owned by your AWS account in the current Region.
1. In the **Network & Security** pane, accept the defaults or specify the options for the **Virtual Private Cloud (VPC)**, **Subnet group**, and **Availability zone** settings.
1. In the **Database options** pane, accept the defaults or specify the options for **Database port**, **DB cluster parameter group**, and **IAM DB Authentication Enabled** settings.
1. In the **Backup** pane, accept the default or specify the option for the **Copy tags to snapshots** setting.
1. In the **Backtrack** pane, accept the default or specify the options for the **Enable Backtrack** or **Disable Backtrack** settings.
1. In the **Encryption** pane, accept the default or specify the options for the **Enable encryption** or **Disable encryption** settings.
1. In the **Log exports** pane, choose the log types to publish to Amazon CloudWatch Logs. The **IAM role** is already defined.
1. In the **Restore role** pane, choose the IAM role that AWS Backup will assume for this restore.
1. After specifying all your settings, choose **Restore backup**.
The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
1. After your restore finishes, attach your restored Aurora cluster to an Amazon RDS instance.
Using the AWS CLI:
+ For Linux, macOS, or Unix:
```
aws rds create-db-instance --db-instance-identifier sample-instance \
--db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r4.large
```
+ For Windows:
```
aws rds create-db-instance --db-instance-identifier sample-instance ^
--db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r4.large
```
See [continuous backups and point-in-time restore (PITR)](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html) for information about continuous backups and restoring to a chosen point in time.
## Use the AWS Backup API, CLI, or SDK to restore Amazon Aurora recovery points
Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. The metadata you can include for a restore job will depend if you are restoring a continuous backup to a point in time (PITR) or if you are restoring a snapshot.
**Restore a cluster from a snapshot**
You can specify the following metadata for an Aurora snapshot restore job. See [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html) in the *Amazon Relational Database Service API Reference* for additional information and accepted values.
```
// Required metadata:
dbClusterIdentifier // string
engine // string
// Optional metadata:
availabilityZones // array of strings
backtrackWindow // long
copyTagsToSnapshot // Boolean
databaseName // string
dbClusterParameterGroupName // string
dbSubnetGroupName // string
enableCloudwatchLogsExports // array of strings
enableIAMDatabaseAuthentication // Boolean
engineMode // string
engineVersion // string
kmsKeyId // string
optionGroupName // string
port // integer
scalingConfiguration // object
vpcSecurityGroupIds // array of strings
```
Example:
```
"restoreMetadata":"{\"EngineVersion\":\"5.6.10a\",\"KmsKeyId\":\"arn:aws:kms:us-east-1:234567890123:key/45678901-ab23-4567-8cd9-012d345e6f7\",\"EngineMode\":\"serverless\",\"AvailabilityZones\":\"[\\\"us-east-1b\\\",\\\"us-east-1e\\\",\\\"us-east-1c\\\"]\",\"Port\":\"3306\",\"DatabaseName\":\"\",\"DBSubnetGroupName\":\"default-vpc-05a3b07cf6e193e1g\",\"VpcSecurityGroupIds\":\"[\\\"sg-012d52c68c6e88f00\\\"]\",\"ScalingConfiguration\":\"{\\\"MinCapacity\\\":2,\\\"MaxCapacity\\\":64,\\\"AutoPause\\\":true,\\\"SecondsUntilAutoPause\\\":300,\\\"TimeoutAction\\\":\\\"RollbackCapacityChange\\\"}\",\"EnableIAMDatabaseAuthentication\":\"false\",\"DBClusterParameterGroupName\":\"default.aurora5.6\",\"CopyTagsToSnapshot\":\"true\",\"Engine\":\"aurora\",\"EnableCloudwatchLogsExports\":\"[]\"}"
```
**Restore a cluster to a point in time (PITR)**
You can specify the following metadata when you want to restore an Aurora continuous backup (recovery point) to a specific point in time (PITR). See [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html) in the *Amazon Relational Database Service API Reference* for additional information and accepted values.
```
// Required metadata:
dbClusterIdentifier // string
engine // string
restoreToTime // timestamp; must be specified if UseLatestRestorableTime parameter isn't provided
// Optional metadata:
backtrackWindow // long
copyTagsToSnapshot // Boolean
dbClusterParameterGroupName // string
dbSubnetGroupName // string
enableCloudwatchLogsExports // array of strings
enableIAMDatabaseAuthentication // Boolean
engineMode // string
engineVersion // string
kmsKeyId // string
optionGroupName // string
port // integer
scalingConfiguration // object
vpcSecurityGroupIds // array of strings
```
# Amazon Aurora DSQL restore
**Topics**
+ [Overview](#restore-auroradsql-overview)
+ [Restore Aurora DSQL single Region cluster](#restore-auroradsql-singleregion)
+ [Restore an Aurora DSQL multi-Region cluster](#restore-auroradsql-multiregion)
+ [Troubleshoot Aurora DSQL restore issues](#restore-auroradsql-troubleshoot)
+ [Aurora DSQL restore frequently asked questions](#restore-auroradsql-faq)
## Overview
To restore a Amazon Aurora DSQL single-Region cluster, use the AWS Backup console or CLI to select the recovery point (backup) you wish to restore. To restore a Aurora DSQL multi-Region cluster, you can now use either the AWS Backup console or CLI.
For single-Region restore, include the name, cluster encryption, and deletion protection, then initiate the restore to a newly created cluster.
For multi-Region restore, you'll need to specify additional parameters including a witness Region, peer Region(s), and regional configuration settings. Multi-Region restore creates a cluster that spans multiple AWS Regions, providing enhanced availability and disaster recovery capabilities.
## Restore Aurora DSQL single Region cluster
You can restore an Aurora DSQL cluster to a single Region by using the AWS Backup console or AWS CLI.
------
#### [ Console ]
****
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. Select the "Restore" button next to the recovery point you wish to restore.
1. Configure the settings for the new cluster to which your recovery point will be restored.
1. By default, the AMK (AWS managed key) will be used to encrypt the restored data. You may alternatively specify a different key.
1. [Deletion protection](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DeleteCluster.html#USER_DeletionProtection) for your Aurora clusters is enabled by default, but unselect the box to turn off the option.
1. Review the settings; when they are satisfactory, select the **Restore backup** button.
AWS Backup will create a new Aurora DSQL cluster.
------
#### [ AWS CLI ]
**Single Region restore**
1. Use the CLI command `aws backup start-restore-job` to restore an Aurora cluster from the specified recovery point.
1. Include the necessary metadata for the restore job. Example:
**Example**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:dsql:us-east-1:123456789012:cluster/example-cluster/backup/example-backup" \
--iam-role-arn "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole" \
--metadata '{"regionalConfig":"[{\"region\":\"us-east-1\",\"isDeletionProtectionEnabled\":true,\"kmsKeyId\":\"my_key\"}]"}' \
--copy-source-tags-to-restored-resource
```
------
## Restore an Aurora DSQL multi-Region cluster
Aurora DSQL multi-Region cluster restore occurs within a closed Region triplet, which is a group of three AWS Regions peers. Multi-Region restore requires that the Regions you specify in the operation are contained in one triplet. For more information about multi-Region clusters, see [Configuring multi-Region clusters](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/configuring-multi-region-clusters.html).
Triplets from the following groups are supported. Where there are more than Regions, choose three in the same group.
+ US East (N. Virginia); US East (Ohio); US West (N. California)
+ Europe (Ireland); Europe (London); Europe (Paris); Europe (Frankfurt)
+ Asia Pacific (Tokyo); Asia Pacific (Seoul); Asia Pacific (Osaka)
To complete multi-Region restore, ensure you have the following permissions:
+ `backup:StartRestoreJob`
+ `dsql:UpdateCluster`
+ `dsql:AddPeerCluster`
+ `dsql:RemovePeerCluster`
You can restore a backup of an Aurora DSQL cluster to multiple Regions using either the AWS Backup console or CLI commands.
**Tip**
If you have a backup plan with a rule that automatically creates a cross-Region copy to one of the indicated Regions, the created copy can be used for this multi-Region restore.
Multi-Region restore starts with your current Region. You will also need a:
+ Peer Region with an identical cross-Region copy of the recovery point in your current Region
+ Witness Region, a designated AWS Region that participates in multi-Region cluster configurations by supporting transaction log-only writes without consuming storage for the actual data. For more information about witness Regions, see [Creating a multi-Region cluster](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/getting-started.html#getting-started-multi-region).
The individual steps are shown below:
------
#### [ Console ]
The AWS Backup console now supports multi-Region restore for Aurora DSQL clusters, providing a streamlined process for creating clusters that span multiple Regions. For more information about multi-Region clusters, see [Configuring multi-Region clusters](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/configuring-multi-region-clusters.html).
1. Sign in to the AWS Management Console and open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Backup vaults**.
1. Choose the backup vault that contains the Aurora DSQL recovery point you want to restore.
1. Select the recovery point you want to restore, then choose **Restore**.
1. On the restore page, under **Restore options**, select **Add peer Regions** to enable multi-Region restore.
1. Select a **Peer cluster Region** from the dropdown menu. This Region must be within the same triplet as your current Region and also must contain a cross-Region copy from the recovery point in the current (first) Region.
1. Select a **Witness Region** from the dropdown menu. This Region must also be within the same triplet.
1. Configure the **Cluster settings** for both the primary and peer Region clusters:
1. For the primary cluster, configure:
+ **Cluster encryption** (optional): Select a KMS key for encryption.
+ **Deletion protection**: Enable or disable deletion protection.
1. For the peer Region cluster, configure:
+ **Peer Region cluster encryption** (optional): Select a KMS key for encryption.
+ **Peer Region cluster deletion protection**: Enable or disable deletion protection.
1. Review your settings and choose **Restore backup**.
1. The console will initiate the multi-Region restore process, which creates clusters in both Regions and automatically links them together.
------
#### [ AWS CLI ]
Multi-Region restore can now be achieved using the new orchestrated restore metadata with AWS Backup CLI commands. This approach simplifies the process by handling the cluster linking automatically. For more information about creating multi-Region clusters programmatically, see [Configuring multi-Region clusters](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/configuring-multi-region-clusters.html) in the Aurora DSQL User Guide.
**Important**
Both the primary cluster and peer cluster must be in Regions within the same group. The operation will fail if the clusters are in Regions outside the group. Supported groups include:
US East (N. Virginia); US East (Ohio); US West (N. California)
Europe (Ireland); Europe (London); Europe (Paris); Europe (Frankfurt)
Asia Pacific (Tokyo); Asia Pacific (Seoul); Asia Pacific (Osaka)
**Multi-Region restore through AWS CLI using orchestrated restore metadata**
1. Create a restore job using the CLI command `aws backup start-restore-job` with the new multi-Region orchestration metadata:
**Example**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:us-east-1:123456789012:recovery-point:abcd1234" \
--iam-role-arn "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole" \
--metadata '{
"witnessRegion":"us-west-1",
"useMultiRegionOrchestration":"true",
"peerRegion":"[\"us-east-2\"]",
"regionalConfig":"[{\"region\":\"us-east-1\",\"isDeletionProtectionEnabled\":true,\"kmsKeyId\":\"arn:aws:kms:us-east-1:123456789012:key/ba4b3773-4bb8-4a7a-994c-46ede70202f5\"},{\"region\":\"us-west-2\",\"isDeletionProtectionEnabled\":true,\"kmsKeyId\":\"arn:aws:kms:us-west-2:123456789012:key/ba4b3773-4bb8-4a7a-994c-46ede70202f5\"}]"
}' \
--copy-source-tags-to-restored-resource
```
The metadata structure includes:
+ `witnessRegion`: The Region that will serve as the witness for the multi-Region cluster. For more information, see [Resilience in Amazon Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/disaster-recovery-resiliency.html).
+ `useMultiRegionOrchestration`: Set to `true` to enable multi-Region orchestration.
+ `peerRegion`: An array containing the Region(s) with peer clusters in the multi-Region cluster. For more information, see [MultiRegionProperties](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_MultiRegionProperties.html) in the Aurora DSQL API Reference.
+ `regionalConfig`: An array containing configuration for each Region:
+ `region`: The AWS Region identifier.
+ `isDeletionProtectionEnabled`: Boolean flag to enable/disable deletion protection. For more information, see [CreateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_CreateCluster.html#API_CreateCluster_RequestSyntax) in the Aurora DSQL API Reference.
+ `kmsKeyId`: The KMS key ARN for encryption (optional).
If `regionalConfig` properties are not specified, then default values will be applied: default encryption and `isDeletionProtectionEnabled` = `TRUE`.
1. Monitor the restore job status using the `aws backup describe-restore-job` command:
```
aws backup describe-restore-job --restore-job-id job-12345678
```
1. Once the restore job completes, you can verify the multi-Region cluster configuration using the Aurora DSQL CLI:
```
aws dsql describe-cluster --cluster-identifier your-cluster-id
```
For more information about multi-Region cluster operations, see [UpdateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UpdateCluster.html) in the Aurora DSQL API Reference.
------
## Troubleshoot Aurora DSQL restore issues
**Error:** Insufficient permissions
**Possible cause:** If you try to copy an Aurora DSQL recovery point into an account (cross-account copy) that has never interacted with DSQL API, you may get a permission issue error since the DSQL service-linked role isn't set up in the destination account.
**Remedy:** Attach the [DSQL managed policy](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html) that includes the DSQL service-linked role, [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ AuroraDsqlServiceLinkedRolePolicy.html), to a role in the destination account.
If you encounter any other issues with the backup or restore process, you can check the status of your backup and restore jobs in the AWS Backup console or using the AWS CLI. Additionally, you can review the AWS CloudTrail logs for any relevant error messages or events related to your AWS Backup operations.
## Aurora DSQL restore frequently asked questions
1. *"Can I use AWS Backup for Aurora DSQL from the Aurora DSQL console?"*
No, you can only perform backups and restores, as well as managing backups, from AWS Backup console, SDK, or CLI.
1. *"What backup granularity is available for Aurora DSQL? Can I backup specific tables or databases in my cluster"*
You can only back up and restore a whole Aurora DSQL cluster.
1. *"Are backups of Aurora DSQL full backups or incremental backups?"*
Recovery points of Aurora DSQL clusters (backups) are full backups of your clusters.
1. *"Can I create backups for my Aurora DSQL multi-Region clusters?"*
Yes, you can create backups for each cluster in multi-Region clusters in the using the same steps as when you create a backup of a single cluster in a single Region.
AWS Backup recommends as a best practice to create a cross-Region copy of your backup in the other Region from which you plan to restore the Multi-Region cluster, as multi-Region restore requires an identical copy of the same recovery point [*identical* in this operation means the recovery points have the same resource name and creation time].
1. *"Will my restored cluster overwrite my existing cluster?"*
No. When you restore your Aurora DSQL data, AWS Backup creates a new cluster from your snapshots; the restored cluster won’t overwrite the source cluster.
# Restore CloudFormation stacks
A CloudFormation composite backup is a combination of a CloudFormation template and all associated nested recovery points. Any number of nested recovery points can be restored, but the composite recovery point (which is the top-level recovery point) cannot be restored.
When you restore a CloudFormation template recovery point, you create a new stack with a change set to represent the backup.
## Restore CloudFormation with the AWS Backup console
From the [CloudFormation console](https://console.aws.amazon.com/cloudformation/) you can see the new stack and change set. To learn more about change sets, see [ Updating stacks using change sets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) in the *CloudFormation User Guide*.
Determine which nested recovery points you want to restore from with your CloudFormation stack, and then restore them using the AWS Backup console.
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. Go to **Backup vaults**, select the backup vault containing your desired recovery point, then click on **Recovery points**.
1. Restore the CloudFormation template recovery point.
1. Click the composite recovery point containing the nested recovery points you want to restore to bring up the Details page for the composite recovery point.
1. Under **Nested recovery points**, the nested recovery points will be displayed. Each recovery point will have a recovery point ID, a status, a resource ID, a resource type, a backup type, and the time that recovery point was created. Click the radio button next to the CloudFormation recovery point, then click **Restore**. Ensure that you are selecting the recovery point that has **resource type: CloudFormation** and **backup type: backup.**
1. Once the restore job for the CloudFormation template is completed, your restored CloudFormation template will be visible in the [CloudFormation console](https://console.aws.amazon.com/cloudformation/) under **Stacks**.
1. Under **Stack names** you should find the restored template with the status of `REVIEW_IN_PROGRESS`.
1. Click on the name of the stack to see the stack's details.
1. There are tabs under the stack name. Click on **Change sets**.
1. Execute the change set.
1. After this processes, the resources in the original stack will be recreated in the new stack. The stateful resources will be recreated empty. To recover the stateful resources, go back to the list of recovery points in the AWS Backup console, select the recovery point you need, and initiate a restore.
**Note**
If a CloudFormation restore operation fails, the stack may remain in `REVIEW_IN_PROGRESS` status with a `FAILED` change set. Delete these stacks manually to avoid naming conflicts when you retry the restore operation.
For more information, see [Deleting a stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) in the *AWS CloudFormation User Guide*.
## Restore CloudFormation with AWS CLI
In the command line interface, [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html) allows you to restore a CloudFormation stack.
The following list is the accepted metadata to restore an CloudFormation resource.
```
// Mandatory metadata:
ChangeSetName // This is the name of the change set which will be created
StackName // This is the name of the stack that will be created by the new change set
// Optional metadata:
ChangeSetDescription // This is the description of the new change set
StackParameters // This is the JSON of the stack parameters required by the stack
aws:backup:request-id
```
# Restoring a DocumentDB cluster
## Use the AWS Backup console to restore Amazon DocumentDB recovery points
Restoring a Amazon DocumentDB cluster requires that you specify multiple restore options. For information about these options, see [ Restoring from a Cluster Snapshot](https://docs.aws.amazon.com/documentdb/latest/developerguide/backup_restore-restore_from_snapshot.html) in the *Amazon DocumentDB Developer Guide*.
**To restore a Amazon DocumentDB cluster**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and the Amazon DocumentDB resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. Ensure you are on the console page **Restore Amazon DocumentDB cluster snapshots**.
1. For **Restore options**, you can configure the following:
+ **Engine version** - Select the DocumentDB engine version for the restored cluster.
**Note**
Instance class and number of instances cannot be configured during the restore process. The restored DocumentDB cluster will use the default instance configuration. You can modify the instance class and add or remove instances after the restore completes by using the Amazon DocumentDB console or API.
1. In the **Settings** pane, input a unique name for your DB cluster identifier.
You can use letters, numbers, and hyphens, though you cannot have two consecutive hyphens or end the name with a hyphen. The final name will be all lowercase.
1. In the **Database options** pane, select the database port.
This is the TCP/IP port that the DB instance or cluster will use for application connections. The connection string of any application connecting to the DB instance or cluster must specify its port number. Both the security group applied to the DB instance or cluster and your organization firewalls must allow connections to the port. All DB instances in a DB cluster use the same port.
1. Also in the **Database options** pane, select the DB cluster parameter group.
This is the parameter group associated with this instance's DB cluster. The DB cluster parameter group acts as a container for engine configuration values that are applied to every DB instance in the cluster.
1. In the **Encryption** pane, select the key that will be used to encrypt this database volume. The default is `aws/rds`. You may alternatively use a customer managed key (CMK).
1. In the **Log exports** pane, choose the log types to publish to Amazon CloudWatch Logs. The **IAM role** is already defined.
1. In the **Restore role** pane, choose either the default IAM role for the restore job or a different IAM role.
1. In the Protected resource tags pane, you may optionally choose to copy tags from the backup to the restored database cluster.
1. After specifying all your settings, choose **Restore backup**.
The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
1. After your restore finishes, attach your restored Amazon DocumentDB cluster to an Amazon RDS instance.
## Use the AWS Backup API, CLI, or SDK to restore Amazon DocumentDB recovery points
First, restore your cluster. Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. You can specify the following metadata during Amazon DocumentDB restores:
```
availabilityZones
backtrackWindow
copyTagsToSnapshot // Boolean
databaseName // string
dbClusterIdentifier // string
dbClusterParameterGroupName // string
dbSubnetGroupName // string
enableCloudwatchLogsExports // string
enableIAMDatabaseAuthentication // Boolean
engine // string
engineMode // string
engineVersion // string
kmsKeyId // string
port // integer
optionGroupName // string
scalingConfiguration
vpcSecurityGroupIds // string
```
Then, attach your restored Amazon DocumentDB cluster to an Amazon RDS instance using `create-db-instance`.
+ For Linux, macOS, or Unix:
```
aws docdb create-db-instance --db-instance-identifier sample-instance /
--db-cluster-identifier sample-cluster --engine docdb --db-instance-class db.r5.large
```
+ For Windows:
```
aws docdb create-db-instance --db-instance-identifier sample-instance ^
--db-cluster-identifier sample-cluster --engine docdb --db-instance-class db.r5.large
```
# Restore a Amazon DynamoDB table
## Use the AWS Backup console to restore DynamoDB recovery points
**To restore a DynamoDB table**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and the DynamoDB resource ID you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. For **Settings**, **New table name** text field, enter a new table name.
1. For **Restore role**, choose the IAM role that AWS Backup will assume for this restore.
1. For **Encryption settings**:
1. If your backup is managed by DynamoDB (its ARN begins with `arn:aws:dynamodb`), AWS Backup encrypts your restored table using an AWS-owned key.
To choose a different key to encrypt your restored table, you can either use the AWS Backup [StartRestoreJob operation](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html) or perform the restore from the [DynamoDB console](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Restore.Tutorial.html#restoretable_console).
1. If your backup supports full AWS Backup management (its ARN begins with `arn:aws:backup`), you can choose any of the following encryption options to protect your restored table:
+ (Default) DynamoDB-owned KMS key (no additional charge for encryption)
+ DynamoDB-managed KMS key (KMS charges apply)
+ Customer-managed KMS key (KMS charges apply)
"DynamoDB-owned" and "DynamoDB-managed" keys are the same as "AWS-owned" and "AWS-managed" keys, respectively. For clarification, see [ Encryption at Rest: How It Works](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.howitworks.html) in the *Amazon DynamoDB Developer Guide*.
For more information about full AWS Backup management, see [Advanced DynamoDB backup](advanced-ddb-backup.md).
**Note**
The following guidance applies only if you restore a copied backup AND want to encrypt the restored table with the same key you used to encrypt your original table.
When restoring a cross-Region backup, to encrypt your restored table using the same key you used to encrypt your original table, your key must be a multi-Region key. AWS-owned and AWS-managed keys are not multi-Region keys. To learn more, see [Multi-Region keys](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) in the *AWS Key Management Service Developer Guide*.
When restoring a cross-account backup, to encrypt your restored table using the same key you used to encrypt your original table, you must share the key in your source account with your destination account. AWS-owned and AWS-managed keys cannot be shared between accounts. To learn more, see [Allowing users in other accounts to use a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) in the *AWS Key Management Service Developer Guide*.
1. Choose **Restore backup**.
The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
## Use the AWS Backup API, CLI, or SDK to restore DynamoDB recovery points
Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. You can specify the following metadata during any DynamoDB restore. The metadata is not case-sensitive.
```
targetTableName
encryptionType
kmsMasterKeyArn
aws:backup:request-id
```
The following is an example of the `restoreMetadata` argument for a `StartRestoreJob` operation in the CLI:
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:us-east-1:123456789012:recovery-point:abcdef12-g3hi-4567-8cjk-012345678901" \
--iam-role-arn "arn:aws:iam::123456789012:role/YourIamRole" \
--metadata 'TargetTableName=TestRestoreTestTable,EncryptionType=KMS,kmsMasterKeyArn=arn:aws:kms:us-east-1:123456789012:key/abcdefg' \
--region us-east-1 \
--endpoint-url https://endpointurl.com
```
The preceding example encrypts the restored table using a customer-managed key.
To encrypt your restored table using an AWS-owned key, specify the following restore metadata: `"encryptionType\":\"Default\"`.
To encrypt your restored table using an AWS-managed key, omit the `kmsMasterKeyArn` parameter and specify: `"encryptionType\":\"KMS\"`.
To encrypt your restored table using a customer-managed key, specify the following restore metadata: `"encryptionType\":\"KMS\",\"kmsMasterKeyArn\":\"arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab\"`.
# Restore an Amazon EBS volume
When you restore an Amazon Elastic Block Store (EBS) snapshot, you can choose to restore it as an EBS volume, restore it to a AWS Storage Gateway volume, or restore selected items from it to an Amazon S3 bucket.
## Restore to an EBS volume
When you restore a snapshot (periodic backup of EBS data) to a new volume, you will specify the volume type, size in GiB, and an availability zone. You can optionally choose to encrypt the new volume with an existing or new AWS KMS key.
## Restore to a gateway volume
When you restore to a gateway volume, you will need to specify a gateway in a reachable state, choose your iSCSI target name, and choose a disk ID if your gateway is volume stored or a capacity equal or greater than your snapshot if your gateway is volume cached.
## File level restore to an Amazon S3 bucket
Prior to starting a restore job of EBS resources to an Amazon S3 bucket, review [ EBS permissions](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) and [Amazon S3 restore permissions](restoring-s3.md#s3-restore-permissions) for access requirements. The necessary permissions are contained in the managed policy [AWSBackupServiceRolePolicyForItemRestores](security-iam-awsmanpol.md#AWSBackupServiceRolePolicyForItemRestores) and should be included in the [IAM role](authentication.md) used for the restore operation.
All new object uploads, including restored data, to an S3 bucket is automatically encrypted. When you choose this type of restore, specify SSE-S3 (server-side Amazon S3 managed key) or SSE-KMS (server-side AWS KMS managed key). SSE-S3 is the default.
You can input up to five paths when restoring from the AWS Backup console; you can specify multiple paths through the command line. A path must have a length less than 1024 bytes in UTF-8 encoded strings, including the user-designated and AWS Backup-designated prefixes
If your snapshot contains multiple partitions, specify the file system identifier of the partition that contains the data you plan to restore. This identifier can be found using [Backup search](backup-search.md) and is the same of the UUID or file system Disk ID.
| | To new EBS volume | To gateway | File level restore to S3 bucket |
| --- | --- | --- | --- |
| Encryption | Optional. You can choose an existing AWS KMS key or create a new KMS key. | | Required. Choose from SSE-S3, SSE-KMS, or the default destination bucket encryption1. |
| Permissions and roles | Choose existing role; If none exists, default role with correct permissions is created. | Choose existing role;If none exists, default role with correct permissions is created | Role choice must have sufficient [EBS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) and [Amazon S3 restore permissions](restoring-s3.md#s3-restore-permissions). |
| Restore from cold storage (EBS Archive Tier) | Available | Unavailable | Unavailable |
| Settings to specify | Volume type; size (GiB); Availability zone; Throughput | Gateway (in a reachable state); iSCSI target name; Disk id (for volume stored gateways); Capacity (for volume cached gateways) | Restore type, including: Destination bucket name; Path(s) to restore; Encryption type; File level restore KMS Key Id if SSE-KMS is set as encryption type |
1In the AWS Backup console, you select one of the three encryption options; if you use CLI to restore, omit `encryptionType` to restore to the default destination bucket encryption.
## Restore an EBS snapshot with the AWS Backup console
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and then choose the EBS resource ID you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. Specify the restore parameters for your resource. The restore parameters you enter are specific to the resource type that you selected.
For **Resource type**, choose the AWS resource to create when restoring this backup.
1. If you choose **EBS volume**, provide the values for **Volume type**, **Size (GiB)**, and choose an **Availability zone**. After **Throughput**, there will be an optional checkbox **Encrypt this volume**. *This option will stay active if the EBS recovery point is encrypted.*. You may specify a KMS key or you may create an AWS KMS key.
If you choose **Storage Gateway volume**, choose a **Gateway** in a reachable state. Also choose your **iSCSI target name**. For *Volume stored* gateways, choose a **Disk Id**. For *Volume cached* gateways, choose a capacity that is at least as large as your protected resource.
If you choose **file level restore**, you can include up to 5 objects or folders from the snapshot. You can [search your indexed backups](backup-search.md) to find the file name or path.
+ Input the file paths.
+ Choose to use an existing Amazon S3 bucket or create a new bucket for the destination where the objects or folders will be restored.
+ Set the encryption of the restored object(s). You can choose the default destination bucket encryption, SSE-S3, or SSE-KMS. For additional detail, see [Restore S3 data using AWS Backup](restoring-s3.md).
1. For **Restore role**, choose the IAM role that AWS Backup will assume for this restore. If the AWS Backup default role is not present in your account, a **Default role** is created for you with the correct permissions. You can delete this default role or make it unusable.
1. Choose **Restore backup** (**Restore items** is displayed for file level restore).
The **Restore jobs** pane will appear. A message at the top of the page provides information about the restore job.
### Restore from archived EBS snapshots
Restoring an archived EBS snapshot moves it from cold to warm storage temporarily to create a new EBS volume. This type of restore incurs a one-time retrieval charge. Storage costs for both warm and cold storage are billed during this restore period.
**Tip**
EBS volumes in cold storage can't be restored to a gateway volume or be restored at the file level.
You can restore an archived EBS snapshot in cold storage by using the [AWS Backup console](https://console.aws.amazon.com/backup/) or the command line. A restore from cold storage can take up to 72 hours. For more information, see [Archive Amazon EBS snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html) in the *Amazon EBS User Guide*.
------
#### [ Console ]
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. Navigate to **Backup vaults** > *Vault* > **Restore archived EBS snapshot**.
1. In the **Settings** section, input a value from 0 to 180, inclusive, that specifies the number of days to temporarily restore an archived snapshot.
1. Input other settings: volume type, size, IOPS, availability zone, throughput, and encryption.
1. Choose your **restore role**.
1. Select **Restore backup**. On the confirmation pop up, confirm the snapshots and restore type. Then, select **Restore snapshot**.
------
#### [ AWS CLI ]
1. Use [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html)
1. Include the required parameters for archived EBS snapshot restore:
```
--recovery-point-arn arn:aws:backup:region:account-id:recovery-point:recovery-point-id
--metadata '{"temporaryRestoreDays":"value","volumeType":"value","volumeSize":"value","availabilityZone":"value"}'
--iam-role-arn arn:aws:iam::account-id:role/service-role/AWSBackupDefaultServiceRole
--resource-type EBS
```
1. Specify the temporary restore duration (0-180 days) in the `temporaryRestoreDays` parameter. This determines how long the archived snapshot will be available in warm storage.
1. Configure the new EBS volume settings including `volumeType` (gp2, gp3, io1, io2, st1, sc1), `volumeSize` in GiB, and target `availabilityZone`.
1. Monitor the restore job status using [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-restore-job.html) with the returned restore job ID. Archive restores can take up to 72 hours to complete.
------
## Restore an EBS snapshot by AWS CLI
To restore Amazon EBS using the API or CLI, use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. You can specify the following metadata during an Amazon EBS restore:
```
aws:backup:request-id
availabilityZone
encrypted // if set to true, encryption will be enabled as volume is restored
iops
kmsKeyId // if included, this key will be used to encrypt the restored volume instead of default KMS Key Id
restoreType // include for file level restore - see details below
throughput
temporaryRestoreDays
volumeType
volumeSize
```
Example:
```
"restoreMetadata": "{\"encrypted\":\"false\",\"volumeId\":\"vol-04cc95f3490b5ceea\",\"availabilityZone\":null}"
```
**File level restore specifications**
`restoreType` is required for file level restore. For this type of restore, the following unique metadata is required:
```
destinationBucketName //
pathsToRestore //
encryptionType // You can specify SSE-S3 or SSE-KMS; do not include if you want to restore to default encryption
kmsKeyId //
```
Filesystem identifier is optional for single partition Snapshots. If this information is not passed, then just the absolute path without the “:” separator (such as `{"/data/process/abc.txt", "/data/department/xyz.txt"}`) will be accepted.
# Restore an Amazon EC2 instance
When you restore an EC2 instance, AWS Backup creates an Amazon Machine Image (AMI), an instance, the Amazon EBS root volume, Amazon EBS data volumes (if the protected resource had data volumes), and Amazon EBS snapshots. You can customize some instance settings using the AWS Backup console, or a larger number of settings using the AWS CLI or an AWS SDK.
The following considerations apply to restoring EC2 instances:
+ AWS Backup configures the restored instance to use the same key pair that the protected resource used originally. You can't specify a different key pair for the restored instance during the restore process.
+ AWS Backup does not back up and restore user-data that is used while launching an Amazon EC2 instance.
+ When configuring the restored instance, you can choose between using the same instance profile that the protected resource used originally or launching without an instance profile. This is to prevent the possibility of privilege escalations. You can update the instance profile for the restored instance using the Amazon EC2 console.
If you use the original instance profile, you must grant AWS Backup the following permissions, where the resource ARN is the ARN of the IAM role associated with the instance profile.
```
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::account-id:role/role-name"
},
```
Replace *role-name* with the name of the EC2 instance profile role that will be attached to the restored EC2 instance. This is not the AWS Backup service role, but rather the IAM role that provides permissions to applications running on the EC2 instance.
+ During a restore, all Amazon EC2 quotas and configuration restrictions apply.
+ If the vault containing your Amazon EC2 recovery points has a vault lock, see [Additional security considerations](vault-lock.md#using-vault-lock-with-backup) for more information.
## Use the AWS Backup console to restore Amazon EC2 recovery points
You can restore an entire Amazon EC2 instance from a single recovery point, including the root volume, data volumes, and some instance configuration settings, such as the instance type and key pair.
**To restore Amazon EC2 resources using the AWS Backup console**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources**, then choose the ID of the Amazon EC2 resource to open the resource details page.
1. In the **Recovery points** pane, choose the radio button next to the ID of the recovery point to restore. In the upper-right corner of the pane, choose **Restore**.
1. In the **Network settings** pane, we use the settings from the protected instance to select the default values for the instance type, VPC, subnet, security group, and instance IAM role. You can use these default values or change them as needed.
1. In the **Restore role** pane, use the **Default role** or use **Choose an IAM role** to specify an IAM role that grants AWS Backup permission to restore the backup.
1. In the **Protected resource tags** pane, we select **Copy tags from the protected resource to the restored resource** by default. If you do not want to copy these tags, clear the check box.
1. In the **Advanced settings** pane, accept the default values for the instance settings or change them as needed. For information about these settings, choose **Info** for the setting to open its help pane.
1. When you are finishing configuring the instance, choose **Restore backup**.
## Restore Amazon EC2 with AWS CLI
In the command line interface, [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html) allows you to restore with up to 32 parameters (including some parameters that are not customizable through the AWS Backup console).
The following list is the accepted metadata you can pass to restore an Amazon EC2 recovery point.
```
InstanceType
KeyName
SubnetId
Architecture
EnaSupport
SecurityGroupIds
IamInstanceProfileName
CpuOptions
InstanceInitiatedShutdownBehavior
HibernationOptions
DisableApiTermination
CreditSpecification
Placement
RootDeviceType
RamdiskId
KernelId
UserData
Monitoring
NetworkInterfaces
ElasticGpuSpecification
CapacityReservationSpecification
InstanceMarketOptions
LicenseSpecifications
EbsOptimized
VirtualizationType
Platform
RequireIMDSv2
BlockDeviceMappings
aws:backup:request-id
```
AWS Backup accepts the following information-only attributes. However, including them will not affect the restore:
```
vpcId
```
[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-block-device-mapping.html#create-ami-bdm](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-block-device-mapping.html#create-ami-bdm) is an optional parameter you can include. AWS Backup supports the following `BlockDeviceMappings` attributes.
**Note**
`SnapshotId` and `OutpostArn` are not supported.
```
{
"BlockDeviceMappings": [
{
"DeviceName" : string,
"NoDevice" : string,
"VirtualName" : string,
"Ebs": {
"DeleteOnTermination": boolean,
"Iops": number,
"VolumeSize": number,
"VolumeType": string,
"Throughput": number,
"Encrypted": boolean,
"KmsKeyId": string
}
}
}
```
For example:
```
{
"BlockDeviceMappings": [
{
"DeviceName": "/def/tuvw",
"Ebs": {
"DeleteOnTermination": true,
"Iops": 3000,
"VolumeSize": 16,
"VolumeType": "gp3",
"Throughput": 125,
"Encrypted": true,
"KmsKeyId": "arn:aws:kms:us-west-2:123456789012:key/ab3cde45-67f8-9g01-hi2j-3456klmno7p8"
}
},
{
"DeviceName": "/abc/xyz",
"Ebs": {
"DeleteOnTermination": false,
"Iops": 3000,
"VolumeSize": 16,
"VolumeType": "gp3",
"Throughput": 125,
"Encrypted": false
}
}
]
}
```
You can also restore an Amazon EC2 instance without including any stored parameters. This option is available on the **Protected resource** tab on the AWS Backup console.
**Important**
If you do not override the AWS KMS key in the `BlockDeviceMappings` when restoring from cross-account or cross-Region backups, your restore might fail. For more information, see [Troubleshoot Amazon EC2 instance restore issues](#restoring-ec2-troubleshooting).
## Troubleshoot Amazon EC2 instance restore issues
**Topics**
+ [Cross-account restore failures](#cross-account-kms-issue)
+ [Cross-Region restore failures](#cross-region-kms-issue)
### Cross-account restore failures
**Description: **Amazon EC2 instance restore fails when attempting to restore from a backup that is shared with your account.
**Possible issues: ** Your account might not have access to the AWS KMS keys used to encrypt the source volumes in the sharing account. The KMS keys might not be shared with your account.
Or, the volumes attached to the source instance are unencrypted.
**Solution: ** To resolve this issue, set the `encrypted` attribute to `true`, and do one of the following:
+ Override the KMS keys in the `BlockDeviceMappings` and specify a KMS key that you own in your account.
+ Request the owning account to grant you access to the KMS keys used to encrypt the volumes by updating the KMS key policy. For more information, see [Allow users in other accounts to use a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html).
### Cross-Region restore failures
**Description: **Amazon EC2 instance restore fails when attempting to restore from a cross-Region backup.
**Issue: ** The volumes in the backup might be encrypted with single-Region AWS KMS keys that are not available in the destination Region. Or, the volumes attached to the source instance are unencrypted.
**Solution: ** To resolve this issue, set the `encrypted` attribute to `true`, and override the KMS key in the `BlockDeviceMappings` with a KMS key in the destination Region.
# Restore an Amazon EFS file system
If you are restoring an Amazon Elastic File System (Amazon EFS) instance, you can perform a full restore or an item-level restore.
**Full Restore**
When you perform a full restore, the entire file system is restored.
AWS Backup does not support destructive restores with Amazon EFS. A destructive restore is when a restored file system deletes or overwrites the source or existing file system. Instead, AWS Backup restores your file system to a recovery directory off of the root directory.
**Item-Level Restore**
When you perform an item-level restore, AWS Backup restores a specific file or directory. You must specify the path relative to the file system root. For example, if the file system is mounted to `/user/home/myname/efs` and the file path is `user/home/myname/efs/file1`, you enter **/file1**. Paths are case sensitive. Wildcard characters and regex strings are not supported. Your path may be different from what is in the host if the file system is mounted using an access point.
You can select up to 10 items when you use the console to perform an EFS restore. There is no item limit when you use CLI to restore; however, there is a 200 KB limit on the length of the restore metadata that can be passed.
You can restore those items to either a new or existing file system. Either way, AWS Backup creates a new Amazon EFS directory (`aws-backup-restore_datetime`) off of the root directory to contain the items. The full hierarchy of the specified items is preserved in the recovery directory. For example, if directory A contains subdirectories B, C, and D, AWS Backup retains the hierarchical structure when A, B, C, and D are recovered. Regardless of whether you perform an Amazon EFS item-level restore to an existing file system or to a new file system, each restore attempt creates a new recovery directory off of the root directory to contain the restored files. If you attempt multiple restores for the same path, several directories containing the restored items might exist.
**Note**
If you only keep one weekly backup, you can only restore to the state of the file system at the time you took that backup. You can't restore to prior incremental backups.
## Use the AWS Backup console to restore an Amazon EFS recovery point
**To restore an Amazon EFS file system**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. Your EFS backup vault receives the access policy `Deny` `backup:StartRestoreJob` upon creation. If you are restoring your backup vault for the first time, you must change your access policy as follows.
1. Choose **Backup vaults**.
1. Choose the backup vault containing the recovery point you would like to restore.
1. Scroll down to the vault **Access policy**
1. If present, delete `backup:StartRestoreJob` from the `Statement`. Do this by choosing **Edit**, deleting `backup:StartRestoreJob`, then choosing **Save policy**.
1. In the navigation pane, choose **Protected resources** and the EFS file system ID you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected file system ID is shown. To restore a file system, in the **Backups** pane, choose the radio button next to the recovery point ID of the file system. In the upper-right corner of the pane, choose **Restore**.
1. Specify the restore parameters for your file system. The restore parameters you enter are specific to the resource type that you selected.
You can perform a **Full restore**, which restores the entire file system. Or, you can restore specific files and directories using **Item-level restore**.
+ Choose the **Full restore** option to restore the file system in its entirety including all root level folders and files.
+ Choose the **Item-level restore** option to restore a specific file or directory. You can select and restore up to five items within your Amazon EFS.
To restore a specific file or directory, you must specify the relative path related to the mount point. For example, if the file system is mounted to `/user/home/myname/efs` and the file path is `user/home/myname/efs/file1`, enter **/file1**. Paths are case sensitive and cannot contain special characters, wildcard characters, and regex strings.
1. In the **Item path** text box, enter the path for your file or folder.
1. Choose **Add item** to add additional files or directories. You can select and restore up to five items within your EFS file system.
1. For **Restore location**
+ Choose **Restore to directory in source file system** if you want to restore to the source file system.
+ Choose **Restore to a new file system** if you want to restore to a different file system.
1. For **File system type**
+ (Recommended) Choose **Regional** if you want to restore your file system across multiple AWS Availability Zones.
+ Choose **One Zone** if you want to restore your file system to a single Availability Zone. Then, in the **Availability Zone** dropdown, choose the destination for your restore.
For more information, see [Managing Amazon EFS storage classes](https://docs.aws.amazon.com/efs/latest/ug/storage-classes.html) in the *Amazon EFS User Guide.*
1. For **Performance**
+ If you chose to perform a **Regional** restore, choose either **(Recommended) General purpose** or **Max I/O**.
+ If you chose to perform a **One Zone** restore, you must choose **(Recommended) General purpose**. One Zone restores do not support **Max I/O**.
1. For **Enable encryption**
+ Choose **Enable encryption**, if you want to encrypt your file system. KMS key IDs and aliases appear in the list after they have been created using the AWS Key Management Service (AWS KMS) console.
+ In the **KMS key** text box, choose the key you want to use from the list.
1. For **Restore role**, choose the IAM role that AWS Backup will assume for this restore.
**Note**
If the AWS Backup default role is not present in your account, a **Default role** is created for you with the correct permissions. You can delete this default role or make it unusable.
1. Choose **Restore backup**.
The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
**Note**
If you only keep one weekly backup, you can only restore to the state of the file system at the time you took that backup. You can't restore to prior incremental backups.
## Use the AWS Backup API, CLI, or SDK to restore Amazon EFS recovery points
Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. When restoring an Amazon EFS instance, you can restore an entire file system or specific files or directories. To restore Amazon EFS resources, you need the following information:
+ `file-system-id` — The ID of the Amazon EFS file system that is backed up by AWS Backup. Returned in `GetRecoveryPointRestoreMetadata`. This is not required when a **new** file system is restored (this value is ignored if parameter `newFileSystem` is `True`).
+ `Encrypted` — A Boolean value that, if true, specifies that the file system is encrypted. If `KmsKeyId` is specified, `Encrypted` must be set to `true`.
+ `KmsKeyId` — Specifies the AWS KMS key that is used to encrypt the restored file system.
+ `PerformanceMode` — Specifies the throughput mode of the file system. Valid values are `generalPurpose` (default) and `maxIO`. The `generalPurpose` mode provides the lowest latency per operation and can achieve up to 7,000 file operations per second. The `maxIO` mode can scale to higher levels of aggregate throughput and operations per second with a slightly higher latency for file operations.
+ `CreationToken` — A user-supplied value that ensures the uniqueness (idempotency) of the request.
+ `newFileSystem` — A Boolean value that, if true, specifies that the recovery point is restored to a new Amazon EFS file system.
+ `ItemsToRestore ` — An array of up to five strings where each string is a file path. Use `ItemsToRestore` to restore specific files or directories rather than the entire file system. This parameter is optional.
You may also include `aws:backup:request-id`.
One Zone restores can be performed by including parameters:
```
"singleAzFilesystem": "true"
"availabilityZoneName": "ap-northeast-3"
```
For more information about Amazon EFS configuration values, see [create-file-system](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/efs/create-file-system.html).
## Disabling automatic backups in Amazon EFS
By default, [ Amazon EFS creates backups of data automatically](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html#automatic-backups). These backups are represented as recovery points in AWS Backup. Attempts to remove the recovery point will result in an error message that notes there are insufficient privileges to perform the action.
It is best practice to keep this auto-backup active. Particularly in the case of accidental data deletion, this backup allows restoration of file system content to the date of the last recovery point created.
In the unlikely event you wish to turn these off, the access policy must be changed from `"Effect": "Deny"` to `"Effect": "Allow"`. See the *Amazon EFS User Guide* for more information about turning [ automatic backups](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html#automatic-backups) on or off.
# Restore an Amazon EKS cluster
You can restore EKS cluster backups using the AWS Backup console or CLI. EKS backups are composite recovery points that include both EKS cluster state and persistent volume backups.
AWS Backup supports multiple restore experiences including granular namespace-level restores. Restores are non-destructive and will not overwrite any existing Kubernetes objects in your target EKS cluster. Restores will also not overwrite the Kubernetes versions of the target EKS cluster.
EKS Backups have to be restored to a target EKS cluster, meaning an Amazon EKS cluster that has been pre-provisioned. As part of the restore workflow, you can opt to create a new EKS cluster which AWS Backup will create on your behalf.
**Note**
AWS Backup will provide a limited set of options for creating a new EKS cluster as a part of a restore. For all EKS cluster creation functionality, customers can create a new EKS cluster using the [EKS Console](https://console.aws.amazon.com/eks/home) or APIs and select this as their restore target.
**Restore capabilities for Amazon EKS**
| Restore type | Restore target | Restore behavior |
| --- | --- | --- |
| Existing cluster restore | Restore to the source EKS cluster or existing EKS cluster | Restores all Kubernetes resources and persistent volumes to existing EKS clusters. All restores are non-destructives and existing objects are not overwritten. For objects that are skipped, you can subscribe to [SNS Notifications](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html) |
| New cluster restore | Creates a new Amazon EKS cluster as part of your EKS restore | Restore creates new EKS cluster and restores all Kubernetes resources and persistent volumes to newly created cluster |
| Namespace restore | Existing Amazon EKS cluster | Restores only specified namespaces, their Kubernetes resources and corresponding persistent storage restores are non-destructives and existing objects are not overwritten. For objects that are skipped, you can subscribe to SNS Notifications |
| Peristent Storage Restore | Persistent Storage Dependent | Restore individual persistent storage as standalone restores. See Restore Behavior of [Amazon EBS](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-ebs.html), [Amazon S3](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-s3.html), [Amazon EFS](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-efs.html). |
**Permissions**
The permissions required depend on the restore type and target destination.
+ AWS Backup's managed policy [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#AWSBackupServiceRolePolicyForRestores) contains the required permissions to restore your Amazon EKS cluster and EBS and EFS persistent storage.
+ If your EKS Cluster contains an S3 bucket, or you are restoring the child S3 recovery point alone you will need to ensure the following policies or permissions within are assigned to your role [AWSBackupServiceRolePolicyForS3Restore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html).
**Considerations before restoring**
Before you begin an EKS restore job, review the following. If you are restoring an EKS backup that has been copied across account or region ensure you check these considerations ahead of restores to prevent restore failures.
1. **IAM Roles**: when restoring onto a different cluster, the IAM Roles used in the source cluster (such as Pod identity, IRSA. OIDC provider configs etc) must be present in the account / region as the destination cluster.
1. **Ensure EKS Version and Compatibility**: The API Versions of the objects that you're wanting to restore should be the same version (or as close to as possible) and supported in the new cluster. AWS Backup will perform a best effort restore between EKS versions, though compatibility issues may arise when restoring between significantly different versions.
1. **Matching Storage Classes**: For restores to an existing EKS cluster, ensure that the appropriate CSI Storage Driver add-ons are installed prior to restore
1. **S3 Buckets**: When restoring an EKS cluster with S3 Buckets, ensure your S3 bucket are versioned and accessible in the destination account or region.
1. **Image Repository**: When restoring an EKS cluster ensure that the destination EKS cluster's account or region have access to the images that are being referenced as part of the restore. Check that your registry has the sufficient cross-region / account policy permissions.
1. **Security Groups**: Security groups should be pre-created for ALB, Pod Identities, EKS Node Groups etc. in the target account and region if creating a new EKS cluster as part of your restore
1. **EBS Availability Zones and Nodes**: The Availability Zones where you recover your EBS volumes should be mapped to the Availability Zone of an existing EKS node
1. **Non-destructive restores**: All EKS restores will be non-destructive and not overwrite Kubernetes objects of the target restore.
1. **Enable EKS Audit Logs**: Enable EKS Audit Logs for additional logging and troubleshooting prior to restore. You can also subscribe to [SNS notifications](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html) to notify of skipped or failed objects on restore.
**EKS Configurations**
When you restore the composite Amazon AWS Backup, you choose the restore type and target destination. You can choose to restore to the source EKS cluster, an existing EKS cluster or create a new EKS cluster as the restore target. For new EKS clusters, you can choose to use the same existing infrastructure settings (e.g. VPC, subnets) as the backed up cluster or configure new ones. AWS Backup is designed to perform a non-destructive restore that doesn't overwrite existing resources.
For namespace restores, you can specify up to 5 namespaces to restore selectively. Only namespace-scoped resources are restored, while cluster-scoped resources are excluded except for related persistent volumes.
As an advanced setting you can opt to change the restore order of the Kubernetes Objects. By Default, AWS Backup will restore all Kubernetes objects in the following order:
**Cluster Scoped Kubernetes Resources**
1. Custom Resource Definitions
1. Namespaces (the namespace itself, not the resources within that namespace)
1. StorageClasses
1. PersistentVolumes
**Namespace Scoped Kubernetes Resources**
1. PersistentVolumeClaims
1. Secrets
1. ConfigMaps
1. ServiceAccounts
1. LimitRanges
1. Pods
1. ReplicaSets
**Persistent Storage Configurations**
As part of the composite Amazon EKS backup restore, the second step will be to configure your Persistent Storage configurations. This will vary based on the persistent storage backed up as part of your EKS cluster.
For Amazon EBS Snapshots you are required to provide an Availability Zone, where the Amazon EBS volume will be restored and created. AWS Backup will then attempt to create the EKS pod in the same availability zone as selected so your volume can be remounted to your EKS cluster as part of restore.
As part of the restore, AWS Backup will remount your Amazon EBS volumes and Amazon S3 buckets to your restored EKS cluster. Amazon EFS filesystems restore to random prefixes and require manual access point creation after restore to remount to your EKS cluster. AWS Backup does not create access points or mount targets on your behalf, refer to guidance here for [ access points](https://docs.aws.amazon.com/efs/latest/ug/create-access-point.html) and [mount targets](https://docs.aws.amazon.com/efs/latest/ug/manage-fs-access-create-delete-mount-targets.html).
## Amazon EKS restore procedure
Follow these steps to restore Amazon EKS backups using the AWS Backup console or AWS CLI:
------
#### [ Console ]
**To restore your Amazon EKS cluster**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Backup vaults**.
1. Choose the backup vault that contains your Amazon EKS backup, then select the recovery point for your Amazon EKS backup.
1. Choose **Restore**.
1. In the **Restore options** pane, choose your restore type:
+ **Restore full EKS cluster** - Restores the entire Amazon EKS composite recovery point
+ **Select namespaces to restore** - Restores up to five specific namespaces
1. Configure the target destination:
+ For cluster restore, choose to create a new cluster or use an existing cluster
+ For new clusters, specify cluster name, Kubernetes version, VPC configuration, IAM roles, subnets, Additional security groups, node group settings, fargate profiles and Pod identity IAM roles
+ For existing clusters, select the target cluster from the dropdown
+ For namespace restore, specify the target cluster and namespace names
1. Optionally, configure advanced settings for custom restore order for Kubernetes resources.
1. Choose the IAM restore role for the job. If not using the default role, ensure the selected role includes the iam:PassRole permission.
1. Choose **Restore backup**.
------
#### [ AWS CLI ]
Use the `aws backup start-restore-job` command with Amazon EKS-specific metadata.
The required metadata depends on your restore type. All restore operations require the `clusterName` parameter.
**Restore Amazon EKS recovery points through AWS CLI**
Use StartRestoreJob. You can specify the following metadata during Amazon EKS restores:
**Mandatory metadata:**
+ `clusterName` - Name of cluster to restore to
**Optional metadata:**
+ `newCluster` - (true/false) If we should create a new EKS cluster during restore. If newCluster is "true", the following metadata fields apply:
+ `eksClusterVersion` - Desired K8s version of cluster if wanting to increase cluster version during restore
+ `clusterRole` - The IAM Role ARN to attach to the created EKS cluster
+ `encryptionConfigProviderKeyArn` - Specify the KMS key ARN to encrypt the destination cluster. This can be either the KMS key from the source cluster, or a different KMS key. A different KMS key must be provided when performing cross-region or cross-account restore. Omit this metadata entirely if the source cluster is not encrypted.
+ `clusterVpcConfig` - VPC/Networking configuration for the created EKS cluster. This field has the following nested fields:
+ `vpcId` - The VPC associated with your cluster
+ `subnetIds [Required]` - The subnets associated with your cluster
+ `securityGroupIds [Required]` - The additional security groups associated with your cluster
+ `nodeGroups` - The Managed Node Groups to be created on the EKS Cluster. The NodeGroups for restore must have all of the same node groups from backup time and have matching nodeGroupId.
+ `nodeGroupId [Required]` - The ID of the node group
+ `subnetIds [Required]` - The subnets that were specified for the Auto Scaling group that is associated with your node group
+ `instanceTypes` - If the node group wasn't deployed with a launch template, then this is the instance type that is associated with the node group
+ `nodeRole [Required]` - The IAM role associated with your node group
+ `securityGroupIds` - The security group IDs that are allowed SSH access to the nodes
+ `remoteAccessEc2SshKey` - The Amazon EC2 SSH key name that provides access for SSH communication with the nodes in the managed node group
+ `launchTemplateId` - Specify the launch template ID to create the node group. This can be either the launch template ID from the source cluster, or a different launch template ID. If the source cluster's launch template contains hard-coded endpoint that points to the source cluster itself, you must provide a different launch template ID. Omit this metadata entirely if the source cluster does not use a launch template.
+ `launchTemplateVersion` - Launch template version associated with the specified launch template ID.
+ `fargateProfiles` - The Fargate Profiles to be created on the EKS Cluster. The Fargate Profiles for restore must have all the same Fargate Profiles from backup time and have matching name.
+ `name [Required]` - The name of the Fargate profile
+ `subnetIds` - The IDs of subnets to launch a Pod into
+ `podExecutionRoleArn [Required]` - The IAM Role ARN of the Pod execution role to use for a Pod that matches the selectors in the Fargate profile
+ `podIdentityAssociations` - The Pod Identity Associations to be created on the EKS Cluster
+ `associationId` - The ID of the Pod Identity Association
+ `roleArn` - The IAM Role ARN for the Pod Identity Association
+ `kubernetesRestoreOrder` - Override the order the Kubernetes manifests are restored in. This order will take precedence over the default service restore order. This follow the format: group/version/kind or version/kind
Ex: `["v1/persistentvolumes","v1/pods","customresource/v2/custom"]`
+ `namespaceLevelRestore` - (true/false) If you would like to perform a namespace level restore
+ `namespaces` - A list of namespaces to restore if namespaceLevelRestore is "true". Can provide up to 5 namespaces to restore.
Ex: `["ns-1","ns-2","ns-3","ns-4","ns-5"]`
+ `restoreKubernetesManifestsOnly` - (true/false) If you would like to only restore the Kubernetes manifest files and no persistent storage systems (EBS, S3, EFS, etc.)
+ `nestedRestoreJobs` - Restore Metadata configuration of all of the nested Recovery Points for the PersistentVolume storage systems in the composite Recovery Point. This is a map of RecoveryPointArn: RestoreMetadata of that Recovery Point
**Restore to existing cluster**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
--iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
--metadata '{"clusterName":"existing-cluster","newCluster":"false"}' \
--resource-type "EKS"
```
**Restore specific namespaces to an existing cluster:**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
--iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
--metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","namespaces":"[\"ns-1\",\"ns-2\",\"ns-3\",\"ns-4\",\"ns-5\"]"}' \
--resource-type "EKS"
```
**Restore nested persistent volumes to an existing cluster:**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
--iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
--metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","nestedrestorejobs":"{\"arn:aws:ec2:us-west-2::snapshot/snap-abc123\":\"{\\\"AvailabilityZone\\\":\\\"us-west-2a\\\"}\",\"arn:aws:backup:us-west-2:123456789012:recovery-point:fa71a304-2555-4c37-8128-f154b9578032\":\"{\\\"DestinationBucketName\\\":\\\"bucket-name\\\"}\"}"}' \
--resource-type "EKS"
```
**Restore to new cluster**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
--iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
--metadata '{"clusterName":"new-cluster","newCluster":"true","clusterRole":"arn:aws:iam::123456789012:role/EKSClusterRole","eksClusterVersion":"1.33","encryptionConfigProviderKeyArn":"arn:aws:kms:us-west-2:123456789012:key/ecb2b326-784d-4ec0-8d07-20ab826b5a13","clusterVpcConfig":"{\"vpcId\":\"vpc-1234\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"securityGroupIds\":[\"sg-123\"]}","nodeGroups":"[{\"nodeGroupId\":\"nodegroup-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"nodeRole\":\"arn:aws:iam::123456789012:role/EKSNodeGroupRole\",\"instanceTypes\":[\"t3.small\"],\"launchTemplateId\":\"lt-0b13949aae3f2b867\",\"launchTemplateVersion\":\"1\"}]","fargateProfiles":"[{\"name\":\"fargate-profile-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"podExecutionRoleArn\":\"arn:aws:iam::123456789012:role/EKSFargateProfileRole\"}]"}' \
--resource-type "EKS"
```
After starting the restore job, use `describe-restore-job` to monitor progress:
```
aws backup describe-restore-job --restore-job-id restore-job-id
```
------
You can subscribe to **Notification Events** for failed and skipped objects for restore. For more information, see [ Notification options with AWS Backup.](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html)
# Restore an FSx file system
The restore options that are available when you use AWS Backup to restore Amazon FSx file systems are the same as using the native Amazon FSx backup. You can use a backup's recovery point to create a new file system and restore a point-in-time snapshot of another file system.
AWS Backup supports restoring file systems that use Intelligent Tiering storage for both FSx for Lustre and FSx for OpenZFS file systems. Intelligent Tiering file systems have specific configuration requirements during restore operations.
When restoring Amazon FSx file systems, AWS Backup creates a new file system and populates it with the data (Amazon FSx for NetApp ONTAP allows restoring a volume to an existing file system). This is similar to how native Amazon FSx backs up and restores file systems. Restoring a backup to a new file system takes the same amount of time as creating a new file system. The data restored from the backup is lazy-loaded onto the file system. You might therefore experience slightly higher latency during the process.
**Note**
You can't restore to an existing Amazon FSx file system, and you can't restore individual files or folders.
FSx for ONTAP doesn’t support backing up certain volume types, including DP (data-protection) volumes, LS (load-sharing) volumes, full volumes, or volumes on file systems that are full. For more information, please see [FSx for ONTAP Working with backups](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/using-backups.html).
AWS Backup vaults that contain recovery points of Amazon FSx file systems are visible outside of AWS Backup. You can restore the recovery points using Amazon FSx but you can't delete them.
You can see backups created by the built-in Amazon FSx automatic backup functionality from the AWS Backup console. You can also recover these backups using AWS Backup. However, you can't delete these backups or change the automatic backup schedules of your Amazon FSx file systems using AWS Backup.
## Use the AWS Backup console to restore Amazon FSx recovery points
You can restore most Amazon FSx backups created by AWS Backup using the AWS Backup console, API, or AWS CLI.
This section shows you how to use the AWS Backup console to restore Amazon FSx file systems.
**Topics**
### Restoring an FSx for Windows File Server file system
**To restore an FSx for Windows File Server file system**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources**, and then choose the Amazon FSx resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. Choose the recovery point ID of the resource.
1. In the upper-right corner of the pane, choose **Restore** to open the **Restore backup** page.
1. In the **File system details** section, the ID of your backup is shown under **Backup ID**, and the file system type is shown under **File system type**. You can restore both FSx for Windows File Server and FSx for Lustre file systems.
1. For **Deployment type**, accept the default. You can't change the deployment type of a file system during restore.
1. Choose the **Storage type** to use. If the storage capacity of your file system is less than 2,000 GiB, you can't use the **HDD** storage type.
1. For **Throughput capacity**, choose **Recommended throughput capacity** to use the recommended 16 MB per second (MBps) rate, or choose **Specify throughput capacity** and enter a new rate.
1. In the **Network and security** section, provide the required information.
1. If you are restoring an FSx for Windows File Server file system, provide the** Windows authentication** information used to access the file system, or you can create a new one.
**Note**
When restoring a backup, you can't change the type of Active Directory on the file system.
For more information about Microsoft Active Directory, see [Working with Active Directory in Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/aws-ad-integration-fsxW.html) in the *Amazon FSx for Windows File Server User Guide*.
1. (Optional) In the **Backup and maintenance** section, provide the information to set your backup preferences.
1. In the **Restore role** section, choose the IAM role that AWS Backup will use to create and manage your backups on your behalf. We recommend that you choose the **Default role**. If there is no default role, one is created for you with the correct permissions. You can also provide your own IAM role.
1. Verify all your entries, and choose **Restore Backup**.
### Restoring an Amazon FSx for Lustre file system
AWS Backup supports Amazon FSx for Lustre file systems that have persistent storage deployment type and are not linked to a data repository like Amazon S3.
**Note**
You can only restore your backup to a file system of the same deployment type, storage class, throughput capacity, storage capacity, data compression type, and AWS Region as the original. You can increase your restored file system's storage capacity after it becomes available.
**To restore an Amazon FSx for Lustre file system**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources**, and then choose the Amazon FSx resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. Choose the recovery point ID of the resource.
1. In the upper-right corner of the pane, choose **Restore** to open the **Restore backup to new file system** page.
1. In the **Settings** section, the ID of your backup is shown under **Backup ID**, and the file system type is shown under **File system type**. **File system type** should be **Lustre**.
1. Choose a **Deployment type**. AWS Backup only supports the persistent deployment type. You can't change the deployment type of a file system during restore.
Persistent deployment type is for long-term storage. For detailed information about FSx for Lustre deployment options, see [Using Available Deployment Options for Amazon FSx for Lustre File Systems](https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-fsx-lustre.html) in the *Amazon FSx for Lustre User Guide*.
1. Choose the **Throughput per unit storage** that you want to use.
**Note**
Throughput per unit storage cannot be configured for file systems using Intelligent-Tiering storage class.
1. (Optional) For file systems using Intelligent-Tiering storage class, choose the SSD read cache sizing mode and capacity. For more information, see the FSx documentation for [ managing provisioned SSD read cache](https://docs.aws.amazon.com/fsx/latest/LustreGuide/managing-ssd-read-cache.html).
1. (Optional) For file systems using Intelligent-Tiering storage class, choose whether to enable EFA (Elastic Fabric Adapter). To enable EFA, make sure that your security group allows all inbound and outbound traffic within the security group.
1. Specify the **Storage capacity** to use. Enter a capacity between 32 GiB and 64,436 GiB.
**Note**
For Intelligent Tiering file systems, storage capacity is elastic and cannot be specified during restore. The capacity will automatically scale based on your data usage.
1. In the **Network and security** section, provide the required information.
1. (Optional) In the **Backup and maintenance** section, provide the information to set your backup preferences.
1. In the **Restore role** section, choose the IAM role that AWS Backup will use to create and manage your backups on your behalf. We recommend that you choose the **Default role**. If there is no default role, one is created for you with the correct permissions. You can also provide your IAM role.
1. Verify all your entries, and choose **Restore Backup**.
## Restoring Amazon FSx for NetApp ONTAP volumes
**To restore Amazon FSx for NetApp ONTAP volumes:**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources**, and then choose the Amazon FSx resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. Choose the recovery point ID of the resource.
1. In the upper-right corner of the pane, choose **Restore** to open the **Restore** page.
The first section, **File system details**, displays the recovery point ID, the file system ID, and the file system type.
1. Under **Restore options**, there are several selections. First, choose the **File system** from the dropdown menu.
1. Next, choose the preferred **Storage virtual machine** from the dropdown menu.
1. Enter a name for your volume.
1. Specify the **Junction Path**, which is location within your file system where your volume will be mounted.
1. Specify the **Volume size** in megabytes (MB) that you are creating.
1. (*Optional*) You can choose to **Enable storage efficiency** by checking the box. This will allow deduplication, compression, and compaction.
1. In the **Capacity pool tiering policy** dropdown menu, select the tiering preference.
1. In the **Restore permissions**, choose the IAM role that AWS Backup will use to restore backups.
1. Verify all your entries, and choose **Restore Backup**.
## Restoring an Amazon FSx for OpenZFS file system
**Note**
Restoring from a backup with a given storage class to a file system with a different storage class is not supported.
**To restore an FSx for OpenZFS file system**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources**, and then choose the Amazon FSx resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. Choose the recovery point ID of the resource.
1. In the upper-right corner of the pane, choose **Restore** to open the **Restore backup** page.
In the **File system details** section, the ID of your backup is shown under **Backup ID**, and the file system type is shown under **File system type**. File system type should be **FSx for OpenZFS**.
1. Under **Restore options**, you may select **Quick restore** or **Standard restore**. Quick restore will use the default settings of the source file system. If you are doing Quick Restore, skip to Step 7.
If you choose Standard restore, specify the additional following configurations:
1. **Provisioned SSD IOPS**: You can choose the **Automatic radio button** or you can choose the **User-provisioned option** if available.
**Note**
SSD IOPS cannot be set for file systems using Intelling-Tiering storage class
1. **Throughput capacity**: You can choose the **Recommended throughput capacity** of 64 MB/sec (for SSD storage class), and 160 MB/sec (for Intelligent-Tiering storage class), or you can choose to **Specify throughput capacity**.
1. (*Optional*) **VPC security groups**: You can specify VPC security groups to associate with your file system’s network interface.
1. **Encryption key**: Specify the AWS Key Management Service key to protect the restored file system data at rest.
1. (*Optional*) **Root Volume configuration**: This configuration is collapsed by default. You may expand it by clicking the down-pointing carat (arrow). Creating a file system from a backup will create a new file system; the volumes and snapshots will retain their source configurations.
1. (*Optional*) **Backup and maintenance**: To set a scheduled backup, click the down-pointing carat (arrow) to expand the section. You may choose the backup window, hour and minute, retention period, and weekly maintenance window.
1. The **SSD Storage capacity** will display the file system’s storage capacity.
**Note**
For Intelligent Tiering file systems, storage capacity is elastic and cannot be specified during restore. The capacity will automatically scale based on your data usage.
1. (Optional) For file systems using Intelligent-Tiering storage class, choose the SSD read cache sizing mode and capacity. For more information, see the FSx documentation for [ managing provisioned SSD read cache](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/managing-ssd-read-cache.html).
1. Choose the **Virtual Private Cloud** (VPC) from which your file system can be accessed.
1. In the **Subnet** dropdown menu, choose the subnet in which your file system’s network interface resides.
1. In the **Restore role** section, choose the IAM role that AWS Backup will use to create and manage your backups on your behalf. We recommend that you choose the **Default role**. If there is no default role, one is created for you with the correct permissions. You can also choose an IAM role.
1. Verify all your entries, and choose **Restore Backup**.
## Use the AWS Backup API, CLI, or SDK to restore Amazon FSx recovery points
To restore Amazon FSx using the API or CLI, use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. You can specify the following metadata during an Amazon FSx restore:
```
StorageCapacity
StorageType
VpcId
KmsKeyId
SecurityGroupIds
SubnetIds
DeploymentType
WeeklyMaintenanceStartTime
DailyAutomaticBackupStartTime
AutomaticBackupRetentionDays
CopyTagsToBackups
WindowsConfiguration
LustreConfiguration
OntapConfiguration
OpenZFSConfiguration
aws:backup:request-id
```
**Note**
Storage capacity cannot be specified for Intelligent Tiering file systems as they use elastic storage that scales automatically based on data usage.
### FSx for Windows File Server restore metadata
You can specify the following metadata during an FSx for Windows File Server restore:
+ ThroughputCapacity
+ PreferredSubnetId
+ ActiveDirectoryId
### FSx for Lustre restore metadata
You can specify the following subfields of `LustreConfiguration` in the metadata during an FSx for Lustre restore:
+ `PerUnitStorageThroughput` - Specifies the throughput capacity per unit of storage provisioned, measured in MB/s per TiB of storage.
+ `DriveCacheType` - The type of drive cache used by `PERSISTENT_1` file systems that are provisioned with HDD storage devices. This parameter is required when `StorageType` is set to HDD.
+ `DataReadCacheConfiguration` - Specifies the provisioned SSD read cache for Intelligent Tiering file systems. Required when `StorageType` is set to `INTELLIGENT_TIERING`. See [ LustreReadCacheConfiguration](https://docs.aws.amazon.com/fsx/latest/APIReference/API_LustreReadCacheConfiguration.html) for more details.
+ `EfaEnabled` - Specifies whether Elastic Fabric Adapter (EFA) and GPUDirect Storage (GDS) support is enabled for the FSx for Lustre file system.
For complete details about all available parameters in `LustreConfiguration`, please see [ CreateFileSystemLustreConfiguration](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateFileSystemLustreConfiguration.html) in the *Amazon FSx API Reference*.
### FSx for ONTAP restore metadata
You can specify the following metadata during an FSx for ONTAP restore:
+ Name \$1name of volume to be created
+ OntapConfiguration: \$1 ontap configuration
+ `junctionPath`
+ `sizeInMegabytes`
+ `storageEfficiencyEnabled`
+ `storageVirtualMachineId`
+ `tieringPolicy`
### FSx for OpenZFS restore metadata
You can specify the following subfields of `OpenZFSConfiguration` in the metadata during an FSx for OpenZFS restore:
+ `ThroughputCapacity` - Specifies the throughput capacity of the restored file system, measured in MB/s.
+ `DiskIopsConfiguration` - When specifying Iops for SSD storage class, use a value between 0 and 160,000. Do not include Mode when Iops is specified.
+ `ReadCacheConfiguration` - Specifies the provisioned SSD read cache for Intelligent Tiering file systems. Required when `StorageType` is set to `INTELLIGENT_TIERING`. See [ OpenZFSReadCacheConfiguration](https://docs.aws.amazon.com/fsx/latest/APIReference/API_OpenZFSReadCacheConfiguration.html) for more details.
For complete details about all available parameters in `OpenZFSConfiguration`, please see [ CreateFileSystemOpenZFSConfiguration](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateFileSystemOpenZFSConfiguration.html) in the *Amazon FSx API Reference*.
Example CLI restore command:
```
aws backup start-restore-job --recovery-point-arn "arn:aws:fsx:us-west-2:1234:backup/backup-1234" --iam-role-arn "arn:aws:iam::1234:role/Role" --resource-type "FSx" --region us-west-2 --metadata 'SubnetIds="[\"subnet-1234\",\"subnet-5678\"]",StorageType=HDD,SecurityGroupIds="[\"sg-bb5efdc4\",\"sg-0faa52\"]",WindowsConfiguration="{\"DeploymentType\": \"MULTI_AZ_1\",\"PreferredSubnetId\": \"subnet-1234\",\"ThroughputCapacity\": \"32\"}"'
```
Example restore metadata:
```
"restoreMetadata": "{\"StorageType\":\"SSD\",\"KmsKeyId\":\"arn:aws:kms:us-east-1:123456789012:key/123456a-123b-123c-defg-1h2i2345678\",\"StorageCapacity\":\"1200\",\"VpcId\":\"vpc-0ab0979fa431ad326\",\"FileSystemType\":\"LUSTRE\",\"LustreConfiguration\":\"{\\\"WeeklyMaintenanceStartTime\\\":\\\"4:10:30\\\",\\\"DeploymentType\\\":\\\"PERSISTENT_1\\\",\\\"PerUnitStorageThroughput\\\":50,\\\"CopyTagsToBackups\\\":true}\",\"FileSystemId\":\"fs-0ca11fb3d218a35c2\",\"SubnetIds\":\"[\\\"subnet-0e66e94eb43235351\\\"]\"}"
```
# Restore a Neptune cluster
## Use the AWS Backup console to restore Amazon Neptune recovery points
Restoring an Amazon Neptune database requires that you specify multiple restore options. For information about these options, see [ Restoring from a DB Cluster Snapshot](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-restore-snapshot.html) in the *Neptune User Guide*.
**To restore an Neptune database**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and the Neptune resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. In the **Instance specifications** pane, accept the defaults or specify the **DB engine** and **Version**.
1. In the **Settings** pane, specify a name that is unique for all DB cluster instances owned by your AWS account in the current Region. The DB cluster identifier is case insensitive, but it is stored as all lowercase, as in "`mydbclusterinstance`". This is a required field.
1. In the **Database options** pane, accept the defaults or specify the options for **Database port** and **DB cluster parameter group**.
1. In the **Encryption** pane, accept the default or specify the options for the **Enable encryption** or **Disable encryption** settings.
1. In the **Log exports** pane, choose the log types to publish to Amazon CloudWatch Logs. The **IAM role** is already defined.
1. In the **Restore role** pane, choose the IAM role that AWS Backup will assume for this restore.
1. After specifying all your settings, choose **Restore backup**.
The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
1. After your restore finishes, attach your restored Neptune cluster to an Amazon RDS instance.
## Use the AWS Backup API, CLI, or SDK to restore Neptune recovery points
First, restore your cluster. Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. You can specify the following metadata during Amazon DocumentDB restores:
```
availabilityZones
backtrackWindow
copyTagsToSnapshot // Boolean
databaseName // string
dbClusterIdentifier // string
dbClusterParameterGroupName // string
dbSubnetGroupName // string
enableCloudwatchLogsExports // string
enableIAMDatabaseAuthentication // Boolean
engine // string
engineMode // string
engineVersion // string
kmsKeyId // string
port // integer
optionGroupName // string
scalingConfiguration
vpcSecurityGroupIds // string
```
Then, attach your restored Neptune cluster to an Amazon RDS instance using `create-db-instance`.
+ For Linux, macOS, or Unix:
```
aws neptune create-db-instance --db-instance-identifier sample-instance \
--db-instance-class db.r5.large --engine neptune --engine-version 1.0.5.0 --db-cluster-identifier sample-cluster --region us-east-1
```
+ For Windows:
```
aws neptune create-db-instance --db-instance-identifier sample-instance ^
--db-instance-class db.r5.large --engine neptune --engine-version 1.0.5.0 --db-cluster-identifier sample-cluster --region us-east-1
```
For more information, see [https://docs.aws.amazon.com/neptune/latest/userguide/api-snapshots.html#RestoreDBClusterFromSnapshot](https://docs.aws.amazon.com/neptune/latest/userguide/api-snapshots.html#RestoreDBClusterFromSnapshot) in the *Neptune Management API reference* and [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/neptune/restore-db-cluster-from-snapshot.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/neptune/restore-db-cluster-from-snapshot.html) in the *Neptune CLI guide*.
# Restore an RDS database
Restoring an Amazon RDS database requires specifying multiple restore options. For more information about these options, see [Backing Up and Restoring an Amazon RDS DB Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html) in the *Amazon RDS User Guide*.
## Use the AWS Backup console to restore Amazon RDS recovery points
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and the Amazon RDS resource ID you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. In the **Instance specifications** pane, accept the defaults or specify the options that you need.
1. In the **Settings** pane, specify a name that is unique for all DB instances and clusters owned by your AWS account in the current Region. The DB instance identifier is case insensitive, but it is stored as all lowercase, as in "`mydbinstance`". This is a required field.
1. In the **Network & Security** pane, accept the defaults or specify the options that you need.
1. In the **Database options** pane, accept the defaults or specify the options that you need.
1. In the **Encryption** pane, use the default settings. If the source database instance for the snapshot was encrypted, the restored database instance will also be encrypted. This encryption cannot be removed.
1. In the **Log exports** pane, choose the log types to publish to Amazon CloudWatch Logs. The **IAM role** is already defined.
1. In the **Maintenance** pane, accept the default or specify the option for **Auto minor version upgrade**.
1. In the **Restore role** pane, choose the IAM role that AWS Backup will assume for this restore.
1. Choose **Restore backup**.
The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
## Use the AWS Backup API, CLI, or SDK to restore Amazon RDS recovery points
Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. For information on accepted metadata and values, see [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) and [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) in the *Amazon RDS API Reference*. Additionally, AWS Backup accepts the following information-only attributes. However, including them will not affect the restore:
```
EngineVersion
KmsKeyId
Encrypted
vpcId
```
# Restore an Amazon Redshift cluster
You can restore automated and manual snapshots in the AWS Backup console or through CLI.
When you restore a Amazon Redshift cluster, the original cluster settings are input into the console by default. You can specify different settings for the configurations below. When restoring a table, you must specify the source and target databases. For more information on these configurations, see [ Restoring a cluster from a snapshot](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html#working-with-snapshot-restore-cluster-from-snapshot) in the *Amazon Redshift Management Guide*.
+ **Single table or cluster**: You can choose to restore an entire cluster or a single table. If you choose to restore a single table, the source database, source schema, and source table name are needed, as well as the target cluster, schema, and new table name.
+ **Node type**: Each Amazon Redshift cluster consists of a leader node and at least one compute node. When you restore a cluster, you need to specify the node type that meets your requirements for CPU, RAM, storage capacity, and drive type.
+ **Number of nodes**: When restoring a cluster, you need to specify the number of nodes needed.
+ **Configuration summary**
+ **Cluster Permissions**
## To restore an Amazon Redshift cluster or table using the AWS Backup console
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Settings** and the Amazon Redshift resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Recovery Points** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. Restore Options
1. Restore cluster from snapshot, or
1. Restore single table within a snapshot to new cluster. If you choose this options, then you must configure the following:
1. Toggle on or off case-sensitive names.
1. Input the source table values, including the database, the schema, and the table. The source table information can be found in the [Amazon Redshift console](https://console.aws.amazon.com/rds/).
1. Input the target table values, including the database, the schema, and the new table name.
1. Specify your new cluster configuration settings.
1. For cluster restore: choose Cluster identifier, Node type, and number of nodes.
1. Specify availability zone and maintenance windows.
1. You can associate additional roles by clicking **Associate IAM roles**.
1. *Optional:* Additional configurations:
1. **Use defaults** is toggled on by default.
1. Use the dropdown menus to select settings for Networking and security, VPC security groups, Cluster subnet group, and Availability zone.
1. Toggle **Enhanced VPC routing** on or off.
1. Determine if you want to make your cluster endpoint **publicly accessible**. If it is, instances and devices outside the VPC can connect to your database through the cluster endpoint. If this is toggled on, input the elastic IP address.
1. *Optional:* Database configuration. You may choose to input
1. Database port (by typing into the text field)
1. Parameter groups
1. Maintenance: You can choose the
1. Maintenance window
1. Maintenance track, from among current, trailing, or preview. This controls which cluster version is applied during a maintenance window.
1. Automated snapshot is set to default.
1. Automated snapshot retention period. Retention period must be 0 to 35 days. Choose 0 to not create automated snapshots.
1. The manual snapshot retention period is 1 to 3653 days.
1. There is an optional checkbox for cluster relocation. If this is checked, it permits the ability to relocate your cluster in another Availability Zone. After you enable relocation, you can use the VPC endpoint.
1. Monitoring: After a cluster is restored, you can set up monitoring through CloudWatch or Amazon Redshift.
1. Choose IAM role to be passed to perform restores. You can use the default role, or you can specify a different one.
Your restore jobs will be visible under **Jobs**. You can see the current status of your restore job by clicking the refresh button or CTRL-R.
## Restore an Amazon Redshift cluster using API, CLI, or SDK
Use [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html) to restore an Amazon Redshift cluster.
To restore a Amazon Redshift using the AWS CLI, use the command `start-restore-job` and specify the following metadata:
```
ClusterIdentifier // required string
AdditionalInfo // optional string
AllowVersionUpgrade // optional Boolean
AquaConfigurationStatus // optional string
AutomatedSnapshotRetentionPeriod // optional integer 0 to 35
AvailabilityZone // optional string
AvailabilityZoneRelocation // optional Boolean
ClusterParameterGroupName // optional string
ClusterSecurityGroups // optional array of strings
ClusterSubnetGroupName // optional strings
DefaultIamRoleArn // optional string
ElasticIp // optional string
Encrypted // Optional TRUE or FALSE
EnhancedVpcRouting // optional Boolean
HsmClientCertificateIdentifier // optional string
HsmConfigurationIdentifier // optional string
IamRoles // optional array of strings
KmsKeyId // optional string
MaintenanceTrackName // optional string
ManageMasterPassword // optional Boolean
ManualSnapshotRetentionPeriod // optional integer
MasterPasswordSecretKmsKeyId // optional string
NodeType // optional string
NumberOfNodes // optional integer
OwnerAccount // optional string
Port // optional integer
PreferredMaintenanceWindow // optional string
PubliclyAccessible // optional Boolean
ReservedNodeId // optional string
SnapshotClusterIdentifier // optional string
SnapshotScheduleIdentifier // optional string
TargetReservedNodeOfferingId // optional string
VpcSecurityGroupIds // optional array of strings
RestoreType // CLUSTER_RESTORE or TABLE_RESTORE or NAMESPACE_RESTORE
```
For more information, see [https://docs.aws.amazon.com/redshift/latest/APIReference/API_RestoreFromClusterSnapshot.html](https://docs.aws.amazon.com/redshift/latest/APIReference/API_RestoreFromClusterSnapshot.html) in the *Amazon Redshift API Reference* and [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/redshift/restore-from-cluster-snapshot.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/redshift/restore-from-cluster-snapshot.html) in the *AWS CLI guide*.
Here is an example template:
```
aws backup start-restore-job \
-\-recovery-point-arn "arn:aws:backup:region:account:snapshot:name
-\-iam-role-arn "arn:aws:iam:account:role/role-name" \
-\-metadata
-\-resource-type Redshift \
-\-region AWS Region
-\-endpoint-url URL
```
Here is an example:
```
aws backup start-restore-job \
-\-recovery-point-arn "arn:aws:redshift:us-west-2:123456789012:snapshot:redshift-cluster-1/awsbackup:job-c40dda3c-fdcc-b1ba-fa56-234d23209a40" \
-\-iam-role-arn "arn:aws:iam::974288443796:role/Backup-Redshift-Role" \
-\-metadata 'RestoreType=CLUSTER_RESTORE,ClusterIdentifier=redshift-cluster-restore-78,Encrypted=true,KmsKeyId=45e261e4-075a-46c7-9261-dfb91e1c739c' \
-\-resource-type Redshift \
-\-region us-west-2 \
```
You can also use [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeRestoreJob.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeRestoreJob.html) to assist with restore information.
In the AWS CLI, use the operation `describe-restore-job` and use the following metadata:
```
Region
```
Here is an example template:
```
aws backup describe-restore-job —restore-job-id restore job ID
-\-region AWS Region
```
Here is an example:
```
aws backup describe-restore-job -\-restore-job-id BEA3B353-576C-22C0-9E99-09632F262620 \
-\-region us-west-2 \
```
# Amazon Redshift Serverless restore
You can restore manual snapshots of databases or tables using the AWS Backup console or AWS CLI.
Redshift Serverless and AWS Backup support *interchangeable restore* for data warehouse snapshots. This means you can restore Redshift Serverless backups to [Amazon Redshift provisioned clusters](redshift-backups.md) or restore provisioned backups to Redshift Serverless namespaces. This applies only to full database restore, not single table restore.
**Restore capabilities for Redshift Serverless**
| Restore capabilities | Namespace | Single table |
| --- | --- | --- |
| Type of snapshot | Manual | Manual |
| Information needed | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/redshift-serverless-restore.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/redshift-serverless-restore.html) |
| Restore target effect | Restores to an existing namespace through a destructive restore that overwrites existing data | Restores to a new table |
| Interchangeable restore? | Yes. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/redshift-serverless-restore.html) | Not supported. |
For more information about configurations, see [Snapshots and recovery points](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html) in the *Amazon Redshift Management Guide*.
## Considerations before restoring
Before you begin a restore job, review the following:
**Configurations**
When you restore an Redshift Serverless snapshot, you choose the target namespace to where you want to restore all the databases or a single table.
When you restore the databases in a snapshot to a Serverless namespace, it is a destructive restore. This means all previously extant data in the target restore namespace is overwritten when you restore to that namespace.
When you restore a single table, it is not a destructive restore. To restore a table, specify the workgroup, snapshot, source database, source table, target restore namespace, and the new table name.
**Permissions**
The permissions required are determined by the target data warehouse (that is, the namespace or provisioned cluster where you will restore the databases or table). The following table can help you determine the permissions, role, and policy to use. For more information on managing IAM policies, see [Identity and access management in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-authentication-access-control.html).
**Required permissions and roles for restore operations**
| Restore target | Needed permission(s) | IAM role and policy |
| --- | --- | --- |
| Amazon Redshift provisioned cluster | redshift:RestoreFromClusterSnapshot | AWSBackupServiceRolePolicyForRestores contains this permission; it can be used for aws backup start-restore-job. |
| Redshift Serverless namespace | redshift-serverless:RestoreFromSnapshot | You must add this permission to the role and policy you will use to call **aws backup start-restore-job**. Since this is a destructive restore job, the service role policy for restores cannot be used. |
## Redshift Serverless restore procedure
Follow these steps to restore Redshift Serverless backups using the AWS Backup console or AWS CLI:
------
#### [ Console ]
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Settings** and select the Redshift Serverless resource ID to restore.
1. On the **Resource details** page, select the recovery point ID in the **Recovery Points** pane, then choose **Restore**.
1. In the **Restore options** pane, choose to restore the entire data warehouse or a single table.
1. Select the destination target in the **Target data warehouse configuration** pane.
+ For a full data warehouse restore, choose between Amazon Redshift provisioned cluster or Redshift Serverless namespace.
+ For a single table restore, specify the source snapshot, database, schema, table name, and target details.
1. Choose the IAM restore role for the job. If not using the default role, ensure the selected role includes the `iam:PassRole` permission.
------
#### [ AWS CLI ]
Use the **aws backup start-restore-job** command.
AWS Backup works with Redshift Serverless to orchestrate the restore job. The CLI command will be prepended with `aws backup` but will also contain metadata relevant to Redshift Serverless or Amazon Redshift.
The required and optional metadata depends on whether you're restoring a whole data warehouse or a single table.
+ For single table restore, see [restore-table-from-snapshot](https://docs.aws.amazon.com/cli/latest/reference/redshift-serverless/restore-table-from-snapshot.html) in the *AWS CLI Command Reference*.
+ For namespace restore, see [restore-from-snapshot](https://docs.aws.amazon.com/cli/latest/reference/redshift-serverless/restore-from-snapshot.html) in the *AWS CLI Command Reference*.
+ To restore to a Amazon Redshift provisioned cluster, see [restore-from-cluster-snapshot](https://docs.aws.amazon.com/cli/latest/reference/redshift/restore-from-cluster-snapshot.html) in the *AWS CLI Command Reference*.
**Example template for `start-restore-job` to restore to a Serverless namespace:**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:region:account:snapshot:name--iam-role-arn "arn:aws:iam:account:role/role-name" \
--metadata \
--resource-type Redshift Serverless \
--region Region \
--endpoint-url URL
```
**Example for `start-restore-job` to restore to a Serverless namespace:**
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:redshift-serverless:us-east-1:123456789012:snapshot/a12bc34d-567e-890f-123g-h4ijk56l78m9" \
--iam-role-arn "arn:aws:iam::974288443796:role/Backup-Redshift-Role" \
--metadata 'RestoreType=NAMESPACE_RESTORE,NamespaceIdentifier=redshift-namespace-1-restore' \
--resource-type "RedshiftServerless" \
--region us-west-2
```
After starting the restore job, use **describe-restore-job** to monitor progress.
------
# Restore an SAP HANA database on an Amazon EC2 instance
SAP HANA databases on EC2 instances can be restored using the AWS Backup console, using API, or using AWS CLI.
**Topics**
+ [Restore an SAP HANA database with the AWS Backup console](#w2aac17c31c43b9)
+ [[StartRestoreJob API](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html) for SAP HANA on EC2](#w2aac17c31c43c11)
+ [CLI for SAP HANA on EC2](#w2aac17c31c43c13)
+ [SAP HANA High Availability (HA) restore](#saphanarestoreha)
+ [Troubleshooting](#saphanarestoretroubleshooting)
## Restore an SAP HANA database with the AWS Backup console
Note that backup jobs and restore jobs involving the same database cannot occur concurrently. When an SAP HANA database restore job is occurring, attempts to back up the same database will likely result in an error: "Database cannot be backed up while it is stopped."
1. Access the AWS Backup console using the credentials from prerequisites.
1. Under the **Target restore location** dropdown menu, choose a database to overwrite with the recovery point you are using to restore (note that the instance hosting the restore target database must also have the permissions from the prerequisites).
**Important**
SAP HANA database restores are destructive. Restoring a database will overwrite the database at the specified target restore location.
1. Complete this step only if you are performing a system copy restore; otherwise, skip to step 4.
System copy restores are restore jobs which restore to a target database different from the source database which generated the recovery point. For system copy restores, notice the `aws ssm-sap put-resource-permission` command provided for you on the console. This command must be copied, pasted, and executed on the machine that completed the prerequisites. When running the command, use the credentials from the role in the prerequisite where you set up the required permissions for registering applications.
```
// Example command
aws ssm-sap put-resource-permission \
--region us-east-1 \
--action-type RESTORE \
--source-resource-arn arn:aws:ssm-sap-east-1:112233445566:HANA/Foo/DB/HDB \
--resource-arn arn:aws:ssm-sap:us-east-1:112233445566:HANA/Bar/DB/HDB
```
1. Once you choose the restore location, you can see the target database’s **Resource ID**, **Application name**, **Database type**, and the **EC2 instance**.
1. *Optionally*, you may expand **Advanced restore settings** to change your catalog restore option. Available options vary based on selected restore settings.
1. Click **Restore backup**.
1. The target location will be overwritten during restore (**"destructive restore"**), so you must provide confirmation that you permit this in the next pop-up dialog box.
1. To proceed, you must understand that the existing database will be overwritten by the one you are restoring.
1. Once this is understood, you must acknowledge the existing data will be overwritten. To acknowledge this and to proceed, type **overwrite** into the text input field.
1. Click **Restore backup**.
If the procedure was successful, a blue banner will appear at the top of the console. This signifies that the restore job is in progress. You will be automatically redirected to the Jobs page where your restore job will appear in the list of restore jobs. This most recent job will have a status of `Pending`. You can search for and then click on the restore job ID too see details of each restore job. You can refresh the restore jobs list by clicking the refresh button to view changes to the restore job status.
## [StartRestoreJob API](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html) for SAP HANA on EC2
This action recovers the saved resource identified by an Amazon Resource Name (ARN).
**Request Syntax**
```
PUT /restore-jobs HTTP/1.1
Content-type: application/json
{
"[IdempotencyToken](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html#Backup-StartRestoreJob-request-IdempotencyToken)": "string",
"[Metadata](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html#Backup-StartRestoreJob-request-Metadata)": {
"string" : "string"
},
"[RecoveryPointArn](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html#Backup-StartRestoreJob-request-RecoveryPointArn)": "string",
"[ResourceType](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html#Backup-StartRestoreJob-request-ResourceType)": "string"
}
```
**URI Request Parameters**: The request does not use any URI parameters.
**Request Body**: The request accepts the following data in JSON format:
**IdempotencyToken**A customer-chosen string that you can use to distinguish between otherwise identical calls to `StartRestoreJob`. Retrying a successful request with the same idempotency token results in a success message with no action taken.
Type: String
Required: No
**Metadata**
A set of metadata key-value pairs. Contains information, such as a resource name, required to restore a recovery point. You can get configuration metadata about a resource at the time it was backed up by calling `GetRecoveryPointRestoreMetadata`. However, values in addition to those provided by `GetRecoveryPointRestoreMetadata` might be required to restore a resource. For example, you might need to provide a new resource name if the original already exists.
You need to include specific metadata to restore an SAP HANA on Amazon EC2 instance. See [ StartRestoreJob metadata](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html#API_StartRestoreJob_RequestBody) for SAP HANA-specific items.
To retrieve the relevant metadata, you can use the call [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_GetRecoveryPointRestoreMetadata.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_GetRecoveryPointRestoreMetadata.html).
Example of a standard SAP HANA database recovery point:
```
"RestoreMetadata": {
"BackupSize": "1660948480",
"DatabaseName": "DATABASENAME",
"DatabaseType": "SYSTEM",
"HanaBackupEndTime": "1674838362",
"HanaBackupId": "1234567890123",
"HanaBackupPrefix": "1234567890123_SYSTEMDB_FULL",
"HanaBackupStartTime": "1674838349",
"HanaVersion": "2.00.040.00.1553674765",
"IsCompressedBySap": "FALSE",
"IsEncryptedBySap": "FALSE",
"SourceDatabaseArn": "arn:aws:ssm-sap:region:accountID:HANA/applicationID/DB/DATABASENAME",
"SystemDatabaseSid": "HDB",
"aws:backup:request-id": "46bbtt4q-7unr-2897-m486-yn378k2mrw9c"
}
```
Example of a continuous SAP HANA database recovery point:
```
"RestoreMetadata": {
"AvailableRestoreBases": "[1234567890123,9876543210987,1472583691472,7418529637418,1678942598761]",
"BackupSize": "1711284224",
"DatabaseName": "DATABASENAME",
"DatabaseType": "TENANT",
"EarliestRestorablePitrTimestamp": "1674764799789",
"HanaBackupEndTime": "1668032687",
"HanaBackupId": "1234567890123",
"HanaBackupPrefix": "1234567890123_HDB_FULL",
"HanaBackupStartTime": "1668032667",
"HanaVersion": "2.00.040.00.1553674765",
"IsCompressedBySap": "FALSE",
"IsEncryptedBySap": "FALSE",
"LatestRestorablePitrTimestamp": "1674850299789",
"SourceDatabaseArn": "arn:aws:ssm-sap:region:accountID:HANA/applicationID/DB/SystemDatabaseSid",
"SystemDatabaseSid": "HDB",
"aws:backup:request-id": "46bbtt4q-7unr-2897-m486-yn378k2mrw9d"
}
```
## CLI for SAP HANA on EC2
The command `start-restore-job` recovers the saved resource identified by an Amazon Resource Name (ARN). CLI will follow the API guideline above.
**Synopsis:**
```
start-restore-job
--recovery-point-arn value
--metadata value
--aws:backup:request-id value
[--idempotency-token value]
[--resource-type value]
[--cli-input-json value]
[--generate-cli-skeleton value]
[--debug]
[--endpoint-url value]
[--no-verify-ssl]
[--no-paginate]
[--output value]
[--query value]
[--profile value]
[--region value]
[--version value]
[--color value]
[--no-sign-request]
[--ca-bundle value]
[--cli-read-timeout value]
[--cli-connect-timeout value]
```
**Options**
`--recovery-point-arn` (string) is a string in the form of an Amazon Resource Number (ARN) that uniquely identifies a recovery point; for example `arn:aws:backup:region:123456789012:recovery-point:46bbtt4q-7unr-2897-m486-yn378k2mrw9d`
`--metadata` (map): A set of metadata key-value pairs. Contains information, such as a resource name, required to restore a recovery point. You can get configuration metadata about a resource at the time it was backed up by calling `GetRecoveryPointRestoreMetadata` . However, values in addition to those provided by `GetRecoveryPointRestoreMetadata` might be required to restore a resource. You need to specify specific metadata to restore an SAP HANA on Amazon EC2 instance:
+ `aws:backup:request-id`: This is any UUID string used for idempotency. It does not alter your restore experience in any way.
+ `aws:backup:TargetDatabaseArn`: Specify the database to which you want to restore. This is the SAP HANA on Amazon EC2 database ARN.
+ `CatalogRestoreOption`: Specify where to restore your catalog from. One of `NO_CATALOG`, `LATEST_CATALOG_FROM_AWS_BACKUP`, `CATALOG_FROM_LOCAL_PATH`
+ `LocalCatalogPath`: If CatalogRestoreOption metadata value is `CATALOG_FROM_LOCAL_PATH`, then specify the path to local catalog on your EC2 instance. This should be a valid file path in your EC2 instance.
+ `RecoveryType`: Currently, `FULL_DATA_BACKUP_RECOVERY`, `POINT_IN_TIME_RECOVERY`, and `MOST_RECENT_TIME_RECOVERY` recovery types are supported.
key = (string); value = (string). Shorthand syntax:
```
KeyName1=string,KeyName2=string
```
JSON syntax:
```
{"string": "string"
...}
```
`--idempotency-token` is a user-chosen string that you can use to distinguish between otherwise identical calls to `StartRestoreJob`. Retrying a successful request with the same idempotency token results in a success message with no action taken.
`--resource-type` is a string that starts a job to restore a recovery point for one of the following resources: `SAP HANA on Amazon EC2` for SAP HANA on Amazon EC2. *Optionally*, SAP HANA resources can be tagged using the command `aws ssm-sap tag-resource`
**Output**: `RestoreJobId` is a string that uniquely identifies the job that restores a recovery point.
## SAP HANA High Availability (HA) restore
There are important considerations and additional steps to include when you are restoring a high availability (HA) system of SAP HANA. Expand the section below that best aligns your use case.
Restore scenario:
### System database to an SAP HANA HA target
Before you restore to the target (destination) SAP HANA HA system,
1. If a cluster is installed, put all cluster notes in Maintenance mode.
1. Stop the SAP HANA database on all nodes, including primary and secondary.
1. *(Recommended)* Disable any backup plans to ensure they don't interfere with the restore operation.
After the restore job completes, go to the restored SAP HANA HA system, then:
1. Start the SAP HANA database on the primary mode.
1. Manually start any tenant database in which the system database was restored but its tenants were not restored.
1. Re-establish SAP HANA system replication (HSR) between the primary and secondary nodes.
1. Start the SAP HANA database on the secondary node.
1. If a cluster is installed, ensure all cluster nodes are online.
1. Enable any backup plans you disabled prior to the restore operation.
*(Optional)* You can keep the application in sync on [AWS Systems Manager for SAP](https://docs.aws.amazon.com/ssm-sap/latest/userguide/what-is-ssm-for-sap.html) by calling [https://docs.aws.amazon.com/ssmsap/latest/APIReference/API_StartApplicationRefresh.html](https://docs.aws.amazon.com/ssmsap/latest/APIReference/API_StartApplicationRefresh.html), or you can wait for the scheduled application refresh that will bring the latest SAP metadata.
### System database to an SAP HANA single-node target
Before you begin a restore job, go to the target single-node SAP HANA system, then:
1. Stop the SAP HANA database on the target SAP HANA system.
1. *(Recommended)* Disable any backup plans to ensure they don't interfere with the restore operation.
After the restore job completes, go to the target single-node SAP HANA system, then:
1. Start SAP HANA on the target SAP HANA system.
1. Manually start each tenant database on the target node.
1. Enable any backup plans you disabled prior to the restore operation.
*(Optional)* You can keep the application in sync on [AWS Systems Manager for SAP](https://docs.aws.amazon.com/ssm-sap/latest/userguide/what-is-ssm-for-sap.html) by calling [https://docs.aws.amazon.com/ssmsap/latest/APIReference/API_StartApplicationRefresh.html](https://docs.aws.amazon.com/ssmsap/latest/APIReference/API_StartApplicationRefresh.html), or you can wait for the scheduled application refresh that will bring the latest SAP metadata.
### Tenant database (in place or system copy)
Before you start a restore job, go to the target SAP HANA system, then:
1. *(Optional, but recommended)* Put any installed clusters into maintenance mode to avoid an unexpected takeover during the restore operation.
1. Ensure the system database is running on the target SAP HANA system.
1. *(Recommended)* Disable any backup plans to ensure they don't interfere with the restore operation.
After the restore job completes:
+ Enable any backup plans you disabled prior to the restore operation.
## Troubleshooting
If any of the following errors occur while attempting a backup operation, see the associated resolution.
+ **Error:** Continuous backup log error
To maintain recovery points for continuous backups, logs are created by SAP HANA for all changes. When the logs are unavailable, the status of each of these continuous recovery points is `STOPPED`. The last certain viable recovery point that can be used to restore is one that has the status of `AVAILABLE`. If the log data is missing for the time between recovery points with a `STOPPED` status and points with `AVAILABLE`, these times cannot be guaranteed to have a successful restore. If you input a date and time within this range, AWS Backup will attempt the backup, but will use the closest available restorable time. This error will be shown by the message `“Encountered an issue with log backups. Please check SAP HANA for details."`
**Resolution:** In the console, the most recent restorable time, based on the logs, is displayed. You can input a time more recent than the time shown. However, if the data for this time is unavailable from the logs, AWS Backup will use the most recent restorable time.
+ **Error:** `Internal error`
**Resolution:** Create a support case from your console or contact Support with the details of your restore such as the restore job ID.
+ **Error:** `The provided role arn:aws:iam::ACCOUNT_ID:role/ServiceLinkedRole cannot be assumed by AWS Backup`
**Resolution:** Ensure that the role assumed when calling the restore has the required permissions to create service linked roles.
+ **Error:** `User: arn:aws:sts::ACCOUNT_ID:assumed-role/ServiceLinkedRole/AWSBackup-ServiceLinkedRole is not authorized to perform: ssm-sap:GetOperation on resource: arn:aws:ssm-sap:us-east-1:ACCOUNT_ID:...`
**Resolution:** Ensure that the role assumed when calling the restore permissions outlined in the prerequisites is entered correctly.
+ **Error:** `b* 449: recovery strategy could not be determined: [111014] The backup with backup id '1660627536506' cannot be used for recovery SQLSTATE: HY000\n`
**Resolution:** Ensure that Backint agent was properly installed. Check all the prerequisites, particularly [ Install AWS BackInt Agent and AWS Systems Manager for SAP](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-installing-configuring.html) on your SAP application server and then retry installing the BackInt Agent again.
+ **Error:** `IllegalArgumentException: Restore job provided is not ready to return chunks, current restore job status is: CANCELLED`
**Resolution:** Restore job was cancelled by the service workflow. Retry restore job.
+ **Error:** Encountered an issue restore a tenant database on an SAP HANA High Availability system: `b* -10709: Connection failed (RTE:[89006] System call 'connect' failed, rc=111:Connection refused ([::1]:40404 → localhost:30013))\n`
**Resolution:** Check SAP HANA to ensure that the SYSTEMDB is up and running.
+ **Error:** `b'* 448: recovery could not be completed: [301102] exception 301153: Sending root key to secondary failed: connection refused. This may be caused by a stopped system replication secondary. Please keep the secondary online to receive the restored root key. Alternatively you could unregister the secondary site in case of an urgent recovery.\n SQLSTATE: HY000\n'`
**Resolution:** On a SAP HANA High Availability system, SAP HANA may not be running on the secondary node while an active restore operation is running. Start SAP HANA on the secondary node, then retry the restore job again.
+ **Error:** `RequestError: send request failed\ncaused by: read tcp 10.0.131.4:40482->35.84.99.47:443: read: connection timed out"`
**Resolution:** Transient network instability is occurring on the instance. Retry the restore. If this issue happens consistently, try adding `ForceRetry: "true"` to agent config file at `/hana/shared/aws-backint-agent/aws-backint-agent-config.yaml.`
For any other AWS Backint agent related issue, refer to [Troubleshoot AWS Backint Agent For SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-troubleshooting.html).
# Restore S3 data using AWS Backup
You can restore the S3 data that you backed up using AWS Backup to the S3 Standard storage class. You can restore all the objects in a bucket or specific objects. You can restore them to an existing or new bucket.
## Amazon S3 restore permissions
Before you begin restoring resources, ensure the role you're using has sufficient permissions.
For more information, see the following entries on policies:
1. [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html)
1. [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html)
1. [Managed policies for AWS Backup](security-iam-awsmanpol.md)
## Amazon S3 restore considerations
+ If ACLs were enabled during the backup, the destination bucket for the restore must have ACLs enabled; otherwise, the restore job fails.
+ If Block Public Access is enabled on the destination bucket, the restore job completes successfully, but objects with public ACLs are not restored.
+ Restores of objects are skipped if the destination bucket has an object with the same name or version ID.
+ When you restore to the original S3 bucket,
+ AWS Backup does not perform a destructive restore, which means AWS Backup will not put an object into a bucket in place of an object that already exists, regardless of version.
+ A delete marker in the current version is treated as the object as nonexistent, so a restore can occur.
+ AWS Backup does not delete objects (without delete markers) from a bucket during a restore (example: keys currently in the bucket which were not present during the backup will remain).
+ **Restoring cross-Region copies**
+ While S3 backups can be copied cross-Region, restore jobs only occur in the same Region in which the original backup or copy is located.
**Example**
**Example: **An S3 bucket created in US East (N. Virginia) Region can be copied to Canada (Central) Region. The restore job can be initiated using the original bucket in US East (N. Virginia) Region and restored to that Region, or the restore job can be initiated using the copy in Canada (Central) Region and restored to that Region.
+ The original encryption method cannot be used to restore a recovery point (backup) copied from another Region. Cross-Region copy AWS KMS encryption is not available for Amazon S3 resources; instead, use a different encryption type for a restore job.
## Restoring ACLs and object tags
When restoring Amazon S3 data, you choose whether ACLs are part of the restore.
If ACLs are available in the recovery point, you choose to restore or exclude ACLs using the Restore ACLs setting; if ACLs were not in the backup, they cannot be restored regardless of the setting. If you try to create a restore job with ACls enabled but they were not part of the backup, you may see an error such as `Unable to restore Access Control Lists (ACLs) for bucket because backup was created with the 'BackupACLs' option disabled. Please proceed with restoring without ACLs`.
Object tags are automatically restored if they were included in the original backup
**Note**
Restoring recovery points without ACLs
If through AWS CLI you attempt to restore ACLs from a backup that excluded ACLs, the restore operation will fail with an error message indicating invalid restore parameters.
## Restore multiple versions
By default, AWS Backup restores only the latest version of your objects. You have the choice to restore additional or all versions of the objects.
See step 6 in the following section for how to restore up the 10 latest versions or all versions using the AWS Backup console.
See [Restore Amazon S3 recovery points through AWS CLI](#s3-restore-cli) later on this page for metadata details to include when restoring programmatically.
## Restore through the AWS Backup console
**To restore your Amazon S3 data using the AWS Backup console:**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources**, and select the Amazon S3 resource ID that you want to restore.
1. On the **Resource details** page, you will see a list of recovery points for the selected resource ID. To restore a resource:
1. In the **Backups** pane, choose the recovery point ID of the resource.
1. In the upper-right corner of the pane, choose **Restore**.
(Alternatively, you can go to the backup vault, find the recovery point, and then click **Actions** then click **Restore**.)
1. If you are restoring a continuous backup, in the **Restore time** pane, select either option:
1. Accept the default to restore to the **Latest restorable time**.
1. **Specify date and time** to restore.
1. In the **Settings** pane, specify whether to ** Restore entire bucket** or perform **Item level restore**.
1. If you choose **Item level restore**, you restore up to 5 items (objects or folders in a bucket) per restore job by specifying each item's [S3 URI](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-bucket-intro.html) that uniquely identifies that object.
(For more information about S3 bucket URIs, see [Methods for accessing a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-bucket-intro.html) in the *Amazon Simple Storage Service User Guide*.)
1. Choose **Add item** to specify another item to restore.
1. By default, only the latest version of an object is restored. You can restore up to the 10 latest versions or restore all versions of the objects. Select your preference from the drop-down menu.
1. Choose your **Restore destination**. You can either **Restore to source bucket**, **Use existing bucket**, or **Create new bucket**.
**Note**
Your restore destination bucket must have versioning turned on. AWS Backup notifies you if the bucket you select does not meet this requirement.
1. If you choose **Use existing bucket**, select the destination S3 bucket from the menu which shows all existing buckets within your current AWS Region.
1. If you choose **Create new bucket**, type in the **new bucket name**. After the bucket is created, you can modify the BPA (Block Public Access) and S3 versioning default settings.
1. For the encryption of objects in your S3 bucket, you can choose your **Restored object encryption**. Use **original encryption keys** (default), **Amazon S3 key (SSE-S3)**, or **AWS Key Management Service key (SSE-KMS)**.
These settings only apply to encryption of the objects in the S3 bucket. This does not affect the encryption for the bucket itself.
1. **Use original encryption keys (default)** restores objects with the same encryption keys used by the source object. If a source object was unencrypted, this method restores the object without encryption.
This restore option allows you to optionally choose a substitute encryption key to encrypt the restore object(s) if the original key is unavailable.
1. If you choose **Amazon S3 key (SSE-S3)**, you do not need to specify any other options.
1. If you choose **AWS Key Management Service key (SSE-KMS)**, you can make the following choices: **AWS managed key (aws/s3)**, **Choose from your AWS KMS keys**, or **Enter AWS KMS key ARN**.
1. If you choose **AWS managed key (aws/s3)**, you do not need to specify any other options.
1. If you **Choose from your AWS KMS keys**, select a AWS KMS key from the dropdown menu. Alternatively, choose **Create key**.
1. If you **Enter AWS KMS key ARN**, type in the ARN into the text box. Alternatively, choose **Create key**.
1. In the **Restore role** pane, choose the IAM role that AWS Backup will assume for this restore.
1. Choose **Restore backup**. The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
## Restore Amazon S3 recovery points through AWS CLI
Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`. You can specify the following metadata during Amazon S3 restores:
```
// Mandatory metadata:
DestinationBucketName // The destination bucket for your restore.
// Optional metadata:
RestoreACLs // Boolean. If ACLs were part of the backup, include and set to TRUE. If the backup
does not include ACLs and this parameter is included, set to FALSE.
EncryptionType // The type of encryption to encrypt your restored objects. Options are original (same encryption as the original object), SSE-S3, or SSE-KMS).
ItemsToRestore // A list of up to five paths of individual objects to restore. Only required for item-level restore.
KMSKey // Specifies the SSE-KMS key to use. Only needed if encryption is SSE-KMS.
RestoreLatestVersionsUpTo // Include this optional parameter to multiple versions.
RestoreTime // The restore time (only valid for continuous recovery points where it is required, in format 2021-11-27T03:30:27Z).
```
`RestoreLatestVersionsUpTo` is an optional metadata key-value pair. By default, or if this is omitted, the latest version is restored. Include this metadata to restore additional versions of your objects. Accepted values are:
+ `1` (to restore the latest version)
+ `n` , where *n* is any positive integer greater than 1. The latest *n* versions of your objects will be restored. If the actual version count of an object is less than *n*, that number of versions will be restored for that object.
+ `all` (to restore all versions)
## Recovery point status
Recovery points will have a status indicating their state.
`EXPIRED` status indicates that the recovery point has exceeded its retention period, but AWS Backup lacks permission or is otherwise unable to delete it. To manually delete these recovery points, see [ Step 3: Delete the recovery points](https://docs.aws.amazon.com/aws-backup/latest/devguide/gs-cleanup-resources.html#cleanup-backups) in the *Clean up resources* section of *Getting started*.
`STOPPED` status occurs on a continuous backup where a user has taken some action that causes the continuous backup to be disabled. This can be caused by the removal of permissions, turning off versioning, turning off events being sent to Amazon EventBridge, or disabling the EventBridge rules that are put in place by AWS Backup.
To resolve `STOPPED` status, ensure that all requested permissions are in place and that versioning is enabled on the S3 bucket. Once these conditions are met, the next instance of a backup rule running will result in a new continuous recovery point being created. The recovery points with STOPPED status do not need to be deleted.
## S3 restore messages
When a restore job completes or fails, you may see the following message. The following table can help you determine the possible cause of the status message.
| Scenario | Job Status | Message | Example |
| --- | --- | --- | --- |
| All objects failed to be restored. | `FAILED` | "No objects were restored from **RecoveryPointARN** to **bucket**. To get notified of these failures, enable SNS event notifications." | The role used to start the restore job does not have permission to put objects in the destination bucket. The restore role does not have permission to verify if object version exists in the destination bucket. |
| One or more (but not all) objects failed to be restored. | COMPLETED | "One or more objects failed to be restored from **RecoveryPointARN** to **bucket**. To get notified of these failures, enable SNS event notifications." | The role used to start the restore job does not have access to the KMS key used by one or more of the original objects. |
| There are no objects to restore. | COMPLETED | "There are no objects that match the restore request for **RecoveryPointARN**." | The recovery point (backup) of source bucket to be restored has no objects. The prefix used for the restore job does not correspond with any object. |
# Restore a Storage Gateway volume
If you are restoring an AWS Storage Gateway volume snapshot, you can choose to restore the snapshot as an Storage Gateway volume or as an Amazon EBS volume. This is because AWS Backup integrates with both services, and any Storage Gateway snapshot can be restored to either an Storage Gateway volume or an Amazon EBS volume.
## Restore Storage Gateway through the AWS Backup console
**To restore an Storage Gateway volume**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and then choose the Storage Gateway resource ID you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. Specify the restore parameters for your resource. The restore parameters you enter are specific to the resource type that you selected.
For **Resource type**, choose the AWS resource to create when restoring this backup.
1. If you choose **Storage Gateway volume**, choose a **Gateway** in a reachable state. Also choose your **iSCSI target name**.
1. For "Volume stored" gateways, choose a **Disk Id**.
1. For "Volume cached" gateways, choose a capacity that is at least as large as your protected resource.
If you choose **EBS volume**, provide the values for **Volume type**, **Size (GiB)**, and choose an **Availability zone**.
1. For **Restore role**, choose the IAM role that AWS Backup will assume for this restore.
**Note**
If the AWS Backup default role is not present in your account, a **Default role** is created for you with the correct permissions. You can delete this default role or make it unusable.
1. Choose **Restore backup**.
The **Restore jobs** pane appears. A message at the top of the page provides information about the restore job.
## Restore Storage Gateway with AWS CLI
In the command line interface, [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html) allows you to restore a Storage Gateway volume.
The following list is the accepted metadata.
```
gatewayArn // The Amazon Resource Name (ARN) of the gateway. Use the ListGateways operation to return a list of gateways for your account and AWS Region.
gatewayType // The type of created gateway. Valid value is BACKUP_VM
targetName
kmsKey
volumeSize
volumeSizeInBytes
diskId
```
# Restore an Amazon Timestream table
When you restore a Amazon Timestream table, there are several options to configure, including the new table name, the destination database, your storage allocation preferences (memory and magnetic storage), and which role you’ll use to complete the restore job. You can also choose an Amazon S3 bucket in which to store error logs. Magnetic storage writes are asynchronous, so you may wish you log the errors.
Timestream data storage has two tiers: a memory store and a magnetic store. Memory store is required, but you have the option of transferring your restored table to magnetic storage after the specified memory time is finished. Memory store is optimized for high throughput data writes and fast point-in-time queries. The magnetic store is optimized for lower throughput late-arrival data writes, long-term data storage, and fast analytical queries.
When you restore a Timestream table, you determine how long you want the table to remain in each storage tier. Using the console or API, you can set the storage time for both. Note that the storage is linear and sequential. Timestream will store your restored table in memory storage first, then automatically transition it to magnetic storage when the memory storage time has been reached.
**Note**
The magnetic store retention period must be equal or greater than the original retention period (shown at the top-right of the console), or data will be lost.
*Example:* You set the memory store allocation to hold data for one week and set the magnetic store allocation to hold the same data for one year. When the data in the memory store becomes a week old, it is automatically moved to the magnetic store. It is then retained in the magnetic store for a year. At the end of that time, it is deleted from Timestream and from AWS Backup.
## To restore a Amazon Timestream table using the AWS Backup console
You can restore Timestream tables in the AWS Backup console that were created by AWS Backup.
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the navigation pane, choose **Protected resources** and the Amazon Timestream resource ID that you want to restore.
1. On the **Resource details** page, a list of recovery points for the selected resource ID is shown. To restore a resource, in the **Backups** pane, choose the radio button next to the recovery point ID of the resource. In the upper-right corner of the pane, choose **Restore**.
1. Specify your new table configuration settings, including:
1. **New table name**, consisting of 2 to 256 characters (letters, numbers, dashes, periods, and underscores).
1. **Destination database**, chosen from the drop down menu.
1. **Storage allocation**: Set the amount of time the restored table will first reside in [ memory storage](https://docs.aws.amazon.com/timestream/latest/developerguide/storage.html), and set the amount of time the restored table will then reside in [magnetic storage](https://docs.aws.amazon.com/timestream/latest/developerguide/storage.html). Memory storage can be set to hours, days, weeks, or months. Magnetic storage can be set to days, weeks, months, or years.
1. *(Optional)*** Enable magnetic storage writes**: You have the option of allowing magnetic storage writes. With this option checked, late-arriving data, which is data with a timestamp outside the memory storage retention period, will be written directly into the magnetic store.
1. *(Optional)* **Amazon S3 error logs location**: You can specify an S3 location in which your error logs will be stored. Browse your S3 files or copy and paste the S3 file path.
**Note**
If you choose to specify an S3 error log location, the role you use for this restore must have permission to write to an S3 bucket or it must contain a policy with that permission.
1. Choose the IAM role to be passed to perform restores. You can use the default IAM role or specify a different one.
1. Click **Restore backup**.
Your restore jobs will be visible under protected resources. You can see the current status of your restore job by clicking the refresh button or CTRL-R.
## To restore a Amazon Timestream table using API, CLI, or SDK
Use [`StartRestoreJob` to restore a Timestream table via API.](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html).
To restore a Timestream using the AWS CLI, use the operation `start-restore-job.` and specify the following metadata:
```
TableName: string;
DestinationDatabase: string;
MemoryStoreRetentionPeriodInHours: value: number unit: 'hours' | 'days' | 'weeks' | 'months'
MagneticStoreRetentionPeriodInDays: value: number unit: 'days' | 'weeks' | 'months' | 'years'
EnableMagneticStoreWrites?: boolean;
aws:backup:request-id
```
Here is an example template:
```
aws backup start-restore-job \
--recovery-point-arn "arn:aws:backup:us-west-2:accountnumber:recovery-point:1a2b3cde-f405-6789-012g-3456hi789012_beta" \
--iam-role-arn "arn:aws:iam::accountnumber:role/rolename" \
--metadata 'TableName=tablename,DatabaseName=databasename,MagneticStoreRetentionPeriodInDays=1,MemoryStoreRetentionPeriodInHours=1,MagneticStoreWriteProperties="{\"EnableMagneticStoreWrites\":true,\"MagneticStoreRejectedDataLocation\":{\"S3Configuration\":{\"BucketName\":\"bucketname\",\"EncryptionOption\":\"SSE_S3\"}}}"' \
--region us-west-2 \
--endpoint-url url
```
You can also use [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeRestoreJob.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeRestoreJob.html) to assist with restore information.
In the AWS CLI, use the operation `describe-restore-job` and use the following metadata:
```
TableName: string;
DestinationDatabase: string;
MemoryStoreRetentionPeriodInHours: value: number unit: 'hours' | 'days' | 'weeks' | 'months'
MagneticStoreRetentionPeriodInDays: value: number unit: 'days' | 'weeks' | 'months' | 'years'
EnableMagneticStoreWrites?: boolean;
```
Here is an example template:
```
aws backup describe-restore-job \
--restore-job-id restore job ID \
--region awsregion \
--endpoint-url url
```
# Restore a virtual machine using AWS Backup
You can restore a virtual machine to VMware, VMware Cloud on AWS, VMware Cloud on AWS Outposts, an Amazon EBS volume, or [to an Amazon EC2 instance](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-ec2.html). Restoring (or migrating) a virtual machine to EC2 requires a license. By default, AWS will include a license (charges apply). For more information, see [Licensing options](https://docs.aws.amazon.com/vm-import/latest/userguide/licensing.html) in the *VM Import/Export User Guide*.
You can restore a VMware virtual machine using the AWS Backup console or through the AWS CLI. When a virtual machine is restored, the VMware Tools folder is not included. See VMware documentation to reinstall VMware Tools.
AWS Backup restores of virtual machines are non-destructive, meaning AWS Backup does not overwrite existing virtual machines during a restore. Instead, the restore job deploys a new virtual machine.
**Topics**
+ [Considerations when restoring a VM to an Amazon EC2 instance](#vm-restore-ec2)
+ [Use the AWS Backup console to restore virtual machine recovery points](#vm-restore-console)
+ [Use AWS CLI to restore virtual machine recovery points](#vm-restore-cli)
## Considerations when restoring a VM to an Amazon EC2 instance
+ Restoring (or migrating) a virtual machine to EC2 requires a license. By default, an AWS will include a license (charges apply). For more information, see [Licensing options](https://docs.aws.amazon.com/vm-import/latest/userguide/licensing.html) in the *VM Import/Export User Guide*.
+ There is a maximum limit of 5 TB (terabytes) for each virtual machine disk.
+ You can't specify a key pair when you restore the virtual machine to an instance. You can add a key pair to `authorized_keys` during launch (through instance user data) or after launch (as described in [this troubleshooting section](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#replacing-lost-key-pair) in the Amazon EC2 User Guide).
+ Confirm your [operating system is supported](https://docs.aws.amazon.com/vm-import/latest/userguide/prerequisites.html#vmimport-operating-systems) for import to and export from Amazon EC2 in the *VM Import/Export User Guide*.
+ Review limitations involved with [Importing VMs to Amazon EC2](https://docs.aws.amazon.com/vm-import/latest/userguide/prerequisites.html#limitations-image) in the *VM Import/Export User Guide*.
+ When you restore to an Amazon EC2 instance using AWS CLI, you must specify `"RestoreTo":"EC2Instance"`. All other attributes have default values.
+ Amazon EC2 offers [EC2 Allowed AMIs](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-allowed-amis.html). If this setting is enabled in your account, add the alias `aws-backup-vault` to your allowlist. Otherwise, restore operations of VM recovery points to EC2 instances will fail with an error message, such as "Source AMI not found in Region".
+ VMware restores to EC2 involving more than 21 disks are not supported. As a workaround, use [VMware Restores to EBS](https://docs.aws.amazon.com//aws-backup/latest/devguide/restoring-vm.html#restore-vm-ebs) to restore each disk individually as an EBS volume, then attach the EBS volumes to an EC2 instance.
## Use the AWS Backup console to restore virtual machine recovery points
You can restore a virtual machine from multiple locations in the left navigation pane of the AWS Backup console:
+ Choose **Hypervisors** to view recovery points for virtual machines managed by a hypervisor that is connected to AWS Backup.
+ Choose **Virtual machines** to view recovery points for virtual machines across all your hypervisors that are connected to AWS Backup.
+ Choose **Backup vaults** to view recovery points stored in a specific AWS Backup vault.
+ Choose **Protected resources** to view recovery points across all your AWS Backup protected resources.
If you need to restore a virtual machine that no longer has a connection with Backup gateway, choose **Backup vaults** or **Protected resources** to locate your recovery point.
**Options**
+ [Restore to VMware](#restore-vm-vmware)
+ [Restore to an Amazon EBS volume](#restore-vm-ebs)
+ [Restore to an Amazon EC2 instance](#restore-vm-ec2)
**To restore a virtual machine to VMware, VMware Cloud on AWS, and VMware Cloud on AWS Outposts**
1. In the **Hypervisors** or **Virtual machines** views, choose the **VM name** to restore. In the **Protected resources** view, choose the virtual machine **Resource ID** to restore.
1. Choose the radial button next to the **Recovery point ID** to restore.
1. Choose **Restore**.
1. Choose the **Restore type**.
1. **Full restore** restores all the virtual machine's disks.
1. **Disk-level restore** restores a user-defined selection of one or more disks. Use the drop-down menu to select which disks to restore.
1. Choose the **Restore location**. The options are **VMware**, **VMware Cloud on AWS**, and **VMware Cloud on AWS Outposts**.
1. If you are doing a full restore, skip to the next step. If you are performing a disk-level restore, there will be a drop-down menu under **VM disks**. Choose one or more bootable volumes to restore.
1. Select a **Hypervisor** from the dropdown menu to manage the restored virtual machine
1. For the restored virtual machine, use your organization’s virtual machine best practices to specify its:
1. **Name**
1. **Path** (such as `/datacenter/vm`)
1. **Compute resource name** (such as VMHost or Cluster)
If a host is part of a cluster then you cannot restore to the host but only to the given cluster.
1. **Datastore**
1. For **Restore role,** select either the **Default role** (recommended) or **Choose an IAM role** using the dropdown menu.
1. Choose **Restore backup**.
1. *Optional*: Check when your restore job has the status `Completed`. In the left navigation menu, choose **Jobs**.
**To restore a virtual machine to an Amazon EBS volume**
1. In the **Hypervisors** or **Virtual machines** views, choose the **VM name** to restore. In the **Protected resources** view, choose the virtual machine **Resource ID** to restore.
1. Choose the radial button next to the **Recovery point ID** to restore.
1. Choose **Restore**.
1. Choose the **Restore type**.
1. **Disk restore** restores a user-defined selection of one disk. Use the drop-down menu to select which disk to restore.
1. Choose the **Restore location** as **Amazon EBS**.
1. Under the **VM disk** dropdown menu, choose bootable volume to restore.
1. Under **EBS Volume type**, choose the volume type.
1. Choose your Availability Zone.
1. Encryption (optional). Check the box if you choose to encrypt the EBS volume.
1. Select your KMS key from the menu.
1. For **Restore role,** select either the **Default role** (recommended) or **Choose an IAM role**.
1. Choose **Restore backup**.
1. *Optional*: Check when your restore job has the status `Completed`. In the left navigation menu, choose **Jobs**.
1. *Optional*: Visit [How do I use LVM to create a logical volume on an Amazon EBS volume's partition?](https://repost.aws/knowledge-center/create-lv-on-ebs-partition) to learn more on how to mount managed volumes and access data on the restored Amazon EBS volume.
**To restore a virtual machine to an Amazon EC2 instance**
1. In the **Hypervisors** or **Virtual machines** views, choose the **VM name** to restore. In the **Protected resources** view, choose the virtual machine **Resource ID** to restore.
1. Choose the radial button next to the **Recovery point ID** to restore.
1. Choose **Restore**.
1. Choose the **Restore type**.
1. **Full restore** restores the file system completely, including the root-level folder and files.
1. Choose the **Restore location** as **Amazon EC2**.
1. For **Instance type**, choose the combination of compute and memory required to run your application on your new instance.
**Tip**
Choose an instance type that matches or exceeds the specifications of the original virtual machine. For more information, see the [Amazon EC2 Instance Types Guide](https://docs.aws.amazon.com/ec2/latest/instancetypes/).
1. For **Virtual Private Cloud (VPC)**, choose a virtual private cloud (VPC), which defines the networking environment for the instance.
1. For **Subnet**, choose one of the subnets in the VPC. Your instance receives a private IP address from the subnet address range.
1. For **security groups**, choose a security group, which acts as a firewall for traffic to your instance.
1. For **Restore role,** select either the **Default role** (recommended) or **Choose an IAM role**.
1. *Optional*: To run a script on your instance at launch, expand **Advanced settings** and enter the script in **User data**.
1. Choose **Restore backup**.
1. *Optional*: Check when your restore job has the status `Completed`. In the left navigation menu, choose **Jobs**.
## Use AWS CLI to restore virtual machine recovery points
Use `[StartRestoreJob](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_StartRestoreJob.html)`.
You can specify the following metadata for a virtual machine restore to Amazon EC2 and Amazon EBS:
```
RestoreTo
InstanceType
VpcId
SubnetId
SecurityGroupIds
IamInstanceProfileName
InstanceInitiatedShutdownBehavior
HibernationOptions
DisableApiTermination
Placement
CreditSpecification
RamdiskId
KernelId
UserData
EbsOptimized
LicenseSpecifications
KmsKeyId
AvailabilityZone
EbsVolumeType
IsEncrypted
ItemsToRestore
RequireIMDSv2
NetworkInterfaces
```
AWS Backup supports both partial restores to Amazon EBS and full restores to Amazon EC2. For partial restores, use `ItemsToRestore` to specify which disk to restore to the specified EBS volume. When restoring to Amazon EC2, the parameter `ItemsToRestore` can be left blank because it is ignored and the full list of disks is restored.
You can specify the following metadata for a virtual machine restore to VMware, VMware Cloud on AWS, and VMware cloud on AWS Outpost:
```
RestoreTo
HypervisorArn
VMName
VMPath
ComputeResourceName
VMDatastore
DisksToRestore
ItemsToRestore
```
AWS Backup supports both partial and full restores to an on-premises virtual machine. You can choose to restore all disks or only a subset of disks. When performing a partial restore, specify your disk selection in `ItemsToRestore`. When performing a full restore, you must either omit both `DisksToRestore` and `ItemsToRestore`, or specify all the disks in `DisksToRestore`. The `DisksToRestore` parameter does not support subsets of disks.
This example shows how to conduct a full restore to VMware:
```
'{"RestoreTo":"VMware","HypervisorArn":"arn:aws:backup-gateway:us-east-1:209870788375:hypervisor/hype-9B1AB1F1","VMName":"name","VMPath":"/Labster/vm","ComputeResourceName":"Cluster","VMDatastore":"vsanDatastore","DisksToRestore":"[{\"DiskId\":\"2000\",\"Label\":\"Hard disk 1\"}]","vmId":"vm-101"}'
```