RDS Aurora clusters, including Aurora Serverless

The N2W management console is accessed via a web browser over HTTPS.

• When a new N2W Server is launched, the server will automatically generate a new self-signed SSL certificate. This certificate will be used for the web application in the configuration step.-

• If no other SSL certificate is uploaded to the N2W Server, the same certificate will be used also for the main N2W application.

• Every N2W Server will get its own certificate.

• Since the certificate is not signed by an external Certificate Authority, you will need to approve an exception in your browser to start using N2W.

When configuring the N2W server, define the following settings:

• AWS Credentials for the N2W root user.

• Time zone for the server.

• Whether to create a new CPM data volume or attach an existing one from a previous N2W server.

• Whether to create an additional N2W server from an existing data volume during Force Recovery Mode.

• Proxy settings. Configure proxy settings in case the N2W server needs to connect to the Internet via a proxy. These settings will also apply to the main application.

• The port the web server will listen on. The default is 443. See section .

• Whether to upload an SSL certificate and a private key for the N2W server to use. If you provide a certificate, you will also need to provide a key, which must not be protected by a passphrase.

• Register the AWS account with N2W Software. This is mandatory only for free trials but is recommended for all users. It will allow N2W to provide quicker and enhanced support. Registration information is not shared.

For the configuration process to work, as well as for normal N2W operations, N2W needs to have outbound connectivity to the Internet, for the HTTPS protocol. Assuming the N2W server was launched in a VPC, it needs to have:

• A public IP, or

• An Elastic IP attached to it, or

• Connectivity via a NAT setup, Internet Gateway, or HTTP proxy.

If an access issue occurs, verify that the:

• Instance has Internet connectivity.

• DNS is configured properly.

• Security groups allow outbound connections for port 443 (HTTPS) or other (if you chose to use a different port).

Following are the configuration steps:

1. Approve the end-user license agreement.

2. Define the root username, email, and password.

3. Define the time zone of the N2W Server and usage of data volume.

4. Fill in the rest of the information needed to complete the configuration process.

2.1 Installing New N2W Server

N2W Server Sizing Guidelines

Following are the recommended instance type sizes to consider when deploying your N2W server:

• Up to 200 instances - T3.medium

• Up to 500 instances - M5.large, C5.large, R5.large, C6i.large, R6i.large, M6i.large, C7i.large, M7i.large

• Up to 1000 instances - M5.xlarge, C5.xlarge,R5.xlarge,C6i.xlarge, R6i.xlarge, M6i.xlarge, C7i.xlarge, M7i.xlarge

• Up to 2000 instances - M5.2xlarge, C5.2xlarge, R5.2xlarge, C6i.2xlarge, R6i.2xlarge, M6i.2xlarge, C7i.2xlarge, M7i.2xlarge

• Up to 4000 instances - M5.4xlarge, C5.4xlarge, R5.4xlarge, C6i.4xlarge, R6i.4xlarge, M6i.4xlarge, C7i.4xlarge, M7i.4xlarge

• Over 4000 instances – Move additional instances to a new CPM Server

2.1.1 Instance ID and End-User License Agreement

To initially be identified as the owner of this instance, you are required to type or paste the N2W server instance ID. This is just a security precaution.

In the next step of the configuration process, you will also be required to approve the end-user license agreement.

2.1.2 License Agreement and Root User

The End User License Agreement field is presented. Select I’m starting a free trial for a free trial. Otherwise, select the appropriate license option in the list, such as Bring Your Own License (BYOL) Edition. Alternatively, if your organization purchased a license directly from N2W Software, additional instructions are shown.

The AWS root user (IAM User) is no longer allowed to control the operation of the N2W server. A user with the Authentication credentials for N2WS Instance IAM Role is the only user allowed to install N2W, log on to the system server, and operate it. As shown below, you need to define the root username, email, and password. This is the third step in the configuration process. The email may be used when defining Amazon Simple Notification Service (SNS) based alerts. Once created, choose to automatically add this email to the SNS topic recipients.

2.1.3 Defining Time Zone, Data Volume, Force Recovery Mode, Web Proxy

In the fourth step of the configuration process, you can:

• Set the time zone of the N2W Server.

• If using a paid license, choose whether to create a new data volume or to use an existing one. Your AWS credentials will be used for the data volume setup process.

• Create an additional N2W server in recovery mode only, by choosing an existing data volume and set Force Recovery Mode.

• Configure proxy settings for the N2W server. See section .

As you will see in section 4.1.3, all scheduling of backup is performed according to the local time of the N2W Server. You will see all time fields displayed by local time; however, all time fields are stored in the N2W database in UTC. This means that if you wish to change the time zone later, all scheduling will still work as before.

Here, you choose to use a new or existing data volume. Actual configuration of the volume, including encryption, will be accomplished at the next step. See section 2.1.4.1.

AWS credentials are required to create a new Elastic Block Storage (EBS) data volume if needed and to attach the volume to the N2W Server instance.

• If you are using AWS Identity and Access Management (IAM) credentials that have limited permissions, these credentials need to have permissions to view EBS volumes in your account, to create new EBS volumes, and to attach volumes to instances. See section 16.3. These credentials are kept for file-level recovery later and are used only for these purposes.

• If you assigned an IAM Role to the N2W Server instance, and this role includes the needed permissions, select Use Instance’s IAM Role, and then you will not be required to enter credentials

2.1.3.1 Proxy Settings

If the N2W server needs an HTTP proxy to connect to the Internet, define the proxy address, port, user, and password. The proxy settings will be kept as the default for the main application. In the N2W UI, proxy settings are made in the Proxy tab of Server Settings > General Settings.

2.1.4 Complete Remaining Fields in N2W Configuration

In the fifth step, you will fill in the rest of the information needed for the configuration of the data volume for the N2W Server.

2.1.4.1 Configuring a New Data Volume

When creating a new data volume, the only thing you need to define is the capacity of the created volume at this step. The default size of the data volume is 10 GiB.

The volume is going to contain the database of N2W’s data, plus any backup scripts or special configuration you choose to create for the backup of your servers. The backup itself is stored by AWS, so normally the data volume will not contain a large amount of data.

Volume Recommendations

• Volume size should be at least 10 GB, which is large enough to manage roughly 50 instances and about 3 times as many EBS volumes.

  • If your environment is larger than 50 instances, increase the volume at about the ratio of 1 GB per 10 backed-up instances·

• Volume type should be at least GP3.

• For Azure, Volume Type defaults to Premium LRS.

The new volume will be automatically created in the same AZ as the N2W instance. It will be named N2W Data Volume. During the configuration process, the volume will be created and attached to the instance. The N2W database will be created on it.

2.1.4.2 Encrypting Volume

Select Encrypted in the Encrypt Volume drop-down list and choose a key in the Encryption Key list. You have the option to use a custom ARN.

2.1.4.3 Web Server Settings

Port 443 is the default port for the HTTPS protocol, which is used by the N2W manager. If you wish, you can configure a different port for the web server. But, keep in mind that the specified port will need to be open in the instance’s security groups for the management console to work, and for any Thin Backup Agents that will need to access it.

The final detail you can configure is an SSL certificate and private key.

• If you leave them empty, the main application will continue to use the self-signed certificate that was used so far.

• If you choose to upload a new certificate, you need to upload a private key as well. The key cannot be protected by a passphrase, or the application will not work.

2.1.4.2 Anonymous Reports Setting

Leaving the Anonymous Usage Reports value as Allow permits N2W to send anonymous usage data to N2W Software. This data does not contain any identifying information:

• No AWS account numbers or credentials.

• No AWS objects or IDs like instances or volumes.

• No N2W names of objects names, such as policy and schedule.

It contains only details like:

• How many policies run on an N2W server

• How many instances per policy

• How many volumes

• What the scheduling is, etc.

2.1.5 Registering and Finalizing the Configuration

After filling in the details in the last step, you are prompted to register. This is mandatory for free trials and optional for paid products.

Select Configure System to finalize the configuration. The configuration will take between 30 seconds and 3 minutes for new volumes, and usually less for attaching existing volumes. After the configuration is complete, a ‘Configuration Successful – Starting Server …’ message appears. It will take a few seconds until you are redirected to the login screen of the N2W application.

If you are not redirected, refresh the browser manually. If you are still not redirected, reboot the N2W server via AWS Management Console, and it will come back up, configured, and running.

2.1.6 Configuration Troubleshooting

Most inputs you have in the configuration steps are validated when you select Next. You will get an informative message indicating what went wrong.

A less obvious problem you may encounter is if you reach the third step and get the existing volume select box with only one value in it: No Volumes found. This can arise:

• If you chose to use an existing volume and there are no available EBS volumes in the N2W Server’s AZ, you will get this response. In this case, you probably did not have your existing data volume in the same AZ. To correct this:

  • Terminate and relaunch the N2W server instance in the correct zone and start over the configuration process, or

  • Take a snapshot of the data volume, and create a volume from it in the zone the server is in.

• If there is a problem with the credentials you typed in, the “No Instances found” message may appear, even if you chose to create a new data volume. This usually happens if you are using invalid credentials, or if you mistyped them. To fix, go back and enter the credentials correctly.

In rare cases, you may encounter a more difficult error after you configured the server. In this case, you will usually get a clear message regarding the nature of the problem. This type of problem can occur for several reasons:

• If there is a connectivity problem between the instance and the Internet (low probability).

• If the AWS credentials you entered are correct, but lack the permissions to do what is needed, particularly if they were created using IAM.

• If you chose an incorrect port, e.g., the SSH port which is already in use.

• If you specified an invalid SSL certificate and/or private key file.

If the error occurred after completing the last configuration stage, N2W recommends that you:

1. Terminate the N2W server instance.

2. Delete the new data volume (if one was already created).

3. Try again with a fresh instance.

If the configuration still fails, the following message will display. If configuring a new instance does not solve the problem, contact the N2W Software Support Team. To access configuration error details, select Download Configuration Logs.

2.1.7 Using AWS Key Management Service

The AWS Key Management Service (KMS) allows you to securely share custom encryption keys between accounts. For details on enabling shared custom keys, see https://aws.amazon.com/blogs/security/share-custom-encryption-keys-more-securely-between-accounts-by-using-aws-key-management-service/.

The use of custom keys is required in the following cases:

• Authentication of cpmuser to N2W server using a non-default certificate with a private key.

• Encrypting new volumes.

• Associating an account for File Level Recovery.

• Authentication of IAM User.

• Running scripts.

• Performing Recoveries, DR, and Cross-Account activities for RDS, EC2, and EFS resources.

2.1.8 Securing Default Certificates on N2W Server

See Appendix G – Securing Default Certificates on N2W Server.

2.2 Upgrading N2W

The following diagram shows the major steps and considerations in an N2W upgrade. The upgrade flow is the same as the installation flow with the addition of using an existing CPM data volume (section ‎2.2.2).

‌The upgrade process consists of the following phases:

1. Before starting the upgrade, refer to instructions specific to your current version in section ‎2.2.

2. Stop the current CPM instance.

3. Select the existing data volume from the snapshot to be used in the upgrade.

4. Configure the new version instance according to instructions in section .

5. Terminate the old version instance, and launch the new version as described in section ‎‎.

6. After the upgrade, there are still a few steps to ensure a complete transition. See section .

If you have any questions or encounter issues, visit the N2W Support Center where you will find helpful resources in a variety of formats or can open a Support Ticket.

2.2.1 Before Upgrading to the Latest N2W Version

The following sections outline the steps required to upgrade to the latest N2W Backup & Recovery version.

‌2.2.1.1 IAM Permissions

Due to new functionality in v4.4.x, you may need to update your permission policies. If you have more than one AWS Account added to the N2W console, you will have to update the IAM Policies for each account.

For AWS: See https://n2ws.zendesk.com/hc/en-us/articles/33252616725533--4-5-0-Required-Minimum-AWS-permissions-for-N2W-operations

For Azure: See https://n2ws.zendesk.com/hc/en-us/articles/33252710830109--4-5-0-Required-Minimum-Azure-permissions-for-N2W-operations

Collecting Information Before Starting Upgrade

Following is the important information you must have ready before starting:

1. Verify that there are no backups, DRs, or Cleanups running or scheduled to run within the next 15-30 minutes.

   If the only thing processing is an S3 archive, you are able to abort it if you want.

2. Have the username and password for the root/admin user ready.

3. If you are using a proxy in the N2W settings, write down the details.

4. Take a screenshot of the N2W EC2 instance network settings: IP, VPC, Subnet, Security Groups, and IAM Role and Keypair name.

5. Take a screenshot of the Tags if you have more than a few.

6. Terminate the N2W EC2 instance.

   1. Terminating is only necessary BEFORE launching the new AMI if it is a Marketplace Subscription.

   2. If you are using BYOL, you can keep the old server until the new upgrade is complete and tested for an easy rollback if necessary.

7. Take a snapshot of the N2W Data Volume. Only the Data Volume is important, as it contains all your settings, backup entries, etc.

8. Download the latest IAM permissions (section ) and update the IAM Policies from your role.

9. If you are using a custom SSL certificate, make sure you have the .CRT and .KEY files available in a place where you can easily add them during the configuration process.

2.2.2 Configurating the New N2W Server Instance

‌To upgrade/redeploy the N2W Server Instance:

1. About 1 minute after launching the new instance, it should in the running state. Connect to the user interface (UI) with a browser using https://[ip-of-your-new-instance].

2. Confirm the Instance ID of your newly launched instance.

3. Accept the Terms and Conditions.

4. Enter the username and password of the admin/root user.

5. Approve the exception to the SSL certificate.

6. Choose the time zone and select Use Existing Data Volume in step #4, “Data Volume and Proxy”.

7. Select your old data volume in the Existing CPM Data Volume list in step #5, “Server Configuration”.

8. Select Configure System in step #6, “Register Your Account”. N2W will automatically resume operations. Wait until the login mask appears.

2.2.3 Terminating the Old Instance and Launching the New Instance

1. Terminate the existing CPM instance.

2. Launch a new N2W Server instance in the same region and AZ as the old one. You can launch the instance using the Your Marketplace Software page on the AWS web site.

3. To determine the AZ of the new instance, launch the instance using the EC2 console rather than using the 1-click option.

4. Wait until the old CPM instance is in the terminated state.

5. Confirm Perform Failover prompt.

6. Wait 5 minutes for the ‘Operation Succeeded’ message.

1. Reboot.

2.2.4 Existing Data Volume

The Existing data volume option is used if:

• You have already run N2W and terminated the old N2W server, but now wish to continue where you stopped.

• You are upgrading to new N2W releases.

• You are changing some of the configuration details.

• You want to configure an additional N2W server in recovery mode only. See section .

The select box for choosing the volumes will show all available EBS volumes in the same AZ as the N2W Server instance. When choosing the volumes, consider the following:

• It is important to create the instance in the AZ your volume was created in the first place.

• Another option is to create a snapshot from the original volume, and then create a volume from it in the AZ you require.

2.2.5 Completing the Upgrade

2.2.6 Force Recovery Mode

You can configure an additional N2W server, in recovery mode only, by choosing an existing data volume:

• In step 4, choose to use an existing volume and in the Force Recovery Mode, select Yes.

• In step 5, in the Existing CPM Data Volume list, select the volume that holds your backup records.

2.3 Automate Configuration with Silent Mode Installation

Configuring N2W in silent mode is available using AWS user data, using AWS Secrets Manager, and for Azure.

2.3.1 AWS Configuration

Launching an EC2 instance in AWS can optionally be set with User Data. See the description of how such user data can be utilized at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html.

The N2W instance can also use this user data when launching.

• If the string CPMCONFIG exists in the user data text, then the text following it is used for the CPM configuration.

• The extraction is until the string CPMCONFIGEND or the end of the data.

• The extracted text is assumed to be in .ini file format.

• The extracted configuration text of the new N2W instance should start with a [SERVER] section, followed by the configuration details.

• For the relevant time_zone parameter value, see .

Following is an example of the whole script:

To use AWS Secrets Manager in Silent Mode for AWS, also see 2.3.2.

Additionally, if you need the N2W server to connect to the Internet via an HTTP proxy, add a [PROXY] section:

The snapshot option does not exist in the UI. It can be used for the automation of a Disaster Recovery (DR) server recovery. Additionally, if you state a volume ID from another AZ, N2W will attempt to create a snapshot of that volume and migrate it to the AZ of the new N2W server. This option is for DR only.

After executing the configuration, on the AWS Instances page, select the Tags tab. If the CPM_Silent_Configuration key value equals ‘succeeded’, then the CPM instance was successfully launched with the user data configured in silent mode.

To verify configuration user data:

1. In AWS, select the CPM instance.

2. In the right-click menu, select Instance Settings, and then select View/Change User Data.

2.3.2 Silent Mode Using AWS Secrets Manager

You can keep Silent Configuration values, such as username and password, on AWS Secrets Manager. Secrets Manager can be used on any textual (not numeric or Boolean) field value in the configuration file. Secrets Manager is:

• Not available for proxy settings

• Available only for AWS.

The format is <silent config key>=@<Secret name>#<key in secret>@

Different secrets may be used within a configuration file, such as a user's password from another secret.

2.3.3 Configuring in Silent Mode for Azure

Silent configuration for Azure can only be executed programmatically using the Azure CLI, not through the Azure Portal.

• The Azure Portal has a limitation whereby a User Managed Identity is not associated with a Virtual Machine until after its creation.

• An existing Managed Identity with predefined permissions must be assigned to the Virtual Machine immediately upon its creation in order to perform various operations.

To deploy N2W using the Azure CLI:

1. In the Azure Portal, accept the license terms for N2W Backup & Recovery for Azure one time.

2. Select the Get Started link.

3. In the Configure Programmatic Deployment screen, Enable the Subscription for the image you are deploying.

4. Create a text file containing the following configuration parameters, including the Managed Identity Client ID, in the indented format shown:

5. Pass the file to the Azure CLI VM creation command as follows:

2.4 Patch Installation

To keep your N2W running at its highest efficiency, N2W will occasionally send you notification of the existence of a patch through an Announcement or an email. Download the patch according to the notification instructions.

To install patches:

1. In the top right toolbar, select Server Settings and then select Patches.

2. Select Choose file to select the patch file.

3. Select Upload and Install.

5.2 Application-Consistent Backup

During application-consistent backups, any application may be informed about the backup progress. The application can then prepare, freeze, and thaw in minimal-required time to perform operations to make sure the actual data on disk is consistent before the backup starts, making minimal changes during backup time (backup mode) and returning to full-scale operation as soon as possible.

There is also one more function that application-consistent backups perform especially for databases. Databases keep transaction logs which occasionally need to be deleted to recover storage space. This operation is called log truncation. When can transaction logs be deleted without impairing the robustness of the database? Probably after you make sure you have a successful backup of the database. In many cases, it is up to the backup software to notify the database it can truncate its transaction logs.

5.3 N2W and a Point in Time

When taking snapshots, the point in time is the exact time that the snapshot started. The content of the snapshot reflects the exact state of the disk at that point in time, regardless of how long it took to complete the snapshot.

5.4 Summary or What Type of Backup to Choose

The type of backup to choose depends on your needs and limitations. Every approach has its pros and cons:

5.4.1 Crash-Consistent

Pros:

• Does not require writing any scripts.

• Does not require installing agents in Windows Servers.

• Does not affect the operation and performance of your instances and applications.

• Fastest.

Cons:

• Does not guarantee a consistent state of your applications.

• Does not guarantee the exact point in time across multiple volumes/disks.

• No way to automatically truncate database transaction logs after backup.

5.4.2 Application-Consistent

Pros:

• Prepares the application for backup and therefore achieves a consistent state.

• Can ensure one exact point in time across multiple volumes/disks.

• Can truncate database transaction logs automatically.

Cons:

• May require writing and maintaining backup scripts.

• Requires installing an N2W Thin Backup Agent or the AWS SSM Agent for Windows Servers.

• May slightly affect the performance of your application, especially for the freezing/flushing phase.

For example, to set the time zone to 'New York', type:

• Users will need to share the encrypted key used for the encryption of the volumes or instances to the other account as N2W will not do it.

• In addition, N2W expects to find a key in the target account with the same alias as the original key (or just uses the default key).

For information on sharing encryption keys between different accounts, see https://n2ws.zendesk.com/hc/en-us/articles/28815492111005-Use-custom-KMS-encryption-keys-for-cross-region-cross-account-DR​

If a matching encryption key is not found with an alias or with custom tags, the behaviour of the backup depends on the setting in the Encryption Key Detection list in the Security & Password tab of the General Settings screen:

• Use Default Key – If the encryption key is not matched, the default encryption key is used.

• Strict – DR encryption key must match, either with an alias or a custom tag.

• Use Default Key & Alert – Use the default key and send an alert.

N2W can support a DR scheme where a special AWS account is used only for snapshot data. This account’s credentials are not shared with anyone and used only to copy snapshots. The IAM credentials used in N2W can have limited permissions that do not allow snapshot deletion.

N2W will tag outdated snapshots instead of deleting them, allowing an authorized user to delete them separately using the EC2 console or a script. The tag cpm_deleted will have a value of ‘CPM deleted this snapshot (<time-of-deletion>)’. Also, you may choose to keep the snapshots only in the vault account and not in their original account. This will allow you to save storage costs and utilize the cross-recovery capability to recover resources from the vault account back to the original one.

12.1 Configuring Cross-Account Backup

Once you have created an account with the Account Type DR, you can configure cross-account DR from the DR tab of a policy.

Cross-account fields will be available only if your N2W is licensed for cross-account functionality. See the pricing page on our website to see which N2W editions include cross-account backup and recovery.

Once you select Cross-Account DR Backup Enabled, other fields become visible:

• To Account – Which account to copy the snapshots to. This account needs to have been defined as a DR Account Type in the Accounts screen.

• DR Account Target Regions – Which region or regions you want to copy the snapshots of the policy to. To include all Target Regions selected for backup, select Original in the list. Select additional regions as needed.

• Keep Original Snapshots – Enabled by default, the original snapshot from the source region will be kept. If disabled, once the snapshot is copied to the DR account, it will be deleted from the source region.

12.2 Cross-Account DR and Clean-Up

N2W performs clean-up on backup policies and deletes backups and snapshots that are out of the retention window, according to the policy’s definition. By default, N2W will clean up snapshots copied to other accounts as well. However, if you do not wish for N2W to clean up, because you want to provide IAM credentials that are limited and cannot delete data, you have that option. If you defined the DR account with Allow Deleting Snapshots set as False, N2W will not try to delete snapshots in the DR account. It will rather flag a snapshot for subsequent deletion by adding a tag to the snapshot called cpm_deleted. The tag value will contain the time when the snapshot was flagged for deletion by N2W.

When using this option, occasionally make sure that these snapshots are actually deleted. You can either run a script on a schedule, with proper permissions or make it delete all snapshots with the tag cpm_deleted. Or, using the EC2 console, filter snapshots by the tag name and delete them.

12.3 Cross-Account with Cross-Region

If you configure the backup policy to copy snapshots across accounts as well as across regions, be aware of how the increased number of copies might affect your AWS costs.

Cross-account with cross-region DR with AMIs is supported.

12.3.1 RDS Cross-Account with Cross-Region Recovery

AWS limits RDS snapshot cross-account copy to the DR account in the original region. To overcome this limitation, N2W performs two snapshot copies during the DR process:

1. Copy from 'Backup account - origin region' to ‘DR account - origin region'.

2. Copy from 'DR account - origin region' to ‘DR account - DR region'.

12.4 Cross-Account Recovery

If you have cross-account functionality enabled in your N2W license, and even if you configured N2Wto copy snapshots between accounts, you can recover across accounts. This is already mentioned in Recovery section 10. You need to choose which account to recover the resource (EC2 instance, EBS volume, or RDS database) to.

When copying snapshots between accounts and not keeping the original snapshots, you will also have the option to restore the instance/volume to the original account. N2W will utilize the AWS share snapshot option to enable recovering resources across accounts.

N2W Login Reset Utility n2ws-reset-login:

To reset login credentials and/or MFA for specific or all users:

1. Connect to N2W instance via SSH with user 'cpmuser' and your SSH key.

2. Switch to root: ‘sudo su’.

3. To see options for using the utility to reset the password or MFA, type ‘n2ws-reset-login’.

4. Disable the root user MFA without changing the password:

5. Disable the root user MFA and reset the password:

6. Enter password and confirmation entry.

7. Reset MFA if relevant.

F.2 Resetting Root Password if no SSH and Version 4.1 or Earlier

If you don’t have SSH access, perhaps because the key is lost, or if you just need to recover your password and disable the MFA, redeploy the instance as follows:

If you know the root/admin username:

1. Follow the upgrade procedure in the N2W User Guide at https://docs.n2ws.com/user-guide/#1-4-upgrading-n-2-ws.

2. When configuring the new instance, use the old username of the root/admin (important!) and the new password.

3. After the new CPM is launched, apply any necessary patches to make sure it’s up-to-date with the latest fixes and features: https://support.n2ws.com/portal/en/kb/articles/release-notes-for-the-latest-v4-1-x-cpm-release

If you don’t know the root/admin username:

1. Follow the upgrade procedure in the N2W User Guide at https://docs.n2ws.com/user-guide/#1-4-upgrading-n-2-ws.

2. During the “upgrade” process, type the username you think it is and the new password.

3. If you typed the wrong root username, N2W will assume you forgot it and will create a file on the server, '/tmp/username_reminder', containing the old username.

   1. To view this file, connect to the N2W server using SSH as ‘cpmuser’.

   2. Now you will be able to use the older username with the new password.

4. After the new CPM is launched, apply any necessary patches to make sure it’s up-to-date with the latest fixes and features:

For further information, see https://support.n2ws.com/portal/en/kb/articles/how-to-reset-the-password-for-the-root-admin-cpm-user

If you specify 0.0.0.0/0, it will enable all IPv4 addresses to access your instance using SSH.

For further details, refer to “Adding a Rule for Inbound SSH Traffic to a Linux Instance” at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html

1. Name – Name for this N2W account.

2. User – The N2W user that this account belongs to. See section ‎18.

3. Access Key ID - ID provided by N2W for authentication.

4. Secret Access Key - Key provided by N2W for authentication.

When creating a policy with the S3 option enabled, N2W will manage the lifecycle according to the policy settings. When configuring S3, consider the differences in the storage types:

• Snapshot – The fastest option. It enables free recovery within seconds, but it has the highest storage cost. Snapshot is useful for backups that you need to recover quickly and keep for a short time.

• S3 Storage – Provides much cheaper storage costs, but recovery is slower and costs a little more. S3 Storage is useful for backups that do not need quick recovery time and that you want to keep for a long time.

• Glacier – Provides the cheapest storage costs, but recovery is the most expensive and the slowest. Glacier is useful for backups that you need to keep for several decades for compliance purposes and which you don’t expect to have to recover urgently.

A.1.2 Bucket Location

When configuring Copy to S3, consider the following when deciding where to put your S3 buckets:

• Having the bucket in a different region then the target snapshot will incur AWS cross-region charges and will also result in slower copy speed due to the greater physical distance.

• Putting the bucket in the same region as your protected resources will:

  • Help avoid cross-region data charges by AWS.

  • Help make the copy faster.

• One bucket for all regions makes for easier management, while one bucket per region makes for optimal cost.

• Since each AWS S3 bucket has some performance limits, configuring an AWS S3 Repository per policy will result in faster and more stable copies to S3. Or, if several policies are all writing to the same bucket, you can stagger the copies to avoid putting too much load on the same bucket at the same time.

A.1.3 VPC S3 Endpoint and VPC Peering

Using VPC endpoint enables instances to use their private IP to communicate with resources in other services, such as S3, within the AWS network without incurring network transfer fees.

You can set up a VPC S3/EBS endpoint in the VPC where the S3 worker is launched to make sure that the communication from the worker will be over private IP. Using an VPC S3 Endpoint can help avoid NAT costs (if used in the VPC) as there is no data processing or hourly charges for using Gateway Type VPC endpoints. Additionally, the copy process will be more secure as the communication will be over private IP, and the copy speed over the S3 Endpoint should be faster than over the Internet.

In addition, you can set up VPC peering between the worker VPC and the N2W server VPC so that communication between the worker and the server will also be routed over private IP.

A.1.4 KMS Keys for the Bucket

When creating the S3 bucket in AWS, you have 2 encryption options:

• SSE-S3 server-side encryption with Amazon S3-managed keys. This option is free, but it is less secure than SSE-KMS.

• SSE-KMS server-side encryption with AWS KMS. This option has a cost per request, but it is more secure than SS3-S3.

When setting up the bucket, consider whether the free option (SSE-S3) is sufficient for your use case, or if you need greater security with SSE-KMS, which is more expensive.

A.2 Creating a VPC S3 Endpoint

1. In AWS, create a subnet within the VPC of the region.

After successful creation, the successful creation message appears.

The subnet is automatically associated with the default route table.

2. Create a new route table.

3. Change the subnet association by associating the previously created subnet with this route table. 4. Create a VPC endpoint for S3 in the region and associate it with the previously created route table.

5. Choose a region.

6. Then choose the previously defined route table. The permissions to access the bucket will be defined by the IAM policies attached to the roles of N2W.

7. Grant Full Access.

The route table of the subnet now looks like the following:

8. If N2W is in a different account/region/VPC, add an Internet Gateway to the route table so the ‘worker’ can communicate with N2W.

1. Add the following rule:

The route table will look like:

2. In this configuration, the connection to S3 will be routed to the VPC endpoint. See the example below:

9. In N2W, select the Worker Configuration tab.

1. Select New. 2. Configure the worker to use this subnet in the specific region and the VPC where it is defined.

For additional information about setting up VPC Gateway Endpoints, see https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html

In the Dashboard screen, you can find both Cost Explorer and Cost Savings information in their respective tiles:

25.1 Enabling and Disabling Cost Explorer

Following are the steps necessary for using Cost Explorer:

• In AWS, activate cost allocation tags. See section 25.1.1.

• In N2W:

  • For CPM, select Enable Cost Explorer in the Cost Explorer tab of General Settings.

  • For each designated user, enable Allow Cost Explorer. See section .

To disable Cost Explorer, it is sufficient to clear Enable Cost Explorer in the Cost Explorer tab.

25.1.1 Configuring AWS to Allow CPM Cost Explorer Calculations

To allow CPM Cost Explorer calculations in AWS, users must add cost allocation tags once.

To activate user cost allocation tags:

1. Log in to the AWS Management Console at https://console.aws.amazon.com/billing/home#/.

2. Open the Billing and Cost Management console.

3. In the navigation pane, choose Cost Allocation Tags.

4. Choose the following tags to activate, and then select Activate:

• cpm_server_id

• cpm_policy_name

For complete details, see http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html​

25.2 Monitoring Costs

In the Policies tab, you can monitor the backup costs of each policy for the last month or a different time period. The breakdown of costs per policy in dollars for the desired period appears in the Cost ($) column.

If the Allow Cost Explorer option is not enabled for the logged-in user, or if the backup was generated within the last 24 hours, the Cost ($) column will show ‘N/A’. To enable Cost Explorer for a user, see section 18.3.

25.2.1 Specifying a Different Time Period for Cost Calculations

You can monitor costs for a different time period by setting the Cost Period for all policies. The maximum period is one year. The current period is shown next to Cost Period in the Policies tab below the filters.

To specify the period for cost calculations:

1. Select the Policies tab and then select Cost Period.

2. Select Period.

3. Choose the From and To dates from the calendars, selecting Apply after each date.

25.3 Monitoring Expected Cost Savings

In the Resource Control Groups tab, you can monitor the expected Cost Savings for each group, based on the schedules you have set to Turn Off an instance or an RDS database.

To update the screen with the current AWS savings, select Refetch Savings Data from AWS, and then select View updated data in the data refetched message. ​

1. Setup Datadog Account.

   Visit Datadog at https://www.datadoghq.com/pricing/ and set up an account that fits your scale.

   ​

2. Install Python Integration.

   a. Login to Datadog and go to Integrations.

   b. Search for ‘Python’ and install it:

c. Search for 'N2WS' and install it. See step 6.

3. Enable Datadog support on N2W Instance. a. Connect to your N2W Backup & Recovery Instance with SSH Client. b. Type sudo su. c. Add the following lines to /cpmdata/conf/cpmserver.cfg:

d. Run service apache2 restart.

4. Install Datadog Agent on N2W Instance. a. Login to Datadog and go to Integrations > Install Agents > Linux:

b. In step 3 of the Install the Datadog Agent on Linux page, create the install command by selecting an API Key, and then selecting Use API Key.

c. Use the copy icon in the upper right corner of the code block to copy the entire agent install command.

d. Connect to your N2W Backup & Recovery Instance with SSH Client, type sudo su and run the agent Install command. e. Restart the Datadog Agent: sudo service datadog-agent restart

5. Setup Datadog Dashboard metrics. a. Log in to Datadog and go to Metrics > Explorer. b. In the Graph list, select your metrics. All N2W metrics begin with cpm_ followed by <metric-name>.

c. In the Over list, select data. You can either select a specific user or the entire N2W instance. All N2W user data begins with cpm:user: followed by <user-name>.

6. Configure your Datadog dashboard by using the N2W template or creating your own dashboards, and choose the data to monitor. a. To use the N2WS template, in Datadog Integrations at https://app.datadoghq.com/account/settings#integrations, search for the 'N2WS' tile and install it. You will get a variety of dashboards for your account. Dashboards are named 'N2WBackup&Recovery-<dashboard_name[-version]>'. When dashboards are added for a new N2W version, the dashboards will contain the version number, such as '3-2-0' and '4-0-0'. Version numbers indicate which dashboards are valid for versions going forward. b. To create a Datadog dashboard: i. Go to Dashboards and select New Dashboard.

ii. Add a graph type by dragging and dropping its template to the dashboard:

iii. Edit the graph for the data to be monitored:

iv. Save the graph settings.

7. View N2W Alerts on Datadog Events. a. Log in to Datadog and go to Events. b. View your instance alerts:

D.2 Monitoring N2W with Web Proxy

If you have restricted outbound traffic, you can proxy all Datadog Agent traffic through different hosts.

1. Connect to your N2W Backup & Recovery Instance with SSH Client.

2. Enable proxy: section on datadog.yaml. 3. Add your proxy IP, port, username, and password:

4. Validate datadog.yaml on https://yamlchecker.com/.

Example:

For additional proxy configuration options, see https://docs.datadoghq.com/agent/proxy/

If a default IAM role was not automatically created by AWS, or you require a custom IAM role, see section 8.2. Selecting the preferred IAM role is only required during the target configuration.

Restore the backups to the same or different EKS clusters with the same namespace or a different one, at your choice.

28.1 Overview

N2W simplifies Kubernetes backup and restore workflows. You can:

• Add EKS Cluster or Namespaces to a policy like any other AWS resource.

• Back up entire an entire EKS Cluster, including:

  • All namespaces

  • Cluster-scoped resources

  • EBS snapshots of Persistent volumes

  • Kubernetes manifests (to S3)

• Back up specific Namespaces only

• Restore anywhere:

  • To the same cluster

  • To a new cluster

  • And rename namespaces.

• Combine EKS backups with other AWS services in a single policy. In the same policy, you can back up:

  • An EKS namespace containing a WordPress deployment together with

  • The associated AWS RDS database instance

28.2 Prerequisites

Before adding EKS resources to a CPM policy, the following steps must be completed:

1. Install Velero on each EKS cluster you want to protect.

Velero is an open-source tool that provides backup and restore for Kubernetes clusters. It backs up Kubernetes resources and persistent volumes, saves them in S3-compatible storage, and lets you safely restore clusters when needed.

Velero must be installed on:

• Every source EKS cluster you back up.

• Every destination EKS cluster you restore into.

1. Configure the Velero backup storage (S3).

During Velero installation, specify:

• An S3 bucket that stores your Kubernetes manifests.

• The velero-plugin-for-aws, which enables Velero to create EBS snapshots.

1. Ensure that the following IAM permissions and access are set:

• Kubernetes RBAC (EKS Access Entry & Policies). Configure an EKS Access Entry for the EC2 instance's IAM role with appropriate policies:

  • Required: Velero Namespace Admin Access

    • Policy: AmazonEKSClusterAdminPolicy

    • Scope: namespace - specifically the velero namespace

    • Purpose: Allows creating and managing Velero backup/restore resources

  • Optional: Cluster-Wide Read Access

    • Policy: AmazonEKSViewPolicy

    • Scope: cluster

• Velero S3 and IAM Roles for Service Accounts (IRSA) Configuration. Ensure that the Velero pod uses IRSA with permissions to:

  • Access the Velero backup S3 bucket

  • Create and manage EBS snapshots

1. Ensure Network connectivity between the VPC and EKS API endpoint.

2. Set EKS Access Entry: Associate the IAM role with EKS access policies.

3. Enable Security Group: Allow outbound HTTPS (port 443) to the EKS cluster API endpoint.

28.3 Creating EKS Policies

To define EKS policies, see section ‎4.2. Select EKS Clusters or EKS Namespaces from the Backup Targets menu.

28.4 Recovering EKS

N2W supports flexible restore operations for EKS:

• Restore the entire EKS cluster backup, which includes:

  • All namespaces

  • All workloads and resources

  • Persistent volumes

  • Optional cluster-scoped resources

• Restore only selected namespaces, which allows restoring workloads into the same cluster or into a different EKS cluster:

  • One or multiple namespaces

  • Optionally rename namespaces during recovery

• During recovery, you can choose whether to restore Cluster-Scoped Resources, such as:

  • ClusterRoles

  • ClusterRoleBindings

When to enable the Cluster-Scoped Resources option:

To recover EKS clusters or EKS namespaces:

1. In the Backup Monitor, select the AWS Cloud button.

2. 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.

3. To filter by resource type, select a resource type in the By Instance list, such as EKS Cluster.

4. Select and then choose a backup in the list and then select Recover. A list of clusters opens.

5. Select a Cluster Name.

To recover namespaces:

1. To recover specific namespaces, select the Namespaces tab.

   1. To include Cluster-Scoped Resources, select Include Cluster Resources.

   2. In the Namespace Name list, select one or more Names.

   3. For each Name, change the Target Namespace Name, if required.

2. Select Recover.

1. For root user policies, scripts need to be under /cpmdata/<instance_id>, for example, ‘/cpmdata/scripts/i-0031fe7934041cf41’.

2. For non-root user policies, scripts need to be under the user folder, for example, ‘cpmdata/scripts/username/i-0031fe7934041cf41’.

You can manage workers and their configurations as well as test their communication with the CPM, SSH, EBS API, and S3 Endpoint in the Worker Configuration tab (section 22.3).​‌

22.1 Worker Parameters

‌It is necessary to define a separate worker configuration for each planned account/region combination of Copy to S3 instance snapshots, or each Explore region.

To configure S3 worker parameters:‌

1. Select the Worker Configuration tab.

2. On the ​ New menu, select AWS Worker.

3. In the User and Account lists, select the User and Account that the new worker is associated with.

4. In the Region list, select a Region. This configuration will be applied to all workers launched in this region for this account.

5. In the Key pair list, select a key pair. Using the default, Don’t use key pair, disables SSH connections to this worker.

6. In the VPC list, select a VPC. The selected VPC must be able to access the subnet where N2W is running as well as the S3 endpoint.

7. In the Security Group list, select a security group. The selected security group must allow outgoing connections to the N2W server and to the S3 endpoint.

8. In the Subnet list, select a subnet, or choose Any to have N2W choose a random subnet from the selected VPC.

   1. When performing a recovery, if you choose ‘Any’ in the Subnet drop-down list, N2W will automatically choose a subnet that is in the same Availability Zone as the one you are restoring to.

   2. If you choose a specific subnet that is

9. In the Worker Role list, select an instance role granting the Worker the permissions required for its policies, or select No Role to not attach an instance role to the Worker.

   1. If Custom ARN is selected, enter the Custom ARN.

   2. If No Role is selected, N2W will generate temporary credentials and securely pass them to the Worker thereby granting the Worker the permissions linked to the Account that owns the policy and/or the repository.

10. In the Network Access list, select a network access method.

11. Select Save.

12. Test the new worker (section 22.3).​

To edit or delete a worker configuration:‌

1. In the Worker Configuration tab, select a worker.

2. Select ​ Delete or ​ Edit.

‌22.2 Worker Tags

You can add multiple tags to each account for workers for subsequent monitoring of cost and usage in the AWS Cost Explorer. When the worker is launched for any type of operation, such as Copy to S3, Recover S3, file-level recovery, Cleanup, worker testing, etc., it will be tagged with the specified tags. You will then be able to filter for the N2W worker tags in the Tags tab of the AWS Cost Explorer.

To activate your worker tags, see section 22.2.1.‌

To add worker tags:‌

1. In the Worker Configuration tab, select a worker and then select the Worker Tags tab.

2. Select ​ New, and enter the Tag Name and Value. The Value may be blank.

3. Select Save.​‌

22.2.1 Configuring AWS to Allow CPM Cost Explorer Calculations

‌To allow CPM Cost Explorer calculations in AWS, users must add cost allocation tags once.‌

To activate user cost allocation tags:‌

1. Log in to the AWS Management Console at https://console.aws.amazon.com/billing/home#/ and open the Billing and Cost Management console.

2. In the navigation pane, select Cost Allocation Tags.

3. Choose the worker tags to activate.

4. Select Activate.

It can take up to 24 hours for tags to activate.‌

For complete details, see http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html.‌

22.3 Testing the Configuration for a Worker

Before a worker is needed, you can test whether it successfully communicates with the N2W server and other communication targets. Depending on the test, some, but not all, AWS permissions are also checked.‌

• Connectivity to N2W Server (default)

• SSH Test - Connectivity to N2W server using SSH

• EBS API Test - Test API connectivity and check AWS ebs:ListSnapshotBlocks permission

• S3 Endpoint Test - Test connectivity; check AWS s3:ListAllMyBuckets and s3:ListBucket permissions

To test a worker configuration:‌

1. Select a worker, and then select ​ Test.

2. If you want to test connections in addition to the worker, in the Select Additional Tests dialog box, select the relevant tests.

3. Select Run Tests. The ‘Worker Configuration test is underway’ message briefly appears at the top right and the ‘ ​ In Progress’ message appears in the Test Status column. Select ​ Refresh as necessary.

4. Check the results in the Test Status column: Successful or Failed.

5. If not 'Successful':

   1. Select ​ Test Status to display information about the root cause.

   2. To check settings, select ​ Edit.

Besides the requested connectivity tests, the Configuration Test Details include Account, Region, Zone, Key Pair, VPC, Security Group, and whether an HTTP Proxy was required.​‌

To view and download the latest log, select​Test Log.​

An N2W app with 2 dashboards for displaying operational insights:

• N2W activity monitor - Information about the data

• N2W Alerts

Limitations:

• No support for Microsoft Azure

• No support for multiple CPMs

• Supported with Splunk Enterprise only

Integration consists of installing Splunk and configuring the TA for N2W.

E.1 Configure N2W Server for Splunk

To configure the N2W Server:

1. Edit the N2W configuration file as follows:

​ 2. Restart apache:

3. To check the status of the Splunk integration, in N2W, go to Help > About and verify that 'External monitoring (Datadog / Splunk) enabled' is Yes.

E.2 Installation on Splunk

Splunk can work with a proxy for reaching N2W APIs.

To install:

1. Log on to your Splunk Web and in the Enterprise Apps screen, select Settings .

The Manage Apps page opens.

2. In the upper right, select Install app from file.

3. For an initial installation: a. Browse for the N2WS_app_for_splunk.spl file. Select Upload.

b. Browse for ta_N2WS_for_splunk.spl. Select Upload.

4. For updates, browse for the current file and select Upgrade app.

Installation of Splunk is fully documented at https://docs.splunk.com/Documentation/Splunk/8.1.1/Installation/InstallonLinux

E.3 Configuration of TA for N2W

Two configurations are required:

• TA of the REST API

• Data inputs from N2W for Alerts and Dashboard information

To configure the TA:

1. Go to splunk > App N2WS Add-on > Configuration.

2. If needed, select the Proxy tab, complete the settings, and select Save.

3. In the Logging tab, select the TA Log level: DEBUG, INFO, WARNING, ERROR, CRITICAL.

4. In the Add-on Settings tab, set the API Url of the target server and the API Key. You can copy and paste the API URL and API Key, or both can be left empty for the customer to fill in.

• The API Url is the address of your N2W server.

• You can generate an API Key in N2W at User > Settings > API Access.

5. Select Save.

To configure data Inputs:

1. In the App menu, select Inputs .

2. In the Create New Input menu, select N2WS Dashboard information or N2WS Alerts .

3. Enter the relevant data input information:

   1. Name - Unique name of the input.

   2. Interval - Time interval for fetching the data from N2W in seconds. 300 is recommended.

   3. Index - The Splunk index (silo) to store the data in:
4. Select Update.

When finished, the Inputs should look like this:

To manage the Inputs, in the Actions column, select from the Action menu: Edit, Delete, Disable, or Clone.

To configure default data indexes:

1. Select Settings on the upper right corner and then select Indexes.

2. Verify that the following indexes exist under the N2W app. If not, select New Index to add indexes of the CPM information.