Configuring an isolated recovery environment on a storage server
You can configure an isolated recovery environment (IRE) on a storage server to create an air gap between your production environment and a copy of the protected data. The air gap restricts network access to the data except during the timeframe when data replication occurs. This feature helps to protect against ransomware and malware.
To configure the IRE, you need a production Access Appliance environment and a target storage server on a supported Cohesity appliance. Check the appliance documentation for compatibility.
The production environment does not require any additional steps for this feature. Use the following procedure to configure an IRE on the target storage server from the MSDP restricted shell. You can login to the MSDP restricted shell by logging in to the target MSDP server IP (deduplication IP) with credentials of a cluster local user having administrator role.
Note:
All the MSDP restricted shell commands should be executed on the IRE/target storage server.
To configure an IRE
- If A.I.R. is not configured on the production domain, continue to the next step.
If A.I.R. is already configured on the production domain, log in as a local user with administrator role (same user that was used for Access Appliance CLISH login). Run the following command to show the SLP windows for replication from the primary server to the server.
setting ire-network-control show-slp-windows production_primary_server=<production domain> production_primary_server_username=<production username> ire_primary_server=<IRE domain> ire_primary_server_username=<IRE username>
Where:
<production domain> is the fully qualified domain name (FQDN) of the primary server in your production environment.
<production username> is the username of the NetBackup primary user with permission to list SLPs and SLP windows in the production environment. For Windows users, enter the username in the format <domain name>\<username>. For other users, enter the username only.
<IRE domain> is the FQDN of the primary server in the IRE. Use the same hostname that you used for the target primary server when you configured the SLPs in the production environment.
<IRE username> is the username of a IRE NetBackup primary user with permission to list SLPs and storage units in the IRE. For Windows users, enter the username in the format <domain name>\<username>. For other users, enter the username only.
For example:
production_primary_server=examplePrimary.domain.com production_primary_server_username=example_user ire_primary_server=exampleIREPrimary.domain.com ire_primary_server_username=example_user1
The following is an example output of the command:
EveryDayAtNoon: SLPs: SLP1 Sunday start: 12:00:00 duration: 00:59:59 Monday start: 12:00:00 duration: 00:59:59 Tuesday start: 12:00:00 duration: 00:59:59 Wednesday start: 12:00:00 duration: 00:59:59 Thursday start: 12:00:00 duration: 00:59:59 Friday start: 12:00:00 duration: 00:59:59 Saturday start: 12:00:00 duration: 00:59:59 WeeklyWindow: SLPs: SLP2 Sunday start: 10:00:00 duration: 01:59:59 Monday NONE Tuesday NONE Wednesday NONE Thursday NONE Friday NONE Saturday start: 10:00:00 duration: 01:59:59
This example shows two SLP windows:
A daily window for one hour starting at noon.
A weekly window for two hours starting at 10:00 A.M.
- Based on the requirements for your environment, determine a schedule and take note of it. For an existing A.I.R. environment, the schedule must accommodate the SLP windows that you viewed in the previous step.
You can set a daily schedule that is open at the same time each day, or you can set a different schedule for each day of the week.
In the previous example, you can accommodate both SLP windows with either of the following:
A daily schedule from 10:00 A.M. to 1:00 P.M.
A schedule from 12:00 P.M. to 1:00 P.M. on Monday through Friday and a schedule from 10:00 A.M. to 1:00 P.M. on Saturday and Sunday
Note:
If the production environment and the IRE are in different time zones, the schedule must begin only once per day in both time zones. For example, if one environment is in the Asia/Kolkata time zone and the other is in the America/New_York time zone, the following schedule in Kolkata is not supported: Tuesday start time 22:00:00 and Wednesday start time 03:00:00. When these start times get converted to the New York time zone, they become Tuesday start time 12:30:00 and Tuesday start time 17:30:00, which is not supported.
- Run the following command to configure which subnets and IP addresses are allowed to access the storage server:
setting ire-network-control allow-subnets subnets=<CIDR subnets or IP addresses>
Where <CIDR subnets or IP addresses> is a comma-separated list of the allowed IP addresses and subnets, in CIDR notation.
For example:
setting ire-network-control allow-subnets subnets=10.80.120.208,10.84.48.0/20
Note:
The IRE primary server, the IRE media servers, and the DNS server for the IRE must be included in the allowed list. If all of these servers are in the same subnet, only the subnet is required to be in the allowed list.
- Run the following command to set the daily air gap schedule:
setting ire-network-control set-schedule start_time=<time> duration=<duration> [weekday=<0-6>]
Where [weekday=<0-6>] is an optional parameter to indicate the day if you need to set different schedules for different days. 0 is Sunday, 1 is Monday, etc.
For example:
setting ire-network-control set-schedule start_time=10:00:00 duration=03:00:00 weekday=0
- Before you can send data between the production domain and the IRE storage server, you must add MSDP reverse connections and add the replication operation.
See Configuring data transmission between a production environment and an IRE storage server.
Note:
When multiple Veritas Data Deduplication instances are configured in an IRE domain cluster, and subnets and schedules are set using the MSDP restricted shell for all the Veritas Data Deduplication instances; if any of the instances is stopped and the cluster is restarted, the outbound connection rules corresponding to that instance is lost after the restart operation. This is by design and the outbound connection rules, if any, are applied back only if the stopped instance(s)are started back.