Troubleshooting File Level Recovery (FLR) communication issue

CPM Configuration

File-level recovery requires N2WS to recover volumes in the background and attach them to a temporary EC2 ‘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. the N2WS server use this configuration to know which VPC/subnet/SG to use for the temporary worker

You need to make sure that you have a worker configured for the account/region where you are using FLR

The AWS key pair that you are defining will enable you to login into the worker if additional troubleshooting or logs are needed

AWS Configuration

File Level Restore Worker needs to be able to connect to the N2WS Server over ports 22(SSH) and 443(HTTPS).

1. You need to make sure that this ports are opened outbound in the AWS security group of the worker
   
2. You also need to make sure that this ports are opened inbound for the N2WS server
   
3. If the worker does not have public IP, you need to make sure it has a way to reach the N2WS server (for example VPC peering)
   

---

Troubleshooting

1. Communication 

The most common issue is communication, You can test connectivity using UI or manually using SSH

To test from UI you can read this KB -  How to test worker KB: https://support.n2ws.com/portal/kb/articles/how-to-test-the-worker-configuration-for-cpm-3-0

You can test connectivity from the Worker by connecting to it over SSH(using "ubuntu" username) and running these commands:

For port 22:

1. ssh cpm_server_ip_address

The result should be "cpmuser@cpmserveripaddress: Permission denied (publickey)."

If connection is blocked, you will receive (after a delay) "ssh: connect to host cpmserveripaddress port 22: Connection timed out"

For port 443:

1. wget --no-check-certificate https://cpmserveripaddress/

This command should result in status 302 (redirecting to "/signin/") followed by status 200

Note: in order to be able to login to the worker instance over SSH you have to make sure that you have configured the workers to use a key pair in the worker configuration 

2. FLR and ELB

ELB can cause issue with the FLR due to timeout: https://support.n2ws.com/portal/kb/articles/elb-timeout-casuses

Thanks for reading this guide,

N2WS Support Team.

• Related Articles

• Troubleshooting File Level Recovery (FLR) 3.2

  Background: File-level recovery requires N2WS to launch temporary worker instance in the target region. The worker will read the snapshot directly or recover volumes in the background and attach them to a ‘worker’ instance launched for the operation. ...

• N2WS-20407 - FLR file corruption

  Issue: Due to recent changes in Cloud API's, the following possible issues may occur when using File Level Recovery: 1) Some files/folders may be missing from the view. 2) Some files may be recovered with an incorrect content (unbeknownst to the ...

• File Level Recovery may fail if Elastic Load Balancing (ELB) is in use

  Using FLR to explore volumes may fail if Elastic Load Balancing (ELB) is in use When using FLR to explore files you may get one of the following errors when the worker launches. This could be caused by an ELB (Elastic Load Balancing) in your ...

• File Level Recovery may fail with error "The reason could be missing/unsupported file system"

  File-level recovery may fail with the following error printed in the CPM logs: Partition Table: gpt Number  Start     End        Size        File system  Name     Flags 1         2097kB   805GB  805GB                          primary    raid INFO:  ...

• File-level restore may fail with the "Could not get CPM instance info" error

  File-level restore may fail with the "Could not get CPM instance info" error: The following error is printed in the CPM server log: ERROR:  explore_backup_init(.\cpmserver\cpm\filemanager\views.py:317)  Could not get CPM instance info ...