10 Performing Recovery with N2WS
Now that you have created some backups, it is time to perform a recovery.
Last updated
Now that you have created some backups, it is time to perform a recovery.
Last updated
N2WS offers several options for data recovery. Since all N2WS backup is based on AWS’s snapshot technology, N2WS can offer rapid recovery of instances, volumes, and databases. Since a backup is not created for S3 Bucket Sync targets, recovery is neither needed nor possible.
For the cross-region and account recovery of regular resources, such as Instances and RDS, N2WS uses the FSx service so there is no need for specific IAM rolls, as with EFS.
N2W Software strongly recommends that you perform recovery drills occasionally to make sure your recovery scenarios work. It is not recommended that you try it for the first time when your servers are down. Each policy on the policy screen shows the last time recovery was performed on it. Use the last recovery time data to track recovery drills.
N2WS provides an enhanced search box to quickly find backup snapshots to recover from.
In the Backup Monitor, you can search for snapshots based on the Backup Target type or policy, including frozen images.
To search for all backup snapshots:
Select Backup Monitor.
In the Search backups box, enter a string to search by. The string can be part of the resource ID or part of the resource tag value.
To filter by resource type, select a resource type in the list, such as RDS database.
Select and then choose a backup in the list.
For backups with multiple resource types as targets, the Recover screen will have a separate tab for each type. Select a backup. The Recover screen opens.
To restore from an S3 Repository, select the repository in the Restore From list. For other considerations when recovering from an S3 Repository, see section 21.3.2.
Depending on the specifics of the backup, the Recover screen includes:
A search box for locating a resource by ID or name.
Tabs for recovering the backed-up instances, independent volumes, databases, etc.
Outputs of any backup scripts and VSS if it exists. These reference outputs may be important during a recovery operation.
If this backup includes DR to another region, there will be a Restore to Region drop-down menu to choose in which region to perform the recovery.
If you have cross-account functionality enabled for your N2WS license, there are two other drop-down menus:
Restore to Account list where you can choose to restore the resources to another account.
If you defined cross-account DR for this policy, you will have the Restore from Account list for choosing from which account to perform recovery.
All the choices about regions and accounts you make in the recover screen apply to all the recovery operations that you initiate from this screen.
Choose the backups to recover and then select the Recover resource type button.
All recovery screens have a drop-down list at the bottom labeled AWS Credentials. By default, the account AWS credentials used for backup will be used for recovery operations also. Depending on the backup, you can select Provide Alternate AWS Credentials and fill in different credentials for recovery. This can be useful if you want to use IAM-created backup credentials that do not have permissions for recovery. See section 16.3. When using custom credentials, N2WS verifies that these credentials belong to the recovery account.
To use custom credentials:
Select Provide Alternate AWS Credentials in the list. The custom credential boxes appear.
In the AWS Access Key box, enter your access key.
In the AWS Secret Key box, enter your secret key.
With Instance recovery, you can recover a complete instance with its data for purposes, such as:
An instance crashed or is corrupted and you need to create a new one
Creating an instance in a different AZ
Creating an instance in a different region. See section 11.5.1.
Creating an instance from a frozen image
When you recover an instance, by default, you recover it with its configuration, tags, and data, as they were at the time of the backup. However, you can change these elements:
Instance type
Placement
Number of CPU cores and threads
Architecture
User data, etc.
You can also choose how to recover the system itself:
For Linux EBS-based instances: if you have a snapshot of the boot device, you will, by default, use this snapshot to create the boot device of the new instance. You can, however, choose to create the new instance from its original image or a different one.
For instance-store-based: you will only have the image option. This means you cannot use the snapshot of the instance’s root device to launch a new instance.
Your data EBS volumes will be recovered by default to create a similar instance as the source. However, you can choose:
To recover some or none of the volumes.
To enlarge volume capacity, change their device name, or IOPS value.
To preserve tags related to the instance and/or data volumes, or not.
For EBS-based Windows Servers: there is a limitation in AWS, prohibiting launching a new instance from a snapshot, as opposed to from an AMI.
N2WS knows how to overcome this limitation. You can recover an instance from a snapshot, but you also need an AMI for the recovery process. By default, N2WS will create an initial AMI for any Windows instance it backs up and use that AMI for the recovery process. Usually, you do not need to change anything to recover a Windows instance.
The instance recovery screen has tabs for Basic Options, Volumes, and Advanced Options.
At the bottom of each screen, there is an option to change AWS Credentials.
The Basic Options tab is divided into the general section and the Networking section:
Launch from – Whether to launch the boot device (Image) from an existing image, a snapshot, or whether to launch the device using the original root volume configuration (Image (Replace root volume)) which will contain the billing code, if available.
The Snapshot option is available only if this is an EBS-based instance, and a snapshot of the boot device is available in this backup.
See table below for all options.
Launching from a snapshot is not available on Windows.
AMI Handling – This option is relevant only if Launch from is set to Snapshot. If this instance is launched from a snapshot, a new AMI image will be registered and defined as follows:
De-Register after Recovery – This is the default. The image will only be used for this recovery operation and will be automatically de-registered at the end. This option will not leave any images behind after the recovery is complete.
Leave Registered after Recovery – The newly created image will be left after recovery. This option is useful if you want to hold on to this image to create future instances. The snapshots the image is based on will not be deleted by the automatic retention process. However, if you want to keep this image and use it in the future, move the whole backup to the Freezer. See section 9.3.
Create AMI without Recovery – This option creates and keeps the image but does not launch an instance from it. This is useful if you want to launch the instance/s from outside N2WS. If you wish to keep using this image, move the backup to the Freezer.
Image ID – This is only relevant if Launch from is set to Image or Image (Replace root volume) or if you are recovering a Windows instance. By default, this will contain the initial AMI that N2WS created, or if it does not exist, the original AMI ID from which the backed-up instance was launched. You can type or paste a different AMI ID here, but you cannot search AMIs from within N2WS. You can search for it with the AWS Management Console.
Instance Type – Choose the instance type of the new instance/s. The instance type of the backed-up instance is the default.
If you choose an instance type that is incompatible with the image or placement method, the recovery operation will fail.
Since not all instance types are available in all AWS regions, recovery of an unsupported instance type in a certain region might fail. Where the instance type is not yet supported by AWS, we recommend that you configure a supported instance type.
Instance Profile ARN – The ARN of the instance role (IAM Role) for the instance. To find the ARN, select the Role name in IAM Management Console and then select the Summary tab. The default will be the instance role of the backed-up instance if it had one.
Instances to Launch – Specifies how many instances to launch from the image. The default is one, which is the sensible choice for production servers. However, in a clustered environment you may want to launch more than one. It is not guaranteed that all the requested instances will launch. Check the message at the end of the recovery operation to see how many instances were launched, and their IDs.
CPU Options - Enable to select Core Count and Threads per Core for recovery target.
Key Pair – The key pair you want to launch the instance with. The default is the key that the backed-up instance was created with. You can choose a different one from the list. Keys are typically needed to connect to the instance using SSH (Linux).
Keys cannot be used to decrypt the Windows password of a restored instance.
The main purpose of the Networking section is to define what will be the placement of the instance. By default, it will be the same placement as the backed-up instance. An instance can be placed using three methods which are not all necessarily available.
By VPC – Default placement if you have VPC subnets defined in your account.
By Availability Zone – This is the most basic type and the only one which is always available. You can choose in which AZ to launch the instance. Additional options are:
You can choose a different AZ from the backed-up instance.
By default, if the backed-up instance was not in a VPC, it will have the same zone as the backed-up instance. Choose a different AZ from the list.
By Placement Group – If you have placement groups defined, this option is available. This is an instance type that can be placed in a placement group. See AWS documentation for details.
For Placement by VPC and Availability Zone, you are asked to select a security group. Learn about AWS Security Groups and settings at https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
If you chose By VPC in Placement, the following fields are available:
VPC –You can choose the VPC the instance is to be recovered to. By default, it will contain the VPC of the original instance.
Clone VPC - Option to recover to a clone of the selected VPC environment. Control switches to the Account’s Clone VPC screen. Choose the date of the source VPC capture for the clone and an optional new destination name. See section 10.3.5. After the cloning process is completed, the name of the newly cloned VPC will appear in the VPC box.
VPC Subnet – This will hold all the subnets in the currently selected VPC.
Security Group – Choose security groups to be applied to the new instance. This is a multiple-choice field. By default, the security groups of the backed-up instance will be chosen.
Security groups for VPC instances are different than groups of non-VPC instances. This field has a filter to help you find the security group that you need.
VPC Assign IP – If the backed-up instance was in a VPC subnet, the default value will be the IP assigned to the original instance.
If the assigned IP is still taken, it can fail the recovery operation. You can type a different IP here. When you begin recovery, N2WS will verify the IP belongs to the chosen subnet.
If this field is empty, an IP address from the subnet will be automatically allocated for the new instance.
If you chose By Availability Zone in Placement:
Availability Zone - By default, if the backed-up instance was not in a VPC, it will have the same zone as the backed-up instance. However, you can choose a different one from the list.
Security Group - Choose security groups to be applied to the new instance. This is a multiple-choice field. By default, the security groups of the backed-up instance will be chosen.
If you chose By Placement Group:
Placement Group - Choose the placement group from the list.
For all Placement options, the following boxes are also available:
Additional NICs - If you want to add additional NICs.
AWS Credentials - You can choose to use different AWS credentials for the recovery operation.
If the policy contains an instance target that has a volume that is also defined as a volume target:
The volume will not be available under the Independent Volumes tab.
Recover the volume by selecting the relevant instance in the Instances tab and then selecting Recover Volumes Only. See section 10.4.
Select the Volumes tab to choose which volumes to recover and how.
All data volumes in the policy except the boot device are listed here. Their default configuration is the same as it was in the backed-up instance at the time of the backup.
Select a volume to include it in the recovery. You can adjust the volumes, as follows:
Enlarge capacity of the volume.
Change the device and device type.
Change IOPS.
Exclude any tags associated with the volume, such as its name.
By default, tags associated with the volume, such as names, are preserved. Clear Preserve Tags to exclude all tags.
By default, the volumes are not deleted on termination of instances recovered from a snapshot. Select Delete on Termination to delete the volume on termination of the instance.
It is possible to recover to a different account and region by recovering to a clone of an original VPC environment. See the Clone VPC options in section 10.3.5.
Advanced options include the following:
Architecture – The default will be the architecture of the backed-up instance. Options are:
i386 – which is X86 – 32-bit
x86_64 – which is X86 – 64-bit
Changing the architecture may result in an error if the image is incompatible with the requested architecture. For example, if your image is a native 64-bit image and you choose i386, the recovery operation will fail.
Tenancy – Choose the tenancy option for this instance.
Shutdown Behaviour – The value of the original instance is the default. If the recovered instance is instance-store-based, this option is not used. The choices are:
stop – If the instance is shut down, it will not be terminated and will just move to stopped state.
terminate – If the instance is shut down, it will also be terminated.
API Termination – Whether terminating the new instance by API is enabled or not. The backed-up instance value is the default.
Auto-assign Public IP - Whether to assign a public IP to the new instance. This is for public subnets. By default, it will behave as the subnet defines.
Kernel – Will hold the Kernel ID of the backed-up instance. You can type or paste a different one. However, you cannot search for a kernel ID from within N2WS. Change this option only if you know exactly which kernel you need. Choosing the wrong one will result in failure.
RAM Disk - Will hold the RAM Disk ID of the backed-up instance. You can type or paste a different one. However, you cannot search for a RAM Disk ID from within N2WS. Change this option only if you know exactly which RAM Disk you need. Choosing the wrong one will result in a failure.
In the Recover Tags section, select one of the recover tag options:
Don't Set Tags
Preserve Original (Tags) - Whether to associate the same tags, such as the volume name, to the recovered volume. The default is yes.
Custom - If selected, select from the table of custom tags that opens.
Allow Monitoring – Select if monitoring should be allowed for the new instance. The value in the backed-up instance is the default.
ENA – Select to support Extended Network Adaptor.
EBS Optimized –Select to launch an EBS Optimized instance. The value from the backed-up instance is the default.
Enable User Data – Whether to use user data for this instance launch. If selected, the User Data box opens. Enter the text. The text of the user data. Special encoding or using a file as the source is not currently supported from within N2WS.
Advanced Options include different additional choices depending on whether Placement is By VPC, By Availability Zone or By Placement Group.
To complete the recovery operation, select Recover Instance and then confirm. If there are errors that N2WS detects in your choices, you will return to the Recover instance screen with error messages. Otherwise, you will be redirected back to the recovery panel screen, and a message will be displayed regarding the success or failure of the operation.
The AMI Assistant is a feature that lets you view the details of the AMI used to launch your instance, as well as find similar AMIs. N2WS will record the details of the AMI when you start backing up the instance. If the AMI is deleted sometime after the instance started backing up, N2WS will remember the details of the original AMI.
After selecting AMI Assistant in the instance recovery screen, you will see these details:
AMI ID
Region
Image Name
Image Description
Owner ID
Root – Device
Type
Virtualization
Hypervisor
To find AMIs with properties that are exactly like the original, select the Exact Matches tab. If the Exact Matches search does not find matches, select the Partial Matches tab which will search for AMIs similar to the original.
AMI Assistant searches can be useful in the following scenarios:
You want to recover an instance by launching it from an image, but the original AMI is no longer available.
You want to recover an instance by launching it from an image, but you want to find a newer version of the image. The fuzzy search will help you.
You are using DR (section 11) and you need to recover the instance in a different region. You may want to find the matching AMI in the target region to use it to launch the instance, or you may need its kernel ID or ramdisk ID to launch the instance from a snapshot.
When you select Clone VPC in the Basic Options tab, the Clone VPC screen opens.
N2WS will have pre-set the following fields according to the selections made in the Advanced Options section:
Capture Source:
Region and VPC
Captured at date and time – You can select a different date and time to clone in the drop-down list of captures.
Clone to Destination:
Region and Account
VPC Name – You can change the suggested name for the new VPC.
As part of the cloning process, N2WS uses CloudFormation. If the CloudFormation template is over 50 kB, select Cloud Formation Template. It requires an existing S3 bucket for uploading. See section 23.5.
When finished, select Clone VPC. If you changed the suggested VPC Name, it will appear in the VPC box.
To view the results of the Clone VPC operation in case manual changes are required, select Download Log.
Volume recovery means creating EBS volumes out of snapshots. In N2WS, you can recover volumes that were part of an instance’s backup or recover EBS volumes that were added to a policy as an independent volume. The recovery process is basically the same.
To recover volumes belonging to an instance:
In the left panel, select the Backup Monitor.
In the Volume Recovery from instance screen, change the recovery fields as needed.
Select Recover Volumes, and confirm.
Attach Behaviour – This applies to all the volumes you are recovering if you choose to attach them to an instance:
Attach Only if Device is Free – If the requested device is already taken in the target instance, the attach operation will fail. You will get a message saying the new volume was created but was not attached.
Switch Attached Volumes – This option will work only if the target instance is in stopped state. If the instance is running, you will get an error message. N2WS will not try to forcefully detach volumes from a running instance since this can cause systems to crash.
Switch Attached Volumes and Delete Old Ones – This option will work only on stopped instances. This option will also delete the old volumes that are detached from the instance.
If you choose Switch Attached Volumes and Delete Old Ones, make sure you do not need the old volumes. N2WS will delete them after detaching them from the target instance.
Recover – Enabled by default. Clear Recover if you do not want that volume recovered.
Zone – AZ. The default is the original zone of the backed-up volume.
Original Volume ID – ID of the original volume.
Capacity – Enlarge the capacity of a volume. You cannot make it smaller than the size of the original volume, which is the default.
Type – Type of the EBS volume.
IOPS – Number of IOPS. This field is used only if the type of volume you chose is Provisioned IOPS SSD. The default will be the setting from the original volume. Values for IOPS should be at least 100, and the volume size needs to be at least 1/10 that number in GiBs. For example, if you want to create a 100 IOPS volume, its size needs to be at least 10 GiB. If you will not abide to this rule, the recovery operation will fail.
Encrypted – Whether device is encrypted.
Device – Which device it will be attached as. This is only used if you choose to automatically attach the recovered volume to an instance. If the device is not free or not correct, the attach operation will fail.
Preserve Tags – Whether to associate the same tags, such as the volume name, to the recovered volume. The default is yes.
Attach to Instance – Whether to attach the newly recovered volume to an instance. Start typing in the list to initiate a filter. The list holds instances that are in the same AZ as the volume. Changing the Zone will refresh the content of this list.
AWS Credentials - As with other recovery screens, you can choose to use different AWS credentials for the recovery operation.
After selecting Recover Volumes and confirming, if there was an error in a field that N2WS detected, you will be returned to the screen with an error notification.
To recover independent volumes:
In the Independent Volumes tab, select a volume or Search by Resource
Complete the From/To options as available.
Select Recover Volumes. A screen similar to recover instance volumes opens. See section 10.3.2.
Recover – Clear Recover to not recover the current database.
Zone – The AZ of the database. By default, it will be the zone of the backed-up database, but this can be changed. Currently, recovering a database into a VPC subnet is not supported by N2WS. You can recover from the snapshot using AWS Management Console.
DB Instance ID – The default is the ID of the original database. If the original database still exists, the recovery operation will fail. To recover a new database, type a new ID.
DB Instance Class – The default is the original class, but you can choose another.
Storage Type – Type of storage.
IOPS - Number of IOPS. This field is used only if the type of volume you chose is Provisioned IOPS SSD. The default will be the setting from the original volume. Values for IOPS should be at least 100, and the volume size needs to be at least 1/10 that number in GiBs.
Port –The default is the port of the original backed-up database, but you can choose another.
Multi AZ – Whether to launch the database in a multi-AZ configuration or not. The default is the value from the original backed-up database.
Subnet Group – Subnet to restore to. The default is the value from the original backed-up database.
You can recover a database from outside a VPC to a VPC subnet group, but the other way around is not supported and will return an error.
If you want to recover the database to a different AWS account (DR), make sure that the subnet groups are configured in that destination account, or else the recovery will fail.
Publicly Access. – Whether the database will be publicly accessible or not. The default is the access from the original backed-up database.
AWS Credentials - As in other types of recovery, you can choose to use different AWS credentials and enter your keys.
DB Parameter Group - The default DB parameter group contains the database engine defaults and Amazon RDS system defaults based on the engine, compute class, and allocated storage of the instance. Database parameters specify how the database is configured. You can manage your database configuration by associating your RDS instances with parameter groups.
Aurora recovery is similar to RDS recovery, with a few important differences.
Aurora introduces the concept of clusters to RDS. You no longer launch and manage a DB instance, but rather a DB cluster that contains DB instances.
An Aurora cluster may be created in a single AZ deployment, and the cluster will contain one instance.
Or, as in production deployments, the cluster will be created in a multi-AZ deployment, and the cluster will have reader and writer DB instances.
When recovering an Aurora cluster, N2WS will recover the DB cluster and then will create the DB instances for it.
Recover – Clear to not recover the current Aurora cluster.
RDS Cluster ID – The default will be the ID of the original cluster. If the original cluster still exists, the recovery operation will fail, unless you change the ID.
RDS Instance ID – The default will the ID of the original instance.
If the original instance still exists, the recovery operation will fail.
Type a new ID to recover a new database. N2WS will use this instance ID for the writer, and in the case of multi-AZ, it will create the reader with this name with _reader added at the end.
RDS Cluster Snapshot ID – Displays the snapshot ID.
Instance Type – The type or class of the DB instances.
Port – The port of the database. The default is the port of the original backed-up database.
Zone – The AZ of the cluster in case of single AZ. If using a subnet group, leave as is.
Subnet Group – Whether to launch the cluster in a VPC subnet or not and to which subnet group. The default is the value from the original backed-up cluster.
Publicly Access – Whether the cluster will be publicly accessible or not. The default is the access from the original backed-up instance.
DB Cluster Parameter Group - Every Aurora cluster is associated with a DB cluster parameter group. Each DB instance within the cluster inherits the settings from that DB Cluster Parameter Group and is associated with a DB Parameter Group.
DB Parameter Group - The default DB parameter group contains the database engine defaults and Amazon RDS system defaults based on the engine, compute class, and allocated storage of the instance. Database parameters specify how the database is configured. You can manage your database configuration by associating your RDS instances with parameter groups.
Select Recover Aurora Clusters when finished.
Recovery of Aurora Serverless is somewhat different than for an Aurora Cluster. As part of the recovery, you can define actions for setting capacity:
Force scaling the capacity to the specified values in Minimum/Maximum Aurora capacity unit when the Timeout for force scaling is reached. When you change the capacity, Aurora Serverless tries to find a scaling point for the change.
Enable to force capacity scaling as soon as possible.
Disable to cancel the capacity changes when the timeout is reached.
Pause compute capacity after consecutive minutes of inactivity. You are only charged for database storage while the compute capacity is paused.
Specify the amount of time (Timeout for force scaling) with no database traffic to scale to zero processing capacity.
When database traffic resumes, Aurora automatically resumes processing capacity and scales to handle the traffic.
4. Change the default field values as needed. See section 10.6 for Instance ID and Subnet Group. 5. If you select Force scaling the capacity to the specified values when the timeout is reached or Pause compute capacity after consecutive minutes of inactivity, the Timeout for force scaling list appears. Change the timeout seconds as needed. 6. Select Recover Aurora Cluster when finished.
When a backup to recover includes snapshots of Redshift clusters, the Redshift Clusters tab opens. All Redshift clusters in the current backup are listed. You can change the following options:
Recover – Clear Recover to not recover the current cluster.
Zone – The AZ of the cluster. By default, it will be the zone of the backed-up cluster, but this can be changed.
Currently, recovering a cluster into a VPC subnet is not supported by N2WS. You can always recover from the snapshot using AWS Management Console.
Cluster ID – The default will the ID of the original cluster. If the original cluster still exists, the recovery operation will fail. To recover a new cluster, type a new ID.
Cluster Snapshot ID– Displays the snapshot ID.
Node Type and Nodes – For information only. Changing these fields is not supported by AWS.
Port – The port of the cluster. The default is the port of the original backed-up cluster.
Subnet Group – Whether to launch the cluster in a VPC subnet or not and to which subnet group. The default will be the value from the original backed-up cluster. You can recover a cluster from outside a VPC to a VPC subnet group, but the other way around is not supported.
AWS Credentials - You can choose to use different AWS credentials and enter your keys.
When a backup to recover includes DynamoDB Table backups, the DynamoDB Tables tab opens.
If you reach the limit of the number of tables that can be recovered at one time, you will need to wait until they have completed before starting the recovery of additional tables.
All DynamoDB tables in the current backup are listed. You can change the following options:
Recover – Clear Recover to not recover a table.
Region – The Region where the table will be recovered, which is the same region as the backup.
Table Name – The default will the Name of the original table. However, if the original table still exists, the recovery operation will fail. To recover to a new table, type a new Name.
Backup Name – Displays the name of the backup.
AWS Credentials - You can choose to use different AWS credentials and enter your keys.
During backup, N2WS retains the DynamoDB tags at the table level and the Time To Live (TTL) metadata and enables these attributes on recovery.
During the recovery process, a confirmation message appears with a reminder to recreate the following settings on the restored DynamoDB tables MANUALLY: Auto Scaling policies, IAM policies, CloudWatch metrics, and alarms.
When a backup includes EFS backups, the Recover EFS tab is available.
For DR and cross accounts, only recoveries to a new EFS are supported.
The AWS role “AWSBackupDefaultServiceRole” is required for recovery.
3. In the Target EFS list, select the target to restore to:
New - Recover to a separate EFS
Original - Recover to the same EFS
Regular recoveries to original and new EFSs are supported. For DR, Target EFS must be 'New'.
When recovering an EFS to the original target, a new folder is created with format aws-backup-restore_[date-time].
4. In cases where EFS DR was performed, select the Restore to Region.
5. For a cross-account recovery:
Target EFS must be 'New'.
In the Cross Account Copy IAM Role list of roles from the source account, select the IAM role needed for copying the recovery point to the target account.
To not miss matching an EFS vault name in the target region during a snapshot backup or a copy, in the AWS console, go to AWS Backup > Backup vaults and select the region you would like to back up or copy EFS snapshots to. This action is to be performed only once before running an EFS backup or DR.
6. Select Recover Volumes.
For file-level recovery, see section 13.3.
To view the progress of the recovery:
In N2WS, select the Recovery Monitor tab.
For ONTAP recovery, see section 10.12.
All of the following parameters are optional except for the password of Win-SMAD, where the original password is the default.
For Self-managed Active Directory, select the SVM tab, complete the recovery options, and then select Recover FSx File System.
Following are the types of ONTAP recoveries:
To recover an ONTAP backup:
In the Recover screen, select an ONTAP file system. The FSx File System Recovery screen opens.
In the Basic Options tab, modify the options as required for the recovery. Selecting Preserve Tags recovers tags on SVMs and their volumes.
In the Subnet ID field, select a single Availability Zone for recovery.
5. In the Volumes tab, select the volumes to recover and update the volume Name as necessary.
6. In the ONTAP FSx Options tab:
a. Update the Recovered File Name as necessary.
b. If required, enable, and specify a password.
7. Select Recover FSx File System.
To recover ONTAP volumes only and attach to an existing SVM:
3. In the Volume Recovery from FSx File System screen, select the volumes to recover. For each volume, type the Name of the volume and select the SVM to attach the volume to.
4. Select the Recover Volumes Only button.
For self-managed active directory recovery options, also see section 10.11.1.
If a backup holds an instance with an SAP HANA configuration and snapshots, the SAP HANA recovery is available. You can recover SAP HANA snapshots to the original EC2 instance or to a new instance created from the EC2 snapshot.
Following are the recovery options:
Recover – EC2 instance recovery with SAP HANA native recovery performed on a newly recovered instance. Cross–region recovery is supported when selecting another region in the Restore to Region list.
Recover SAP HANA Internal DBs only - Recovering an SAP HANA backup to the original EC2 instance.
Some SAP HANA installations require changing the/etc/hosts file in order to communicate with the database. As part of backup and recovery, the user data attached to the instance changes from the original IP address to 127.0.0.1 to enable communication to the database on localhost.
Cross-region recovery might fail on communication issues. Validate that communication is possible between N2WS and the SAP HANA instance on designated ports.
Recovering SAP HANA DB to a new EC2 instance might fail. However, N2WS runs additional (2) retires on the recovery. The recovery operation fails permanently on the 3rd try.
Cross-account recovery is not currently supported on N2WS. It’s possible to run cross-account backup and then perform a cross-account recovery for the EC2 instance only.
In the Backup Monitor, select the SAP HANA backup with the instance for recovery. Select Recover.
In the SAP HANA Instances tab, select an instance and then select a recovery option:
3. Except for SAP HANA Internal DBs, set all tab options as you would for regular EC2 instance recovery. See section 10.3.
4. If the Recover option is selected, also select the SAP HANA Internal DBs tab, select all or individual DBs, and then select Recover Instance.
5. If Recover SAP HANA Internal DBs Only is selected, select the internal DBs for recovery, and then select Recover Instance.
6. If Recover Volumes Only is selected, configure as for a regular EC2 volumes only recovery. See section 10.3.2.
You can recover an SQL Server or only its databases.
To recover an SQL Server:
3. In the Credentials section, enter the Server Admin Login and Password for the recovered SQL Server.
4. In the Network tab, select Firewall Rules and Virtual Network Rules or set Deny Public Network Access.
5. In the SQL Databases tab, select the databases to recover.
6. In the Worker Options tab, set values so that communication between the worker and the SQL Server is available.
7. Select Recover SQL Server.
To recover only SQL databases:
2. In the SQL Databases tab, enter a new Name for each database. Similar names will cause the recovery to fail. Change other settings as needed.
3. Select Recover SQL Database.
When you select Recover for a certain backup, you are directed to the Backup Monitor Recover screen. You can Search by Resource using the resource ID or name.
AMI Assistant – Select to view the details of the AMI used to launch your instance and find similar AMIs.
To view the cloning progress and status, select Background Tasks in the toolbar. Background Tasks only appears after the first Clone VPC or Check Secured DR Account operation.
In the Backup Monitor tab, select a backup, and then select Recover.
Select an instance, and then select Recover Volumes Only.
To follow the progress of the recovery, select the Open Recovery Monitor link in the ‘Recovery started’ message at the top right corner, or select the Recovery Monitor tab.
Select a backup, and then select Recover. The recover volumes screen opens.
When a backup includes snapshots of RDS databases, selecting Recover to bring you to the RDS Databases tab. You will see a list of all RDS databases in the current backup. You can change the following options:
After selecting a backup with Aurora Clusters, select Recover. The Aurora Clusters Recover screen opens. In this screen, all Aurora clusters that were backed up are listed. You can change the following options:
After selecting a backup with Aurora Serverless in the Backup Monitor, selectRecover. The Recover screen opens.
2. In the Aurora Clusters tab, select the recovery target. Aurora Serverless can be identified by the value 'Serverless' in the Role column. 3. SelectRecover. The Recovery Aurora Cluster screen opens.
In the Backup Monitor screen, select an EFS backup. To search backups, you can enter either the EFS name or AWS ID in the search box, select By Elastic File System in the list, and then select the Search icon.
2. Select Recover.
To view details of the recovery process, select the recovery record, and select Log. Select Refresh as needed.
To view the contents of a backup for recovery, in the Backup Monitor, select a backup and then selectView Snapshots.
In the Backup Monitor, select an FSx backup for the recovery. Select Recover. The FSx File Systems tab will show the Original FSx Name and ID, Region, and File System Type.
Select an FSx File System and then select Recover. Parameters are shown depending on whether they are relevant for the type of FSx.
To recover all or some volumes to a new ONTAP FSx, select Recover.
To recover selected volumes and attach them to an existing SVM, select Recover Volumes Only.
To view the contents of a snapshot for recovery, useView Snapshots in the Backup Monitor.
In the Backup Monitor, select the backup for recovery. Select Recover. The FSx File Systems section will show the Original FSx Name and ID, Region, and File System Type.
In the Backup Monitor, select an FSx backup for the recovery. Select Recover. The FSx File Systems tab will show the Original FSx Name and ID, Region, and File System Type.
Select the ONTAP file system to recover and then select Recover Volumes Only.
To view the recovery progress, select Recovery Monitor. Use the Cloud buttons to display the Azure () recoveries.
1. In the Backup Monitor, select the backup, and then select Recover.
1. In the Recover screen, select the SQL Server snapshot that you want to recover from, and then select Recover.
2. In the SQL Server tab of the Recover screen, select 1 SQL Server, and then select Recover. The Basic Options tab opens.
1. Select Recover SQL Databases Only.
Launch from
Snapshots Only
Snapshots + Initial AMI
AMI Only
Image
Possible if supply AMI ID
Possible
Default
Image (Replace root volume)
Windows: Default
Other OS: Possible if supply AMI ID
Default
Not possible
Snapshot
[Create AMI from
root snapshot]
Windows: Not possible
Other OS: Default
Windows: Not possible
Other OS: Possible
Not possible
Parameter
FSx Types
Comment
Target VPC
All
AWS Subnet ID of selected VPC
Security Group
All
AWS Security Group IDs of selected VPC
Subnet ID
Win-AD, Win-SM
Subnet ID
Active Directory ID
Win-AD
Domain Name
Win-SMAD
IP Addresses
Win-SMAD
User Name
Win-SMAD
Password
Win-SMAD
Mandatory
