Restore
This page covers how to actually restore a recovery point, into a new account or back into the original one, and the restore behavior of each AWS service NTC Backup has been tested with. It assumes Member Account Requirements is already in place, restoring a not-fully-managed resource's recovery point requires the same CMK access as backing it up did. See Troubleshooting if a restore or backup job isn't behaving as expected.
Restore Process
AWS Backup has no direct cross-account restore, restoring a recovery point that only exists in the central vault always means copying it back into a member account's local vault first, then restoring locally from there. Which path you take depends on whether you're restoring into the account that originally produced the recovery point or into a new one.
Restoring Into a New Account
Only necessary if the original account has been compromised, or otherwise can't be reused, and the restore needs to land in a fresh account.
- In the backup account, find the recovery point to restore in the relevant central vault.
- Copy the recovery point from the central vault into the new member account's local vault. This is a
StartCopyJobin the reverse direction of the normal member-to-central copy. It's authorized by the central account'scentral_backup_operator_iam_role_namerole (defaultntc-central-backup-operator-role), or any sufficiently privileged principal in that account, since the member vault's access policy trusts the whole central account (its root), not one specific role. - Restore locally in the new member account, using that account's restorer role (default
ntc-local-backup-restorer-role). The resource is created in the member account by that role. - If a new resource was created rather than restored in place, import it into your Infrastructure as Code so Terraform/OpenTofu picks up ownership going forward.
Restoring Into the Original Account
If the original account is still trustworthy and only a resource needs restoring:
- Recovery point still in the local vault: the central backup account isn't needed at all. Either restore directly from the local vault, or use the resource's own native restore mechanism where one exists (for example, Aurora point-in-time restore).
- Recovery point already expired locally (past
local_backup_vault_retention_days):- Copy the recovery point from the central vault back into the member account's local vault, the same reverse
StartCopyJobdescribed above. - Restore locally using the restorer role (default
ntc-local-backup-restorer-role). Check Service-Specific Restore Notes below first, some services have a native, more flexible restore path that's worth using instead of the generic AWS Backup restore UI.
- Copy the recovery point from the central vault back into the member account's local vault, the same reverse
Service-Specific Restore Notes
Restores should be performed using the local restorer role (default ntc-local-backup-restorer-role). Some services support an in-place restore, but for most, a new resource is created and has to be imported into your Infrastructure as Code afterward. Some services offer a native restore experience in their own console; others, like S3, only expose restore through the AWS Backup console. Where a native option exists, prefer it, it typically gives more restore flexibility than the generic AWS Backup restore UI.
The following services have been tested. Other AWS Backup resource types not listed here (for example DocumentDB, FSx, Redshift, Redshift Serverless, CloudFormation, Storage Gateway, Timestream, SAP HANA on Amazon EC2, or EKS) haven't been validated for restore yet, they may work, but the behavior isn't confirmed:
| Service | Result of a restore | CMK selectable at restore? | Restore path |
|---|---|---|---|
| S3 | New or existing bucket | Yes | AWS Backup console only |
| RDS | New cluster | No, fixed to the recovery point's CMK, see workaround below | Native (RDS console), via workaround |
| Aurora | New cluster | Yes | Native (RDS/Aurora console) recommended, or AWS Backup |
| Neptune | New cluster | Yes | Native (Neptune console) recommended, or AWS Backup |
| DynamoDB | New table, or existing table after deletion | Yes | AWS Backup console only |
| EC2 | New instance, from an AMI | Yes (volume encryption) | AWS Backup, or launch from the image in the EC2 console |
| EBS | New volume | Yes | AWS Backup console only |
| EFS | New or existing file system | Yes, for a new file system | AWS Backup console only |
S3
Pay attention to the documented behavior for restoring into an existing bucket, it does not behave the same as restoring into a new one.
Before restoring, run a malware scan against the recovery point first, especially when restoring into a new account because the original was compromised. Restoring an infected object straight back into production defeats the point of having recovered from the incident at all.
RDS
Restoring a recovery point always uses the CMK the recovery point was encrypted with, you cannot choose a different key at restore time. This is a problem if the recovery point is encrypted with the backup vault's CMK and you want the restored cluster encrypted with a different key. Work around it:
- Get the RDS snapshot ARN of the recovery point.
- Create a manual snapshot from that snapshot ARN (via the CLI or AWS Console) and select the desired CMK.
- Restore the cluster from the manual snapshot using RDS's native restore tooling instead of the generic AWS Backup restore.
Aurora
The native RDS/Aurora console restore also supports restoring into a Serverless cluster; AWS Backup's own restore feature doesn't offer that option, even though it still lets you choose a CMK.
Neptune
Same pattern as Aurora: the native Neptune console restore includes the Serverless option, while AWS Backup's restore feature is more restricted in what it lets you configure for the new cluster, even though CMK selection is still available there too.
DynamoDB
You cannot restore over an existing table, either restore to a new table name, or delete the existing table first.
EC2
A recovery point is an image (AMI); restoring launches a new instance from it.
Before restoring, run a malware scan against the recovery point first, especially when restoring into a new account because the original was compromised. Launching a new instance from an infected AMI just reintroduces the same problem into the fresh account.
EBS
No further notes beyond the table above.
Before restoring, run a malware scan against the recovery point first, especially when restoring into a new account because the original was compromised. A restored volume attached to a new instance can reintroduce the same infection there.
EFS
Two independent choices:
- Restore scope: full restore (the entire file system) or item-level restore (specific files/folders, given as paths relative to the file system root, for example
/file1, case-sensitive, no wildcards or regex). The console allows up to 10 items per job; the CLI has no item-count limit but caps restore metadata at 200 KB. - Restore destination: a new file system (AWS Backup provisions a fresh one, where you can set configuration such as performance mode and the KMS key, the recommended option for a clean recovery), or an existing file system (the source one, or another).
Regardless of scope or destination, AWS Backup always creates a new directory named aws-backup-restore_<datetime> at the root of the target file system and restores content into it, preserving the original folder hierarchy. Existing files are never overwritten or deleted, EFS restores are non-destructive by design, there is no overwrite option. Each restore attempt gets its own directory, so repeated restores accumulate side by side instead of colliding.