5.1 Crash-Consistent Backup

By default, snapshots taken using N2WS are Crash-consistent. When you back up an EC2 instance at a certain time, and later want to restore this instance from backup, it will start the same as a physical machine booting after a power outage. The file system and any other applications using EBS volumes were not prepared or even aware that a backup was taking place, so they may have been in the middle of an operation or transaction.

Being in the middle of a transaction implies that this backup will not be consistent, but this is not the case. Most modern applications that deal with important business data are built for robustness. A modern database, be it MySQL, PostgreSQL, Oracle, or SQL Server, has transaction logs. Transaction logs are kept separately from the data itself, and you can always play the logs to get to a specific consistent point in time. A database can start after a crash and use transaction logs to get to the most recent consistent state. NTFS in Windows and EXT3 in Linux have implemented journaling, which is not unlike transaction logs in databases.

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

N2WS Backup & Recovery (CPM), known as N2WS, is an enterprise-class backup, recovery, and disaster recovery solution for Amazon Web Services (AWS). Designed from the ground up to support AWS, N2WS uses cloud-native technologies (e.g., EBS snapshots) to provide unmatched backup and, more importantly, restore capabilities in AWS.

• N2WS also supports backup and recovery for Microsoft Azure Virtual Machines, SQL Servers, and Disks (section 26).

• N2WS also supports using Wasabi Cloud Object Storage for Amazon S3 backups (section 27).

N2WS is sold as a service. When you register to use the service, you get permission to launch a virtual Amazon Machine Image (AMI) of an EC2 instance. Once you launch the instance, and after a short configuration process, you can start backing up your data using N2WS.

Using N2WS, you can create backup policies, schedules, and import non-N2WS backups to Amazon Simple Storage Service (S3). Backup policies define what you want to back up (i.e., Backup Targets) as well as other parameters, such as:

• Frequency of backups

• Number of backup generations to maintain, duration of retention, and lock application

• Whether to copy the backup data to other AWS regions, etc.

• Whether to back up a resource immediately

Backup targets can be of several different types, for example:

• EC2 instances (including some or all instance’s EBS volumes)

• Independent EBS volumes (regardless of whether they are attached and to which instance)

• Amazon Relational Database Service (RDS) databases - regular and custom

• RDS Aurora clusters, including Aurora Serverless

• Redshift clusters

• DocumentDB

• DynamoDB tables

• Elastic File System (EFS)

• FSx File Systems - Lustre, NetApp ONTAP, Windows with managed Active Directory, OpenZFS

• S3 Sync to copy objects between S3 buckets

• For Azure policies, Virtual Machines (VM), SQL Servers, and Disks

In addition to backup targets, you also define backup parameters, such as:

• In Windows achieving application consistency using Microsoft Volume Shadow Copy Service (VSS)

• Running backup scripts

• Number of retries in case of a failure

Schedules are used to define how you want to time the backups. You can define the following:

• A start and end time for the schedule, including time zone of data

• Backup frequency, e.g. every 15 minutes, every 4 hours, every day, etc.

• Days of the week to run the policy

• Special times to disable the policy

A policy can have one or more schedules associated with it. A schedule can be associated with one or more policies. As soon as you have an active policy defined with a schedule, backups will start automatically.

N2WS provides monitoring at multiple levels. The Dashboard displays key performance indicators for backups, disaster recoveries, volume usage, backups to S3, and other metrics. Operation-specific monitors allow you to view details. And support for additional monitoring using Datadog and Splunk is available.

Following is a summary of the supported services for AWS and Azure backup targets:

AWS Main Backup Targets

AWS FSx Backup Targets with Exceptions, Services, and Options

Azure Backup Targets

1.1 Purchasing N2WS on the AWS Marketplace

N2WS is available in several different editions that support different usage tiers of the solution, e.g. number of protected instances, number of AWS, Azure, and Wasabi accounts supported, etc. The price for using the N2WS software is a fixed monthly price which varies between the different N2WS editions.

To see the different features for each edition, along with pricing and details, go to the N2W Software Web site. Once you subscribe to one of the N2WS editions, you can launch an N2WS Server instance and begin protecting your AWS environment. Only one N2WS Server per subscription will actually perform a backup. If you run additional instances, they will only perform recovery operations (section 1.3.4).

1.1.1 Moving between N2WS Editions

If you are already subscribed and using one N2WS edition and want to move to another that better fits your needs, you need to perform the following steps:

1. Terminate your existing N2WS instance. N2WS recommends that you do so while no backup is running.

2. Unsubscribe from your current N2WS edition. It is important since you will continue to be billed for that edition if you don’t cancel your subscription. You will only be able to unsubscribe if you don’t have any running instances of your old edition. You manage your subscriptions on the AWS Marketplace site on the Your Software page.

3. Subscribe to the new N2WS Edition and launch an instance. You need to launch the instance in the same Availability Zone (AZ) as the old one. If you want to launch your new N2WS Server in a different zone or region, you will need to create a snapshot of the data volume and either create the volume in another zone or copy the snapshot to another region and create the volume there.

4. During configuration, choose Use Existing Data Volume and select the existing data volume.

Once configuration completes, continue to work with your existing configuration with the new N2WS edition.

1.1.2 Downgrading

If you moved to a lower N2WS edition, you may find yourself in a situation where you exceed the resources your new edition allows. For example, you used N2WS Advanced Edition and you moved to N2WS Standard Edition, which allows fewer instances. N2WS will detect such a situation as a compliance issue, will cease to perform backups, display a message, and issue an alert detailing the problem.

To fix the problem:

• Move back to an N2WS edition that fits your current configuration, or

• Remove the excessive resources, e.g., remove users, AWS accounts, or instances from policies.

Once the resources are back in line with the current edition, N2WS will automatically resume normal operations.

1.2 N2WS Architecture

The N2WS Server is a Linux-based virtual appliance. It uses AWS APIs to access your AWS account. It allows managing snapshots of EBS volumes, RDS instances and clusters, Redshift clusters, DocumentDB, and DynamoDB tables. Except in cases where the user chooses to install our Thin Backup Agent for Windows Servers or use the AWS Simple System Manager (SSM) Remote Agent, N2WS does not directly access your instances. Access is performed by the agent, or by a script that the user provides, which performs application quiescence.

N2WS consists of the following parts, all of which reside on the N2WS virtual server:

• A database that holds your backup related metadata.

• A Web/Management server that manages metadata.

• A backup server that performs the backup operations. These components reside in the N2WS server.

The N2WS architecture is shown below. N2WS Server is an EC2 instance inside the cloud, but it also connects to the AWS infrastructure to manage the backup of other instances. N2WS does not need to communicate or interfere in any way with the operation of other instances. The only case where the N2WS server communicates directly with and has software installed on, an instance, is when backing up Windows Servers for customers who want to use Microsoft VSS for application quiescing.

• If you wish to have VSS or script support for application quiescence, you need to install the AWS SSM Agent or the N2WS Thin Backup Agent. The agent gets its configuration from the N2WS server, using the HTTPS protocol.

• The SSM Agent doesn't require any inbound ports to be opened. All communication from the agent is outbound from HTTPS to the SSM and EC2 Message endpoints in the region where your instances are registered.

1.3. N2WS Server Instance

The N2WS instance is an EBS-based instance with two EBS volumes. One is the root device, and the other is the CPM data volume. All persistent data and configuration information reside on the data volume. From N2WS’s perspective, the root device is dispensable. You can always terminate your N2WS instance and launch a new one, then using a short configuration process continue working with your existing data volume.

1.3.1 Root Volume

Although you have access to the N2WS Server instance via SSH, N2W Software expects the N2WS Server instance will be used as a virtual appliance. N2W Software expects you not to change the OS and not to start running additional products or services on the instance. If you do so and it affects N2WS, N2W Software will not be able to provide you with support. Our first requirement will be for you to launch a clean N2WS server.

1.3.2 Backing up the N2WS Server

N2WS server runs on an EBS-based instance. This means that you can stop and start it whenever you like. But if you create an image (AMI) of it and launch a new one with the system and data volume, you will find that the new server will not be fully functional. It will load and will allow you to perform recovery, but it will not continue performing backup as this is not the supported way to back up N2WS servers. What you need to do, is to back up only the data volume, launch a fresh N2WS server, and connect it to a recovered data volume. See section 11.4.3.

1.3.3 N2WS Server with HTTP Proxy

N2WS needs connectivity to AWS endpoints to be able to use AWS APIs. This requires Internet connectivity. If you need N2WS to connect to the Internet via an HTTP Proxy, that is fully supported. During configuration, you will be able to enable proxy use and enter all the required details and credentials: proxy address, port, user, and password. User and password are optional and can be left empty if the proxy server does not require authentication. Once you configure proxy settings at the configuration stage, they will also be set for use in the main application.

The proxy setting can be modified at any time in the Proxy tab of N2WS Server Settings > General Settings. Select or clear Enable Proxy. If enabled, enter the requested proxy information.

1.3.4 Multiple N2WS Servers

If you are trying to launch multiple N2WS servers of the same edition in the same account, you will find that from the second one on, no backup will be performed. Each such server will assume it is a temporary server for recovery purposes and will allow only recovery. Typically, one N2WS server should be enough to back up your entire EC2 environment. If you need more resources, you should upgrade to a higher edition of N2WS. If you do need to use more than one N2WS server in your account, contact N2W Software support.

1.4 N2WS Technology

As part of the cloud ecosystem, N2WS relies on web technology. The management interface through which you manage backup and recovery operations is web-based. The APIs which N2WS uses to communicate with AWS are web-based. All communication with the N2WS server is performed using the HTTPS protocol, which means it is all encrypted. This is important since sensitive data will be JavaScript communicated to/from the N2WS server, for example, AWS credentials, N2WS credentials, object IDs of your AWS objects (instances, volumes, databases, images, snapshot IDs, etc.).

1.5 Browser Support

Most interactions with the N2WS server are performed via a web browser.

• Since N2WS uses modern web technologies, you will need your browser to be enabled for JavaScript.

• N2WS supports Microsoft Chromium Edge, Mozilla Firefox, and Google Chrome.

• Other browsers are not supported.

1.6 Viewing Tutorial and Free Installation

If you want to view a getting-started tutorial, or to try the fully-functional N2WS free for 30 days, go to https://n2ws.com/support/video-tutorials/getting-started. Follow the instructions in the ‘Getting Started with N2WS Backup & Recovery for AWS’ video.

1.7 Customized Free Trial

It is now possible to have a free trial of N2WS with the usage limitations customized for your specific AWS infrastructure. Contact N2W Software sales to start your customized free trial. The N2W Software sales team may provide a reference code for your customized installation.

​1.8 Support for AWS Outposts

N2WS provides customers the ability to back up and recover on-premise workloads running on AWS Outposts as well as workloads on AWS. N2WS can run the core backup application on the AWS cloud and protect workloads running either on regions outside of AWS Outposts or protect applications that need to be backed up on AWS Outposts.

N2WS supports the following AWS services running on Outposts:

• EC2/EBS/RDS/SES/S3/VPC

• The services can be deployed in all AWS regions.

1.8.1 Deployment

N2WS is available on AWS Marketplace with different editions ready to support any size environment: https://aws.amazon.com/marketplace/search/results?x=29&y=9&searchTerms=n2ws

You can launch N2WS as an AMI directly from the AWS Marketplace or use a pre-configured CloudFormation (CF) template. Configuration takes a few minutes. Find our install videos here: https://n2ws.com/support/install-guide

For further information regarding the AWS Outposts service, go to https://console.aws.amazon.com/outposts/

1.8.2 Supported Use Cases

The prerequisite for support is complete installation of N2WS Backup & Recovery. Use cases are:

• Backup - N2WS can either back up applications, such as a media server, that run on AWS Outposts by storing the backup data on Outposts, as well as protect applications running outside of AWS Outposts by storing backup data in the same AWS region.

• Disaster Recovery (DR) - In the case of Disaster Recovery, N2WS protects resources running on AWS Outposts and copies data to another AWS Region or AWS account.

  • Another option is to use N2WS Backup & Recovery to back up resources running in a specific AWS region to Amazon Outposts.

  • DR failback reverses the workflow.

The following example is the CPMCONFIG time_zone parameter for Israel:

To obtain the list of time zones or to set the time zone:

1. SSH into the CPM instance using the logon cpmuser and the instance’s private key.

2. To obtain a list of all time zones, type: sudo cpm-set-timezone

3. To set the time zone, type: sudo cpm-set-timezone <new-time-zone>

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

Available only in Standard, Advanced, and Enterprise Editions, N2WS's cross-account functionality allows you to automatically copy snapshots between AWS accounts as part of the DR module. With cross-region DR, you can copy snapshots between regions as well as between accounts and any combination of both. In addition, you can recover resources (e.g., EC2 instances) to a different AWS account even if you did not copy the snapshots to that account. This cross-account functionality is important for security reasons.

The ability to copy snapshots between regions can prove crucial if your AWS credentials have been compromised and there is a risk of deletion of your production data as well as your snapshot data. N2WS utilizes the snapshot share option in AWS to enable copying them across accounts. Cross-account functionality is currently supported only for EC2 instances, EBS volumes, and RDS instances, including Aurora.

Cross-account functionality is enabled for encrypted EBS volumes and instances with encrypted EBS volumes and RDS databases.

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

• In addition, N2WS 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://support.n2ws.com/portal/kb/articles/cpm-supports-custom-encryption-keys-for-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.

N2WS 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 N2WS can have limited permissions that do not allow snapshot deletion.

N2WS 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 N2WS is licensed for cross-account functionality. See the pricing and registration page on our website to see which N2WS 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

N2WS 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, N2WS will clean up snapshots copied to other accounts as well. However, if you do not wish for N2WS 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, N2WS 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 N2WS.

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, N2WS 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 N2WS license, and even if you configured N2WS to 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. N2WS will utilize the AWS share snapshot option to enable recovering resources across accounts.

N2WS allows configuring remote and local agents from the UI. See section 6.1.2.

• The configuration in the text box needs to be in ‘INI’ format.

• According to the section header, N2WS will pass the key-value pairs to the appropriate agents.

• Each agent writes the set of key-value pairs it receives for a section to its configuration file and restarts to reload the configuration.

To configure agents:

1. Select Server Settings > Agents Configuration.

2. Write the configuration in the text box with the section header followed by its key-pair, as shown in the sample rules below.

3. Select Publish.

The following sample rules show how to configure relevant agents:

• Pass configuration to all remote agents of a given policy. The following will pass the key-value max_seconds_to_wait_for_vss=100 to all remote agents that belong to the policy by the name ‘p1’:

[policy__p1]
max_seconds_to_wait_for_vss=100

• Pass configuration to a specific remote agent. The following will pass the key-value max_seconds_to_wait_for_vss=100 to the remote agent whose AWS instance ID is ‘agent_id ‘:

[agent__agent_id]
max_seconds_to_wait_for_vss=100

• Pass configuration to all remote agents. The following will pass the key-value max_seconds_to_wait_for_policy=600 to all remote agents:

[all_remote_agents]
max_seconds_to_wait_for_policy=600

• Pass configuration to a local agent. The following will pass the key-value max_seconds_to_wait_for_policy=600 to the local agent:

[local_agent]
max_seconds_to_wait_for_policy=600

One or more instances of all of the above can be pasted together to the text box in the Agent Configuration screen. On Publish, N2WS iterates over all sections and passes the relevant configuration to each agent.

The N2WS server comes with a default self-signed HTTPS certificate that will show as ‘Not Secure’ in the browser. You can secure the certificate and reach the UI by either:

• Selecting the Advanced button in the ‘Your connection is not private” message, or

• Adding an exception to the browser. See the Appendix B screenshot in the N2WS Quick Start Guide at

If you purchased an HTTPS certificate from a certificate authority, you can replace the default certificate with the new one as follows:

1. Connect to the N2WS instance over SSH.

2. Use ‘sudo’ to reach the certificate folder, keeping the ownership and permissions of the files (‘cp’).

3. Go to /opt/n2wsoftware/cert

4. In the folder, replace cpm_server.crt and cpm_server.key with new files having the same names.

5. If you are using MobaXterm, you can drag/drop files to the SSH session, and then copy the files to the correct folder.

6. After replacing the files, restart Apache: sudo service apache2 restart

For full details, see:

To test the certificate before deploying to production:

The user can launch a new N2WS trial instance to see if the new certificate works there.

If there are any issues, you can restore/recreate the original default certificate as follows:

1. Connect to the N2WS instance over SSH using a tool such as PuTTY or MobaXterm.

2. Use ‘sudo’ to reach the certificate folder, keeping the ownership and permissions of the files: sudo su

3. Go to /opt/n2wsoftware/cert:

4. Move the existing .crt and .key files to a new name:

5. Stop/Start the instance.

For full details, see:

Wasabi Storage is an independent third-party provider of storage account services. Wasabi storage is compatible with Amazon S3 object storage and is available for use through N2WS. Storing snapshots with Wasabi instead of S3 allows customers to save on their long-term storage costs.

A Wasabi repository is based on a bucket in the Wasabi system. Wasabi repositories can be used to store snapshots for both AWS and Azure policies. You can cross-cloud backups by going from N2WS on AWS to Wasabi or from N2WS on Azure to Wasabi.

27.1 Adding a Wasabi Account to N2WS

Authentication to Wasabi using user-specified credentials is required first for N2WS to access a Wasabi bucket.

• Create a Wasabi account in N2WS with the required credentials.

• Create a Wasabi repository in any bucket accessible to the specified account. See section ‎.

To create a Wasabi account:

1. Log on to N2WS using the root username and password used during the N2WS configuration.

2. Select the Accounts tab.

3. In the New menu, select Wasabi Account..

4. Complete the New Account screen using the App registration view information.

   1. Name – Name for this N2WS account.

   2. User – The N2WS user that this account belongs to. See section .

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

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

27.2 The Wasabi Repository

Wasabi repositories are where backups of SQL servers are stored. Wasabi repositories can also be used to store disk snapshots via a Lifecycle policy or serve as cross-cloud storage for AWS volume snapshots via a Lifecycle policy. For further details, see section

27.2.1 Configuring a Wasabi Repository

To configure a Wasabi Repository:

1. In N2WS, select the Storage Repositories tab.

2. In the New menu, select Wasabi Storage Repository.

3. In the Storage Repository screen, complete the following fields, and then select Save.

   1. Name - Type a unique name for the new repository, which will also be used as a folder name in the Wasabi Repository container. Only alphanumeric characters and the underscore are allowed.

   2. Description - Optional brief description of the contents of the repository.

   3. User – Select the user in the list.

   4. Account - Select the account that has access to the repository.

   5. Wasabi S3 Bucket Name – Select the name of the S3 bucket from the list.

27.2.2 Deleting a Wasabi Repository

You can delete all snapshots copied to a specific Wasabi repository.

To delete a Wasabi repository:

1. Select the Storage Repositories tab.

2. Select the repository to delete.

3. Select Delete, and confirm.

27.3 Recovering from a Wasabi Repository

1. In the Backup Monitor, select the Cloud button for Wasabi .

2. To minimize the top bars, select the up arrow in the top right corner. To open the filters dialog box, select the filter icon ( ).

1. Filter as necessary by type of target, policies, users, accounts, backup status, and freezer status.

4. Select a backup, and then select Recover. The Recover screen opens. For backups with multiple resource types as targets, the Recover screen will have a separate tab for each type.

5. Follow the recovery instructions for the resource type as described in section .

The reset method depends on whether you have SSH access to the N2WS instance and what is your version of N2WS:

• If you have SSH access to the N2WS instance and are running version 4.2 and above, see section .

• If you do not have SSH access to the instance or are running an older version, see section .

F.1 Resetting Root Password if SSH and Version 4.2 or Later

N2WS Login Reset Utility n2ws-reset-login:

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

1. Connect to N2WS 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 resent the password or MFA, type ‘n2s-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 N2WS User Guide at .

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:

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

1. Follow the upgrade procedure in the N2WS User Guide at .

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

3. If you typed the wrong root username, N2WS 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 N2WS 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

N2W Software customers have a single point of control and management over the procedure of backing up their cloud-based services and data stores. Monitoring the costs will help customers define backup plans that fit their budget and thereby avoid unexpected costs. N2WS provides the following services for monitoring costs:

• Cost Explorer – Cost of storage that was created by N2WS to hold short-term backup snapshots of the customer’s cloud-based assets.

  • Allows customers to monitor the costs by the backup processes generated by N2WS.

  • Allows customers to issue monthly bills per policy backups.

  • Calculations are made for the last month by default and can be set to prior periods.

  • Breakdown of costs is found in the Costs ($) column of the Policies tab.

• Cost Savings – Amount of money that users can save by enabling Resource Control management.

  • Calculations are made for the next month.

  • Breakdown of savings is found in the Cost Savings column of the Resource Control Groups tab.

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 N2WS:

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

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

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

Making an application-consistent backup of Linux instances does not require any agent installation. Since the N2WS server is Linux based, backup scripts will run on it. Typically, such a script would use SSH to connect to the backed-up instance and perform application quiescence. However, this can also be accomplished using custom client software.

There is no parallel to VSS in Linux, so the only method available is by running backup scripts.

7.1 Connecting to the N2WS Server

To create, test, and install backup scripts, you will need to connect to the N2WS server using SSH with cpmuser. The only way to authenticate cpmuser is by using the private key from the key pair you used when you launched the N2WS server instance. If your key is not compromised, no unauthorized person will be able to connect to the N2WS server.

With cpmuser, you will be able to copy (using secure copy), create, and test your scripts. cpmuser is the same user N2WS will use to run the scripts. If you need to edit your scripts on the N2WS Server, you can use Vim or nano editors. Nano is simpler to use.

7.2 Backup Scripts

Backup scripts should be placed in the path /cpmdata/scripts. If the policy belongs to an N2WS user other than the root user, scripts will be in a subfolder named like the user (e.g., /cpmdata/scripts/cpm_user1). This path resides on the CPM data volume and will remain there even if you terminate the N2WS server instance and wish to launch a new one. Backup scripts will remain on the data volume, together with all other configuration data. As cpmuser, you have read, write, and execute permissions in this folder.

• All scripts should exit with the code zero 0 when they succeed and one 1 (or another non-zero code) when they fail.

• All scripts have a base name (detailed for each script in the coming sections) and may have any addition after the base name. The delimiter between the base part of the name and the file extension is a period (.). For example,before_policy1.v11.5.bashwhere ‘before_policy1’ is the base name, ‘v11.5’ is the optional additional part of the name, and ‘bash’ is the file extension.

• Scripts can be written in any programming language: shell scripts, Perl, Python, or even binary executables.

• You must make sure the scripts can be executed and have the correct permissions.

There are three scripts for each policy:

• Before

• After

• Complete

7.2.1 Before Script

The before_<policy-name>[.optional_addition].<ext> script runs before backup begins. Typically, this script is used to move applications to backup mode. The before script typically leaves the system in a frozen state for a short time until the snapshots of the policy are fired. One option is to issue a freeze command to a file system like XFS.

7.2.2 After Script

The after_<policy-name>[.optional_addition].<ext> script runs after all the snapshots of the policy fire. It runs within a few seconds after the before script. This script releases anything that may have been frozen or locked by the before script. This script accepts the success status of the before script. If the before script succeeded, the argument will be one 1. If it failed, crashed, or timed out, the argument will be zero 0.

7.2.3 Complete Script

The complete_<policy-name>[.optional_addition].<ext> script runs after all snapshots are completed. Usually, it runs quickly since snapshots are incremental. This script can perform cleanup after the backup is complete and is typically used for transaction log truncation. The script accepts one argument. If the entire backup was successful and all the previous scripts were successful, it will be one 1. If any issues or failures happened, it will be zero 0. If this argument is one 1, truncate logs.

7.2.4 Capturing the Output of Backup Scripts

You can have the output of backup scripts collected and saved in the N2WS Server, see section 4.2.4.

7.2.5 Troubleshooting and Debugging Backup Scripts

You can use the output collected by N2WS to debug backup scripts. However, the recommended way is to run them independently of N2WS, on the N2WS Server machine using SSH. You can then view their outputs and fix what is needed. Once the scripts work correctly, you can start using them with N2WS. Assuming these scripts are using SSH, during the first execution you will need to approve the SSH key by answering yes at the command line prompt. If you terminate your N2WS Server and start a new one, you will need to run the scripts again from the command line and approve the SSH key.

7.2.6 Example Backup Scripts

Following is an example of a set of backup scripts that use SSH to connect to another instance and freeze a MySQL Database:

• The before script will flush and freeze the database.

• The after script will release it.

• The complete script will truncate binary logs older than the backup.

The scripts are written in Bash:

before_MyPolicy.bash

#!/bin/bash
ssh -i /cpmdata/scripts/mysshkey.pem sshuser@ec2-host_name.compute-1.amazonaws.com "mysql -u root –p<MySQL root password> -e 'flush tables with read lock; flush logs;'
if [$? -gt 0[; then
 echo "Failed running mysql freeze" 1>&2
 exit 1
else
 echo "mysql freeze succeeded" 1>&2
fi

This script connects to another instance using SSH and then runs a MySQL command. Another approach would be to use a MySQL client on the N2WS Server, and then the SSH connection will not be necessary.

After that script is executed, the N2WS server will start the snapshots, and then call the next script:

after_MyPolicy.bash

#!/bin/bash
if [ $1 -eq 0 ]; then
 echo "There was an issue running first script" 1>&2
fi
ssh -i /cpmdata/scripts/mysshkey.pem sshuser@ec2-host_name.compute-1.amazonaws.com "date +'%F %H:%M:%S' > sql_backup_time; mysql -u root -p<MySQL root password> -e 'unlock tables;'"
if [ $? -gt 0 ]; then
 echo "Failed running mysql unfreeze" 1>&2
 exit 1
else
 echo "mysql unfreeze succeeded" 1>&2
fi

This script checks the status in the first argument and then does two things:

• First, it saves an exact timestamp of the current backup of the frozen database to a file,

• Then, it releases the lock on the MySQL table.

After that, when all snapshots succeed, N2WS runs the complete script:

complete_MyPolicy.bash

#!/bin/bash
if [ $1 -eq 1]; then
 cat /cpmdata/scripts/complete_sql_inner |ssh -i /cpmdata/scripts/mysshkey.pem sshuser@ec2-host_name.compute-1.amazonaws.com "cat > /tmp/complete_ssh; chmod 755 /tmp/complete_ssh; /tmp/complete_ssh"
 if [ $? -gt 0 ]; then
 echo "Failed running mysql truncate logs" 1>&2
 exit 1
 else
 echo "mysql truncate logs succeeded" 1>&2
 fi
else
 echo "There was an issue during backup - not truncating logs" 1>&2
fi

It calls an inner script, complete_sql_inner:

butime='<sql_backup_time'>
mysql -u root -p<MySQL root password> -e 'PURGE BINARY LOGS BEFORE "'"$butime"'"  

These two scripts purge the binary logs only if the complete script receives one 1 as the argument. They purge logs earlier than the time in the timestamp files.

7.2.7 Scripts and SSH Access in a Multi-user Environment

If your N2WS configuration requires multiple users, which are separated from each other, you may wish to allow users to access N2WS using SSH to create and debug backup scripts:

• Create additional Linux users in the N2WS instance and allowing each user access to their own scripts folder only.

• cpmuser will need to be able to access and execute the scripts of all users. This can be achieved by assigning the user cpmuser as the group of all user subfolders and scripts. Then, if given executable permissions for the group, cpmuser will be able to access and execute all scripts.

7.3 Using SSM Agent for Linux Backups

Some differences between the ‘old backup scripts’ and the new SSM scripts:

• SSM scripts are per instance and run on the instance, which can give better granularity and don’t require SSH.

• The old local scripts are per policy and can be good for a centralized approach or operations that function across instances.

• The old local scripts require the use of SSH for connectivity, thereby requiring connectivity between the CPM and the target.

• SSM, however, requires a setup that includes putting an IAM role on your instance, which you may not want to do.

To use SSM for Linux backups:

1. Install an SSM Agent on the target machine. Some Linux AMI, such as AWS Linux AMI, come with SSM already installed. To install an agent, see https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html

2. An IAM role with the core SSM policy (AmazonSSMManagedInstanceCore) attached to an instance should be sufficient for using the agent. To attach an IAM instance profile to an EC2 instance, see Next8 Using Elastic File System (EFS)

3. Similar to using normal backup scripts, as mentioned in section 7.2, create before/after/complete scripts.

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

The process to configure N2WS to work with CloudFormation is a single stream that starts with subscribing to N2WS on the Amazon Marketplace and ends with configuring the N2WS server.

• N2WS provides several editions, all of which support CloudFormation.

• An IAM role will automatically be created with minimal permissions and assigned to the N2WS instance.

1. Go to https://aws.amazon.com/marketplace

2. Search for N2WS.

3. Select CPM Edition to install:

• Free Trial & BYOL

• Advanced

• Free

• Standard

• Enterprise

4. Select Continue to Subscribe. Log in and select Accept Terms.

5. Select Continue to Configuration.

6. In the Fulfillment Option drop-down list, select CloudFormation Template. Select the relevant Software Version and Region and then select Continue to Launch.

7. In the Launch this software page, select Launch CloudFormation in the Choose Action list and then select Launch.

The Create stack/Specify template page opens.

8. Under Prepare template, select Template is ready.

9. Under Template source, choose Amazon S3 URL. Select the default Amazon S3 URL and then select Next. The Specify stack details page opens.

10. Complete the Stack name and Parameters sections. For Inbound Access CIDR, security groups act as a firewall for associated instances, controlling both inbound and outbound traffic at the instance level. Configuring Inbound Access CIDR allows you to add rules to a security group that enable you to connect to your Linux instance from your IP address using SSH:

• If your IPv4 address is 203.0.113.25, specify 203.0.113.25/32 to list this single IPv4 address in CIDR notation. If your company allocates addresses within a range, specify the entire range, such as 203.0.113.0/24.

• 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​

11. Select Next. The Configure stack options page opens.

12. Complete the stack options and select Next. The Review page opens.

13. Select I acknowledge that AWS CloudFormation might create IAM resources, and then select Create stack. The CloudFormation Stacks page opens.

14. Select the new stack. The Instances page opens.

15. Select the instance. Copy the Instance ID value shown in the Description tab and select Launch Instance. The N2WS Server Configuration page opens.

16. Continue configuring N2WS as in section 2.

Configuring EFS on N2WS allows you to determine backup:

• Schedule and frequency

• Retention

• Lifecycle policy, including moving backups to cold storage, defining expiration options, and deleting them at end of life.

• Whether to use AWS Backup Vault Lock. See section 8.4.

With AWS Backup, you pay only for the backup storage you use and the amount of backup data you restore in the month. There is no minimum fee and there are no set-up charges.

8.1 Configuring EFS

1. In the AWS Console, create the EFS in one of the available regions. See section 8 for regions not supported for EFS.

2. In N2WS, in the Backup Targets tab of a Policy, select Elastic File Systems in the Add Backup Targets menu.

3. In the Add Elastic File System screen list, select one or more EFS targets and then select Add selected.

4. In the Backup Targets tab, select an EFS target and then select Configure.

5. Configure the EFS backup and restore options described in section 8.1.1.

6. When finished, select Apply.

7. Select Save in the Backup Targets screen to save the configuration to the policy.

8.1.1 EFS Backup and Restore Options

• Backup Vault – A logical backup container for your recovery points (your EFS snapshots) that allows you to organize your backups.

• IAM Role – An IAM identity that has specific permissions for all supported AWS backup services. The following AWS backup permissions should be attached to your IAM role:

  • AWSBackupServiceRolePolicyForBackup - Create backups on your behalf across AWS services.

  • AWSBackupServiceRolePolicyForRestores - Perform restores on your behalf across AWS services.

  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 EFS policy configuration.

• Transition to cold storage– Select the transition lifecycle of a recovery point (your EFS snapshots). The default is Never.

• Expire – When does a protected resource expire. The default is Policy Generations.

8.2 Creating IAM Roles in AWS

A default or custom IAM role is necessary for AWS to perform EFS operations on behalf of N2WS.

To create a default IAM Role:

1. Go to the AWS Backup Service: https://us-east-1.console.aws.amazon.com/backup/

2. Select Create an on-demand backup.

3. For Resource type, select EBS.

4. For Volume ID, select any EBS volume to backup.

5. Select Default IAM Role.

6. Select Create on-demand backup. Ignore the error provided by AWS.

7. Verify that the following role was created on AWS IAM Service:

To create a custom IAM Role:

1. Go to AWS IAM Service: https://console.aws.amazon.com/iam/home#/roles

2. Select Create role.

3. Select AWS Backup and then select Next: Permissions.

4. Search for BackupService.

5. Select the following AWS managed policies:

   1. AWSBackupServiceRolePolicyForBackup

   2. AWSBackupServiceRolePolicyForRestores

6. Select Next: Tags and then select Next: Review.

7. Enter a Role name and select Create role.

8.3 Backup Options for EFS Instances

EFS can be configured by creating the cpm backup or cpm_backup tag. In this case, N2WS will override the EFS configuration with the tag values. See section 14.1.4 for keys and values.

8.4 Support for AWS Backup Vault Lock

For complete details on using AWS Backup Vault Lock for EFS, see https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html

• The lock is created using an AWS API, not the AWS console.

• N2WS supports AWS Backup Vault Lock by setting the expiration time on an EFS target.

• N2WS cleanup will work correctly.

• User-initiated deletions of a backup, such as delete a specific recovery point, delete all backup record and policy snapshots, will fail.

To configure N2WS to support AWS Backup Vault Lock:

In the EFS Policy Configuration screen, select the Expire time on the EFS target. When selecting the Expire time, consider that AWS may have a vault lock on the backup.

A.1 Considerations When Configuring Copy to S3

A.1.1 Choosing a Storage Type

When creating a policy with the S3 option enabled, N2WS 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 N2WS 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 N2WS.

7. Grant Full Access.

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

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

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 N2WS, 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

N2WS Backup & Recovery Instance is now supporting the monitoring of backups, DR, copy to S3, alerts, and more by Datadog. Datadog is a monitoring service for cloud-scale applications, providing monitoring of servers, databases, tools, and services, through a SaaS-based data analytics platform. Datadog will allow CPM users to monitor and analyze the N2WS Backup & Recovery Dashboard metrics.

D.1 Activating Datadog and Monitoring N2WS

Use the following procedure to activate Datadog. Ready-made dashboards for monitoring are included.

To activate the service and to monitor your N2WS instance:

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

   b. Search for ‘Python’ and install it:

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

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

[external_monitoring]
enabled=True

d. Run service apache2 restart.

4. Install Datadog Agent on N2WS Instance. a. Login to Datadog and go to Integrations > Agent > Ubuntu:

b. Copy the Agent ‘Use our easy one-step install’ command line.

c. Connect to your N2WS Backup & Recovery Instance with SSH Client, type sudo su and run the agent Install command. d. 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 N2WS 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 N2WS instance. All N2WS user data begins with cpm:user: followed by <user-name>.

6. Configure your Datadog dashboard by using the N2WS 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 'N2WSBackup&Recovery-<dashboard_name[-version]>'. When dashboards are added for a new N2WS 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 N2WS Alerts on Datadog Events. a. Log in to Datadog and go to Events. b. View your instance alerts:

D.2 Monitoring N2WS with Web Proxy

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

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

cd /etc/datadog-agent

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

https: "http://your-proxy-IP:your-proxy-port"    
http: "http://your-proxy-IP:your-proxy-port"

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

Example:

proxy:
http://54.159.14.45:3128
http://54.159.145.45:3128

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

When N2WS copies data to or restores data from a Storage Repository, or Explorint snapshots, it launches a temporary ‘worker’ instance to perform the actual work, such as writing objects into the repository or exploring snapshots.‌

• When performing backup operations, or Exploring snapshots, the ‘worker’ instance is launched in the region and account of the target instance. The backup or Explore ‘worker’ instance is configured in the Worker Configuration tab.

• When performing restore operations, the ‘worker’ instance is launched in the region and account that the backed-up instances are to be restored to. The restore ‘worker’ instance is selected or configured according to the following criteria:

  • If a ‘worker’ for the target account/region combination was configured in the Worker Configuration screen, that ‘worker’ instance will be used during the restore or the Explore.

  • If such a ‘worker’ does not exist for the target account/region combination, N2WS will attempt to launch one based on N2WS’s own configuration.

  • If the N2WS configuration cannot be used because the restore, or Explore, will be to a different account or region than N2WS's, the user will be prompted during the restore to configure the ‘worker’.

• You can add tags to a worker for subsequent tracking in the AWS Cost Explorer.

  • To activate Cost Explorer in N2WS and AWS, see section 25.1.

  • To add worker tags, see section 22.2.

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 N2WS 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 N2WS server and to the S3 endpoint.

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

   1. When performing a recovery, if you choose ‘Any’ in the Subnet drop-down list, N2WS 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 not in the same Availability Zone as the one you are restoring to, you will have to choose a different subnet from the Subnet drop-down list in the Worker Configuration tab of the Recovery screen.

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, N2WS 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 N2WS 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 N2WS server and other communication targets. Depending on the test, some, but not all, AWS permissions are also checked.‌

• Connectivity to N2WS Server (default)

• SSH Test - Connectivity to N2WS 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.​

NEWS supports file-level recovery. N2WS performs a backup on the volume and instance level and specializes in the instant recovery of volumes and complete instances. However, in many cases, a user may want to access specific files and folders rather than recovering an entire volume.

N2WS also provides the ability to locate the same item across a chain of consecutive snapshots during a single recovery session.

In previous versions of N2WS, you could recover a volume, attach it to an instance, mount it, and then access the data from within that instance. After completing the restore, assuming the volume is no longer needed, the user needed to unmount, detach, and delete the volume. N2WS now automates this entire process.

In the Backup Monitor, select a backup and then select Recover. In the Recover screen, select an instance or an independent volume, and then select Explore Volumes. For an instance, you can also select Recover Volumes Only, select the required volume, and then select Explore Volumes.

If there is more than 1 backup available to view, the File Level Recovery dialog opens showing the number of backups.

1. To view an instance across a chain of snapshots, select the number of backups to view.

2. To view the latest backup only, leave the value at the default of 1.

3. Select Start Session.

N2WS will open the Initializing File Level Recovery message.

Select Open Session for an Explorer-like view of the entire instance or a specific volume, folder, or files. Loading the session may take a few minutes. If the Initializing File Level Recovery message closes before you can select Open Session, in the left pane, select the File Level Recovery Sessions tab, select the active session, and then select Explore.

You will be able to browse, search for files, and download files and folders. Use the left and right arrows in the left corner to move between folders.

Select any file or folder and then select Download. Folders are downloaded as uncompressed zip files.

File-level recovery requires N2WS to recover volumes in the background and attach them to a ‘worker’ launched for the operation. The worker will be launched in the same account and region as the snapshots being explored, using a pre-defined worker configuration. See section 22 to configure a ‘worker’ instance in the region that the snapshots exist.

After you complete the recovery operation, select Close for all the resources to be cleaned up and to save costs. Even if you just close the tab, N2WS will detect the redundant resources and clean them up, but N2WS recommends that you use Close. Sessions can be closed from the File Level Recovery Sessions tab also.

13.1 Limitations

13.2 File Level Recovery from Snapshots in a Storage Repository

1. In the Backup Monitor, select a backup Stored in Storage repository, and then select Recover. The Recover screen opens.

2. In the Recover From drop-down list, select Storage Repository. If the original EBS snapshots of the selected backup were already deleted, Storage Repository will be the only option, and the drop-down list will be disabled.

3. In the Recover screen, select an instance or an independent volume, and then select Explore Volumes. For an instance, you can also select Recover Volumes Only. Select the required volume, and then select Explore Volumes.

4. In the Initializing File Level Recovery message, select Open Session. Loading the session may take a few seconds. If the Initializing File Level Recovery message closes before you can select Open Session, in the left pane, select the File Level Recovery Sessions tab, select the active session, and then select Explore.

5. In the File Level Recovery Session window, navigate to the desired folder. See section 13.

6. Select the folders or snapshots to recover and select Download.

7. To close an active session, in the File Level Recovery Sessions tab, select the active session and then select Close.

13.3 File-Level Recovery from EFS

You can restore up to 5 items in your EFS to the directory in the source file system.

To restore EFS at the item level:

1. In the Backup Monitor, select a snapshot, and then select Recover.

2. In the EFS Restore Type column, select File/Directory Restore.

3. The default Preserve Tags action during recovery is Preserve Original for the volumes associated with the virtual machine. To manage tags, see section ‎‎10.3.

4. At the left, select the right arrow (>) to open the item recovery path input box.

5. In the Paths for Files/Directories to Recover box, enter a forward slash (/) and the name of the path. See further limitations on the pathname in the Warning box below.

6. Select New to add up to 5 recovery paths.

Security is one of the main issues and barriers in decisions regarding moving business applications and data to the cloud. The basic question is whether the cloud is as secure as keeping your critical applications and data in your own data center. There is probably no one simple answer to this question, as it depends on many factors.

Prominent cloud service providers like Amazon Web Services, are investing a huge number of resources so people and organizations can answer ‘yes’ to the question in the previous paragraph. AWS has introduced many features to enhance the security of its cloud. Examples are elaborate authentication and authorization schemes, secure APIs, security groups, IAM, Virtual Private Cloud (VPC), and more.

N2WS strives to be as secure as the cloud it is in. It has many features that provide you with a secure solution.

16.1 N2WS Server

N2WS Server’s security features are:

• Since you are the one who launches the N2WS server instance, it belongs to your AWS account. It is protected by security groups you control and define. It can also run in a VPC.

• All the metadata N2WS stores are stored in an EBS volume belonging to your AWS account. It can only be created, deleted, attached, or detached from within your account.

• You can only communicate with the N2WS server using HTTPS or SSH, both secure protocols, which means that all communication to and from N2WS is encrypted. Also, when connecting to AWS endpoints, N2WS will verify that the SSL server-side certificates are valid.

• Every N2WS has a unique self-signed SSL certificate. It is also possible to use your own SSL certificate.

• AWS account secret keys are saved in an encrypted format in N2WS’s database.

• N2WS supports using different AWS credentials for backup and recovery.

• N2WS Server supports IAM Roles. If the N2WS Server instance is assigned an adequate IAM role at launch time, you can use cross-account IAM roles to “assume” roles from the main IAM role of the N2WS instance account to all the other AWS accounts you manage and not type AWS credentials at all.

• To manage N2WS, you need to authenticate using a username and password.

• N2WS allows creating multiple users to separately manage the backup of different AWS accounts, except in the Free Edition.

16.2 Best Security Practices for N2WS

Implementing all or some of the following best practices depends on your company’s needs and regulations. Some of the practices may make the day-to-day work with N2WS a bit cumbersome, so it is your decision whether to implement them or not.

16.2.1 Avoid using AWS Credentials

By using the N2WS Server instance IAM role and cross-account IAM role, you can manage multiple AWS accounts without using AWS credentials (access and secret keys) at all. This is the most secure way to manage multiple AWS accounts and the one recommended by AWS.

16.2.2 Credential Rotation

Assuming you have to use AWS credentials, you should follow AWS practices. N2WS recommends that you rotate account credentials from time to time. ​

After changing credentials in AWS, you need to update them in N2WS. Select on the account name in the Accounts management screen and modify the access and secret keys.

16.2.3 Passwords Rules and Expiration

To improve user security and align with current password practices, the N2WS root user can enforce password rules and password expiration. Both are optional and can be enabled or disabled through Security settings.

• Password settings allow the root user to enforce password rules on all N2WS users (including the root user himself), to define the period for password expiration, and to enforce password expiration.

• The default is to enable password rules and password expiration for 6 months.

• Default password rules and expiration settings can be disabled by clearing their respective Enable/Enforce check boxes.

• Password settings are enforced throughout N2WS.

To set password rules, expiration, and history limit:

1. In Server Settings in the top right toolbar, select General Settings, and then select the Security & Password tab.

2. In the Password Settings section, if you want to disable the default enforcement of the password roles, clear the Enable user password rules check box.

3. If you didn’t disable the default password rules, change the various default rule options as necessary:

   1. Password must contain certain characters.

   2. Set minimum password length. Default is 8.

   3. Limit common passwords. Passwords are matched against a list of 20,000 common passwords.

   4. Restrict numeric-only passwords.

4. If you want to disable the default enforcement of password expiration and history, clear the Enforce password expiration and history check box.

5. If you didn’t disable the default enforcement of the password expiration and history, change the various default expiration and history options as necessary:

   1. Password expiration in terms of duration.

   2. Limit of number of passwords to be included in history. Default is 3, maximum is 10.

Password Enforcement

Password rules are enforced throughout all N2WS functions and features:

• Configuration Wizard

• User/Delegate creation

• Reset Password (by root user)

• Change Password (by the user itself)

In the following example, a user attempted to change their password to ‘1234’, which breaks all password rules:

Password Expiration

When the password expires, the user will see the following message after login. The user will then be transferred to a password change page.

16.2.4 Automatic Logout

Setting an automatic logout is another security best practice. Setting a Login Session Expiration value handles automatic logout from N2WS Backup & Recovery.

To set the time for automatic logout:

1. In Server Settings in the top right toolbar, select General Settings tab, and then select the Security & Password tab.

2. In the Login Session Expiration section, select the time after which the user is to be logged out.

The default logout is after 12 hours of mouse and keyboard being idle. The minimum expiration time is 3 minutes.

16.2.5 Security Groups

Since the N2WS server is an instance in your account, you can define and configure its security groups. Even though N2WS is a secure product, you can block access from unauthorized addresses:

• You need HTTPS access (original 443 port or your customized port) from:

  • Any machine which will need to open the management application

  • Machines that have N2WS Thin Backup Agent installed on them. See section 6.1.

• You will also need to allow SSH access to create and maintain backup scripts.

• Blocking anyone else will make N2WS server invisible to the world and therefore completely bullet-proof.

Learn more about AWS Security Groups and settings at https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

16.3 Using IAM

N2WS keeps your AWS credentials safe. However, it is preferable to use IAM roles and not use credentials at all. Additionally, N2WS will not accept root user credentials. To minimize risk, try:

• To provide credentials that are potentially less dangerous if they are compromised, or

• To set IAM roles, which will save you the need of typing in credentials at all.

You can create IAM users/roles and use them in N2WS to:

1. Create a user/role using IAM.

2. Attach a user policy to it.

3. Use the policy generator to give the user custom permissions.

An IAM role can also be used in the N2WS Server (for the account the N2WS Server was launched in) and for instances running N2WS Agent to perform the configuration stage as well as normal operations by combining some of the policies. You can attach more than one IAM policy to any IAM user or role.

The permissions that the IAM policy must have depend on what you want to policy to do. For more information about IAM, see IAM documentation: http://aws.amazon.com/documentation/iam/​

16.3.1 N2WS Server Configuration Process

AWS credentials in the N2WS configuration process are only used for configuring the new server. However, if you want to use IAM credentials for the N2WS configuration process, or to use the IAM role associated with the N2WS Server instance, its IAM policy should enable N2WS to:

• View volumes instances, tags, and security groups

• Create EBS volumes

• Attach EBS volumes to instances

• Create tags

Generally, if you want to use IAM role with the N2WS Server instance, you will need the following policy and the policies for N2WS Server’s normal operations, as described in section 16.3.2.

Minimal IAM Policy for N2WS Configuration:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupEgress",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeInstanceAttribute",
        "ec2:DescribeInstanceStatus",
        "ec2:DescribeInstances",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeTags",
        "ec2:DescribeVolumeAttribute",
        "ec2:DescribeVolumeStatus",
       "ec2:DescribeVolumes"
     ],
     "Sid": "Stmt1374233119000",
     "Resource": [
       "*"
     ],
     "Effect": "Allow"
    }
  ]
}

16.3.2 N2WS Server IAM Settings

You can use the N2WS Server’s IAM role to manage backups of the same AWS account. If you manage multiple AWS accounts, you will still either need to create cross-account roles or enter the credentials for other accounts. If you want to use an IAM user for an account managed by N2WS Server (or the IAM role), you need to decide whether you want to support backup only or recovery as well. There is a substantial difference:

• For backup, you only need to manipulate snapshots.

• For recovery, you will need to create volumes, create instances, and create RDS databases. Plus, you will need to attach and detach volumes and even delete volumes. If your credentials fall into the wrong hands, recovery credentials can be more harmful.

• If you use a backup-only IAM user or role, then you will need to enter ad hoc credentials when you perform a recovery operation.

• Generally, if you want to use the IAM role with the N2WS Server instance, you will need a certain policy, or policies, for N2WS Server’s normal operations. For details, see the N2W Software Knowledge Base article on minimal IAM policies at https://n2ws.zendesk.com/hc/en-us/sections/28832824787741-IAM-permission-files

You can check on the permissions required for AWS services and resources, such as backup, RDS, and DynamoDB, and compare them to the policies which cover the requirements.

In the Accounts tab, select an account and then select Check AWS Permissions. To expand a line, select its down arrow .

• To download a CVS report, select Permissions Check Report.

• To download a JSON file, select AWS Permissions Summary.

16.3.3 Configure N2WS’s IAM Role with CloudFormation

CloudFormation is an AWS service that allows you to treat a collection of AWS resources as one logical unit. CloudFormation provides a common language for you to describe and provision all the infrastructure resources in your cloud environment, across all regions and accounts in an automated and secure manner.

The IAM role will automatically contain the required permissions for N2WS operations. See section 20.

N2WS Backup & Recovery Instance is now supporting the monitoring of backups, DR, copy to S3, alerts, and more by Splunk. The N2WS add-on features:

• Ability to define data input from N2WS via a Technology Add-on (TA)

• Ability to monitor resources and instances

• An N2WS app with 2 dashboards for displaying operational insights:

  • N2WS activity monitor - Information about the data

  • N2WS 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 N2WS.

E.1 Configure N2WS Server for Splunk

To configure the N2WS Server:

1. Edit the N2WS configuration file as follows:

>> su cpmuser
>> vi /cpmdata/conf/cpmserver.cfg
[external_monitoring]
enabled=True

​ 2. Restart apache:

>> sudo service apache2 restart

3. To check the status of the Splunk integration, in N2WS, 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 N2WS 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 N2WS

Two configurations are required:

• TA of the REST API

• Data inputs from N2WS 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 N2WS server.

• You can generate an API Key in N2WS 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 N2WS in seconds. 300 is recommended.

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

      • For Alerts, n2ws_alerts

      • For Dashboard information, n2ws_di

   4. Last alert ID - Leave blank.

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 N2WS app. If not, select New Index to add indexes of the CPM information.

• n2ws_alerts

• n2ws_di

3. In the file system, copy macros.conf from the default folder to the local folder. For example, Source: C:\Program Files\Splunk\etc\apps\N2WS_app_for_splunk\default Target: C:\Program Files\Splunk\etc\apps\N2WS_app_for_splunk\local

4. Edit the macros.conf file under 'local' and change the default index to the new indexes that were created.

3. Restart the Splunkd service from Windows Services.

E.4 Viewing Dashboards

Go to Splunk Apps and find N2WS app for splunk. The N2WS app contains tabs for N2WS activity monitor and N2WS Alerts. Edit and Export options are available in the upper right corner of each dashboard.

E.4.1 N2WS activity monitor

• Filter for Time Range (defaults to last 24 hours) and Users, including root and delegates.

• Displays All Accounts, Policies, Protected Resources, Managed Snapshots, Backups DR, S3 Backups, Volume Usage, and other requested data.

For Protected Resources and Managed Snapshots, select the displayed number to drill down and view a table of the resources and the number of items for each resource type for the selected users, or managed snapshots, count of each type, and a total.

E.4.2 N2WS Alerts

The Alerts dashboard includes filters for:

• Time range - Last 24 hours (default)

• User - All (default) or username

• Severity - All or Info or Warning

• Category - All or Tag Scan, volume usage limit exceeded

The list defaults to descending sort order. Select any column to change sort order.

• Time - Date, time, event ID

• User

• Severity

• Category

• Message

From the point of view of the AWS infrastructure, there is not much difference between backing up Linux/Unix instances or Windows instances. You can still run snapshots on EBS volumes. However, there is one substantial difference regarding recovering instances:

• In Unix/Linux instances, you can back up system volumes (root devices), and later launch instances based on the snapshot of the system volume. You can create an image (AMI) based on the system volume snapshot and launch instances.

• This option is currently not available for Windows Servers. Although you can take snapshots of the system volume of a Windows Server, you cannot create a launchable image (AMI) from that snapshot.

  Because of this limitation, N2WS needs an AMI to start the recovery of a Windows instance. N2WS will still make sure all the volumes, including the root device (OS volume), will be from the point-in-time of the recovered backup. By default, N2WS will create an initial AMI when you start backing up a Windows instance. That AMI will be used as the default when recovering this instance.

If crash-consistent backup is sufficient for your needs, you do not need to install any agent. However, to use VSS for application-consistent backups or to run backup scripts, you will need to install N2WS proprietary Thin Backup Agent or the AWS SSM Agent. AWS’s SSM Agent can be installed and configured for EC2 instances, on-premise servers, or virtual machines (VMs).

6.1 Configuring N2WS Thin Backup Agents

If a crash-consistent backup is sufficient for your needs, you do not need to install any agent. However, to use VSS or run backup scripts, you will need to install an N2WS Thin Backup Agent.

The N2WS Thin Backup Agent is used for Windows instances that need to perform application quiescence using VSS or backup scripts.

• The agent communicates with the N2WS Server using the HTTPS protocol.

• No sensitive information passes between the backup agent and the N2WS Server.

Any Windows instance in a policy can have a backup agent associated with it.

6.1.1 Associating an Agent with a Policy

After adding your Windows instance to the backup targets page (section ), the next step is to configure its agent by associating it with a policy.

To associate an agent with a policy:

1. In the Policies tab, select the policy and then select Edit.

2. In the Backup Targets tab, select the Windows instance and selectConfigure.

3. In the configuration screen, select Application Consistent Backup.

4. Select the Remote Agent Type: AWS SSM or N2WS Thin Backup Agent

6.1.2 Downloading and Distributing an N2WS Thin Backup Agent Configuration

1. You can download the installation package of the agent from the Agents tab in the left panel. Select Download Thin Backup Agent to download a standard Windows package (CPMAgentService.msi) to the Downloads folder.

2. After downloading the agent installation package, select Server Settings and then select Agents Configuration.

3. Enter the configuration syntax as described in , and select Publish.

6.1.3 Installing an N2WS Thin Backup Agent

The agent can be installed on any Windows 2016, 2019, 2022, or 2025 instance, 32 or 64-bit. After accepting the license agreement, the Setup screen opens.

The required fields are:

• The address of the N2WS server that is reachable from this instance.

• The default port is 443 for HTTPS communication. Change it if you are using a custom port.

After finishing the installation, the N2WS agent will be an automatic service in your Windows system.

6.1.4 Changing an N2WS Thin Backup Agent Configuration

To change the configuration of the backup agent after installation, edit the backup agent configuration file.

To change the agent configuration file:

1. Before proceeding, N2WS recommends that you make a copy of the cpmagent.cfg file, which resides in the N2WS Agent installation folder.

2. If the address or port of the N2WS Server had changed, edit the agent configuration file manually. Make the change after the equation sign.

3. After making the changes, restart the CPM Agent Service, in the Windows Service Manager console.

4. As an alternative, you could uninstall and reinstall the agent.

6.1.5. Using the N2WS Thin Backup Agent with an HTTP Proxy

N2WS supports configurations where the backup agent for a Windows instance can reach the CPM server only through a proxy.

To configure the agent with an HTTP proxy:

1. See section about editing cpmagent.cfg, and:

2. Add the following lines under the General section:

3. If your proxy server requires authentication, add the following two lines as well:

4. Restart the CPM Agent Service from the Windows Service Manager.

6.2 Configuring Simple System Manager (SSM) Agents

Following are the general steps to run a VSS snapshot backup:

• Define an SSM IAM Role.

• Define a VSS IAM Role.

• Associate an SSM Agent with an N2WS policy

• Install the latest SSM Agent.

• Install and run the latest VSS app.

• Backup scripts for Windows targets must be PowerShell scripts.

To use the SSM agent with VSS, the following AWS permissions are required:

• AmazonSSMFullAccess – For N2WS and the instance to use the SSM remote agent for VSS and scripts.

• AmazonSSMFullAccess and CreateVssSnapshot - For creating VSS.

6.2.1 Associating an SSM Agent with a Policy

To enable SSM in an N2WS policy, when configuring a Windows instance in the Policy Instance and Volume Configuration screen, select All Volumes in the Which Volumes list and Simple Systems Manager (SSM) in the Remote Agent Type list. See section .

6.2.2 Defining and Attaching an IAM Instance Profile for SSM

To create an IAM instance profile for SSM, see

To attach an IAM instance profile to an EC2 instance, see

Following is an example of adding SSM permissions to an IAM policy on AWS:

Following is an example of attaching an SSM role to an EC2 Instance on AWS:

6.2.3 Installing SSM Agents

To manually install an SSM Agent on EC2 instances:

For Windows Servers, see

Following is an example of how to install an SSM Agent during EC2 launch:

6.2.4 Defining an IAM VSS Role and Installing VSS App

To create an IAM role for VSS-enabled snapshots and to download and install VSS components on Windows for an EC2 instance, except for US government cloud regions, see

For US government cloud regions, update the IAM role with 'aws-us-gov' as shown below:

6.2.5 Using Backup Scripts on Windows Targets

When using an SSM remote agent for Windows instance targets, all 'before' or 'after' backup scripts must be PowerShell scripts. Each script’s content must consist of valid PowerShell commands. Saving the files with the ‘.ps’ extension is not necessary.

6.3 Using VSS

VSS, or Volume Shadow Copy Service, is a backup infrastructure for Windows Servers. It is beyond the scope of this guide to explain how VSS works. You can read more at . However, it is important to state that VSS is the standard for Windows application quiescence, and all recent releases of many of the major applications that run on Windows use it, including Microsoft Exchange, SQL Server, and SharePoint. It is also used by Windows versions of products not developed by Microsoft, like Oracle.

N2WS supports VSS for backup on Windows Servers 2016, 2019, 2022, and 2025 only. Trying to run VSS on other Windows OSs will always fail. VSS is turned on by default for every Windows agent. For unsupported OSs, you will need to disable it yourself. This can be done in the instance configuration screen, see section .

6.3.1 How N2WS Uses VSS

The N2WS Agent or SSM Agent performs under the role of a VSS Requestor to request the VSS System Provider to perform shadow copies. The process is:

• When N2WS initiates a backup, it requests an agent to invoke a backup of all relevant volumes. The agent then requests the VSS System Provider to start the shadow copy.

• VSS only creates differential copies, which means that for the N2WS to fully backup each volume, a few extra MBs are needed for the backup to complete. The amount of MBs depends on the size of the volume and the amount of data written since the last backup. Once the backup is complete, the backup agent will request the VSS Provider to delete the shadow copies. The agent will notify all relevant VSS writers that the backup is complete, only after making sure all the EBS snapshots are completed successfully.

You can see the process depicted below.

6.3.2 Configuring VSS

By default, VSS is enabled when a backup agent is associated with an instance in a policy. In many cases, you will not need to do anything. By default, VSS will take shadow copies of all the volumes. However, you may want to exclude some volumes. For example, since the system volume (typically C:\) cannot be used to recover the instance in a regular scenario, you may want to exclude it from the backup.

To make shadow copies of only some of the volumes:

1. In the Instance and Volume configuration screen, change the value of Volumes for shadow copies.

2. Type drive letters followed by a colon, and separate volumes with a comma, e.g., D:, E:, F:.

6.3.3 Excluding and Verifying VSS Writers

Writer exclusions and inclusions are configured using a text file, not the UI.

You may wish to exclude VSS Writers from the backup process in cases where the writer is:

• Failing the backup.

• Consuming too many resources.

• Not essential for the backup’s consistency.

To exclude VSS writers:

In the subfolder scripts under the installation folder of the backup agent (on the backed-up instance), create a text file named vss_exclude_writers_<policy-name>.txt. with the following structure:

• Each line will contain a writer ID, including the curly braces.

• If you write in one of the lines all, all writers will be excluded. This can be handy sometimes for testing purposes.

In some cases, you want to make sure that certain writers are included (verified) in the shadow copy, and if not, fail the operation.

To verify writers:

In the subfolder scripts under the installation folder of the Thin Backup Agent (on the backed-up instance), create a text file named vss_verify_writers_<policy-name>.txt with the following structure:

• Each line will contain a writer ID, including the curly braces.

• all is not an option.

An example of a line in either of the files is:

{4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}

6.3.4 Troubleshooting VSS Issues

When a VSS-enabled policy runs, you will see its record in the Backup Monitor tab.

• If it finished with no issues, the status of the record will be Backup Successful.

• If there were issues with VSS, the status will be Backup Partially Successful.

To troubleshoot:

• To view the errors that VSS encountered, look in the backup log.

• To view the output of the exact VSS error, select Recover.

• To view the VSS Disk Shadow log, select its link in the recovery panel. There is a link for each of the agents in the policy, with the instance ID stated.

• In most cases, VSS will work out of the box with no issues. There can be a failure from time to time in stressed system conditions.

• If the writers do not answer the freeze request fast enough, the process times out and fails. Often, the retry will succeed.

• When VSS is constantly failing, it is usually a result of problems with one of the writers. This could be due to some misconfiguration in your Windows system.

• In most cases, the problem is out of the scope of N2WS. The best way to debug such an issue is to test VSS independently. You can run the Diskshadow utility from a command line window and use it to try and create a shadow copy. Any issue you have with VSS using N2WS should also occur here.

• To learn how to use the Diskshadow utility, see:

• You may see failures in the backup because VSS times out or is having issues. You will see that the backup has status Backup Partially Successful. Most times you will not notice it since N2WS will retry the backup and the retry will succeed.

• If the problem repeats frequently, check that your Windows Server is working properly. You can check the application log in Window’s Event Log. If you see VSS errors reported frequently, contact .

6.3.5 VSS Recovery

Recovering instances using N2WS is covered in section . When recovering a Windows Server that was backed up with VSS, you need to revert to the shadow copies in the recovery volumes to get the consistent state of the data.

To revert to shadow copies after VSS recovery:

1. Connect to the newly recovered instance.

2. Stop the services of your application, e.g., SQL Server, Exchange, SharePoint, etc.

3. Open an administrator command line console and type diskshadow.

4. In the recovery panel screen, select the VSS DiskShadow Data link to find the IDs of the shadow copies made for the required backup.

5. Type revert {shadow id} for each of the volumes you are recovering, except for the system volume (C: drive). After finishing, the volumes are in a consistent state.

6. Turn the services on and resume work.

If you wish to recover a system disk, it cannot be reverted to the shadow copy using this method. The system volume should not contain actual application data as it is not a recommended configuration, and, therefore, you should be able to skip this revert operation. However, you can expose the system disk from the shadow and inspect its contents.

To expose the system disk from the shadow:

1. In the Diskshadow utility, type: expose {shadow id} volletter:

2. After finishing, remember to unexpose the disk.

3. To avoid unnecessary resource consumption, delete the shadow: (delete shadow {shadow id}).

To revert to a shadow copy for a system volume:

If you have a strict requirement to recover the consistent shadow copy for the system volume as well, do the following:

1. Before reverting for other volumes, stop the instance; wait until it is in stopped state.

2. Using the AWS Console, detach the EBS volume of the C: drive from the instance and attach it to another Windows instance as an “additional disk”.

3. Using the Windows Disk Management utility, make sure the disk is online and exposed with a drive letter.

4. Go back to the process in the previous section (VSS Recovery), and revert to the snapshot of drive C which will now have a different drive letter. Since it is no longer a system volume, it is possible to do so.

5. Detach the volume from the second Windows instance, reattach to the original instance using the original device, which is typically /dev/sda1, and turn the recovered instance back on.

6.4 Using Backup Scripts on Windows

Besides VSS, there is also the option to run backup scripts to achieve backup consistency. It is also possible to add backup scripts in addition to VSS.

• You enable backup scripts in the Instance and Volume Configuration screen of the instance in the policy and select the type of agent that you want to execute the scripts.

• All scripts are named with a prefix plus the name of the policy.

• There are 3 types of events. If scripts are used, a script must be provided for each of these events. If any script is not defined, N2WS will treat the missing script as a failing script.

  • Before the VSS backup - BEFORE_<policy-name>.<ext>

  • After the VSS backup started - AFTER_<policy-name>.<ext>

  • After the VSS backup has completed - COMPLETE_<policy-name>.<ext>

• Scripts can have any extension if they are executable. They can be batch scripts, VBS scripts, PowerShell, or even binary executables. However, N2WS cannot run PowerShell scripts directly as Windows scripts.

• All scripts must be set with exit code zero 0.

6.4.1 Location and Execution of Scripts

When using the N2WS Thin Backup Agent:

• As opposed to Linux, Windows backup scripts run directly on the agent. All the scripts are in the subfolder scripts under the installation folder of the N2WS Thin Backup Agent.

• If the N2WS user that owns the policy is not the root user, the scripts will be under another subfolder with the username (e.g., …\scripts\cpm_user1).

• Scripts are launched by N2WS Thin Backup Agent, so their process is owned by the user that runs the agent service. By default, this is the local system account. However, if you need to run it under a different user you can use the service manager to change the logged-on user to a different one. For example, you might want to run it with a user who has administrative rights in a domain.

When using the SSM Agent:

• Scripts are saved locally on the N2WS server and invoked remotely.

• Scripts must be saved in /cpmdata/scripts/<username>/<instance_id>/

• Script names are the same as for the N2WS Thin Backup Agent. The PowerShell file extension is not required.

6.4.2 Before Script

The before_<policy-name>.<ext> runs before the backup begins. Typically, this script is used to move applications to backup mode. The before script leaves the system in a frozen state. This state will stay for a very short while, until the snapshots of the policy start, which is when the after script is started.

6.4.3 After Script

The after_<policy-name>.<ext> script runs after all the snapshots of the policy start. It runs shortly after the before script, generally less than 2-3 seconds. This script releases anything that may have been frozen or locked by the before script.

This script accepts the success status of the before script. If the before script succeeded, the argument will be one 1. If it failed, crashed, or timed out, the argument will be zero 0.

6.4.4 Complete Script

The complete_<policy-name>.<ext> script runs after all snapshots are completed. Usually, the script runs quickly since snapshots are incremental. This script can perform clean-up after the backup is complete and is typically used for transaction log truncation.

The script accepts one argument. If the entire backup was successful and all the previous scripts were successful, it will be one 1. If any issues or failures happened, it will be zero 0. If this argument is one 1, truncate logs.

When you enable backup scripts, N2WS assumes you implemented all three scripts. Any missing script will be interpreted as an error and be reflected in the backup status. Sometimes the complete script is often not needed. In this case, write a script that just exits with the code zero 0, and the policy will not experience errors.

6.4.5 Capturing the Output of Backup Scripts

You can have the output of backup scripts collected and saved in the N2WS Server. See section .

Resource Control allows users to stop and start Instances and RDS Databases for each Account during a week. It also allows users to stop the resources at a designated time in the future.

• A Group is the controlling entity for the stopping and starting of selected resources. Resource Control allows for stopping on one day of a week and starting on another day of the same week. Once an Off/On schedule is configured for a Group, N2WS will automatically stop and start the selected resource targets.

• Resources that are eligible and enabled for hibernation in AWS will be hibernated regardless of whether their current operation is On or Off if their controlling Resource Control Group is enabled for hibernation. Hibernated instances are restarted by an On operation.

• See in the .

• For enabling hibernation in N2WS, see the Hibernate description in section .

• The stopping and starting of targets identified for each Group are independent of the backup schedule for an Account’s policy.

• It is possible to turn off operations for a long period of time even though the Group was never turned on.

• Ad hoc Off and On operations are available in addition to the Resource Control schedule.

• Off/On operations are not allowed for Groups with a Status of ‘disabled’.

Following are Resource Control tabs in the left panel of the N2WS user interface:

• Resource Control Monitor – Lists the current operational status of Groups under Resource Control. The Log lists the details of the most recent operation for a Group.

• Resource Control Groups – Use the Groups tab to add and configure a Group: the account, the days, and off/on times, which Resource Targets are subject to the Group control, and other features. You can also delete a group and activate Turn On Now / Turn Off Now controls.

After configuring a group, you can add resources in the Operation Targets tab. See section .

15.1 Adding a Resource Control Group

In the Resource Control Groups tab, select New and complete the Group Details screen fields:

• Name –Only alphanumeric characters and the underscore allowed (no spaces).

• Account – Owner of the Group. Users are configured for a maximum number of Resource Control entities. See section .

• Enabled – Whether the Group is enabled to run.

• Operation Mode – Two options for controlling operation:

  • Turn On/Off – Turn Group on and off according to schedule.

  • Turn Off Only – Turn off for an undefined long period of time without having to ever have the Group turned on.

• Auto Target Removal – Whether a target resource is automatically removed from the Group if the resource no longer exists in AWS.

• Timeout (in minutes) - How long will the operation wait in minutes until finished. Default is 30 minutes. Failure from exceeding the timeout does not necessarily mean that the operation of stopping or starting the resource has failed. The Log will show the run status for each resource.

• Hibernate (if possible) – Whether eligible instances will be hibernated. If enabled, only instances within the Group’s target resources that are eligible for hibernation by AWS will be hibernated. See Info on limitations below.

• Description – Optional description of the Resource Control Group function.

After adding a Group, select Next at the bottom of the screen or select the Operation Targets tab and configure the Operation Targets (section ) and the Off/On Times (section ).

15.2 Adding Resource Targets to a Group

Instances and RDS Databases may be added to the Group.

• Eligible resources within a Group enabled for hibernation that has been stopped have a Status of ‘stopped-hibernation’.

• The Status column shows whether a target is ‘running’ or ‘stopped’.

Select the Operation Targets tab. In the Add Backup Targets menu, select a resource type to add to the Group.

If you selected Instances, the Add Instances screen opens.

If you selected RDS Databases, the Add RDS Databases screen opens:

In the relevant screen:

1. Check the Status column to determine whether a resource is eligible for adding to the Group.

2. Select one or more resources, and then select Add Selected. Selected resources are removed from the table.

3. Continue until you are finished and select Close to return to the Operations Targets screen.

4. Select Save to save the Operation Targets selections.

15.3 Configuring Off/On Scheduler

Scheduling overlapping off and on time ranges is invalid. For example:

• A resource is turned off at 20:00 on Wednesday and turned on at 23:00 the same day.

• Then, an attempt to schedule the same resource to be turned off on Wednesday at 9:00 and turned off at 22:00 on Wednesday will result in an invalid input error.

1. Select Next to advance to the Schedules tab for the group.

2. Select New to open a default time range row ready for your changes.

3. In the time range row, select the Turn Off Day and Time and the Turn On Day and Time values from the drop-down lists, choosing AM or PM as required. After each time selection, select Apply.

4. To open another time range row, select New.

5. When finished creating the time ranges, select the required time range rows, and then select Save.

15.4 Overriding a Resource Control Schedule

After creating the Group, you can initiate a stop or start action outside of the scheduled times by selecting the Turn On Now or Turn OFF Now in the Resource Control Groups tab.

15.5 Using Scan Tags with Resource Control

Scan tags for Resource Control can be used to:

• Create a new Group based on an existing Group’s configuration.

• Add a resource to a Group.

• Remove a tagged or untagged resource from a Group.

The tag format isKey: cpm_resource_controlwith one of the following values:

• Value:<group-name> or <group-name>:<based-on-group>

  • If the value in <group-name> equals ‘g1’, the resource will be added to the g1 group.

  • The template <group-name>:<based-on-group> means, in the case of g1:g2:

    • If g1 exists, add the resource to g1.

    • Otherwise, create a new group g1 based on group g2, and add the resource to it.

• Value: no-resource-control- Remove the resource instance or RDS database from the Group whether it is tagged or not.

• Value: <no value> - Remove the tagged resource instance or RDS database from the Group.

15.6 Resource Control Reporting

Resource Control provides individual logs of off and on operations and a summary report of all operations.

The individual log contains timestamps for each step within the operation, from firing to completion, and is downloadable as a CSV file. To view individual logs, in the Resource Control Monitor tab, select a group and then select Log.

To download the individual log, select Download Log.

To generate the summary log:

1. Select the Reports tab in the left panel.

2. Select the Immediate Report Generation tab and then select Resource Control Operations in the Report Type list.

3. Complete the filter and time range boxes.

4. Select Generate Report. The report is automatically downloaded as a CSV file.

The Resource Control Operations Report contains information for all saved operations for all accounts. For each operation it contains:

• Resource Control Operation ID – A sequential number for each operation.

• User – User generating the report.

• Account – The N2WS owner of the Resource Control Group.

• AWS Account Number – The AWS account number of the owner of the resources.

• Resource Control Group – The N2WS Resource Control Group name.

• Status – Operation status.

• Start Time – Start date and time.

• End Time – End date and time.

• Marked for Deletion – Whether the resource is marked for deletion.

Be sure to review this entire section before starting an N2WS installation (section ‎2.1) or an upgrade (section ‎2.2).

The primary differences between an installation and an upgrade are:·

• In an upgrade, you use an existing CPM data volume, rather than creating a new volume.

• In an upgrade, for each version you are upgrading from, there are specific steps to follow before performing the actual upgrade.

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

• When a new N2WS 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 N2WS Server, the same certificate will be used also for the main N2WS application.

• Every N2WS 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 N2WS.

When configuring the N2WS server, define the following settings:

• AWS Credentials for the N2WS root user.

• Time zone for the server.

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

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

• Proxy settings. Configure proxy settings in case the N2WS 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 2.1.4.2.

• Whether to upload an SSL certificate and a private key for the N2WS 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 N2WS to provide quicker and enhanced support. Registration information is not shared.

For the configuration process to work, as well as for normal N2WS operations, N2WS needs to have outbound connectivity to the Internet, for the HTTPS protocol. Assuming the N2WS 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 N2WS Server and usage of data volume.

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

2.1 Installing New N2WS Server

N2WS Server Sizing Guidelines

Following are the recommended instance type sizes to consider when deploying your N2WS 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

To initially be identified as the owner of this instance, you are required to type or paste the N2WS 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 N2WS server. A user with the Authentication credentials for N2WS Instance IAM Role is the only user allowed to install N2WS, 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 N2WS 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 N2WS server in recovery mode only, by choosing an existing data volume and set Force Recovery Mode.

• Configure proxy settings for the N2WS server. See section 2.1.3.2.

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

As you can see below, the choice of new or existing data volume is made here. Actual configuration of the volume will be accomplished at the next step.

AWS credentials are required to create a new Elastic Block Storage (EBS) data volume if needed and to attach the volume to the N2WS 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 N2WS 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

When creating a new data volume, the only thing you need to define is the capacity of the created volume. You also have the option to encrypt the volume, as described in section 2.1.4.1.

The volume is going to contain the database of N2WS’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.

The default size of the data volume is 10 GiB.

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 N2WS instance It will be named N2WS Data Volume. During the configuration process, the volume will be created and attached to the instance. The N2WS database will be created on it.

2.1.3.2 Proxy Settings

If the N2WS 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 N2WS UI, proxy settings are made in the Proxy tab of Server Settings > General Settings.

2.1.4 Complete Remaining Fields in N2WS Configuration

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

If you chose to create a new volume, you can choose the volume capacity, type, and whether to encrypt.

2.1.4.1 Encrypting a New Data Volume

If you choose a new data volume, you have an option to encrypt CPM user data. You also have the option to encrypt a new data volume if using the silent configuration mode. See section 2.3.1 for AWS, section 2.3.2 for AWS with Secrets Manager, and section 2.3.3 for Azure.

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.2 Web Server Settings

Port 443 is the default port for the HTTPS protocol, which is used by the N2WS 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.3 Anonymous Reports Setting

Leaving the Anonymous Usage Reports value as Allow permits N2WS 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 N2WS names of objects names, such as policy and schedule.

It contains only details like:

• How many policies run on an N2WS 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 N2WS application.

If you are not redirected, refresh the browser manually. If you are still not redirected, reboot the N2WS 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 N2WS 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 N2WS 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, N2WS recommends that you:

1. Terminate the N2WS 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 N2WS 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 N2WS Server

See Appendix G – Securing Default Certificates on N2WS Server.

2.2 Upgrading N2WS

The following diagram shows the major steps and considerations in an N2WS 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 ‎2.2.3.

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

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

If you have any questions or encounter issues, visit the N2WS 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 N2WS Version

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

‌Permissions

Due to new functionality in v3.x, you may need to update your permission policies. If you have more than one AWS Account added to the N2WS console, you will have to update the IAM Policies for each account. See the JSON templates at https://support.n2ws.com/portal/kb/articles/what-are-the-required-minimal-aws-permissions-roles-for-cpm-operation

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 N2WS settings, write down the details.

4. Take a screenshot of the N2WS 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 N2WS 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 N2WS Data Volume. Only the Data Volume is important, as it contains all your settings, backup entries, etc.

8. Download the latest IAM permissions 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 N2WS Server Instance

‌To upgrade/redeploy the N2WS 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”. N2WS 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 N2WS 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 N2WS and terminated the old N2WS server, but now wish to continue where you stopped.

• You are upgrading to new N2WS releases.

• You are changing some of the configuration details.

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

The select box for choosing the volumes will show all available EBS volumes in the same AZ as the N2WS 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 N2WS 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 N2WS 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 N2WS 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 N2WS instance should start with a [SERVER] section, followed by the configuration details.

• For the relevant time_zone parameter value, see Appendix C.

Following is an example of the whole script:

[any-script-before-cpmconfig]
CPMCONFIG
[SERVER]
user=<username for the N2WS user>
password=<password>
volume_option=<new or existing>
volume_size=<in GB, used only for the new volume option>
volume_id=<Volume ID for the data volume, used only in the existing volume option>
volume_type=<set your storage performance and cost.
   The default is “gp3”. It can be set to “io1”, "io2", “gp2” or "gp3">
snapshot_id=<snapshot ID to create the data volume from, used only with the existing volume option, and only if volume_id is not present>
encryption_key=<encrypt user-data volume by setting the ARN of the 
   KMS key. used only for the new volume option>
time_zone=<set N2WS server’s local time.
   The default timezone is GMT. See Appendix C for available time zones.> 
allow_anonymous_reports=<send anonymous usage data to N2W Software. 
   The default is “False”>
force_recovery_mode=<allow additional N2WS server to perform recovery
   operations only. The default is “False”. If it set to “True” - it
   requires volume_option=existing>
activation_key=<Activation Key>
CPMCONFIGEND
[any-script-after-cpmconfig]

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

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

[PROXY]
proxy_server=<address of the proxy server>
proxy_port=<proxy port>
proxy_user=<user to authenticate, if needed>
proxy_password=<password to authenticate, if needed>

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, N2WS will attempt to create a snapshot of that volume and migrate it to the AZ of the new N2WS 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>@

CPMCONFIG
[SERVER]
user=@<secret_name>#<secret_name_user_key>@
password=@<secret_name>#<secret_name_pw_key>@
volume_option=existing
volume_id=@<secret_name>#<secret_name_vol_key>@
volume_type=gp2
time_zone=Europe/Berlin
CPMCONFIGEND

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

user=@CPMCredentials#N2WS_User2@
password=@CPMAlternativeCredentials#N2WS_Password@

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 N2WS using the Azure CLI:

1. In the Azure Portal, accept the license terms for N2WS 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: