DELL EMC PowerStore Protecting Your Data User Guide

Dell EMC PowerStore
Protecting Your Data
Version 3.x

EMC PowerStore Protecting Your Data

Notes, cautions, and warnings
NOTE: A NOTE indicates important information that helps you make better use of your product.
CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid the problem.
WARNING: A WARNING indicates a potential for property damage, personal injury, or death.

Additional Resources

As part of an improvement effort, revisions of the software and hardware are periodically released. Some functions that are described in this document are not supported by all versions of the software or hardware currently in use. The product release notes provide the most up-to-date information about product features. Contact your service provider if a product does not function properly or does not function as described in this document.
Where to get help
Support, product, and licensing information can be obtained as follows:

• Product information
  For product and feature documentation or release notes, go to the PowerStore Documentation page at https://www.dell.com/powerstoredocs.

• Troubleshooting
  For information about products, software updates, licensing, and service, go to https://www.dell.com/support and locate the appropriate product support page.

• Technical support
  For technical support and service requests, go to https://www.dell.com/support and locate the Service Requests page. To open a service request, you must have a valid support agreement. Contact your Sales Representative for details about obtaining a valid support agreement or to answer any questions about your account.

Introduction

This chapter contains the following information:
Topics:

• Data protection
• Snapshots
• Replication
• Protection policies
• Metro protection

Data protection
PowerStore provides both local and remote data protection. Using the PowerStore Manager, you can protect your data locally by creating snapshots (point-in-time copies) of volumes, volume groups, virtual machines, or file systems. You can also apply remote protection by replicating your data to a remote system, or mirroring the data using metro volumes for redundancy in the event of a disaster.
PowerStore enables you to create custom protection policies, which are sets of rules for snapshot creation, replication, or both, and assign them to volumes, file systems, and NAS servers. Protection policies apply the defined rules on the storage resource, providing it with local and/or remote protection.
NOTE: Protection policies that include a replication rule cannot be assigned to metro volumes. See Using protection policies with metro.
NOTE: As of version 3.x, protection policies cannot be applied to virtual volumes based virtual machines. See Virtual volumes replication.
Snapshots
Snapshots are read-only, point-in-time copies of data of a volume, volume group, virtual machine, or file system. Creating a snapshot saves the state of the storage resource at that particular point-in-time. Using snapshots, you can easily protect your data locally and restore a storage resource to a previous state.
You can manually create snapshots at any time. It is also possible to configure snapshot rules as part of a protection policy and assign them to the relevant storage resources. The system automatically creates snapshots of the relevant resource according to the schedule specified in the protection policy.
If data corruption occurs or data is accidentally deleted, you can recover the data from the snapshots or restore the volume or volume group to the point in time when the snapshot was created.
For file systems, you can create two access types of read-only file snapshot: protocol and .snapshot. The default access type is protocol, which can be exported as an SMB share, NFS export, or both. You can share and mount the snapshot on a client like any other file system. For .snapshot access types, you can access the files within the snapshot from the production file system in the . s n a p s h o t subdirectory of each directory.
You can also create write-order consistent and application consistent snapshots of volumes:

• Write-order consistent snapshots – PowerStore holds all writes on the volume group members to provide a uniform point in time copy, and therefore ensure consistent protection across all member volumes. You can generate write-order consistent snapshots from the PowerStore Manager.
• Application consistent snapshots – You can create application consistent snapshots of a volume or a volume group using AppSync. When creating an application consistent snapshot, all incoming I/O for a given application is quiesced while the snapshot is created.
  To verify whether a snapshot is write-order consistent or application consistent, look at the Write-Order Consistent and Application Consistent columns in the snapshot tables for a volume or volume group in PowerStore Manager.

NOTE: If you cannot see these columns, you can add them, using the Show/Hide Table Columns option.
Mapping snapshots to hosts is not supported in PowerStore. To allow a connected host to access a snapshot, you can create a thin clone – a writable, space efficient copy of the snapshot – and map it to a host. You can update the thin clone from differensnapshots using the refresh operation.
For details on the possible snapshot-related operations you can perform, using the PowerStore Manager, refer to the Snapshotchapter.
Replication
Data replication is a process in which data is duplicated to a remote system, which provides enhanced redundancy in case the main production system fails. Replication minimizes the downtime-associated costs of a system failure and simplifies recovery following a natural disaster or human error.
PowerStore supports asynchronous remote replication for volumes and volume groups, NAS servers, and virtual volumes.
To configure replication for volumes and volume groups:

1. Create a remote connection between the source and destination systems.
2. Create a protection policy with a replication rule that best meets your business needs.
3. Assign a protection policy to the volume or volume groups.

To configure replication for NAS servers:

1. Configure and map the file mobility network. For details see the PowerStore Networking Guide for PowerStore T Models on https://www.dell.com/powerstoredocs.
2. Create a remote connection between the source and destination systems.
3. Create a protection policy with a replication rule that best meets your business needs.
4. Assign a protection policy to the NAS server.

NOTE: It is not recommended to modify the file mobility network when the peer system is unreachable. When the peer system is up again, the result may be that both NAS servers are in production mode.
To configure replication for virtual volumes:

1. Create a remote connection between the source and destination systems.
2. Creating protection policies and assigning them to virtual volumes is done on vSphere. See Virtual volumes replication.

For volume and file replication, PowerStore enables you to failover control to the remote system and reverse the direction of a remote protection session. Failover may be required in the following cases:

• If you want to migrate data to a new system, and then switch to working from it without losing data. In this case, failover can be performed with no data loss.
• When there is no access to the data in the source system, you can switch to the remote system, and continue working using the latest point-in-time remote protection copy. However, data loss might occur in this situation because the latest copy in the remote system does not include data changes that are made between the time this copy was created and the time the data in the system became inaccessible.
• When the data in the source system is accessible but its integrity may be compromised. In such a case, you should revert to the latest point-in-time protection copy created before the data was compromised.

You can perform a failover test on the destination storage resource to test the system disaster recovery readiness.
For detailed information about replication-related procedures that you can perform, see the Replication chapter.
Protection policies
A protection policy consists of snapshot rules, replication rules, or both, that you can create to establish consistent data protection across storage resources. After configuring a protection policy, you can assign it to new or existing storage resources.
Each protection policy can only include one replication rule, and up to four snapshot rules. A replication/snapshot rule can be included in multiple policies.
Protection policies manage snapshot creation and replication sessions, based on the rules included in them. You can create policies with various rules that provide different levels of protection to meet your local and remote protection needs, and assign a policy to multiple storage resources to provide identical protection to those resources.
Based on your user privileges, you can create or modify relevant rules and policies.
If you want to create a new snapshot or replication rule, ensure that you review the parameters and your business requirements with an administrator before proceeding. This helps achieve and maintain consistent policies across the system.
For detailed information on protection policies-related procedures you can perform, refer to the Protection Policies chapter.
Metro protection
Metro provides bi-directional synchronous replication (active/active) across two PowerStore systems. A metro volume is exposed using two distinct systems, typically located in two different data centers, up to 96 km (or 60 miles) apart, or in two distant locations within the same data center. The two systems cooperate to expose a single metro volume to application hosts by providing the same SCSI image and data, making the hosts and application running on them perceive two physical volumes that are hosted by the two systems as a single volume with multiple paths.
Metro protection enables increased availability and disaster avoidance, resource balancing across data centers and storage migration between two PowerStore systems.
When you configure a metro volume, the content of a metro volume is replicated to the remote system. Protection policies are used to configure additional protection such as local snapshots.
A metro session consists of two PowerStore systems. One system is configured as ‘preferred’ while the other is configured as ‘non-preferred’. These roles guide the system behavior on failure situations. When a failure occurs (either on one of the systems or to the connection between the systems), the metro session becomes ‘fractured’ and the non-preferred system stops servicing I/Os.
The following table summarizes the allowed actions that you can perform on a metro volume depending on the current metro status and the system from which the action is initiated.
NOTE: The table addresses common use cases and does not include rare failure scenarios.
Table 1. Allowed Metro Actions

Location| Metro Status| Modify Role| Promote| Demote| Pause| Resume| End Metro
---|---|---|---|---|---|---|---
On preferred system| Operating Normally| Yes| No| No| Yes| No| Yes
Paused| No| No| Yes| No| Yes| Yes
Fractured| No| No| Yes| Yes| No| Yes
Switching to Metro
Synchroniza tion| No| No| No| Yes| No| Yes
On non-preferred system| Operating Normally| Yes| No| No| Yes| No| Yes
Paused| No| Yes (if other system is unreachable )| No| No| Yes| Yes
Fractured| No| Yes (if other system is unreachable)| No| Yes| No| Yes
Switching to Metro
Synchroniza tion| No| No| No| Yes| No| Yes

Snapshots

This chapter contains the following information:
Topics:

• Create a snapshot
• Create a thin clone
• Using clones to access read-only snapshots from hosts
• Refresh a storage resource
• Restore a storage resource from a snapshot

Create a snapshot
Creating a snapshot saves the state of the storage resource and all files and data within it at a particular point in time. You can use snapshots to restore the entire storage resource to a previous state. You can create a snapshot of a volume, volume group, file system, or virtual machine.
Before creating a snapshot, consider the following:

• Snapshots are not full copies of the original data. Do not rely on snapshots for mirrors, disaster recovery, or high-availability tools. Because snapshots are partially derived from the real-time data of the storage resources, they can become inaccessible if the storage resource becomes inaccessible.
• Although snapshots are space efficient, they consume overall system storage capacity . Ensure that the system has enough capacity to accommodate snapshots.
• When configuring snapshots, review the snapshot retention policy that is associated with the storage resource. You may want to change the retention policy in the associated rules or manually set a different retention policy, depending on the purpose of the snapshot.
• Manual snapshots that are created with PowerStore Manager are retained for one week after creation (unless configured otherwise).
• If the maximum number of snapshots is reached, no more can be created. In this case, to enable creation of new snapshots, you are required to delete existing snapshots.
  If you cannot view the snapshots created for a storage object, add the Snapshots column to the table using the Show/Hide Table Columns. The Snapshots column displays the number of snapshots created for each object. Clicking the number opens the Snapshots window that provides detailed information for each snapshot.

Create a snapshot of a volume
About this task
If you want to create a single snapshot of a volume (and not as a part of an assigned protection policy), use the Create Snapshot option.
NOTE: You can use the same procedure to create a snapshot of a volume group.
Steps

1. To open the Volumes window, select Storage > Volumes.

2. Click the check box next to the relevant volume to select it and then select Protect > Create Snapshot.

3. In the Create Snapshot of Volume slide-out panel, enter a unique name for the snapshot, and set the Local Retention Policy.
   NOTE: Retention period is set to one week by default. You can set a different retention period or select the No Automatic Deletion for indefinite retention.

4. Click Create Snapshot.

Create a snapshot of a file system
About this task
If you want to create a single snapshot of a file system (and not as a part of an assigned protection policy), use the Create Snapshot option.
Steps

1. To open the Flie Systems window, select Storage > File Systems.

2. Click the check box next to the relevant file system to select it and then select Protect > Create Snapshot.

3. In the Create Snapshot of File System slide-out panel, enter a unique name for the snapshot, and set the Local Retention Policy.
   NOTE: Retention period is set to one week by default. You can set a different retention period or select the No Automatic Deletion for indefinite retention.

4. Set the File Snapshot Access Type.

5. If events publishing was configured on the NAS server, you can select to enable events publishing.

6. Click Create Snapshot.

Create a snapshot of a virtual machine
About this task
If you want to create a single snapshot of a virtual machine (and not as a part of an assigned protection policy), use the Create Snapshot option.
Steps

1. To open the Virtual Machines window, select Compute > Virtual Machines.
2. Click the check box next to the relevant virtual machine to select it and then select Protect > Create Snapshot.
3. In the Create Snapshot of Virtual Machine slide-out panel, enter a unique name for the snapshot.
4. Optionally, enter a short description.
5. Click Create Snapshot.

Create a thin clone
Thin clones are writable copies of a snapshot, volume, volume group, or file system that can be accessed by a host. Unlike a full clone, a thin clone is a space efficient copy that shares data blocks with its parent object and not a full backup of the original resource. A thin clone can be created directly as a copy of the parent object or using one of its snapshots.
Thin clones retain full read access to the original resource. You can modify the data within the thin clone while preserving the original snapshot.
Using thin clones, you can establish hierarchical points in time to preserve data over different stages of data modifications. If the parent resource is deleted, migrated, or replicated, the thin clone is unaffected.
Create a thin clone of a volume or volume group
About this task
You can perform the following actions on thin clones of volumes and volume groups:

• Map thin clones to different hosts.
• Refresh the thin clone.
• Restore the thin clone from a backup.
• Apply protection policies to thin clones.

Steps

1. Select Storage > Volumes or Storage > Volume Groups to open the relevant resource window.

2. Click the check box next to the relevant volume or volume group and then select Repurpose > Create Thin Clone.

3. In the Create Thin Clone slide-out window perform the following:
   • Enter thin clone name.
   • Enter description (optional).
   • Set performance policy (only for thin clones created from volumes) .
   • Set host connectivity (only for thin clones created from volumes).
   • Set protection policy.

4. Click Clone.

Create a thin clone of a file system
About this task
You can perform the following actions on thin clones of volumes and volume groups:

• Map thin clones to different hosts.
• Restore the thin clone from a backup.
• Apply protection policies to thin clones.

Steps

1. Select Storage > File Systems to open the File Systems window.
2. Click the check box next to the relevant file system and then select Protect > Clone File System
3. In the Create Thin Clone slide-out window, set the thin clone name and, optionally, a description
4. If events publishing was configured on the NAS server, you can select to enable events publishing.
5. Click Clone.

Create a thin clone of a snapshot
About this task
You can create a thin clone of a snapshot created for a volume, volume group, or file system.
Steps

1. Open the relevant storage resource window.
2. Click a resource to open its Overview window.
3. Click the Protection tab.
4. Click Snapshots to view the list of snapshots created for the resource.
5. Select a snapshot from the table and then select More actions > Create Thin Clone using Snapshot.

Using clones to access read-only snapshots from hosts
Mapping and unmapping block snapshots to hosts is not supported in PowerStore. To allow a connected host to access a snapshot, create a thin clone of the snapshot and map it to a host. After creating the thin clone, you can use the refresh operation to update the thin clone from different snapshots. For more information, see Refresh a storage resource.
File snapshots can be mounted on hosts either directly (to allow read-only access) or by creating a thin clone (to allow read-write access). To mount the file system directly, the snapshots can be exported as NFS export or SMB share.
You can export snapshots using one of the following access types:

• Protocol – The snapshot is exported with a new share name.
• .snapshot – You can see the snapshot on Unix/Linux under the .snapshot directory of the file system, and on Windows, by right-clicking the file system and selecting the Previous Version option.

Refresh a storage resource
The refresh operation is used to replace the contents of a storage resource with contents from a related resource (a clone or an indirect child snapshot). You can create a duplicate of the production environment to be used for various purposes (such as test and development, reporting etc.). To keep the duplicated environment up-to-date, it should be updated with a storage resource that includes the recent changes.
You can use the refresh operation in the following scenarios:

• Refresh a thin clone from the base volume.
• Refresh a storage resource or thin clone from another thin clone in the family.
• Refresh a storage resource or thin clone from a snapshot of a related thin clone or base volume.

For file systems, you can refresh a snapshot of a file system with its direct parent file system.
If you refresh the thin clone of a snapshot that has derivative snapshots, the derivative snapshots remain unchanged and the family hierarchy stays intact. If you refresh a volume group, the point-in-time image on all member volumes is also refreshed.
When refreshing a resource from a snapshot that was replicated from a remote system, check the creation time and source data time values to ensure that you are using the correct snapshot. The Source Data Time value of replicated snapshots reflects the original source data time, and the Creation Time value is updated to the time of replication.
NOTE: Because the refresh operation replaces the contents of a storage resource, it is recommended to take a snapshot of the resource before refreshing it. Creating a backup allows you to revert to a previous point in time.
Before refreshing a snapshot, it is mandatory to shut down the application and unmount the volume or file system that is running on the production host, and then flush the host cache to prevent data corruption during the refresh operation.
Refresh a volume using a snapshot
About this task
To refresh a volume using a snapshot:
Steps

1. Open the volume list window.
2. Click the volume from which the snapshot was taken to open its Overview window.
3. Click the Protection tab, and then click Snapshots.
4. From the snapshots list, select the snapshot you want to use for the refresh operation.
5. Click More Actions > Refresh using Snapshot.
6. In the Refresh using Snapshot slide-out panel, select the volume or clone you want to refresh from the Volume being refreshed drop-down list.
7. Select whether to create a backup snapshot for the refreshed volume (the option is selected by default).
8. Click Refresh

Refresh a volume from a related volume
About this task
You can refresh a volume using a related volume (a clone or an indirect child snapshot).
Steps

1. Open the volume list window
2. Select a volume and then select Repurpose > Refresh Using Related Volume.
3. In the Refresh using Related Volume slide-out panel, click the Select volume to refresh from and select the source volume.
4. Click Refresh.

Refresh a snapshot of a file system
About this task
You can refresh a snapshot of a file system with its direct parent file system.
Steps

1. Open the file system list window.
2. Click the file system from which the snapshot was taken to open its Overview window.
3. Click the Protection tab, and then click Snapshots.
4. From the snapshots list, select the snapshot that you want to use for the refresh operation.
5. Click More Actions > Refresh using Snapshot.
6. Click Refresh.

Restore a storage resource from a snapshot
The restore operation is used to reconstruct an environment following an event that may have compromised its data. You can use the restore operation to replace the contents of a parent storage resource with data from a direct child snapshot. Restoring resets the data in the parent storage resource to the point in time at which the snapshot was taken.
Before restoring a snapshot, it is mandatory to shut down the application and unmount the file system that is running on the production host, and then flush the host cache to prevent data corruption during the restore operation.
If you restore a volume group, all member volumes are restored to the point in time associated with the source snapshot. When restoring a resource from a snapshot that was replicated from a remote system, check the source data time value to ensure that you are using the correct snapshot.
Restore a volume or volume group from a snapshot
About this task
NOTE: To prevent data integrity issues, before restoring a volume, it is mandatory to shut down applications that are using the volume and take the volume offline on the host.
Steps

1. Check the check box next to the volume or volume group that you want to restore.
2. Select Protect > Restore from Snapshot.
3. In the Restore Volume from Snapshot slide-out panel, select the snapshot to use for the restore operation.
4. Select whether to create a backup snapshot of the restored volume or volume group (the option is selected by default).
5. Click Restore.

Restore a file system from a snapshot
About this task
Before proceeding with the restore operation, applications using the file system should be shut down and the file system taken offline on the hosts to prevent data integrity issues.
Steps

1. Check the check box next to the file system that you want to restore.
2. Select Protect > Restore from Snapshot.
3. In the Restore File System from Snapshot slide-out panel, select the snapshot to use for the restore operation.
4. Select whether to create a backup snapshot of the restored file system (the option is selected by default).
5. Click Restore.

Protection Policies

This chapter contains the following information:
Topics:

• Snapshot rules
• Replication rules
• Create a protection policy
• Modify a protection policy
• Assign a protection policy
• Unassign a protection policy

Snapshot rules
You can create snapshot rules to control parameters such as the frequency of snapshot creation, and snapshots retention period. Snapshot rules, combined with replication rules, enable you to configure and apply consistent data protection policies to storage resources based on the data protection requirements.
If you want to create a new snapshot rule in addition to the existing rules, it is recommended to review the business requirements with an administrator before proceeding. This can help in achieving and maintaining consistent policies across the system.
Create a snapshot rule
Steps

1. Select Protection > Protection Policies

2. In the Protection Policies window, click Snapshot Rules on the Protection bar .

3. In the Snapshot Rules window, click Create.

4. In the Create Snapshot Rule slide-out panel, enter a name for the new rule.

5. Set the following:
   ● Select the days on which a snapshot will be created.
   ● Set the frequency/start time:
   ○ For a snapshot to be taken at a fixed interval, select this option and set the number of hours after which a snapshot will be created.
   ○ For a snapshot to be taken at a particular time of the selected days, select the Time of day option and set the time and time zone.
   ● Set the retention period.
   ● For file snapshots , select the file snapshot access type.

6. Click Create.

Replication rules
A replication rule is a set of parameters the system uses to synchronize data in a replication session. The parameters include selecting a replication destination and setting a recovery point objective (RPO).
After you have configured a replication rule, you can choose to use it in a new or existing protection policy, which then automatically changes or applies the replication session parameters for any storage resource that uses the protection policy.
You cannot change a protection policy to use a different replication rule with a different remote system. To change a protection policy with a replication rule using a different remote system, remove the old policy before assigning a new one.
NOTE: Changing a remote system requires a full synchronization.
If you want to create a new replication rule in addition to the existing rules, it is recommended to review the parameters and your business requirements with an administrator before proceeding. This can help in achieving and maintaining consistent policies across the system.
Create a replication rule
Steps

1. Select Protection > Protection Policies.

2. In the Protection Policies window, click Replication Rules on the Protection bar .

3. In the Replication Rules window, click Create.

4. In the Create Replication Rule slide-out panel, enter a name for the new rule.

5. Set the following:
   ● Select an existing replication destination or configure a new destination.
   ● Set the RPO.
   ● Set the alert threshold.

6. Click Create.

Recovery point objective
Recovery point objective (RPO) indicates the acceptable amount of data, measured in units of time, that may be lost in case a failure occurs. When you set up a replication rule, you can configure automatic synchronization based on the RPO. Possible RPO values range from 5 minutes to 24 hours. The default RPO value is one hour.
NOTE: A smaller RPO interval provides more protection and consumes less space. However, it has a higher performance impact, resulting in more network traffic. A higher RPO interval may result in more space consumption, which can affect snapshot schedules and space thresholds.
Alert threshold
When you configure a replication rule, you can specify an alert threshold, which is the amount of time the system will wait before generating a compliance alert when a replication session does not meet the RPO. Setting the alert threshold to zero means that alerts will be generated if the actual synchronization time exceeds the RPO.
Create a protection policy
About this task
Create a protection policy to provide local and/or remote protection for your storage resources. Each protection policy can include one replication rule and up to four snapshot rules. A rule can be in multiple policies.
Steps

1. Select Protection > Protection Policies.
2. In the Protection Policies window, click Create.
3. In the Create Protection Policy slide-out panel, enter a name for the new policy.
4. Select the snapshot rules that you want to include in the policy or create a new snapshot rule (see Create Snapshot Rules).
5. Select the replication rules that you want to include in the policy or create a new replication rule (see Create Replication Rules).
6. Click Create.

Results
When you create a protection policy that includes a replication rule, the policy is automatically replicated to the remote system and assigned to destination resources created by the policy. The replicated policy and associated rules names are identical to the policy and rules on the source system with the name of the remote system appended at the end. Changes made to the original policy or included rules, are replicated to the remote system to maintain synchronization. After a replication failover, the replicated policy becomes active on the destination system.
The replicated policies and rules are managed by the system and are not displayed in the destination system policy and rules tables. However, you can see the rules details in the Protection tab of the replicating volumes or volume groups, by hovering over the replicated policy name. For protection policies that are assigned to metro volumes, an identical read-only policy is created on the remote system and can be viewed on the Protection Policies window of the remote system PowerStore Manager.
Modify a protection policy
You can modify a protection policy by adding and removing snapshot and replication rules.
About this task
NOTE: Changing the settings of a protection policy applies the new settings to all objects to which the protection policy is assigned. If you need to change the protection policy for one resource, it is recommended to create a new protection policy, and assign it to that resource instead.
You cannot change the replication destination on a replication rule used in protection policies which are assigned to one or more storage resources. To reconfigure replication to a different remote system, unassign the protection policy and assign a new one with a different replication rule. Unassigning a protection policy with a replication rule will delete the associated replication session and assigning a new protection policy will create a new one, which requires a full synchronization to the new destination.
Steps

1. Select Protection > Protection Policies.

2. Select the check box next to the relevant policy and click Modify.

3. In the Properties slide-out panel, you can modify the following parameters:
   ● Policy name
   ● Selected snapshot rules
   ● Selected replication rules

4. Click Apply.

Assign a protection policy
Assign a protection policy to one or more storage resources to apply the snapshot and replication rules included in the policy to the storage resource. The protection policy automatically performs snapshot operations and replication based on the specified parameters.
If a protection policy that meets your data protection requirements is available, you can assign it to a storage resource at anytime. When you assign a new protection policy that contains a replication rule to the storage resource, a complete initial synchronization is required.
You can assign protection policy to a storage resource during the resource creation or at a later stage.
For block storage protection, you can assign protection policies containing snapshot and/or replication rules to volumes and volume groups.
With file protection, PowerStore supports local protection (snapshots) at the file system level and remote protection (replication) at the NAS server level.
You can assign a protection policy to a NAS server only if it includes a replication rule. The replication rule will be applied to all file systems on the NAS sever and snapshot rules (if such exist) will be ignored.
You can assign a protection policy to a file system only if it includes a snapshot rule. The snapshot rule will be applied to the file system and a replication rule (if such exists) will be ignored.
With metro volumes, you can assign only protection policies that include snapshot rules. Policies that include a replication rule cannot be assigned to a metro volume.
Assign a protection policy to a storage object
About this task
Assign a protection policy to a volume, volume group, file system, or NAS server.
Steps

1. Select the check box of the storage resource to which you want to assign a protection policy.

2. Select Protect > Assign Protection Policy.
   NOTE: if you selected an invalid resource, the assign option is inactive. Hovering your mouse over the Assign Protection Policy displays a tooltip explaining why it is invalid for this action.

3. From the Assign Protection Policy slide-out panel, select the protection policy.

4. Click Apply.

Assign a protection policy to multiple storage objects
About this task
Assign a protection policy to multiple storage objects of the same type (volumes, volume groups, file systems, or NAS servers).
Steps

1. Select Protection > Protection Policies.

2. Select the checkbox a policy from the list and then select More Actions > Assign Protection Policy.
   The Assign Protection Policy slide-out panel provides a summary of all the storage resources that are already have an assigned protection policy.

3. From the Assign Protection Policy slide-out panel, select the resource type and then select the relevant objects from the resource list.

4. Repeat Step 3 if you want to assign the selected policy to additional resource types.

5. Click Assign.

Change the protection policy assigned to a storage object
About this task
NOTE: You can only change assignment of protection policies that do not have a replication rule, or if the remote system specified in the new policy is the same as the one specified in the old policy. To change assignment of a protection policy with a replication rule using a different remote system, remove the old policy before assigning a new one.
Steps

1. Select the relevant storage resource to open its Overview window.
2. Click the Protection tab.
3. Next to the assigned protection policy name, click Change.
4. In the Change Protection Policy slide-out panel, select a different protection policy.
5. Click Apply.

Unassign a protection policy
Prerequisites
Removing the protection policy from a storage resource results in the following:

• Scheduled snapshots and replication based on the rules associated with the policy stop.
• Existing snapshots remain, and are retained in the system, based on the snapshot rule settings when they were created.
• The destination storage resource stays in read-only mode. You can clone the destination storage resource to get a read/ write copy or change the replication destination attribute in the Properties page of the storage resource.

NOTE: You cannot unassign a protection policy while importing is in progress.
Steps

1. Select the check box of the storage resource to which you want to assign a protection policy.
2. Select Protect > Unassign Protection Policy.
3. Click Unassign to confirm.

Replication

This chapter contains the following information:
Topics:

• Remote systems
• Synchronization
• Failover
• Additional considerations for replication
• Virtual volumes replication

Remote systems
Both remote replication and metro protection require a remote system connection between two PowerStore systems. In PowerStore, the remote system connection is associated with the replication rule. You can create a remote system connection before configuring remote replication. If you are using PowerStore manager, you can create a remote system connection while creating a replication rule. It is also possible to create a remote system when configuring metro on a volume.
It is possible to create a remote connection between systems running different versions (1.x, 2.x, 3.x). The systems versions determine the supported capabilities. It is required that both systems run a PowerStore version for a capability that is included in this version to be supported. The following conditions should be met for replication of storage objects:

• Volume replication
  • The paired systems must run version 1.x or later.
• File replication
  • The paired systems must run version 3.x or later.
  • Connection type – TCP
• Virtual volumes replication
  • The paired systems must run version 3.x or later.
  • Connection type – TCP
• Metro
  • The paired systems must run version 3.x or later.
  • Connection type – TCP (see Metro pre-requisites and limitations)
  • Network latency – Low

The Remote Systems table (under Protection) displays the configured remote system connections. In the Remote Systems table you can:

• View remote systems information – You can see the name and IP of the remote system, supported capabilities (visible only if supported by both systems), and data connection status. The detailed view provides IP connectivity status for all initiators.
• Click a remote system to modify its attributes. You can change the description and network latency of a remote system connection.
• Select a remote system and click Delete to remove it. You cannot delete a remote system in the following instances:
  • When there are active replication sessions.
  • When there is a replication rule that is associated with the remote system.
  • When there are Metro volumes
• Select a remote system and click More Actions > Verify and Update to verify and update the connection to the remote system. Verify and update detects changes in the local and remote systems and reestablishes data connections, while also taking the Challenge Handshake Authentication Protocol (CHAP) settings into account.
• Monitor the management and data connection status for troubleshooting purposes.

Add a remote system connection
Configure a remote system connection between the source and destination systems. A remote system connection is used by asynchronous replication and/or metro.
Prerequisites
Before creating a remote system connection, ensure that you have obtained the following remote system details:

• System IP address
• User authentication credentials for connecting to the system

If you are using jumbo frames, ensure that jumbo frames are configured on both sides of the remote system connection (hosts and network ports), as well as on all ports between the two storage arrays. MTU size mismatch results in a warning in the following cases:

• Configuring a remote system connection.
• Modifying remote system connection settings.
• Using the Verify and update option.

NOTE: It is not recommended to change the MTU size of a storage network when a replication session is active. To change the MTU size:

1. Pause replication session.
2. Change MTU the storage network MTU size.
3. Run Verify and update on the remote system to confirm that no warning is issued.
4. Resume the replication session.

Steps

1. Select Protection > Remote Systems.

2. In the Remote Systems window, click Add.

3. In the Add Remote System slide-out panel, configure the following:
   ● Management IP address
   ● Description (optional)
   ● Network latency
   ● Username and password

4. Click Add.

Synchronization
PowerStore enables you to asynchronously update the destination resource with changes (such as changes in content, size, and membership) that occurred on the source resource since the last synchronization cycle.
Synchronization can occur either automatically – according to a set schedule – or manually. Snapshots are synchronized from the source system to the destination system, and maintain block sharing efficiency.
When a volume on the destination system is mapped to a host, the system sets the node affinity for this volume, and as a result, all I/Os are automatically directed to the selected node. There is no need to pause and resume the replication session for the I/O redirection to take effect. Setting node affinity for volumes on the destination system provides load balancing and prevents latency of replication. You can set the node affinity manually using REST API.
NOTE: If you cannot see the node affinity column in the Volumes table, add it using the Show/Hide Table Columns.
NOTE: When you add volumes to a volume group or change the size of the volume group during an asynchronous replication session, the changes do not immediately appear on the destination. You can either perform a manual synchronization or wait until the synchronization occurs based on the RPO.
For NAS servers, all file systems on a protected NAS server are synchronized from the source to destination system. When file systems are modified during an asynchronous replication session, the changes are reflected on the destination system at the next synchronization cycle.
You can synchronize a replication session when it is in the following states:

• Operating normally
• System paused

While a replication session is synchronizing, you can take the following actions:

• Planned failover from the source system
• Fail over from the destination system
• Pause replication sessions from the source or destination system
• Delete a replication session by removing a protection policy

If synchronization fails, the replication session is placed in a system paused state. When the system recovers, the replication session continues from the same point as when the system was paused.
Failover
Failing over a replication session includes switching roles between the source and destination systems and reversing the direction of the replication session.
There are two types of failovers:

• Planned failover – User initiated, includes synchronization between source and destination to prevent data loss.
• Unplanned failover – Initiated by the destination system in response to source system failure.

During a replication session failover, the system performs the following actions:

• Stop I/Os on the source object.
• Synchronize the source and destination storage objects (occurs only in a planned failover).
• Stop the replication session.
• Reverse roles between source and destination systems.
• Promote the latest object version on the new source.
• Resume I/Os on the new source (initiated by the user).

After a failover, you can access applications on the new source system to recover data.
Perform a failover test
After you set up a replication session, you can test the connection to ensure that your sites are correctly configured and prepared for disaster recovery.
During a failover test, the system performs a failover and production access is provided to the destination site using replicated data or a point-in-time snapshot. The destination storage resource is available in read/write mode, and production access is enabled for hosts and applications. You can verify your disaster recovery configuration while replication continues to run in the background.
When you wish to stop the failover test, select one of the following actions:

• Failover to the current test data – If you made changes to the data during the failover test, you can use the updated test data. This will stop the test and preserve the test data. Any data replicated from the source during the test will be discarded and the destination system will become the source.
  NOTE: You must acknowledge these changes before failing over to the test data.

• Stop the failover test – When you stop the test, production access to the destination will be disabled for hosts and applications and the destination storage resource will be updated with the latest data synched from the source system. You can create a backup snapshot of the test data before stopping the failover test.

Restrictions
A failover test can only be performed under the following conditions:

• The PowerStore version on both the source and destination system is 2.x or later.
• The replication session state is not Initializing, Failing Over, Failed Over, Paused for NDU/Migration, or Failover Test in Progress.

During the failover test, you cannot execute the following actions on the destination system:

• Change volume group membership
• Increase volume group size
• Change volume group name
• Start migration
• Remove a protection policy
  NOTE: You can still perform these actions from the source system.

You cannot perform a planned failover while a failover test is in progress. Stop the failover test to perform a planned failover. However, unplanned failovers may still occur uninterrupted in response to a disaster. If possible, it is recommended to stop the failover test before an unplanned failover, because any data replicated to the destination after the failover test started will be lost.
You can also pause and resume replication sessions during a failover test. If you delete a replication session during a failover test, the test will be cancelled.
Start a failover test
You can start a failover test from the current destination data, or from any snapshot.
There are two ways to start a failover test:

• From Protection > Replication, select the replication session you want to test, then select Start Failover Test.
• From the Protection tab of the resource, select Replication, then select Start Failover Test.

After the failover test starts, an alert is raised on the replication session. The alert is cleared after the test is stopped.
Stop a failover test
Before you stop the failover test, it is recommended that you unmount file systems and stop any running applications on the destination resource to avoid data corruption.
There are two ways to stop a failover test:

• From Protection > Replication, select the replication session that has a test in progress, then select Stop Failover Test.
• From the Protection tab of the resource with a test in progress, select Replication, then select Stop Failover Test.

You can also choose to create a snapshot to save the test data that was created during the failover test.
Planned Failover
When you perform a planned failover, the replication session is manually failed over from the source system to the destination system. Prior to the failover, the destination system is synchronized with the source system, to prevent any data loss.
Before performing a planned failover, make sure that you stop I/O operations for any applications and hosts. You cannot pause a replication session that is undergoing a planned failover.
During a planned failover, you can take the following actions:

• Perform an unplanned failover.
• Delete the replication session by removing the protection policy on the storage resource.

You cannot initiate a planned failover when a failover test is in progress.
You can initiate a planned failover test from the current source data, or from any snapshot.
There are two ways to initiate a planned failover:

• From Protection > Replication, select the relevant replication session, and then select Planned Failover.
• From the Protection tab of the resource, select Replication, and then select Planned Failover.

After a planned failover, the replication session is inactive. To synchronize the destination storage resource and resume the replication session use the Reprotect action. You can also select the auto-reprotect option before failing over, which automatically initiates the synchronization in the opposite direction (at the next RPO) after the failover is complete, and returns the source and the target system to a normal state.
Unplanned Failover
Unplanned failover occurs following source system events such as source system failure, or events that leads to downtime for production access. Unplanned failover is initiated from the destination system, and provides production access to the original destination resource from a point-in-time snapshot.
When you initiate an unplanned failover, you can select whether to use the most recent data copy or a snapshot of the data (if available) as the data source.
When the connection to the source system is re-established, the original source resource is placed into destination mode. Use the Reprotect option to synchronize the destination storage resource, and then resume the replication session.
NOTE: When performing file replicatoin, it is not recommended to modify the file mobility network after performing an unplanned failover. After the connection between the source and destination systems is restored, the result may be that both NAS Servers are in production mode.
Additional considerations for replication
During block replication, when the source system is paused for NDU and the destination system is up, the destination system status is changed to System_Paused. If the destination system is down during the source system NDU, when the destination system is up again, its status remains OK.
During file replication, when the source system is paused for NDU, the destination system remains in OK state regardless of its connectivity status.
Virtual volumes replication
PowerStore integrates with VMware Site Recovery Manager (SRM) to support asynchronous replication of virtual volume.
Virtual machine remote protection is configured using vSphere Storage Policy- Based Management (SPBM). For recovery from failure, failover of virtual machines is configured using VMware SRM.
VMware SRM is a VMware disaster recovery solution that automates recovery or migration of virtual machines between a protected site and a recovery site.
Snapshot and Replication rules that are created in PowerStore are exposed to vSphere and can be added to protection policies.
vSphere provides a storage policy to PowerStore during vVol creation.
A replication group, that includes virtual volumes that should be replicated together, is the replication and failover unit configured in vSphere.
To view the details of a virtual volume replication session:

1. Select Protection > Replication.
2. Click the replication session status to view it details.

The graphic in the replication session details window indicates that vSphere manages the replication session.
From the replication window you can do the following:

• View the replication session details.
• Rename the replication group.
• Pause and resume the replication session.
• Synchronize the replication session.

Pre-requisites
Before configuring virtual volume replication, ensure that the following pre- requisites are met:

• Both local and remote system must be connected and must have vVol capability (see Remote systems).
• Storage containers must be defined on both systems (Storage > Storage Containers > Create) so that they can be paired. If there is a single storage container on each system, the storage containers are paired automatically. Otherwise, it is required to manually specify the storage container destination (Storage > Storage Containers > [storage container] > Protection > Create).

Create a virtual volume replication session
About this task
For information about the required configuration on vSphere, see VMware SRM user documentation.
Steps

1. On PowerStore, create a replication rule.
   The replication rule is exposed to vCenter as a Replication capability.

2. On vSphere, create a policy using the exposed rule.
   A read-only copy of the protection policy, with an identical name, is added to PowerStore (visible on the Protection
   Policies table and marked with a lock icon.
   NOTE: You can also add snapshot rules to enable local protection.
   NOTE: It is not possible to create, modify, or delete a read-only protection policy, and to assign or unassign the policy to virtual machines using PowerStore. To perform this actions, use Storage Policy update in vSphere.

3. On vSphere, create a virtual machine, assign a storage policy with a replication rule to it, and associate it with a replication group.

Results
The replication group and replication session are created automatically in PowerStore (visible under Protection > Replication > [replication group session].
Virtual machine recovery
Site Recovery Manager (SRM) is a VMware disaster recovery solution that automates the recovery of virtual machines during failure states.
To enable virtual machine recovery, it is required to configure a recovery plan using SRM. A recovery plan runs predefined recovery steps on selected replication groups. The recovery steps include failover, reprotect, and failover test.
A protection group is created on vSphere, that includes one or more replication groups and a recovery plan. If failure occurs, the SRM runs the recovery plan on the virtual volumes in the replication groups.
In PowerStore, you can monitor the replication session status during recovery.
For additional details, see VMware Site Recovery Manager.

Metro Protection

This chapter contains the following information:
Topics:

• Pre-requisites and limitations
• Configure a metro volume
• Configure host connectivity
• Monitor metro resources
• Setting metro role
• Pause a metro volume
• Resume a metro volume
• Promote a metro volume
• Demote a metro volume
• End a metro volume
• Using protection policies with metro

Pre-requisites and limitations

Before configuring metro, consider the following limitations:

• Metro support is available only with PowerStore T model appliances. Metro is not supported with PowerStore X model appliances.
• Metro protection is enabled only for volumes.
• Metro protection supports FC/SCSI or iSCSI connected VMware ESXi hosts.

When a connection to a remote system is established, the system automatically detects the configuration and enables the supported capabilities for the remote system. To enable block metro capability, verify that the following conditions are met on both PowerStore systems:

• The two systems are running PowerStore 3.x or later.
• The latency on the remote system is low.
• The data connection type is TCP – When local and remotePowerStore systems running version 3.x (or later) are installed ,

TCP connection is automatically supported. However, when one or both of the PowerStore systems are running version 2.x, you need to upgrade the systems to 3.x to enable metro. Following the upgrade, an alert is displayed, requiring you to update the remote system connection type. Click the link in the in the displayed alert to open the Update Remote System Transport window. Then, click Update Transport.
NOTE: The alert is cleared only after transport is updated.
Configure a metro volume
About this task
Enabling metro configuration for a volume makes it visible to hosts from two PowerStore systems with a remote system connection.
The following volumes cannot be configured as metro:

• A volume clone
• A volume that is assigned with a protection policy that includes a replication rule
• A volume that is a member of a volume group
• A volume with a read-only protection policy
• A volume that is being migrated or imported
• A volume that is a read-only replication destination, left after replication is removed

Steps

1. Select Storage > Volume and select the checkbox of a volume.

2. Select Protect > Configure Metro Volume.
   The Configure Metro Volume slide-out panel is displayed.

3. Select a remote system or configure a new remote system.

4. Optionally, select the placement of the volume on the remote system.

5. Click Configure.

6. On the remote system, map the configured metro volume to a host.

Configure host connectivity
NOTE: Host support is provided for VMware vSphere metro storage cluster. Both Fibre Channel and SCSI connectivity are supported.
Host metro connectivity is configured on a local and remote PowerStore systems and enables hosts and applications to perceive physical volumes from the two systems as a single volume. When you configure metro connectivity for the host, select the preferred array to determine which system will retain access to the storage in case of failure.
To enable host metro connectivity, an ESXi host must be defined on both the local and remote systems and be connected to both systems.
When you create a new ESXi host, the Add Host wizard enables you to set the host connectivity:

• Local Connectivity – Provides host access only to the local system.
  NOTE: Local connectivity can also be used with metro volumes.

• Metro Connectivity – Provides host access to both local and remote systems. If you select this option, set system access:

  • Metro local on both systems – Latency and performance of host path are equal for both local and remote systems. The host will send I/Os to the local or remote systems based on its multipath considerations.
  • Metro optimized on the current system – Host path latency is lower for the local system and higher for the remote system. The host will always attempt to send I/Os to the local system (except for when the local system is down).
  • Metro not optimized on the current system – Host path latency is lower for the remote system. The host will always attempt to send I/Os to the remote system (except when the remote system is down).
    NOTE: Regardless of the configured connectivity, all hosts must be configured on the same vCenter cluster.
    NOTE: For an ESXi host mapped to a metro volume, it is recommended to use round robin Path Selection Plugin (PSP) with latency mode enabled.
    NOTE: In case one of the systems goes offline, the ESXi host enters an All Paths Down (APD) condition. To resolve this condition, it is recommended to configure vSphere HA. This configuration enables virtual machines on available ESXi hosts to restart and resolve the APD condition.

Monitor metro resources
About this task
You can monitor all the metro objects in the system and perform actions on selected resources or monitor the status of a selected metro volume.
Steps

1. From the Dashboard, select Protection > Metro.
2. Select the checkbox of a metro volume to view the possible actions that you can perform on that volume.
3. To view detailed information about a specific metro volume, click the status of the volume in the Metro Status column.
   You can also view detailed information about a metro volume from the Storage > Volumes page.
   a. Click the name of a metro volume on the Storage > Volumes page to display the volume information page.
   b. Then select the Protection card and select the Metro Volume tab to display the metro volume information.

Setting metro role
The system from which the metro volume is configured is automatically set as preferred upon metro volume configuration. The preferred system keeps host and production access and an active association with a protection policy when the metro volume is fractured or paused.
When the metro volume state is Operating Normally (Active-Active), you can change the metro volume role from preferred to non-preferred or non-preferred to preferred using the following options:

• Modify Preferred Role – Use this option to change the current role of a selected metro volume. This option can be used from both the preferred or non-preferred system.
  NOTE: This option is in the metro volume details window.

• Set Local Role to Preferred – Use this option to set the role of multiple selected non-preferred metro volumes to preferred. This option should be used before shutting down the preferred system for planned maintenance. Setting the non-preferred metro volumes to preferred allows the metro volume to continue host and production access during the shutdown.

Pause a metro volume
About this task
Temporarily pausing a metro volume is required in the following scenarios:

• When there are required configuration changes that cannot be performed when the volume is operating normally, such as changing the volume properties.
• When the preferred or non-preferred systems require maintenance, such as replacement of faulty hardware components or changes in network infrastructure.
• When there is a failure on the preferred system that requires promoting the non-preferred system to enable controlled recovery.

Pause can be initiated from either the preferred or non-preferred system. When a metro volume is paused, the synchronization between the systems is temporarily stopped. Production access and protection policies remain active on the preferred system.
When a metro volume is fractured, and there is no connection between the local and remote system, pause is implemented only on the local system (where it was implemented):

• When pause is initiated from the preferred system
  • Host and production access remains enabled on a paused, preferred metro volume.
  • Host and production access remains unchanged on the non-preferred metro volume.
• When pause is initiated from the non-preferred system:
  • Host and production access remains disabled, unless the metro volume has been promoted.
  • Since there is not network connectivity, the pause does not modify the preferred metro volume state.
• When connectivity is resolved, pause should be initiated from the remote system as well.

Steps

1. Select Protection > Metro.

2. Select the check box of the metro volume to pause and click Pause.
   The Pause Metro Volume slide-out panel is displayed.

3. click Pause to confirm.

Resume a metro volume
About this task
Resume can be initiated either from the preferred or from the non-preferred system.
When you resume a preferred, paused metro volume, the preferred system starts synchronizing data and snapshots with the non-preferred system. After synchronization is complete, the Metro volume status returns to an active/active state.
When you resume a promoted, (previously non-preferred), paused metro volume, the non-preferred system starts synchronizing with the preferred system (Reprotecting state) to return to active-active state.
NOTE: If a metro volume was paused for a long time, synchronization may take a while due to data accumulation on the preferred system.
If the non-preferred system was promoted, resuming the metro volume from the promoted non-preferred system synchronizes data from the promoted non- preferred system to the preferred.
Steps

1. Select Protection > Metro.

2. Select the check box of the metro volume to resume and click Resume.
   The Resume Metro Volume dialog box is displayed.

3. Click Resume to confirm.

Promote a metro volume
Prerequisites
The metro volume to promote must be in a F r a c t u r e d or P a u s e d state.
About this task
When the link between the two storage systems fails or when the non-preferred system is down, the synchronization between the systems is stopped and the metro volume becomes fractured. The preferred system remains active and continues to service I/Os. If the user is on the preferred system, no action is required and the systems synchronize when the issue is resolved.
When a failure occurs on the preferred system, the synchronization between the systems is stopped and the metro volume becomes fractured. Both systems stop servicing I/Os. To be able to access the metro volume, the user must promote the metro volume on the non-preferred system to enable host and production access to it until the preferred system recovers. If the user verifies that the preferred system is available, the metro volume on the non-preferred system can be promoted with no implication. When the user is on the non- preferred system, it is not possible to know the status of the preferred system (whether the system is down or the link between the system is down). In this case, promoting the metro volume on the non-preferred system may result in a situation where both systems continue to service I/O but do not synchronize.
Steps

1. Select Protection > Metro.
   The Metro page lists all the metro resources and makes it easy to evaluate all the impacted volume and prioritize promoting according to your considerations.
   NOTE: The metro status of the volume should be F r a c t u r e d.

2. Click the status of the metro volume to display the Metro Volume page and click Promote.
   The Promote Metro Volume slide-out panel is displayed.
   NOTE: Before the promotion takes place, a snapshot of the metro volume is taken.

3. Verify that you understand the implication of promoting the metro volume in case the remote system is servicing I/Os and verify that the remote system is down if possible.

4. Select the confirmation checkbox at the bottom of the Promote Metro Volume slide-out panel, and select Promote.
   The promoted state of the volume is indicated in the Metro Volume Details section of the Metro Volume page.

Demote a metro volume
About this task
When the preferred system runs out of storage space, the synchronization between the systems is stopped and the metro volume becomes fractured. Both systems stop servicing I/Os. In that case, the metro volume on the non- preferred system must be promoted to enable host and production access to it until the preferred system resolves the problem. To enable this state, the metro volume on the preferred system must be demoted first.
Steps

1. Select Protection > Metro.
   NOTE: The Metro page lists all the metro resources and makes it easy to evaluate all the impacted volume and prioritize promoting according to your considerations.

2. Click the status of a metro volume to display the Metro Volume page and click Demote.
   The Demote Metro Volume slide-out panel is displayed.

3. Verify that you understand the implication of demoting the metro volume in case the remote system is servicing I/Os and verify that the remote system is down if possible.

4. Click Demote.
   The demoted state of the volume is indicated in the Metro Volume Details section of the Metro Volume page.

End a metro volume
About this task
When you end a metro volume, the metro configuration is removed, resulting in two independent volumes. If the remote volume is not deleted, the system removes the protection policy assigned to it, unmaps the hosts and assigns it with a new, different SCSI WWN. You can end a metro volume either from the preferred or the non-preferred system.
Steps

1. Select Storage > Volume and select the checkbox of a volume.

2. SelectProtect > End Metro Volume.
   The End Metro Volume slide-out panel is displayed.

3. Select one of the following options from the slide-out panel:
   ● End metro and keep the volume on both the local and remote system.
   NOTE: The remote system unmaps the hosts and assigns a different SCSI WWN to the volume.
   ● End metro and delete the volume and any associated snapshots on the remote system.

4. Click End.

Using protection policies with metro
When an existing metro volume is assigned with a protection policy, or a volume with a protection policy is configured for metro, the same protection is applied to the metro volume on the both systems. The protection policy that is created on the remote system is read-only. Changes to the protection policy and snapshot rules can only be made to the policy created by the user (regardless of the storage system it was created on). The read-only policy is synchronized with the changes every 15 minutes.
User-initiated snapshots that are created on one storage system are also generated on the other system.
NOTE: Asynchronous replication is not supported with metro volumes. A protection policy that contains a replication rule cannot be assigned to a metro volume.
Assigning a protection policy can be done on either the local or remote system (either preferred or non-preferred).
Unassigning the protection policy should be done on the storage system where it was assigned. After the protection policy is unassigned from the volume in the local system, it is unassigned from the volume on the other system as well. Once the read-only protection policy is no longer being used by any metro volumes, it is automatically deleted from the system.
NOTE: When the policy cannot be unassigned from the storage system where it was assigned, due to a metro volume failure, the following is allowed:

• A read-only policy can be unassigned or swapped for a read-write policy from a preferred metro volume when it is fractured.
• A read-only policy can be unassigned or swapped for a read-write policy from a promoted non-preferred metro volume.

When the metro volume is fractured, snapshots are generated only on the active system and are synchronized to the other system following recovery.

Use cases

This chapter contains the following information:
Topics:

• Snapshot and thin clone use cases
• Replication use cases
• Metro protection use cases

Snapshot and thin clone use cases
You can use snapshots and thin clones to restore corrupted volumes and create test environments.
Snapshots are read-only copies that can be used to save the current state of an object. You can use snapshots to quickly recover data if there is corruption or user error. Snapshots cannot be directly accessed by a host.
Thin clones are writable copies of a snapshot, volume, or volume group that can be accessed by a host. Thin clones can be created directly as a copy of the parent object or using one of its snapshots. Both snapshots and thin clones are space efficient copies that share data blocks with their parent object.
Using snapshots and thin clones for partial recovery of a volume
You can use snapshots and thin clones to recover part of a volume, such as individual files or database records, from a previous point in time. First, create a thin clone using the snapshot that contains the data you need to recover. Then, provide host access to the clone, and recover data from the host.
Using snapshots to restore a volume or volume group
You can use snapshots to roll back a volume to a previous point of time, if there is corruption. To revert a volume or volume group to a previous point in time, use the volume restore operation and supply a snapshot from before the corruption occurred. The restore operation is instantaneous. You can also create a backup snapshot to save the state of the volume or volume group before you use the restore operation.
Using thin clones to test a patch before applying it to the production volume
Before installing a patch or software update of a critical application on a volume, you can take a thin clone of the volume, then apply the update to the thin clone. After you have installed the update and verified that the update is safe for your environment, you can install the update on the other volumes.
Create thin clones for development use
Instead of provisioning volumes or volume groups for each individual developer, you can create thin clones. Creating thin clones of the volume or volume group enables you to distribute the same data and configuration to each developer. The thin clones also take up less space than if you had created a full clone of the volume, or provisioned individual volumes or volume groups. You can also take snapshots of thin clones and replicate them.
Replication use cases
You can use replication for planned downtime, such as during inter-cluster migration, the installation of a major software update, and disaster recovery.
Intercluster migration
If you need to migrate a storage object to another PowerStore cluster, you can set up a one-time replication between the two clusters, followed by a planned fail over to the new cluster to complete the migration. After the migration, dismantle the source object to reclaim space on the original cluster.
Using replication for planned downtime
Planned downtime is a situation where you take the source system offline for maintenance or testing, while operating off the destination system. Before the planned downtime, both the source and destination are running with an active replication session. There is no data loss in planned downtime.
In this scenario, the source system, Boston, is taken offline for maintenance, and the destination system, New York, is used as the production system during the maintenance period. After maintenance is over, return production to the Boston system.
To start planned downtime, select Planned Failover on the Boston source system. The New York destination system is fully synchronized with the source to ensure that there is no data loss. The session remains paused, while the Boston source system becomes read-only and the destination becomes read/write. The New York destination storage resource can provide access to the host. On the New York destination storage resource, select Reprotect to resume replication in the reverse direction.
To resume operations on the Boston system after maintenance, select Planned Failover on the New York system. After the failover is complete, Reprotect on the Boston system.
NOTE: To replicate data from the destination to the source with the reprotect operation, ensure that there is a replication policy on the destination system that has a replication rule pointing to the source system. For example, if the regular replication session is from a site in Boston to a site in New York, the replication policy on the destination storage resource in New York must point to Boston.
Using replication for disaster recovery
In this disaster recovery scenario, the source system, Boston, is unavailable due to a natural or human-caused disaster. A destination system, New York, was created, which contains a full copy, or replica, of the production data. Data access can be restored by failing over to New York because a replication session was configured between the Boston and New York systems.
Using replicas for disaster recovery minimizes potential data loss. The replica is up-to-date with the last time that the destination synchronized with the source, as specified in the associated replication rule. The amount of potential data loss is based on the recovery point objective (RPO) setting in the associated replication rule. The replication session can be failed over to the New York destination system, using the latest data that was replicated from Boston.
After the session is failed over to the New York system, it becomes read/write. When originally establishing a replication session between the source and destination systems, the storage resource was given the correct access permissions to the host and share. Creating the correct host access on the destination system ahead of time reduces downtime in an event of a disaster.
To resume operations on the Boston system, when it is available:

1. From the New York system, select the Reprotect option, which resumes the replication session in the reverse direction.
2. After the systems are synchronized, select the Planned Failover option on the New York system.
3. Select the checkbox to auto-reprotect the system after failing over. Or, after the failover is complete, on the Boston system, select Reprotect.

NOTE: To replicate data from the destination to the source with the reprotect operation, ensure that there is a replication policy on the destination system that has a replication rule pointing to the source system. For example, if the replication session is from a site in Boston to a site in New York, the replication policy on the target storage resource in New York must point to Boston.
Metro protection use cases
Use Metro protection to ensure data high availability, load balancing and migration.
Using metro for high availability
A Metro volume is exposed using two distinct storage arrays that cooperate to expose a single Metro volume to application hosts by providing the same SCSI image and data. The hosts and applications running on them perceive two physical volumes as a single volume with multiple paths. As a result, hosts can access both sides of the Metro volume. If there is a link loss or failure of one of the systems, host access can still be maintained to the active system.
Metro protection provides bi-directional synchronous replication, where both sides of the Metro volume can be used for production. Instead of disaster recovery (by failing over a replication session to a remote system), Metro enables disaster avoidance by providing automatic synchronization between the systems without downtime.
Using metro for load balancing
With PowerStore metro volume, the data centers can be optimized to fully use PowerStore systems through an active/ active environment that enables workload balancing across PowerStore systems. Moving applications non-disruptively between PowerStore systems is simple and easy and can be done when capacity or performance balancing is required.
Using metro for migration
You can use metro volumes when there is a need to migrate workloads between PowerStore systems. Using metro volumes for migration is simple and easy to use, and it reduces the risk for data loss. With the metro volume option, the migration is non-disruptive and, when migration is complete, the metro volume can be either removed or kept for allowing an extremely fast recovery in the event of a system failure or even a full site failure.

October 2022
Rev. A03

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>