Recovery Manager Central Concepts Guide

Abstract
This document lists and captures the concepts of Recovery Manager Central product. The contents of this
guide are intended for users of the RMC product and the supported application plug-ins.

Part Number: P13156-003

Published: September 2019
Edition: 4
© Copyright 2019 Hewlett Packard Enterprise Development LP

Notices
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise
products and services are set forth in the express warranty statements accompanying such products and services.
Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable
for technical or editorial errors or omissions contained herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or copying.
Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard Enterprise has no
control over and is not responsible for information outside the Hewlett Packard Enterprise website.

Acknowledgments

Intel®, Itanium®, Optane®, Pentium®, Xeon®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in
the U.S. and other countries.

Microsoft® and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.

Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.

Java® and Oracle® are registered trademarks of Oracle and/or its affiliates.

UNIX® is a registered trademark of The Open Group.

VMware®, VMware® vCenter Server®, and VMware vSphere® Web Client are registered trademarks or trademarks of
VMware, Inc. in the United States and/or other jurisdictions.

SAP HANA® is the trademark or registered trademark of SAP SE in Germany and in several other countries.

Revision History
Document part number Edition Publication date Edition Notes
P13156-003 4 September 2019 Added Chapter Migration.
P13156-002a 3 June 2019 Updated the Peer Copy
topic.
P13156-002 2 May 2019 Added information for
Recovery, Copy Policies, and
Cloning for RMC-V and
RMC-S plug-ins. Also, added
information about Peer
Copy.
P13156-001 1 January 2019 Initial publication.
Contents

Documentation Overview................................................................................................ 6

Introduction to Recovery Manager Central.................................................................. 7

Recovery Manager Central.........................................................................................................................................................................................7
Application plug-ins....................................................................................................................................................................................................... 7
RMC deployment architecture diagram..............................................................................................................................................................8
Multitier data protection..............................................................................................................................................................................................9
Centralized Copy Policies.........................................................................................................................................................................................10

Preparing to work with RMC......................................................................................... 11

Storage Devices............................................................................................................................................................................................................. 11
Copy Repositories, Catalyst Stores, and Storage Pools..........................................................................................................................11
Support for MS SQL servers across multiple Active Directories.......................................................................................................11
Preparing to work with RMC-V.............................................................................................................................................................................11
Registering or managing the RMC-V plug-in from RMC GUI............................................................................................ 12

Copy Policies.................................................................................................................... 13
Copy Policy....................................................................................................................................................................................................................... 13
Snapshots..........................................................................................................................................................................................................................14
RMC-E Snapshots........................................................................................................................................................................................14
RMC-S snapshots........................................................................................................................................................................................ 15
Snapshot and Express Protect integrity check........................................................................................................ 15
RMC-V Snapshots....................................................................................................................................................................................... 15
RMC-O Snapshots.......................................................................................................................................................................................16
About Remote Copy....................................................................................................................................................................................................16
Remote Copy for RMC-O.........................................................................................................................................................................17

Protection......................................................................................................................... 18
Protection of VMware resources and Protection Groups......................................................................................................................18
Protect VMFS datastore..........................................................................................................................................................................18
Protect VVol VM.......................................................................................................................................................................................... 18
Protect VVol Datastore............................................................................................................................................................................19
Protect VMFS VM........................................................................................................................................................................................19
RDM Support................................................................................................................................................................................................. 19
Protection Groups.......................................................................................................................................................................................19
Group-level consistency Protection Groups.............................................................................................................. 20
Resource-level consistency Protection Groups........................................................................................................21
Protect multiple VMFS VMs................................................................................................................................................ 21
Protect multiple VVol VMs...................................................................................................................................................22
Protect multiple datastores................................................................................................................................................. 22
Protect a VM or datastore with Remote Snapshots..............................................................................................22
Protection Group consistency support matrix..........................................................................................................22
Protection of databases............................................................................................................................................................................................23

3
 Consuming Copies........................................................................................................... 24
Clone.....................................................................................................................................................................................................................................24
Types of cloning...........................................................................................................................................................................................24
Database cloning......................................................................................................................................................................................... 24
Cloning in RMC-O...................................................................................................................................................................... 24
Cloning in RMC-S.........................................................................................................................................................................................25
Cloning in RMC-V (VM and datastore cloning)......................................................................................................................... 25
Mount...................................................................................................................................................................................................................................27
Restore................................................................................................................................................................................................................................27
Restoring in RMC-E....................................................................................................................................................................................27
Restoring in RMC-S.................................................................................................................................................................................... 29
Preparing for the recovery process.................................................................................................................................30
Restoring SQL databases when transaction log backups are managed outside of RMC-S...........30
Restoring in RMC-V....................................................................................................................................................................................31
Restore VMFS VM..................................................................................................................................................................... 32
Restore VVol VM........................................................................................................................................................................32
Restore Datastore......................................................................................................................................................................33
Restore Protection Group.....................................................................................................................................................33
Restoring in RMC-O................................................................................................................................................................................... 33
Restore Copies.............................................................................................................................................................................33

View and Manage Copies............................................................................................... 35

Copies View......................................................................................................................................................................................................................35
Management of Copies in RMC.............................................................................................................................................................................35
RMC-V Copies................................................................................................................................................................................................................. 35
Viewing RMC-V copies.............................................................................................................................................................................36
Viewing Copies of a Protection Groups..........................................................................................................................................36
Copies of deleted VMware resources.............................................................................................................................................. 36

Reporting.......................................................................................................................... 37
Schedules...........................................................................................................................................................................................................................37
RMC-V Schedules..........................................................................................................................................................................................................38
Dashboard.........................................................................................................................................................................................................................38
RMC-V Dashboard........................................................................................................................................................................................................39

Migration...........................................................................................................................40
Migration in RMC.......................................................................................................................................................................................................... 40
Migration report...........................................................................................................................................................................................41
RME to RMC-E migration......................................................................................................................................................................................... 42
Overview - Migration Process..............................................................................................................................................................42
Migration prerequisites .......................................................................................................................................................................... 43
Configuring storage systems................................................................................................................................................................43
Registering all the RME 4.8.x servers............................................................................................................................................. 43
RME to RMC-E migration report........................................................................................................................................................ 44
Various RME resources post migration..........................................................................................................................................44
Migrating Remote Copy snapshots...................................................................................................................................................45
Migrating Remote Copy snapshots for nonsynchronous long distance (non-SLD)
configurations for a single RMC-E VM .........................................................................................................................46
Migrating Remote Copy snapshots for nonsynchronous long distance (non-SLD)
configurations for two RMC-E VMs.................................................................................................................................46
Migrating Remote Copy snapshots for synchronous long distance (SLD) configurations ........... 47

4
 Migration in RMC-O.....................................................................................................................................................................................................49
Migration in RMC-S......................................................................................................................................................................................................49
Migration prerequisites............................................................................................................................................................................49
Migration prechecks.................................................................................................................................................................................. 50
Post-migration considerations............................................................................................................................................................ 50
Migration in RMC-SH..................................................................................................................................................................................................51
Migration in RMC-V..................................................................................................................................................................................................... 51
Post-migration considerations............................................................................................................................................................ 51
Migrated remote Snapshots..................................................................................................................................................................52
Frequently asked questions about migration.............................................................................................................................................. 52

Remote Copy or Replication configurations...............................................................55

Remote Copy management by single RMC appliance.............................................................................................................................55
Remote Copy management by RMC appliance at each site................................................................................................................ 55
Sync replication for RMC.......................................................................................................................................................................................... 56
Supported configurations........................................................................................................................................................................................ 56

Advanced Concepts........................................................................................................ 58
Group to role mapping...............................................................................................................................................................................................58
Authentication for Active Directory users..................................................................................................................................................... 58
Security............................................................................................................................................................................................................................... 59
Firewall rules and port requirements...............................................................................................................................................59
Best practices for maintaining a secure appliance....................................................................................................................................59
Remote RMC appliance............................................................................................................................................................................................. 61
Secured appliance access.........................................................................................................................................................................................61
MS SQL server recommendations.......................................................................................................................................................................62
RMC-S virtualization support.................................................................................................................................................................................62
Microsoft Hyper-V environment........................................................................................................................................................ 62
VMware virtualization...............................................................................................................................................................................62
RMC-S support for MS SQL server on physical RDM disks................................................................................................ 63
RMC-E Virtualization Support...............................................................................................................................................................................64
RMC-O Virtualization Support.............................................................................................................................................................................. 64
RMC-SH Important points....................................................................................................................................................................................... 65

Websites............................................................................................................................66

Support and other resources.........................................................................................67

Accessing Hewlett Packard Enterprise Support.........................................................................................................................................67
Accessing updates........................................................................................................................................................................................................67
Customer self repair.................................................................................................................................................................................................... 68
Remote support............................................................................................................................................................................................................. 68
Warranty information................................................................................................................................................................................................. 68
Regulatory information............................................................................................................................................................................................. 69
Documentation feedback......................................................................................................................................................................................... 69

5
Documentation Overview
Document title What the document contains Where to find
Recovery Manager Central Tasks you can perform with the RMC
HTML — Recovery Manager Central 6.2.0
Online User Guide user interface.
Online User Guide

PDF — Recovery Manager Central 6.2.0

Online User Guide

Recovery Manager Central for Tasks you can perform with the vSphere
HTML — Recovery Manager Central 6.2.0
VMware Online User Guide Web Client for using RMC-V.
for VMware Online User Guide

PDF — Recovery Manager Central 6.2.0

Online User Guide

Recovery Manager Central Conceptual information about RMC Recovery Manager Central Concepts Guide
Concepts Guide features.
Recovery Manager Central Information to assist you during RMC Recovery Manager Central Installation
Installation Guide installation. Guide
Recovery Manager Central CLI Reference information about the RMC Recovery Manager Central CLI Guide
Usage Guide CLI commands usage.
Recovery Manager Central Troubleshooting information to assist Recovery Manager Central
Troubleshooting Guide when you encounter a problem. Troubleshooting Guide
Recovery Manager Central New features, enhancements, limitations, Recovery Manager Central 6.2.0 Release
Release Notes and fixes in the latest released version. Notes
SPOCK Information on supported HPE Storage Single Point of Connectivity Knowledge
Products and the relative environment, (SPOCK)
hardware, and software platforms.

6 Documentation Overview
Introduction to Recovery Manager Central
Recovery Manager Central
HPE Recovery Manager Central (RMC) software integrates HPE 3PAR, HPE Primera and HPE Nimble Storage arrays with
HPE StoreOnce backup systems to provide converged data protection. RMC facilitates policy-driven copy data
management for your business critical applications at speeds required for all-flash storage. RMC leverages snapshot
performance with storage-integrated backups to deliver flash speed application protection and copy data management
with less cost and complexity than legacy solutions. The software is also built for cloud, that allows you to leverage public
cloud for cost-effective long-term retention of your backups.
Key features
• Centralized policies to automate copy data management and data protection.
• Create and automate application-consistent snapshots to protect your applications from data loss or corruption risks.
• Support for multiple applications including VMware vSphere, Microsoft SQL Server, Microsoft Exchange, Oracle, and
SAP HANA databases. Integration with any other application can be scripted using RMC REST APIs.
• The Express Protect backups are much faster than traditional backups. Data is moved directly from primary storage to
protection storage without any intermediate server restrictions. These application-integrated, snapshot-based
backups are for additional protection against threats.
• The Express Restore feature ensures that only the changed blocks are efficiently read back from protection storage to
deliver much faster restores than traditional backup restores. The feature allows rapid recovery from any of the point-
in-time copies — backups or copies on public cloud.
• Create space-efficient virtual clones from any of the point-in-time copies to be used for secondary use cases such as
testing or development, analytics, and reporting.
• Detailed reporting, activity tracking, and email notifications.
•
Peer Copy feature that facilitates asynchronous periodic replication between two or more homogeneous or
heterogeneous storage systems.
• Simple and intuitive GUI designed for storage generalists and database administrators without requiring storage
specialist expertise.

Application plug-ins
HPE Recovery Manager Central (RMC) Software delivers unified data protection for your business critical application data
stored on HPE Storage arrays. RMC addresses a range of RPO/RTO objectives with flexible recovery options using
Snapshots, backups, and replicated data copies to meet a wide variety of Disaster Recovery requirements. RMC primarily
automates Snapshot-based protection on HPE 3PAR, HPE Primera, and HPE Nimble Storage systems. RMC currently
supports the following plug-ins:
• HPE Recovery Manager Central for VMware - (RMC-V) allows VMware administrators to create application-
consistent Snapshots and initiate rapid online recovery of datastores and VMs from the VMware vCenter Server
virtualization Management Console. With the RMC Express Protect feature, you can back up and restore VM
Snapshots using HPE StoreOnce.
• HPE Recovery Manager Central for Microsoft SQL Server - (RMC-S) is a data protection solution that provides rapid
recovery from point in time Snapshot or backup copies of a Microsoft SQL Instances/Databases. It allows SQL
Database Administrator to create, schedule, and manage application-consistent Snapshots of databases on both
Physical and Virtual SQL servers. Virtual SQL server includes protection of MS SQL databases/instances configured
with direct iSCSI/FC, RDM, and VMFS presentations of volumes coming from HPE 3PAR, HPE Primera, or HPE Nimble
Storage systems.

Introduction to Recovery Manager Central 7

 It also provides Express Protect feature to protect SQL databases lying on HPE 3PAR, HPE Primera, or HPE Nimble
Storage Volumes to HPE StoreOnce backup appliance.
• HPE Recovery Manager Central for Oracle - (RMC-O) is a data protection solution that provides rapid recovery from
point-in-time Snapshots of an Oracle database. Allows administrators to create, schedule, and manage Snapshots on
HPE 3PAR, HPE Primera and HPE Nimble Storage systems. Provides Express Protect feature as a second-tier of data
protection with backup of Oracle database volumes from HPE 3PAR, HPE Primera, or HPE Nimble Storage to HPE
StoreOnce. You can use RMC-O with either HPE StoreOnce to protect and restore Snapshots created by RMC-O.
• HPE Recovery Manager Central for SAP HANA - (RMC-SH) is a data protection solution that provides rapid recovery
from point-in-time Snapshots of an SAP HANA database.
• HPE Recovery Manager Central for Microsoft Exchange - (RMC-E) allows Exchange database administrators to
protect the Exchange databases and orchestrate data from HPE 3PAR, HPE Primera, or HPE Nimble Storage storage
volumes onto the HPE StoreOnce Backup appliance.

RMC deployment architecture diagram

RMC architecture diagram details the connections between RMC, HPE 3PAR, HPE Primera, HPE Nimble Storage and HPE
StoreOnce for deploying RMC on a VMware host.

RMC (VM)

Management Path Management Path

HPE Cloud Bank

Data Path

HPE 3PAR/ HPE StoreOnce

HPE Nimble Storage/
HPE Primera

Figure 1: Sample RMC deployment

• The connectivity between HPE 3PAR, HPE Primera and RMC appliance for data traffic is either over FC or iSCSI.
• The connectivity between HPE Nimble Storage and RMC appliance for data traffic is over iSCSI and FC.

• The connectivity between HPE StoreOnce and RMC appliance is over:

◦ CoFC (Catalyst Over Fibre Channel)

8 Introduction to Recovery Manager Central

 NOTE: The first CoFC back up performed on an RMC instance sets the value of Number of Devices per Initiator
Port to 64. In case you are modifying the value, you must manually reboot RMC for the modifications to take
effect. If the required number of paths are not available and if you are manually changing this value, the changes
may impact backup operations. If you are configuring additional FC ports for HPE StoreOnce, you have to
configure Number of Devices per Initiator Port in the HPE StoreOnce Management Console.

◦ CoEthernet (Catalyst Over Ethernet)

• The connectivity between RMC, HPE 3PAR, HPE Primera, or Nimble, and HPE StoreOnce for management traffic is
over IP.

Multitier data protection

With an increase in data access and usage, there is a significant increase in the liability to handle data. The bigger
challenge lies in securing and protecting data so that it can be effectively used and retrieved without any data loss. As a
database administrator, you can use HPE Recovery Manager Central to create, schedule, and manage snapshots. Using
Express Protect, you can create a second-tier of data protection with backup of database volumes from HPE 3PAR, HPE
Primera array to HPE StoreOnce.

Snapshot
Snapshot is a point-in-time copy of the base volume. RMC integrates with various applications to take application-
consistent snapshots at any given point-in-time. RMC can take application-consistent snapshots of VMware vSphere VMs,
Microsoft SQL Server, Microsoft Exchange, Oracle, and SAP HANA databases residing on 3PAR volumes. Only Microsoft
SQL Server is supported with HPE Nimble Storage at present. RMC can also take crash-consistent snapshots for any
application or file system data on both HPE 3PAR, HPE Primera and HPE Nimble Storage. Additionally, RMC REST APIs
can be used with scripted solutions combined with application quiescing scripts to create crash-consistent snapshots to
ensure application-consistent snapshots for any application not mentioned above, across both HPE 3PAR, HPE Primera
and HPE Nimble Storage.

Remote Snapshot
HPE 3PAR, HPE Primera Remote Copy feature helps you safeguard against disasters by keeping copies of data on a
separate HPE 3PAR, HPE Primera storage system, which can be placed at a remote location. HPE 3PAR, HPE Primera
Remote Copy Software provides RMC the capability to recover data from any protected site to a recovery site. Using the
Remote Recovery Configuration feature, you can create and manage Synchronous, Periodic, or Synchronous Long-
Distance Remote Recovery Sets at HPE 3PAR Remote Copy group level.
If there is disaster or failure of a storage system, HPE 3PAR Remote Copy solution enables you to recover data at either
sites.

Express Protect
Express Protect provides a second-tier of data protection with backup from HPE storage systems to HPE StoreOnce.
Backups to HPE StoreOnce are block-level copies of volumes, de-duplicated to save space, and can be used to recover
back to the original or a different HPE 3PAR, HPE Primera or HPE Nimble Storage, even if the original base volume is lost.

Catalyst Copy
Catalyst Copy is a copy of an Express Protect on another HPE StoreOnce system. You can also create a Copy for an
existing Catalyst Copy.

Cloud Copy
Cloud Copy is a copy of an Express Protect on a Cloud Bank Store. RMC also integrates with StoreOnce CloudBank
Storage technology which allows you to automate and schedule creating a copy on a public cloud such as Amazon S3 or
Microsoft Azure or on an on-premises object storage such as Scality. Reads and writes to and from the object storage

Introduction to Recovery Manager Central 9

 repository are designed with efficiency to ensure that you incur fewer charges from the cloud service provider by moving
only as less data as is required without having to rehydrate the deduplicated data.

Clones
Cloning enables you to create a HPE 3PAR, HPE Primera Read-Write snapshot or a Nimble Zero Copy Clone, which
facilitates creating copies of your VM or database for test/dev or other secondary data use cases without occupying any
additional storage space or affecting the performance of your production copy.

Peer Copy Snapshots

The Peer Copy feature in RMC facilitates asynchronous periodic replication between two or more homogeneous or
heterogeneous storage systems. Peer Copy is a complementary technology to HPE 3PAR, HPE Primera Remote Copy
replication for creating a copy of the data on a secondary storage system. This feature supports data replication across
HPE 3PAR, HPE Primera, and HPE Nimble Storage systems.
Peer Copy allows for one-to-many, many-to-one, and multihop topologies, managed from within the RMC GUI. You can
replicate data between HPE 3PAR, HPE Primera and HPE Nimble Storage systems in the following scenarios:

• Asynchronous replication of a single volume to multiple storage systems: Assume that a volume has to be
replicated to four different storage systems. In this case, you have to create four different Volume Sets from four
storage systems as the source and from a single storage system as the target.
• Simultaneous volume replication from multiple storage systems to a single system: In this case, volumes from
multiple HPE 3PAR, HPE Primera systems are replicated to a single HPE 3PAR, HPE Primera.
• Multihop: Assume that a volume in HPE 3PAR, HPE Primera (A) has to be replicated to a volume in HPE 3PAR, HPE
Primera (B). This same volume has to be replicated again to HPE 3PAR, HPE Primera (C). In this case, RMC creates
two different Volume Sets. One for replication between the systems A and B, and one for replication between the
systems B and C.

NOTE:
◦ To maintain data consistency, ensure that the target volumes in a peer copy relationship are not used for any
other purposes.
◦ From RMC 6.2.0 onwards, peer copy target volume is write-reserved for RMC appliance using SCSI persistent
reservation. This prohibits you to write directly on target volume while it is in peer copy relationship in RMC. The
reservation is cleared as part of split operation and volumes that become writable to other hosts.

MS SQL server transaction log backups

Transaction Log backup operation is used to back up the database Transaction Logs that contain all the committed and
uncommitted transactions. After a database failure, you can run the transaction log restore along with a full snapshot or
backup restore to recover data to any point-in-time or point-of-failure.
A full database backup must exist each time you initiate a manual or schedule a transaction-log backup.
When you initiate a manual or scheduled transaction log backup using RMC-S, the database log is truncated. RMC-S
supports transaction log backups for databases configured with full recovery model on MS SQL server.

Centralized Copy Policies

Copy Policy, a centralized template is a collection of protection rules and is used to protect volumes, databases, and
VMware resources. The centralized Copy Policies facilitate automating and monitoring the life cycle of Copies across
storage tiers. You are allowed to define the frequency and retention for each Copy Type.
You can use the default Copy Polices, customize a default Policy or even create a new Policy based on your requirements.

10 Introduction to Recovery Manager Central

Preparing to work with RMC
Storage Devices
Storage devices in RMC denotes a primary storage and backup storage. The primary storage device is an HPE 3PAR, HPE
Primera or an HPE Nimble Storage system. Backup storage device is HPE StoreOnce.
RMC enables you to add, edit, and delete a storage system from the GUI. When you add a Storage System, RMC allows you
to select the iSCSI protocol to configure a Storage System.

Copy Repositories, Catalyst Stores, and Storage Pools

While you register storage devices, you can select the required Catalyst Stores or Storage Pools to be used as Copy
Repositories. Copy Repositories are the Catalyst Stores on HPE StoreOnce that are used for Express Protect backups,
Catalyst Copies, and Cloud Copies from an RMC appliance. You can create catalyst stores using RMC and add it as Copy
Repositories. Copy repositories are also the storage pools that are used for Peer copy.

Support for MS SQL servers across multiple Active Directories

Assume that you have multiple SQL servers in a domain. You may have two such nontrusted domains running in two
different sites. RMC-S enables you to discover the active SQL server instances across different domains. RMC-S does not
mandate you to save cross domain hostname, username, and password in Manage Windows Credential options available in
the control panel.
Before you create snapshots, Express Protect backups or schedule tasks, ensure the following:
• Systems in two nontrusted domains are able to resolve each other using the commands ping, nslookup and
reverse nslookup test.

• In the AlwaysOn database configuration, your primary replica and secondary replica must be a part of the same
domain.
• When registering the MS SQL server, ensure that you specify NETBIOS. If you do not configure RMC-S, then you might
encounter unspecified error when executing RMC-S operations.

Preparing to work with RMC-V

Use the RMC installation wizard to install the RMC-V plug-in in a configured VMware vCenter environment. The installer
installs and registers the RMC-V plug-in (if you opt for the plug-in) with vCenter. Also, the installer enables you to add
storage systems to RMC. Post successful installation, the RMC-V plug-in is available in the vCenter. You can then perform
protection and recovery of VMware datastores and VMs using the RMC-V plug-in the vCenter user interface.

Preparing to work with RMC 11

 vCenter

RMC VM
RMC-V
Plug-in

Installs Deploys

RMC Installation
Wizard

NOTE: Use the vCenter GUI for RMC-V related tasks.

Registering or managing the RMC-V plug-in from RMC GUI

RMC-V plug-in can be registered and managed using the RMC GUI. After a successful installation of RMC with the VMware
plug-in, the vCenter server is displayed in the Hypervisor Servers screen in RMC GUI. You can use this vCenter server for
other application plug-ins such as RMC-S and RMC-O.
You need not launch the installer to register RMC-V from an existing RMC appliance. Use the Hypervisor Servers screen
in RMC GUI to register or unregister the RMC-V plug-in with RMC.

Procedure

1. Log in to RMC GUI.

2. Click HPE Recovery Manager Central > Hypervisor Servers.
3. Click + Hypervisor Server and then specify the server details.
4. Click OK.

To unregister the plug-in, from the Actions menu, click Unregister.

12 Preparing to work with RMC

Copy Policies
Copy Policy
A Copy Policy is a centralized template and is a collection of protection rules that defines what type of a Copy to create,
where the Copy resides (Copy Repository), when to create a Copy (frequency) and how to manage the life cycle of a Copy
(expiry and retention). You can apply a Policy to multiple application resources or volumes.
By default, RMC factory ships the following standard Copy Policies that you can readily use for multitiered protection:
• Platinum — Contains Snapshot, Express Protect, and Cloud Copy.
• Gold — Contains Snapshot, Express Protect, and Catalyst Copy.
• Silver — Contains Snapshot and an Express Protect.
• Peer Copy — Contains Snapshot and a Peer Copy.
• (Only for MS SQL application) SQL T-Log Backup Policy — Contains Snapshot and a Transaction Log backup.
• Bronze — Contains only a Snapshot.

During a Copy Policy creation, you can define the protection rules. A single Copy Policy can have multiple rules and
multiple schedules. Post server registration, all the application-specific default policies become available. Express Protect,
Catalyst Copy, and Cloud Copy have a Source and a Target. If no specific target is assigned, RMC assigns the target as
Auto. The same protection rule can have multiple schedules too. Schedule is basically the recurrence time that you define
for a rule with expiration and retention times.
Multiple Schedules
For a given copy type and source-target combination, if there are different policy requirements to be met at different
frequencies, multiple schedules can be created for the same rule. For example, a daily backup without verify option and a
weekly backup with verify option. Daily backup expiring after seven days and a monthly backup expiring after six months.
Multiple Rules

Copy Policies 13
 For a given copy type and different source-target combination, multiple rules of the same type can be created. For
example, two remote snapshot rules can be created in an SLD configuration.

•
NOTE:
For an Oracle snapshot protection rule, the following are file types:
Online
A point-in-time image of a database, which is taken while the database is open or online. The database is put in
backup mode before the snapshot is created. After the snapshot is complete, the database is taken out of backup
mode.
Datafile
A point-in-time image of all the datafiles of all databases, which is taken while the database is open or online. The
database is put in backup mode before the snapshot is created. This backup only takes a snapshot of only the
datafiles and not archives log destination. A snapshot created with this option is only useful when archive log files
generated during the creation of the snapshot are also available. Also, datafile creates an offline snapshot which is
a point-in-time image of a database taken while the database is closed or offline.
Archive log
A point-in-time image of archive log destination of the database, which is taken while the database is open or
online.

NOTE: As part of snapshot creation process, CONTROLFILE, pfile, and password files (if applicable) are
captured. These files can be used during the snapshot or express restore operation. A snapshot is in warning
state if meta data collection fails. Ensure that you rectify the errors so that the future snapshots are not created
in the state.

Snapshots
RMC-E Snapshots
When a Windows server hosting a Microsoft Exchange database is registered in RMC-E, all the databases hosted by the
server are automatically registered and are available for taking a snapshot. RMC-E supports databases and database log
files hosted on a single storage volume or on separate HPE 3PAR, HPE Primera or HPE Nimble Storage volumes provided
that both the volumes are hosted by the same storage device. RMC-E supports taking a snapshot on a single database
along with support for databases that have multiple copies.
RMC-E supports the ability to snapshot a particular database copy by selecting the database to snapshot and by
specifying the default Snapshot Server to take the snapshot. Alternatively, you can perform a snapshot on the active
database by specifying the Auto option. When multiple snapshot frequencies are specified in a policy, you can override
the default database instance by selecting an alternative Exchange Server from the selection box.
As part of the snapshot operation, RMC-E has the additional option to truncate the database logs and to verify the
integrity of the snapshot. When you select the Verify option, it is necessary to select a server to perform the validation
and it cannot be a production server.
RMC-E allows customers to protect and manage Microsoft Exchange Server mailbox databases that are stored on HPE
3PAR, HPE Primera, and HPE Nimble Storage virtual volumes that are mounted as a root drive (drive letter) or
subdirectories of other mounted drives (like a folder mount).
Scenario
Contrary to the recommendation where one logical disk must contain only one database. In this section, we describe a
scenario and the corresponding RMC behavior where there are multiple logical disks (partitions) created on one iSCSI
device exported from HPE 3PAR, HPE Primera system.

14 Copy Policies
 • A Snapshot taken for selected database is created for entire disk, not just for partitions containing database or logs.
• Snapshot or backup restore to parent fails.
• Snapshot restore to file works.
• Backup restore to other volume works.
• Snapshot mount works.
• Backup mount fails.

RMC-S snapshots
RMC-S creates instance-level snapshots and database-level snapshots using Microsoft volume shadow copy service
framework. Using RMC-S, you can also schedule jobs to create snapshots of instances or databases or both.
To create a snapshot, install and configure the MS SQL server instance on HPE 3PAR, HPE Primera volume or HPE Nimble
Storage volume. When RMC-S creates an instance-level snapshot, a snapshot of all the databases under that instance,
including the system databases for the instance is created. You can also exclude databases from an instance-level
snapshot. For example, create a snapshot of only system database or user databases by excluding either of the types. If
the databases are spread across multiple HPE 3PAR, HPE Primera or HPE Nimble Storage arrays, then RMC-S returns an
error. Similarly, when RMC-S creates a database-level snapshot, it creates a snapshot of the entire volume where the
database and log files reside. Before creating a database-level snapshot, you must ensure that the database data and log
files reside on the same HPE 3PAR, HPE Primera or HPE Nimble Storage volume.
RMC-S creates copy-only snapshot for availability group databases on secondary replica.
If you have HPE 3PAR Remote Copy set up, you can create a snapshot to be saved on Remote RMC. For the RMC-S GUI to
manage snapshots on the remote RMC appliances, you must register the remote RMC appliance.

NOTE: Assume that for an HPE Nimble Storage, you are creating an instance-level Snapshot including all the databases.
RMC-S cannot create a database-level Snapshot for the specified database as the Volume Collection is already created for
an instance-level Snapshot. Similarly, this behavior exists if you have already created a database-level Snapshot and then
later you are trying to create an instance-level Snapshot. For creating instance-level Snapshots, ensure to exclude the
databases that are not part of the existing HPE Nimble Storage Volume Collection.

Snapshot and Express Protect integrity check

RMC-S performs an integrity verification of the snapshot using Database Consistency Checker (DBCC). DBCC is a MS SQL
server utility that verifies the page-level integrity of databases. This check ensures that the verified snapshot is
application consistent. You can perform this check only at MS SQL server database level.
You can select to verify the snapshot to protect it with an Express Protect feature.
You can also select to verify the data integrity of the backed up data while taking an Express Protect backup.

RMC-V Snapshots
RMC-V creates application-consistent Snapshots of one or more virtual volumes that reside on HPE 3PAR, HPE Primera,
or HPE Nimble Storage systems that are used to create a VMware datastore or VM. These Snapshots are also called
Virtual Copies in the HPE 3PAR, HPE Primera, and HPE Nimble Storage systems. You can assign Copy Policies with
Snapshot rules to VMware resources — VM, datastore, storage folder, or a group of VMs or datastores using Protection
Groups.
Before creating Snapshots, ensure that the following conditions are met:

Copy Policies 15
 • Creating a VM-level Snapshot requires sufficient free space on the datastore where the VMDK file resides.
• VMware Tools is required in a VM to guarantee consistent and usable Snapshots. VMware Tools must be installed
on the guest VM when application consistency is required.
• The datastore and VMs must be in accessible state. RMC-V operations cannot be performed on a VM when the VM or
its datastore is in inaccessible state.

NOTE: For VMware VVols while protecting a VM, specify the maximum number of snapshots that you intend to retain.
The maximum number of snapshots that you can retain is 30.

RMC-O Snapshots
Prerequisites for RMC-O to create a Snapshot:
• The Oracle database must have two different volumes or volume sets for Datafile and Archlog from a same Storage
system (either from HPE 3PAR or Nimble or Primera) for a successful snapshot creation.
• Enable the archive log mode in the database.
• Set the log_archive_dest_n parameter to point to the archive log destinations.

RMC-O allows Oracle database administrators to create, schedule, and manage application consistent snapshots on HPE
3PAR. A database snapshot consists of multiple snapshots of underlying HPE 3PAR or HPE Nimble Storage or Primera
virtual volumes used by Oracle datafiles, archive log destination, or both, depending on the option that you specify.
RMC-O enables you to create the following type of snapshots:
Online snapshot
A point-in-time image of a datafile and archive logs, taken while the database is open or online. The database is put in
backup mode before the datafile snapshot is created. After the datafile snapshot is complete, the database is taken
out of backup mode.
Datafile snapshot
A point-in-time image of the datafiles of all databases, taken while the database is open. The database is put in
backup mode before the snapshot is created. This backup only takes a snapshot of only the datafiles and not archives
log destination. A snapshot created with this option is only useful when archive log files generated during the
creation of the snapshot are also available. When the database is in shutdown state, an offline snapshot can also be
created using this option.
Archive log snapshot
A point-in-time image of archive log destination of the database, taken while the database is open or online.
If the corresponding storage device is not registered in RMC-O, while registering the Oracle database, you are prompted
to enter the storage device details. If you decide to cancel the registration of storage devices, while database registration
and add it later, the volumes (recovery sets) are created during the first successful snapshot creation.
As part of snapshot creation process, CONTROLFILE, pfile, and password files (if applicable) are captured. These files
can be used during the snapshot or express restore operation. A snapshot is in a warning state if meta data collection fails.
Ensure that you rectify the errors so that the future snapshots are not created in the warning state. The archive log can be
optionally truncated by RMC-O, which helps in effective space management of Archive log destinations on successful
online snapshot creation.

About Remote Copy

HPE 3PAR Remote Copy feature is a data replication solution for HPE 3PAR, HPE Primera systems. Data can be replicated
to remote locations which allows the protection and sharing of data. Remote Copy when combined with appropriate
clustering technology, services, and processes, can serve as the foundation for a Disaster Recovery solution.

16 Copy Policies
 Remote Copy features and benefits include:
• Set up and test basic configurations quickly using HPE 3PAR, HPE Primera Management Console or HPE 3PAR
Command-Line Interface.
• Leverage existing infrastructure with native IP and Fibre Channel support eliminating the need for dedicated or
specialized infrastructure.
• Provide flexible and efficient multitenant disaster recovery with different configuration options and licensing for
only a portion of installed capacity.
• Achieve fast recovery time objectives (RTO) and stringent recovery point objectives (RPO) with multisite,
multinode synchronous long-distance replication configuration.
• Replicate only written data for bandwidth optimization improves the speed of initial synchronization and enables
conversion of fully provisioned volumes to thin-provisioned volumes.
• Automate transparent failover between sites at metropolitan distances, with an option to have a third copy at a
geographic distance with HPE Peer Persistence.
• Synchronous replication between sites at metropolitan distances, with the option to have a third copy at a
geographic distance site with synchronous long distance (SLD).

NOTE: Local and Remote snapshots are not supported in Synchronous Replication mode for HPE Nimble Storage.

For more information on Remote Copy feature, see HPE 3PAR Remote Copy Concepts Guide.

Remote Copy for RMC-O

The first Remote Snapshot created for a specific target mode (synchronous or periodic) through RMC-O creates additional
database entries corresponding to the HPE 3PAR, HPE Primera system on which, the snapshot is created. This database is
listed in the <database_name> (3PAR serial number) format.
A database listed with only the database_name corresponds to the HPE 3PAR, HPE Primera system that provides the
LUNs on which, the database is hosted and indicates that the snapshots or remote snapshots must be triggered from this
database. To perform further Copy Data Management (Express Protect, Catalyst Copy, Cloud Copy, Clone, and restore)
use the database that corresponds to the HPE 3PAR system on which the snapshot exists.

Failover or Failback Scenarios

If the remote copy groups are in failover or failback state, then a switch happens automatically when a new snapshot is
created on the database corresponding to the HPE 3PAR, HPE Primera system on which the failover or failback has
happened, the name of the database from which snapshot was triggered is replaced with the database_name only
signifying that the snapshots and remote snapshots can be triggered from this database and all other database name
have its corresponding HPE 3PAR, HPE Primera serial number.
After the switch over of database, protection can be continued as described in the previous section. Existing Protection
fails in failover or failback state, remove the protection from the previous database and add protection to the database on
which failover or failback has happened to continue protection.

Copy Policies 17
Protection
Protection of VMware resources and Protection Groups
To protect a VM, datastore, or a Protection Group, assign a Copy Policy. When you assign a Copy Policy, RMC creates and
manages the life cycle of the VM copies or datastore copies according to the defined copy rules.
The Protection (HPE RMC-V > Protection) screen enables you to configure and manage Protection Groups, Clones, and
schedules.

Protect VMFS datastore

You can apply protection at the datastore level to protect all the VMs and VMDKs that use the datastore space.

VM 1
VM
DK
1 Datastore 1 LUN 1 Entire LUN 1 is snapshotted
backed up with application
VMDK 2 consistency for all VMs
VM 2
Protected at Can restore: Datastore/
Datastore level Individual VMs
D K3
VM Can “Recover”: Datastore or
VM 3 VM or VMDK using clone/mount

Protect VVol VM
A VVol VM does not support time-based policy (expiry and retention) but supports numeric-based policy. Using the
numeric-based policy, you can configure the maximum number of Snapshots that you want to retain at a point-of-time.
The supported maximum number of snapshots per VM is 30. Also, ERT instant cloning is not supported on a VVol VM.

NOTE: To protect multiple VVol volumes, use Protection Groups.

Figure 2: Protection of VVol VMs

Storage Container
vvol LUN 1

VM 1

vvol LUN 2

Can restore/clone:
VM 2 Each VM separately
Protected at VM level

vvol LUN 3

VM 3

18 Protection
Protect VVol Datastore
Container-level protection and recovery are not supported.

Protect VMFS VM
Protecting a VMFS VM quiesces IO for only the selected VM in the VMFS datastore. This protection level is recommended
only when application consistency of other VMs in the VMFS datastore is not required.

VM 1 Datastore 2 LUN 2 Entire LUN 2 is snapshotted

backed up with application
VMDK 1 consistency for the VM
Protected at Can restore: VM or Datastore
VM level
Can “Recover”: Datastore or VM
or VMDK using clone/mount

RDM Support
The RDM Support table lists the support for virtual RDM attached to VM in a datastore and physical RDM attached to VM
in a datastore.

Table 1: RDM Support

Virtual RDM attached to VM in datastore Physical RDM attached to VM in datastore

App Consistent Crash Consistent App Consistent Crash Consistent

VM Supported Supported Not Supported Supported

Snapshot
Remote Supported Supported Not Supported Supported
Snapshot

NOTE: For datastore-level protection, RDMs of VMs are not considered.

Protection Groups
A Protection Group is a folder-like structure that can contain multiple VMs, datastores or storage folders that you want to
protect using RMC. Protection Groups are used for easier management of protection jobs and schedules. For example, you
can group all the VMs or datastores that are associated with an application or a department using a single Copy Policy.
You can then manage the Protection Group using a single schedule or protection job.
You can add or remove VMs and datastores from a Protection Group at any time. However, when associated with array-
based replication groups, you cannot modify the Protection Group.

NOTE: You cannot add a combination of VMs and datastores to a single Protection Group. Similarly, you cannot add a
combination of VMFS VMs and VVol VMs to a single Protection Group.

Use the Protect later option to create a Protection Group without a Copy Policy. Assign a Copy Policy later to protect the
Group and to create Copies.
A Protection Group can be created at group-level consistency or resource-level consistency.

Protection 19
Group-level consistency Protection Groups
Each resource in the group-level consistency Group is individually protected at the same consistency level. Before creating
a storage Snapshot, all the VMs are quiesced together at the same time. This consistency level is recommended only when
group-level consistency has to be maintained.
The VMs or datastores that you want to add to a group-level consistency Group must be from the same storage systems.
Assume a scenario where the VMDKs of VMs are not from a single datastore. The OS disk of VM1 is on Datastore1 and
the data disk is on Datastore2. To make this VM consistent, snapshot has to be created at the same time for both the
datastores. In this scenario, use the group-level consistency.
RMC Protection Group
Group level consistency
Datastore 1
VM 1
OS disks

All VMs are quiesced before

taking storage snapshot
VM 2
Protected at Can recover:
Group level Either entire group, datastore,
VM, or VMDK

VM 3
Datastore 2
Data disks

Figure 3: Sample scenario of protecting datastores or VMs in a Protection Group at group-level consistency

At the group-level consistency, the maximum number of datastores that you can add to a Protection Group is limited to
16.
Group-level consistency Protection Groups can be categorized into the following:

• Generic Group— A folder-like structure that contains either multiple datastores or VMs from a single storage system.
• Remote Copy capable Group— Group is created when you apply the Remote Snapshot rule on a VM or datastore that
is part of Remote Copy Group or device collections.

Remote Copy Groups and HPE Nimble Storage Volume Collections

Remote Copy Groups and HPE Nimble Storage Volume Collection can be protected only at group-level consistency. When
protecting Remote Copy Group and HPE Nimble Storage Volume Collection, RMC-V internally creates two Protection
Groups (local and remote) with all the datastores in the Remote Copy Group or Volume Collection. The local and remote
Protection Groups are created with the same name as the Remote Copy Group.
Remote Copy capable Groups — failover and failback scenarios
Perform the following steps after a failover and failback scenario:

1. Export usable LUNs to the host.

2. On VMware vCenter, perform Rescan All HBA to access the VMs and datastores.
3. Perform Update Recovery Manager Cache to update the role of Protection Groups.

If an existing Protection fails in a failover or a failback state, then remove Protection from the previous Protection Group.
To proceed, add Protection to the Protection Group on which failover and failback has occurred.

20 Protection
Resource-level consistency Protection Groups
Each resource in the resource-level consistency Group is individually protected, all at different consistency levels.
Individual VMs or all VMs in a datastore are quiesced independently and then separate storage snapshots are created.
When protection is requested at VM-level, only those VMs for which you are creating snapshots are quiesced. When the
VMs need similar protection and if the group-level consistency is not required, use the resource-level consistency.
You can add VVol VMs only to resource-level consistency Groups. These Groups do not support VMFS VMs.
Assume a scenario where a datastore contains VM1 and VM2 and only VM1 is added to a Protection Group. In this case,
only VM1 is quiesced but not VM2 even though both VMs are shown as protected. VM2 is protected with crash-consistent
Copy. To avoid this inconsistency, instead of adding individual VMs, you can add datastores to a Protection Group.

RMC Protection Group

Resource-level consistency

VM 1 Datastore 1

VM 2

VM 3 VMs in each datastore are quiesced

Datastore 2 separately and individual storage
snapshots are created
Protected at Can recover:
VM 4 Group level Either datastore, VM, or VMDK

VM 5
Datastore n

VM 6

Figure 4: Sample scenario of protecting datastores or VMs in a Protection Group at resource-level consistency

Protect multiple VMFS VMs

Multiple VMFS VMs can be added to a Protection Group at group-level consistency.
Assume a scenario where the VMDKs of VMs are not from a single datastore. The OS disk of VM1 is on Datastore1 and
the data disk is on Datastore2. To make this VM consistent, snapshot has to be created at the same time for both the
datastores. In this scenario, use the group-level consistency.

Datastore 1 LUN 1

VM 1
1
VMDK Entire LUN 1 and LUN 2 are
grouped and backed up
VM Datastore 2 LUN 2
DK Protected at Can restore: VM or Datastore
2
VM level Can “Recover”: Datastore or VM
or VMDK using clone/mount

Protection Group

Protection 21
Protect multiple VVol VMs
When multiple VVol VMs require the same level of protection, create a Protection Group at resource-level consistency.
Then you can assign the required Copy Policy to the Protection Group.
You can add VVol VMs only to resource-level consistency Groups.

Protect multiple datastores

To protect VMs sharing space from multiple datastores, add datastores to a Protection Group at group-level consistency.
When the VMs are in the same datastore and when there are multiple such datastores that require same level of
protection, use the resource-level consistency Protection Groups.
More information
Group-level consistency Protection Groups on page 20
Remote Copy capable Groups — failover and failback scenarios on page 20
Resource-level consistency Protection Groups on page 21

Protect a VM or datastore with Remote Snapshots

To protect a datastore or VM with Remote Snapshots, you can add a Copy Policy with Remote Snapshot rules. Remote
Snapshots are supported only at a group-level consistency. When protecting Remote Copy Group and HPE Nimble
Storage Volume Collection, RMC-V internally creates two Protection Groups (local and remote) with all the datastores in
the Remote Copy Group or Volume Collection. The local and remote Protection Groups are created with the same name as
the Remote Copy Group.
HPE 3PAR or
RMC Protection Group HPE Primera Remote Copy/
Group-level consistency HPE Nimble Volume Collection
Datastore 1
OS disks LUN 1
VM 1

All VMs are quiesced

before taking storage
snapshots
VM 2 When protecting with Can recover:
Remote Snapshot Copy
Either entire group,
Policy, RMC-V auto
creates Protection Group datastore, VM,
with all datastores or VMDK
VM 3

Datastore 2 LUN 2
Data disks

Use the Protection Group page or alternatively, use the Add Protection action on one of the datastores in the Remote
Copy Group or Volume Collection.

Protection Group consistency support matrix

Resource Group-level consistency Resource-level consistency
Datastore Yes Yes
VMFS VM Yes No
VVol VM No Yes
(Required for remote snapshots) Remote Yes No
Copy Group datastores

22 Protection
Protection of databases
Protect Once option allows you to protect your database by applying an existing Copy policy or creating a new copy
policy that contains a combination of a Snapshot, an Express Protect, and Catalyst Copy. You can use Protect Once option
and select a protection type from the following list:
• Using existing Copy Policy
• Snapshot
• Express Protect
• Catalyst Copy
• Cloud Copy
• Remote Snapshot

Protection 23
Consuming Copies
Clone
A clone is a complete and separate identical copy of an application resource or database, based on copies of actual data
and hosted on application tiers identical to the original environment, which and is both fully functional and separate in its
own right.

Types of cloning
Physical Clone
Physical clone enables you to restore data from an Express Protect or Catalyst Copy to a different set of volumes and
then creates an instance of the database.

NOTE:
• While creating a physical clone of HANA database that spans multiple HPE 3PAR, HPE Primera, ensure that LUN
size of target volumes is equal or greater than maximum size of source volumes.
• HANA database which spans across multiple HPE 3PAR, HPE Primera allows you to create physical clone on
single target array only.

Virtual Clone
Virtual clone from a new snapshot enables you to create a snapshot of a database in the current state. The clone of
the database is created from the newly created snapshot. Virtual clone from an existing copy enables you to select an
existing RMC copy and create an instance of the database.
Instant Clone
Instant clone enables you to instantly clone an application resource or a volume set from an Express Protect or a
Catalyst Copy. Instant clone is directly available from a HPE StoreOnce appliance. Instant clone (also known as
Element Recovery Technology (ERT)) provides you the ability to access application resources or volume sets as read-
only entities from HPE StoreOnce protected Express Protect copies, without repopulating the primary disk array
volumes.

Database cloning
Database cloning is a method that is used to create a writable copy of the existing database. The writable copy can be
created either from an existing point in time copy or clones can be directly created from the database.
Cloned databases can be used for Devops, analytics, and granular recovery.

Cloning in RMC-O
The clone procedure creates a fully functional single-instance database in OPEN state. Snapshot of type online or datafile
can be used to create a clone.

Cloning of database is performed in two steps of mount and clone. In the mount step, RMC-O creates read/write copy of
the selected snapshot and mounts it on the specified Oracle Server. The read/write copy is mounted on the user specified
mountpoints, if the mountpoints are not specified, RMC-O mounts the read/write snapshot on the default path
- /opt/hpe/rmc/oracle/data/<production_server_hostname>.ora.<production_sid>/
<rw_snap_id>. In the clone step, RMC-O generates pfile from user specified parameters and starts, recovers, and
opens the database. If the clone SID and the clone home are not specified, RMC-O creates the clone with same SID and
oracle home path present in production Oracle Server. If redo locations are not specified, RMC-O creates the redo
location under the default path - /opt/hpe/rmc/oracle/data/
<production_server_hostname>.ora.<production_sid>/<rw_snap_id>.

24 Consuming Copies
 A clone database can be created using a precreated snapshot or from a new snapshot. If a new snapshot is requested
before creating clone, then RMC-O creates an online snapshot before performing clone operations. Multiple clones of the
same snapshot can be created simultaneously on different Oracle Server. Cloning of database on the production Oracle
Server is supported for databases on raw File System or through Logical Volume Manager (LVM) only.
A clone database can be created with or without automatic recovery (applying archivelogs from the snapshot). If recovery
is selected, the clone database is open with reset log, otherwise, the clone database is in mounted status. The primary
database and the standby database of an Oracle Dataguard cannot coexist on the same Oracle server.
RMC-O does not create snapshots for virtual volumes used by Oracle database temporary files, to be consistent with
Oracle's backup procedure.

NOTE:
• If an Oracle database is created on multiple partitionings, then mount and clone operations are not supported.
• The minimum memory requirement on the backup server must be equal to the memory present on the application
server. The cloned database uses the same set of memory-related parameters (SGA, PGA, and so on) configured on
the application database.

Cloning in RMC-S
The clone feature enables you to create a fully functional copy of the original database on same or different SQL instance.
While performing a clone of a database, you can create a copy of the original database from any of the existing points in
time snapshots or backups (Express Protect or Catalyst copy). You can also create a copy of the original database with the
current state using the New option while creating database clone.
RMC-S supports all cloning mechanism as described in this document.

Physical Clone
To create a physical clone of a database, perform the following manual steps to complete the cloning process on SQL
production server:

1. Present the physical cloned disks to the SQL production Server from HPE 3PAR, HPE Primera or HPE Nimble Storage
array.
2. Clear the disk attributes such as Read-only flag, Hidden flag, Shadow copy flags on the cloned disks using
windows DISKPART tool.

3. Clear the Windows volumes attributes such as Read-only flag, Hidden volume flag, Shadow copy flag for
the volumes on cloned disks using windows DISKPART tool.

4. Mount the cloned volumes on the SQL production server using Windows Disk Management tool.
5. Attach the database using data files on mounted volume paths using SQL management studio or SQL command-line
tool such as OSQL/TSQL.
For more information, see Microsoft online documentation to change the disk and volume attributes, mounting
windows volumes and attaching SQL database.

Cloning in RMC-V (VM and datastore cloning)

RMC-V allows you to recreate a VM by cloning your data volume, which facilitates creating copies of your VM for test/dev
or secondary data use cases such as reporting or analytics. You can clone an entire datastore and recreate one or more
VMs. RMC-V internally mounts the snapshot or a backup to the target, rescans the disks and recreates the VMs.
The mount or clone operation is not supported on a Cloud Copy. An RMC-V Copy can be mounted on ESXi hosts,
Windows, or Linux systems.

Consuming Copies 25
 The Clone/Mount from Snapshot - VMFS datastores and VMs illustration describes a Clone/Mount operation to create
Clone of VMs or datastores from the Snapshot Copy.
Figure 5: Clone/Mount from Snapshot - VMFS datastores and VMs

VM 1
VM
DK
1 Datastore 1 HPE LUN

VMDK 2
VM 2
RMC Copy Policy
Snapshot
D K3
VM
VM 3

Clone of
Datastore 1
Register VM(s)

Copy Create new VMs(Clone) / Mount the snapshot

h or
Attac DK
VM

Granular recovery of VMDK from a Snapshot Copy

You can perform a granular recovery at the VMDK level either by attaching VMDK to an existing VM or copying a VMDK
to an existing datastore.

Clount/Mount from backup Copies

The Clone/Mount from backup illustration describes the workflow of applying a copy policy on a datastore and then using
clone/mount operation to create VMs and have a cloned copy of the datastore. The data recovery can be performed using
a virtual cloning, instant cloning, or physical cloning from the copy (backups) created out of the policy assignment.

26 Consuming Copies
 VM 1
VM
DK
1 Datastore 1 HPE LUN

VMDK 2
VM 2
RMC Copy Policy
Backup (Express Protect and
D K3 Catalyst Copy)
VM
VM 3

Recover Data Using Create new VMs

Snapshot - Express Restore (Clone) / Mount
(Virtual Clone)
Clone of
Datastore 1
Register VM(s)
Another volume (Physical Clone)

opy (RMCV seamlessly creates new

c h or C volume, DS and recovers the copy)
At ta
K
VMD
Element Recovery Technology
(ERT) - Instant Recovery (Instant Clone)

Figure 6: Clone/Mount from backup

Granular recovery of VMDK

You can perform a granular recovery at the VMDK level either by attaching VMDK to an existing VM or copying a VMDK
to an existing datastore. Use attach VMDK option to attach the VMDK files to an existing VM. Use detach VMDK to undo
attachment of VMDK disks from an existing VM. You can perform all the VMDK operations from a cloned or mounted
Copy.

Mount
Mount operation makes a writable copy of the application entity available to the production server. This writable copy can
be later used to peform recovery or cloning.

Restore
Restore operation allows you to recover a volume set or an application entity to a given point in time using copies from
different protection tiers. The copies can be Snapshots, Express Protects, Catalyst Copies, and Cloud Copies.

Restoring in RMC-E
Restore Snapshot
Volume restore and file copy restore types are recommended in a disaster type scenario where the current database has
become corrupted. RMC-E does not perform a validation of the snapshot prior to restore and it is the responsibility of the
user to ensure the integrity of the Exchange database snapshot. Volume and file copy restore processes have a large
dependency on running Microsoft Exchange Management Shell (EMS) commands and windows OS calls. Occasionally,
attempts to bring the database back online after a restore may fail and the user may have to perform certain Exchange or
Windows command-line operations manually. In these situations, the required Actions are clearly documented in the
Activity page of the RMC GUI.
RMC-E supports the following types of snapshot restore:

Consuming Copies 27
 • Volume - A volume type restore rolls back the parent volume with data of the selected snapshot.
• File Copy - A file copy restore rolls back to the selected snapshot by explicitly copying over Exchange database files.
• Mailbox

Restore Remote Copy Snapshot

The options to restore Remote copy Snapshots are identical to those for conventional snapshots but restore to a parent
volume is only possible in the following situation:
• Peer persistence is configured for exchange database volumes.
• The storage device on which the snapshot resides is the primary storage device (IE storage has failed over).
• The Remote Copy group to which the database volume belongs has stopped.

If peer persistence is not configured and the primary storage volume is still accessible, then File Copy restore is the
recommended restore approach. Before using File Copy Restore, ensure that the secondary storage device is added as a
target on the Windows Exchange Server and the Windows Exchange server is added as a host on the secondary storage
device. If the primary storage server has failed, then, before performing the File Copy restore, new volumes for the
exchange database has to be created and exported to the primary exchange server, the volumes have to be mounted
using the same drive letter as the original volumes and the database and log directories have be created on the new
volumes.

Volume restore
At the start of a volume restore, an attempt is made to unmount the Exchange database in Microsoft Exchange, and
Exchange is prepared for restore. Parent volumes are unexported from all the connected hosts and the volume restore
operation is performed. Once restore has finished, the parent volumes are exported back to the original host. The volumes
are released (made writable on the windows OS) and finally the database is mounted on the Microsoft Exchange server.

File Copy restore

At the start of a file copy restore, an attempt is made to unmount the Exchange database in Microsoft Exchange, and
Exchange is prepared for restore. The snapshot is mounted on the target server and the file copy operation is performed.
Once restore has finished, the snapshot is unmounted and finally the database is mounted on the Microsoft Exchange
server.

Mailbox Restore
Mailbox restore is different from the other types of restore. Mailbox restore does not involve the restore of the whole
Exchange database but only the restore of individual mailbox or mailbox folders. Before performing a mailbox restore, the
snapshot must be first mounted using the Clean option. Mailbox restore jobs are configured by selecting a source mailbox
or mailbox folder and selecting a target user mailbox where the restored mail items are sent. Frequently, the source and
target mailboxes are the same. The restored mail is always copied to a folder called Recovered by HPE in the target
mailbox. The responsibility of target mailbox owner is to manage individual emails restored inside the Recovered by HPE
folder. Typically the target mailbox user logs on to the mailbox and searches, finds, and copies individual emails to restore
from the Recovered by HPE folder and deletes all the unwanted restored emails.

Backup Restore
Parent volume type of restore is recommended in a disaster type scenario where the current database has become
corrupted. RMC-E does not perform a validation of the backup prior to restore and it is the responsibility of the user to
ensure the integrity of the Exchange database backup.
RMC-E supports the following types of backup restore:

28 Consuming Copies
 • Parent Volume
• New Volume
• Mailbox
• New Snapshot

Parent Volume Restore

At the start of a parent volume restore, an attempt is made to unmount the Exchange database in Microsoft Exchange,
and Exchange is prepared for restore. Parent volumes are unexported from all the connected hosts and the volume
restore operation is performed. Once restore has finished, the parent volumes are exported back to the original host, the
volumes are released (made writable on the windows OS) and finally the database is mounted on the Microsoft Exchange
Server. Parent Volume restores have a large dependency on running Microsoft Exchange Management Shell (EMS)
commands and windows OS calls. Occasionally, attempts to bring the database back online after a restore may fail and the
user may have to manually perform certain Exchange or Windows command-line operations. In these situations, the
Actions required are clearly documented in the Activity page of the RMC GUI.

Mailbox Restore
Mailbox restore is different from the other types of restore as does not involve the restore of the whole Exchange
database. Mailbox restore process restores the individual mailbox or mailbox folders. Before performing a mailbox restore,
the backup must be first mounted using the Clean option. Mailbox restore jobs are configured by selecting a source
mailbox or mailbox folder and selecting a target user mailbox where the restored mail will be sent. Frequently, the source
and target mailboxes are the same. The restored mail is always copied to a folder called Recovered by HPE in the target
mailbox. The responsibility of target mailbox owner is to manage individual emails restored inside the Recovered by HPE
folder. Typically the target mailbox user logs on to the mailbox and searches, finds, and copies individual emails to restore
from the Recovered by HPE folder and when finished, deletes all the unwanted restored emails.

Restore Constraints
Restoring a protection point in a Database Availability Group (DAG) environment operates with restrictions. The
Exchange Server software does not test a corrupt passive copy of a mailbox database (in the Failed or
FailedAndSuspended state) to determine whether it is restored to a working copy when mounting the database.
Also, you cannot move the active copy of the database to a copy in this state. Reseeding is the only mechanism to restore
a corrupt passive copy supported by Microsoft.
The Exchange plugin prevents a requested restore from proceeding if it detects the target database copy is in this state
(a corrupt passive copy). In this situation, the correct means of restoring the database is to restore to a healthy passive
copy or the active copy (regardless of whether it is corrupt or not). In the former case, the healthy passive copy is
temporarily promoted to the active role. Reseed the other database copies from the freshly restored copy to return the
corrupt passive copies to a usable state.

New Snapshot
A backup may be copied to a new snapshot of any copy for the parent database. This includes the original parent
database, regardless of whether it retains the original parent volumes for backup. Restoring to a new snapshot does not
interfere with the operation of the Exchange database.

Restoring in RMC-S
RMC-S supports SQL server databases recovery from snapshot and backup. Recovering from snapshots and backups
enables you to perform a point-in-time or point-of-failure or a specific date and time recovery operation.
The restore method is automated and brings the databases into a running state.

Consuming Copies 29
Preparing for the recovery process
During the recovery process, database is moved to an offline state. After the recovery process has completed, RMC-S
automatically moves the database to online state.
If the recovery is performed at the instance level or system database level, the instance goes offline during the restore
process, and post recovery, the instance becomes online. RMC-S allows you to add databases to SQL availability group
along with point-in-time restore operation when restore operation is performed on Primary availability group replica
instance.
Point-in-time recovery using RMC-S
Point-in-time recovery is useful for recovering from logical errors. Point-in-time recovery allows you to restore the
database to an older point-in-time state of the database when the snapshot or backup were created.
With this recovery approach, you are allowed to put database in No Recovery mode to apply the transaction logs in case
the transaction log backups are managed by a user outside of RMC-S.
Point-of-failure recovery using RMC-S
Point-of-failure recovery is useful if you cannot afford to lose any data during system failure. Recovery consists of the
following tasks:
• Creation of the tail of log backup of the transaction log of database.
• Restoration of the last full and subsequent transaction log backup managed by RMC-S until the system failure.
• Restoration of the tail of log backup to bring the database to a state it was before the system failure.

NOTE: As a part of the point-of-failure restore process, the following scenarios may occur:
◦ If any transaction in the log backup in the log chain is lost or damaged, restore is done until the transaction logs
before the missing transaction log records.
◦ If the tail of log backup cannot be taken for database, the database is restored to the latest point in time copy
available with RMC-S.

Specific date and time recovery using RMC-S

This recovery option is useful in recovering a database to any specified date and time. In this recovery process, RMC-S
recovers the database to the specific date and time provided with the STOP AT option while restoring transaction log
backups managed within it.

NOTE: If there are no transaction logs back ups available, for restoring the database according to the specified date and
time, RMC-S recovers the database with the snapshot or backup copy taken at a point just after the specified date and
time.

Restoring SQL databases when transaction log backups are managed outside of RMC-S
If you are using RMC-S transaction log feature for creating transaction log backups, then RMC-S replays transaction log
backups automatically during restore process to recover the database to the wanted state. Whereas, if you are using any
third part tool other than RMC-S (for example, SQL Management Studio or SQL command-line tool (TSQL/OSQL) or other
backup application) to manage transaction log backup, perform the following steps while recovering the databases:

1. For a point-in-time restore, perform the following:

30 Consuming Copies
 a. Restore the full snapshot or backups (Express Protect, Catalyst copy, or Cloud copy) and select the advanced No
Recovery option while restoring database using RMC-S.
b. Replay the transaction log backup with the correct sequence to the wanted point-in-time using preferred tool used
for transaction log backup.

2. For a specific date and time restore, perform the following:

a. Restore the full snapshot or backups (Express Protect, Catalyst copy, or Cloud copy) and select the advanced No
Recovery option while restoring database using RMC-S.
b. Replay the transaction log backup with the correct sequence.
c. Use WITH STOPAT option with specific date and time while replying the transaction log backup containing the
transactions until the wanted specific date and time.
For restoring transaction log with STOPAT option using TSQL command-line tool, you can refer to the following
example:
RESTORE LOG [DB2] FROM DISK = N'C:\Program Files\Microsoft SQL Server
\MSSQL11.MSSQLSERVER\MSSQL\Backup\DB_Log.trn' WITH STATS = 10, STOPAT =
N'2016-11-25T14:30:34'

3. For perform point-of-failure restore, perform the following:

a. Create a tail-log backup of database using the preferred transaction log backup tool.
b. Restore the most recent full snapshot or backups (Express Protect, Catalyst copy, or Cloud copy) and select the
advanced No Recovery option while restoring database using RMC-S.
c. Replay the transaction log backup with the correct sequence.
d. Replay the tail-log log backup of the database.

Restoring in RMC-V
Restore operation is the process to move the data back to the parent volume. The existing data is lost and is overwritten
with the data from the Copy.
Restore using Snapshots
Restore can be performed at the datastore level. The data and configurations of all VMs in the datastore are restored to
point-in-time of the Copy.
Restore can also be performed at individual VM level.
Restore from other RMC-V Copies
Similar to restoring using Snapshots, you can restore a VM or datastore from other RMC-V Copies such as Express
Protect, Catalyst Copy, or a Cloud Copy.

Consuming Copies 31
 Table 2: Restore

Level of Copy Type Clone/Mount (Recreate VM) Restore

restore

Datastore or From Snapshot Supported Supported

VM-level
Restore From backups Supported Supported

VVol VM From Snapshot Supported Supported

Restore
From backups Supported Supported

Restore VMFS VM
A VM can be restored from a Copy of datastore or Protection Group.

VM 1

Datastore 1 LUN 1

VM 2
RMC Copy Policy
Snapshot/
Backups

VM 3

Restore – specific VM

NOTE: The VMFS VM restore operation clones the VM from a Snapshot or backup Copy and then migrates (using the
VMware vMotion feature) the restored VM to the parent datastore.
If the VM that is being restored is of the size 10GB, then before restoring, ensure that there is a free space of 10GB
available on the datastore. If a restore fails, or there are space constraints, you can manually recover the VM using the
Clone option and then relocate to the parent location.

NOTE: Post a VM-level restore operation, the additionally attached VMDKs that are from different datastores are
consolidated or copied to VM datastore. The attached datastores are disassociated from the VM.

NOTE: Post restoring a VM from an Express Protect, the powered off VM is in powered on state.

Restore VVol VM
Restores the Snapshot or backup Copy back to the parent container.

32 Consuming Copies
 Vvol Virtual Machine Restore
Storage Container
HPE LUN
RMC Copy Policy on VM1
VM 1

Copy (Snapshot/
HPE LUN Backups)

VM 2

Restore/Clone
HPE LUN

VM 3

Restore Datastore
Restore can be performed at the datastore level. The data and configurations of all VMs in the datastore are restored to
point-in-time of the Copy.

VM 1 VMFS datastore and VMs restore

VM
DK
1 Datastore 1 LUN

VMDK 2
VM 2
RMC Copy Policy
Copy (Snapshot/
K3 Backups)
V MD
VM 3 Restore

Figure 7: Restore datastore

NOTE: If the datastore-level Snapshot that you are restoring has no virtual machines, the datastore loses all its
associations with the older Snapshots and job schedules.

Restore Protection Group

Restores all the resources in a Protection Group.

Restoring in RMC-O

Restore Copies
RMC-O provides the following options to restore copies and recover Oracle databases:
Complete recovery of an Oracle database
Complete recovery of an Oracle database option brings the Oracle database in an OPEN state (available for
transactions), restored to the specified point in time without any intervention. For a complete recovery of an Oracle
database, RMC-O performs the following:

Consuming Copies 33
 1. Prerestore steps (shutdown database instances, dismount diskgroups or unmount file systems, and deactivate
logical volumes).
2. Restore at volume level (Detach base volumes, restore the volumes, and then attach back the base volumes).
3. Post-restore operations (Mount diskgroups or activate logical volumes and mount them, restore controlfile and
recover the database to a point in time specified in the GUI).
To perform a complete recovery of an Oracle database, you have to select Automate Restore Database and
select Yes for the Automate Database Recovery option. Select the specific Point In Time or to the Copy Point
In Time to which, you have to recover the database and then select the Restore controlfile option, for a complete
recovery of the database on the Restore page.

NOTE:
• If automate recovery fails in post restore steps, for any reason, user can manually perform the post restore steps
and bring the database to OPEN state.
• Complete recovery of an Oracle database is available only for online snapshots or backups.
• If restoring from a copy with a different type of the Oracle database, the controlfile must be restored.

Incomplete recovery of an Oracle database

Incomplete recovery of an Oracle database option brings the Oracle database in STARTED state, you have to
manually perform controlfile restore and recover database to OPEN the oracle database for transactions after restore
is complete. For an incomplete recovery of an Oracle database, RMC-O performs the following:

1. Prerestore steps (shutdown database instances, dismount diskgroups or unmount file systems, and deactivate
logical volumes).
2. Restore at volume level (Detach base volumes, restore volumes, and then attach back the base volumes).
3. Post-restore operations (Mount diskgroups or activate logical volumes and mount them, Startup nomount on the
Oracle database). You have to manually recover the database once the RMC-O restore task is completed.
To automate restore only of an Oracle database, you have to select the Automate Restore Database on the
Restore page.

Non-Automated restore of an Oracle databases

Non-Automated restore of an Oracle databases option performs only volume level restore. All pre- and post restore
steps must be performed manually. This can be performed by clearing the Automate restore option in the GUI
restore dialog. For detailed steps on pre- and post restore, see the Recovery Manager Central 6.2.0 Online User
Guide.

NOTE: If you have added disk to the existing Nimble volume group in LVM, and you to perform a restore using a
precreated object:
• Restore succeeds but the post restore steps and automated recovery fail.
• Manually detach the additional volumes that are not part of the copy select for restore and bring up the file systems
and mount points and eventually recover the database.

34 Consuming Copies
View and Manage Copies
Copies View
The Copies view in the RMC GUI has the following sections:
Job Status
The Job Status option enables you to view the jobs that have run in the last hours or days. Based on the selection of
the time frame from the Job Status menu, the type, and the corresponding number of Copy Type jobs that have failed
out of the total number of attempted jobs get listed.
Copies
The Copies section lists the various Copy Types that are currently associated with a selected database. This section is
generated based on the Protection Type that you select to protect your database from the Protect Once option from
the RMC GUI Actions menu.
Scheduled
The Scheduled Jobs section lists the Copy Policy that is associated with a selected database. This section displays all
the details that are contained in the assigned Copy Policy. It lists the different Copy Types, the execution frequency,
the target device, the date and time stamps for the last execution, the last successful execution, and the next
scheduled execution.

Management of Copies in RMC

The Copies section lists the various Copy Types that are currently associated with a selected database. The actions on the
Copy Types can be performed from the corresponding Copy Type window. For example, when you select a snapshot and
click the underlined value, a window listing all the available snapshots appears. The window allows you to perform the
following operations based on the selected Copy Type:

Copy Type Operations

Snapshot Protect, Edit, Delete, Verify*, or Download Metadata*.
Express Protect Protect, Delete, Mount, Restore, Verify, or Edit.
Catalyst Copy Protect, Delete, Edit, or Verify.
Remote Snapshots [For RMC-O, RMC-E, RMC-V, and RMC- Protect, Edit, Delete, Mount, or Validate.
S]
Transaction Log Delete and Restore.
Cloud Copy Protect, Edit, Delete, Mount, or Restore.
Clone Attach, Detach, or Remove.
Peer Copy Attach, Detach, or Remove.
* Applicable for RMC-O and RMC-SH.

RMC-V Copies
Get a single pane of glass view of all the copies of VMs or datastores with health status and the copy jobs scheduled for
execution. Use the RMC-V Copies tab of the protected VM or datastore to manage the copies.

View and Manage Copies 35

Viewing RMC-V copies
To manage RMC-V Copies, restore, clone, or to view job schedules of a specific VMware resource, navigate to a VM or
datastore and then click Configure > HPE RMC-V Copies.
Alternatively, use the All Resources screen to search copies by VM or datastore name.

Viewing Copies of a Protection Groups

To view or manage RMC-V Copies of a Protection Group, navigate to HPE RMC-V > Protection > Protection Groups.
Select a Group-level consistency Group and then click Copies.

Copies of deleted VMware resources

You can view the RMC created copies of a VM or datastore that have been deleted from the VMware inventory. Navigate
to HPE RMC-V > Deleted Resources. There is an option to clone the Copies of a VM or datastore. You can also restore
Copies of a VM, but not a datastore.

36 View and Manage Copies

Reporting
Schedules
After the Copy Policies are assigned to resources, schedules are auto created by RMC. The Schedules (HPE Recovery
Manager Central > Schedules) screen provides an overview of all the schedules that the appliance is running.
The Job Density graph projects the workload of RMC over a time period — 24 hours, 7 days, or 30 days. The spikes in the
graph denote the time when the workload on RMC is high and the troughs denote that the workload is low. Based on the
pattern observed from the graph, Hewlett Packard Enterprise recommends you to plan your new jobs when the workload
on RMC is low.
The Recovery Objectives graph provides details about the Copy Policies that you have assigned for various resources,
and how these resources are protected by Recovery Point Objectives (X-axis) and Recovery Time Objectives (Y-axis)
combination. The RPOs represent the frequency of schedules and the RTOs represent the time taken to recover data. The
Y-axis of the graph describes the tier of protection and hence, the time taken to recover your data. For example, a Cloud
Copy takes the maximum time to recover.
To view the schedules specific to an application plug-in, use the Application drop-down option.
The following schedule details are listed:
Application Type
The application plug-in for which the schedule is set.
Resource Name
The application resource or Volume Set for which the schedule is set.
Copy Policy
The Copy policy assigned to the resource.
Next Run Time
The time when the schedule is set to run next.
Recent Runs
Displays the summary of the recent five runs that occurred for all the copy types in the schedule.
The expanded schedule view lists the following details:
Copy Type
The Copy type for which the schedule is set.
Frequency
The time interval after which the next schedule is set to start.
Target Device
The location where the copies are created.
Next Run Time
The time when the schedule is set to run next for each Copy type.
Recent Runs
Displays the last five run statuses for each Copy type.

Reporting 37
RMC-V Schedules
Assigning a Copy Policy to a VM, datastore, or a storage folder creates the schedules. All the schedules of an RMC-V
appliance can be viewed and managed from the Schedules (HPE RMC-V > Protection > Schedules) screen. Using the
Manage Schedules tab, you can view, delete, edit, suspend, and resume schedules that you created for the VMware
resources.

The refresh icon can be used to update the latest schedule information on the page. Use the edit button to edit a
schedule. To view details specific to a schedule, click the resource name. Use the delete button to delete a schedule.

Use the pause icon to suspend a schedule and use the play icon to resume a suspended schedule.
In the Scheduled Jobs section, the following schedule details are listed:
Resource Name
The VM, datastore, storage system, or Protection Group for which the schedule is set.
Copy Policy
The Copy Policy assigned to the resource.
Next Runtime
The time when the schedule is set to run next.
State
The state of the schedule — suspend, resume, expired, or expires.
Recent Runs
Displays the last five runs for each Copy type.

Dashboard
After the Copy Policies are assigned to resources, and the schedules are created by RMC, you can use the Dashboard
(HPE Recovery Manager Central > Dashboard) to monitor protection jobs. You can filter the dashboard charts based on
the application plug-ins that you select. The dashboard provides a high-level information on the Scheduled (to be run
later in the day), Completed, Running, and Failed jobs in the last 24 hours. The Dashboard reports are collated and
cached periodically or when the data is available.
The dashboard provides you the following charts:
Copy Policy Execution
The Copy Policy Execution chart provides success to failure ratio of the completed protection jobs in RMC. The graph
maps every execution of the policy over the time period that you set. The graph is derived from the calculation of the
expected number of runs, the actual number of runs, and also the number of runs that are skipped due to system

issues. To download the copy policy execution data, click the download icon. A CSV file is downloaded and
consists of data for a selected application plug-in. The details include policy name, number of expected runs,
successful runs, missed runs, and failed runs. The details are listed for each resource and for each Copy type.
Copies By Type
Displays the number of copies that are available for each Copy type.
Copies By Age
Provides you an account of the cost of Copies. The graph displays the types of Copies and the age of these Copies.
Using this chart, you can understand the effective way of storing copies in the right tier of storage, according to the
age of the copy. Hewlett Packard Enterprise recommends you to store the Copy that you want to use for a longer
term on a cheaper storage, such as cloud storage.

38 Reporting
 Backup Efficiency
Displays the effective savings that you get by using RMC over a time period — 24 hours, 7 days, or 30 days. The
graph displays the savings with RMC optimized and incremental backup and snapshot of the delta backups taken
over time based on the data changes.
Copy Policy Protection Tiers
Displays the number of resources and their levels of protection based on the current policy assignments. For example,
if a resource is protected by a snapshot and an express protect backup, the protection level for that resource is 2.

RMC-V Dashboard
The dashboard provides a high-level information on the Scheduled (to be run later in the day), Completed, Running, and
Failed jobs in the last 24 hours. The dashboard reports are collated and cached periodically or when the data is available.
To access the RMC-V dashboard, click Shortcuts and then click the HPE logo . Alternatively, click the Menu drop-
down list and then click HPE RMC-V.
The dashboard provides you the following charts:
Copy Policy Jobs
The Copy Policy Execution chart provides success to failure ratio of the completed protection jobs in RMC. The graph
maps every execution of the policy over the time period that you set. The graph is derived from the calculation of the
expected number of runs, the actual number of runs, and also the number of runs that are skipped due to system
issues.
Copies By Type
Displays the number of copies that are available for each Copy type.
Copies By Age
Provides you an account of the cost of Copies. The graph displays the types of Copies and the age of these Copies.
Using this chart, you can understand the effective way of storing copies in the right tier of storage, according to the
age of the copy. Hewlett Packard Enterprise recommends you to store the Copy that you want to use for a longer
term on a cheaper storage, such as cloud storage.
Backup Efficiency
Displays the effective savings that you get by using RMC over a time period — 24 hours, 7 days, or 30 days. The
table displays the actual backup volume size and the delta volume size that is backed up.
Protection Summary
The chart displays the number of VMs and their protection tiers based on the current policy assignments. For
example, if four VMs are protected by a Snapshot and an Express Protect, the protection tier for the four VMs is two.
In another example, if five VMs are protected by a Snapshot, an Express Protect, and a Cloud Copy, then the
protection tier for the five VMs is three.
The table displays the summary of VMs and datastores hosted on the RMC supported HPE storage systems. A count
of VMs and datastores in protected and unprotected states are displayed. The table also displays the number of
Protection Groups in RMC. The number is clickable and redirects to the Protection Group page.

Reporting 39
Migration
Migration in RMC
With changes and enhancements to simplify the RMC user experience, starting RMC 6.0.0 release, new resources were
created. Starting RMC 6.0.0, the changes and enhancements were performed for the following:
• Management of policies and schedules
• Remote snapshot creation
• Copy data management.

To use these enhanced features, the older versions of RMC (only RMC 5.0.x versions) have gone through a migration
process.

Table 3: RMC over versions

Versions 5.0.x Versions 6.0.0 and 6.1.0

Snapshot Sets to create a local or Remote Snapshot.

Copy Policy and workflow were introduced. Where, a Copy
Policy is collection of different set of schedules that have
details of recurrence, expiry, retention, source of Copy,
target of Copy and other advanced options. Copy Policy in
simple terms is a summary of how to protect the resource.
A workflow is assignment of copy policy to a protection
resource.

Backup Sets to create Snapshot and Express Protects.

All the scheduled jobs and policies associated with a
One-click copy to create Snapshot, Express Protect, and protection resource is migrated to a new or existing Copy
Catalyst Copies. Policy, and the creation of workflow by assigning the Copy
Policy is schedules or policies migration.

Migration prerequisites

• Create a VMware or Hyper-V Snapshot of RMC and Windows VM to roll back to an older state. This Snapshot is useful
when the migration is unsuccessful.
• Configure Catalog Protection. The RMC configuration can be protected by backing up the configuration data on to a
shared location or HPE StoreOnce. If RMC is down and permanently unavailable, you can deploy a new RMC and
restore the backed-up catalogs.
• For Remote Copy migrations, register the source and target storage systems with all the RMCs involved.
• All the source and target storage systems are reachable over network from RMC appliance.

Post migration
• If the migration is unsuccessful, you can retry the process. RMC moves all the previous files to archival directory and
initiates the migration.
• A Copy Policy generated of migration has the same number of frequencies and scheduled jobs as of the migrated
protection resource.
• A Copy Policy creates a rule for the following scenarios:

40 Migration
 ◦ Source of any Copy types (Snapshot, Express Protect, and Catalyst Copy) differs.
◦ Target of Copy types differs.

• A Copy Policy is reused for different protection resource if it has the same number of rules, frequencies per rule,
recurrence, and expiry or retention value match for the frequencies and source or target of copy matches.
• All RMC 5.0.x schedules are converted to Copy Policies after migration.
• When you accept the report by clicking Close on the Report screen after login, upgrade reports are not be seen for
RMC 6.0.0 and RMC 6.1.0 to RMC 6.2.0 upgrades as there is no Data migration performed.
• Migrated job counts do not get updated in the Job Status of the Migrated databases and Instances. However, new jobs
are updated.
• You need to wait till all the migration related tasks are complete.

Migration report
Post a migration and upgrade operation, log out of the appliance and relogin to view and download the Migration Report.
The migration report screen contains the details of all the resources that were involved in the migration process. The
migration report screen displays the Workflows with their health status. The Download Report option allows you to
download the Migration Report CSV format file for further analysis. The migration report contains the following fields:
App type
The RMC plug-in that was selected for migration.
App resource type
An application-specific resource that was used to backup data.
Category
The copy type that was used for a backup.
Schedule name
The name of the schedule that was associated with the copy policy.
Frequency details
The frequency of the scheduler.
Copy policy name
The name of the Copy Policy created for resource migration.
App resource name
The assigned name for the application resource type.
Status
The status of the application resource.
Messages
The details of the errors encountered during the migration process.
Recommended actions
The suggested corrective actions to rectify the issues encountered during migration.

NOTE: [Only for RME]

Migration 41
 Migration report can be viewed once the migration operation is completed. You can access the migration report form the
Associated Data option of the Migrate RM for Exchange (RME) Data task in the Activities page.

RME to RMC-E migration

There are various prerequisites and processes required to migrate data from HPE 3PAR Recovery Manager (RME)
versions 4.8.0, 4.8.1, or 4.8.2 to HPE Recovery Manager Central for Microsoft Exchange (RMC-E) version 6.2.0. Post
migration, all the local and remote snapshots along with their policies and schedules are migrated from RME 4.8.x to RMC-
E 6.2.0.
During the migration process, objects like recovery sets and their attributes are in a volatile state and hence, Hewlett
Packard Enterprise recommends you to not perform any other task during this time and allow the migration to complete.
All scheduled tasks running during the migration process window fail with an undefined state. The failure of scheduled
tasks has no impact on the migration process and does not impact any RMC-E tasks after the migration is complete.

NOTE: The term 4.8.x used refers to RME 4.8.0, 4.8.1, and 4.8.2. RMC-E does not support Microfocus Data Protector,
Veritas NetBackup, and Veritas Backup Exec. Hence, all the existing backup policies are not migrated. However, all the
local snapshots, remote snapshots, and their schedules are migrated.

Overview - Migration Process

The migration operation involves the following operations:
• RME catalog fetch from the RMC-E 6.2.0 interface servers.
• RME catalog extraction.
• Processing of the extracted data and then load of the migrated data in the local RMC 6.2.0 VM database. The
following set of events occurs:

◦ Creation of Recovery Sets.

◦ Migration of snapshots and their association with the Recovery Sets.
◦ Migration of policies.
◦ Migration of schedules.

• Verification of the migrated data with the data fetched from the storage arrays.
• Generation of the final migration report.

From the RMC GUI, use the Migrate All servers option in the Actions drop-down menu in the Servers tab of Exchange
Databases page to start the migration. For more information on the procedure, see Recovery Manager Central 6.2.0
Online User Guide.

NOTE:
• 1. If the database protected in RME 4.8.x does not have a copy policy associated with it post migration, click
Actions > Add Protection to manually add protection. Click Select that will fetch all the existing copy policies on
the system. Select the migrated policy corresponding to the database and Click OK.
2. Some of the migrated snapshot's expiration and retention times may vary from the original migration and
retention times by a few minutes.

42 Migration
Migration prerequisites
Prerequisites

• Ensure that you deploy RMC 6.2.0 VM.

• Ensure that you install the RMC-E 6.2.0 agent on all the interface servers.
• Ensure that you install RMC-E 6.2.0 agent on all the MS Exchange servers.
• Ensure that you add all the relevant storage systems to the RMC 6.2.0 VM.
• Ensure that you register the interface servers and Exchange servers with the RMC 6.2.0 VM.

Premigration RME data safety

The RMC-E 6.2.0 installer program automatically detects the previous RME 4.8.x installation path and upgrades the
software. The RME data folder is backed up to the RME-Migration folder. When the migration process runs, the migration
engine captures data from this backup folder and transfers data to the registered RMC 6.2.0 VM.
For example, for an existing RME 4.8.x installation path C:\Program Files\3PAR\RM\Exchange\, the RME
4.x datapath is C:\Program Files\3PAR\HWPRV\Data\. After upgrading to RMC-E 6.2.0, the RME backup
data is available at C:\RME-Migration.

Configuring storage systems

Prerequisites
Ensure that all the storage systems used in RME before migration is registered in RMC-E 6.2.0.

Procedure

1. Log in to the RMC-E GUI.

2. Click HPE Recovery Manager Central > Storage Devices.
3. Click +Storage Device.
4. Select the type as 3PAR.
5. Specify the IP Address or Host Name.
6. Specify the Username and Password credentials with admin privileges.
7. Click OK.

Registering all the RME 4.8.x servers

Register all the RME 4.8.x servers in RMC-E 6.2.0. All the Microsoft Exchange servers, Interface servers with RME 4.8.x
installed have to be registered for migration to be successful.

Procedure

1. Click the main menu and then click Exchange Databases > Servers.
2. On the master pane of the Servers screen, click +Servers.
3. Provide the following details:

Migration 43
 • IP Address of Host Name - The IP address or the fully qualified domain name of the server.
• Port - [Optional] The port number of the server.

NOTE: By default, RMC-E operates on port 50002. If port 50002 is already in use, you can change the port during
the server registration.

• Username - The username for server login.

• Password - The password for login username.
• Description- [Optional] Short description about the server.

4. Click Add.

TIP: When you are registering multiple servers with the same Username, Password and Port, use the Add +
button and enter only the IP Address of the next server.

RME to RMC-E migration report

Migration report can be viewed once the migration operation is completed. You can access the migration report form the
Associated Data option of the Migrate RM for Exchange (RME) Data task in the Activities page.

Report highlights
• Servers involved in fetching the migration data.
• Details of migrated or failed snapshots, including the total count.
• Number of schedules migrated.
• Number of Notification Policies Migrated.

Various RME resources post migration

Copy policies
You can navigate to the copy policies option from the RMC main menu. The migrated copy policies have a Migrated_policy
as a prefix in the policy name. The copy policy associated with a particular database can be viewed from the Databases
tab of the Exchange Databases window.

Snapshot
Click HPE Recovery Manager Central > Exchange Databases and go to Databases tab to view the copies migrated. All
the migrated snapshots appear with a VSS_Snapshot_Migrated prefix.

Schedules
You can navigate to the schedules option from the RMC main menu. Post migration, all the migrated RME schedules are
RMC-E 6.2.0 compatible. To ensure that the RME schedules that were scheduled in the RME backup server (interface
server) are triggered at the required time after migrating to RMC-E 6.2.0, Hewlett Packard Enterprise recommends that
you synchronize the local time zone, date, and time on VMware ESXi host (on which RMC appliance is deployed), interface
server, and Microsoft Exchange servers.

44 Migration
 Schedules translation from RME 4.8.x to RMC-E 6.2.0
The policies in RME 4.8.x cannot be migrated as is into RMC-E 6.2.0. as RME 4.8.x and RMC-E 6.2.0 are different
products. Therefore, it is translated to achieve the best fit. The following table shows the translation of schedules from
RME 4.8.x to RMC-E 6.2.0:

Table 4: Schedule translations

Schedule type Note

One Off If in an One Off schedule, time is earlier than the migration
time, the schedule is not migrated.

Hourly For a duration of [number] days option is not be fully

translated. All hourly schedules will be migrated as running
indefinitely.

Daily All values are translated as is.

Weekly Recur every [number] week on: Entry is migrated as

occurring weekly option is not translated completely.

Monthly Following options are not translated:

• ·Day [number] of every [number] month.

This is translated as day [number] of every month.
• The [number] [weekday] of every following selected
month.
Entry of this type is migrated as first day of each
month.

NOTE:
• If a Remote Copy snapshot schedule in RME was created with an IP address or FQDN provided for the target server,
then such schedules are not be migrated. You have to create schedules post migration. Only the schedules created
with Server name are migrated.
• Copy policies must be reviewed post migration. If there are multiple frequencies with the same trigger, keep only one
and delete the rest. According to RMC 6.2.0 guidelines, it is advisable to keep only three frequencies per protection
type in a copy policy.
• In a migrated copy policy, if a frequency trigger in a particular protection type has Verify Copy set, all the
snapshots triggered from the schedule are validated even if some of the schedules do not have Verify Copy set
to True.

• Verify Edit protection to check the Optional Replication mode. Set it to the same mode to which the array is
configured.

Migrating Remote Copy snapshots

Migrating Remote Copy snapshots is similar to migrating local snapshots. All the existing Remote Copy snapshots get
imported as local snapshots. If there were any schedules for Remote Copy snapshot creation in RME 4.8.x, post migration,
the new remote snapshots that get created as part of the schedule appear in the Remote snapshots category.

Migration 45
Migrating Remote Copy snapshots for nonsynchronous long distance (non-SLD) configurations for a
single RMC-E VM
This configuration is for a single RMC-E server managing source and target interface servers.

Procedure

1. Install RMC-E 6.2.0.

a. Install RMC-E 6.2.0 agent on the source application server.

b. Install RMC-E 6.2.0 agent on the source interface server.
c. Install RMC-E 6.2.0 agent on target application server.
d. Install RMC-E 6.2.0 agent on target interface server.

2. Deploy RMC virtual machine.

a. Deploy RMC VM as shown in the figure.

Source Target
RMC-E 6.2.0 GUI
IP
IP
IP
RMC VM

Interface Interface
Server 1 Server 2

Deploy RMC VM
using vCenter

Application Servers Application Servers

Network (IP)

RME 4.8.x

b. Add source storage system and target storage system to RMC VM.

3. Register the source and target interface servers on RMC VM.

4. From RMC VM, click HPE Recovery Manager Central > Exchange Databases > Servers > Actions > Migrate All
Servers.

Migrating Remote Copy snapshots for nonsynchronous long distance (non-SLD) configurations for two
RMC-E VMs
This configuration is for two RMC-E VMs each managing source and target interface servers.

Procedure

1. Install RMC-E 6.2.0.

a. Install RMC-E 6.2.0 agent on the source application server.

b. Install RMC-E 6.2.0 agent on the source interface server.

46 Migration
 c. Install RMC-E 6.2.0 agent on target application server.
d. Install RMC-E 6.2.0 agent on target interface server.

2. Deploy RMC virtual machines.

a. . Deploy RMC VM-I and RMC VM-II as shown in the figure.

Source Target
RMC-E 6.2.0 GUI RMC-E 6.2.0 GUI

IP IP

IP IP
RMC VM-I RMC VM-II

Interface Interface
Server 1 Server 2

Deploy RMC VM Deploy RMC VM

using vCenter using vCenter

Application Servers Application Servers

Network (IP)

RME 4.8.x

b. Add source storage system to RMC VM-I.

c. Add source storage system to RMC VM-II.

3. Add remote appliance.

a. Log in to RMC VM-I and click HPE Recovery Manager Central > Remote Appliance > Add RMC VM-II.].
b.

4. Register the source interface server on RMC VM-I.

5. Register the target interface server on RMC VM-II.
6. From the RMC VM-I, click PE Recovery Manager Central > Exchange Databases > Servers > Actions > Migrate All
Servers.
7. From the RMC VM-II, click PE Recovery Manager Central > Exchange Databases > Servers > Actions > Migrate All
Servers.

Migrating Remote Copy snapshots for synchronous long distance (SLD) configurations

Prerequisites
Ensure that you have two target interface servers.

Procedure

1. Install RMC 6.2.0 agent on source and target agents or interface servers as shown in the figure.

Migration 47
 Source Target-1
RMC-E 6.2.0 GUI RMC-E 6.2.0 GUI

IP IP

IP IP
RMC VM-I RMC VM-II

Interface Interface
Server 1 Server 2

Deploy RMC VM Deploy RMC VM

using vCenter using vCenter

Application Servers Application Servers

Network (IP) Target-2

RMC-E 6.2.0 GUI

IP

IP
RMC VM-III

Interface
Server 3

Deploy RMC VM
using vCenter

Application Servers

RME 4.8.x

a. Deploy RMC VM-I, RMC VM-II, and RMC VM-III as shown in the figure.
b. Add all source HPE 3PAR storage systems according to the existing RME configuration.

2. Use the source interface server RMC VM-I GUI to add the storage systems.
Add remote appliance RMC VM-II and RMC VM-III as remote appliances in source RMC GUI.
3. Use source interface server RMC VM-I GUI to add the remote appliance.

a. Add target sync or periodic storage systems according to the RME configuration.
b. Use target interface server-I RMC VM-II GUI to add storage systems.
c. Use target interface server-II RMC VM-III GUI to add storage systems.
d. Migrate snapshots and schedule jobs from the source interface server.

4. Use source interface server RMC-E (RMC VM-I) GUI to migrate snapshots.
After the source interface server snapshots and schedule jobs are migrated, you must migrate the snapshots and
schedule jobs from both target interface servers separately.
5. Use target I interface server RMC-E GUI (RMC VM-II) to migrate snapshots and schedule jobs.
6. Use target II interface server RMC-E GUI (RMC VM-III) to migrate snapshots and schedule jobs.

NOTE: By default, during the migration of SLD configuration to RMC, the remote target is the same for all the copy
policies. Review the replication mode of the copy policy post migration and set sync or async target accordingly.

48 Migration
Migration in RMC-O
Considerations
Before you upgrade to RMC-O 6.2.0 from RMC-O 5.x and RMC-O 6.0:

• All ISV backups and RMC-O protection policies specific to ISVs are removed from RMC. RMC-O 6.2.0 onwards, there is
no support for ISV backup to an ISV. Also, during an upgrade process, if ISV backups or RMC-O Protection policies
having ISV backups are found, upgrade process is terminated and you will be directed to delete the ISV resources.
• Database page has changed to manage the database volumes in a Remote Copy configuration in RMC 6.2.0 release. If
a database is in a Remote Copy configuration, a separate database entry referencing the storage system on which the
volumes are present is created. This enables an easy way to manage snapshots and backups on individual storage
system for all the target storage system. For more information, see Remote Copy for RMC-O section.
• The management of copies from multiple RMC is aligned to sync remote snapshot details to all the remote RMC
registered in RMC-O 6.2.0. If there are multiple RMCs managing a database, then it is required to create a remote
snapshot on all the target replication mode, this completes the migration of all the Remote Copy resources. After
creating the first remote snapshot, all the RMCs start displaying the database and the remote snapshots. If there are
multiple RMCs, all storage devices must be registered in every registered Remote RMC else, migration fails.
• Post migration, it is recommended to Inspect the copy policy assigned to the database and check the values of
recurrence and expiry or retention for each rule. An option to truncate the archive logs after the creation of online
snapshots is introduced starting RMC-O 6.2.0 release. Post migration, the option to truncate the archive logs is not
set by default. If you intend to automatically clean up the archive logs, then the copy policy can be updated to
automatically truncate the archive logs after successful creation of online snapshot.

NOTE: Post migration, a migration report file is generated where you can download and view the migrated resources.

Migration in RMC-S
Migration prerequisites
Before you upgrade to RMC-S 6.2.0 from RMC-S 5.0.x and RMC-S 6.x.0, check the following mandatorily:
• Upgrade agent on all the interface servers and production servers registered in RMC-S 5.0.x to 6.2.0.
• Hostname or FQDN of all the interface servers and production servers resolves to an IP address from DNS servers set
in RMC.
• Register the target storage systems with RMC-S.
• All the interface servers and production servers are reachable over network from RMC appliance.
• RMC-S 6.2.0 does not support ISV backups. Before migrating, remove all the Copies and schedules of the SQL
databases or instances.
• All Transaction Log repository servers are reachable from RMC over network and hostname or FQDN must resolve
properly.
• Run analyze on existing resources in RMC-S 5.0.x to avoid failure in migrating Copies.
• Add firewall rules (if required) on the RMC-S service ports on production servers.
• Create a VMware or Hyper-V Snapshot of RMC and Windows VM to roll back to an older state. This Snapshot is useful
when the migration is unsuccessful.

Migration 49
 NOTE: If you have configured FC passthrough, power off the RMC VM and then create a Snapshot.

Migration prechecks
RMC and RMC-S upgrade operation performs the following checks before migration and prompts error if the checks are
invalid:
• All interface servers registered in RMC-S are upgraded to 6.2.0.
• All interface servers hostname or FQDN resolves to an IP Address from DNS servers set in RMC.
• All interface servers are reachable over network from RMC appliance.
• All interface servers are accessible with credentials registered in RMC-S 5.0.x.
• Checks the presence of any ISV schedules or backups in RMC-S 5.0.x.
• Checks the presence of any ISV specifications in RMC-S 6.x.0.

Post-migration considerations
Post migration, a migration report file is generated where you can download and view the migrated resources.

RMC 5.0.x to RMC 6.2.0

• RMC-S 6.2.0 does not support interface server. All the Windows physical servers or VMs hosting registered SQL
server instances in RMC-S 5.0.x are added as a new server entity in 6.2.0.
• RMC-S 6.2.0 supports protection of clustered SQL instances using Cluster Virtual IP Address registration unlike RMC-
S 5.0.x. Therefore, all RMC-S 5.0.x clustered SQL server instances are migrated to create a Cluster Virtual IP Address
entry in servers.
• RMC-S 5.0.x migrated local and remote Snapshots time-stamp is converted from local time zone to UTC assuming
production server time zone to be same as RMC time zone.
• When performing Sync Remote Copy Snapshot operation, RMC 5.0.x created local and Remote Snapshots (Snapshots
on primary and target storage device) and tagged both of them as Remote Snapshots. However, RMC-S 6.2.0 creates
only Remote Snapshot (Snapshot on target storage device). The redundant local Snapshot from RMC-S 5.0.x is
migrated as is and tagged as Remote Snapshot. Therefore, when performing any operation on RMC-S 6.2.0 GUI,
multiple Snapshots with the same time stamp appear.
• RMC-S 5.0.x tagged Cloud Copy as Catalyst Copy. It is migrated as is in RMC-S 6.2.0.
The file copy restore and instant clone operations on these Catalyst Copies are not allowed from a migrated Cloud
Copy.
• RMC-S 5.0.x supported mount and attach of database from protected Copies. Those mounted Copies and attached
database from mounted Copies are migrated as Clones in RMC-S 6.2.0.
Mounted Copies are listed as Clones with mounted state in Copies view for an SQL resource.
Attached databases with mounted Copies are listed as Clones with attached state in Copies view for an SQL resource.
• RMC-S 5.0.x schedules and policies are converted to new RMC-S 6.2.0 workflows.
• Configuring multiple Express Protect or Catalyst Copy schedules for a database or an instance using the same Catalyst
Store is not supported.
• RMC-S 6.2.0 deprecating numeric policy support must handle conversion of numeric policies set in RMC-S 5.0.x to
time-based policies.

50 Migration
 • The Add database to availability group option is not enabled when you remove database from availability group
before migration. If the database is added to a new availability group before the migration, then the new availability
group name is selected as the target availability group by RMC-S. In this scenario, you have to provide the correct
target availability group name as per requirement.
• On migration to RMC 6.2.0, Remote Snapshot inherits the expiry parameter when a numeric policy in RMC 5.0.x is
configured at instance-level for Snapshot, Express Protect, and Catalyst Copy.

RMC 6.x.0 to RMC 6.2.0

• Ensure that all RMC-S 6.x.0 resources and Copies are successfully migrated with the new RMC-S 6.2.0 structures.
• Post upgrade of RMC 6.x.0 to 6.2.0, in copies view against the application objects (database or instance), you can see
the job status of all the older ISV backup sessions if taken with the previous RMC version. These ISV backups job
statuses automatically expire or disappear post 30 days from the ISV backup creation time.
• Post upgrade of RMC 6.x.0 to 6.2.0, Job Status (job count) of the migrated databases and instances is not updated.
Status for the new jobs that you create is updated.

Migration in RMC-SH
Considerations
Before you upgrade to RMC-SH 6.2 from RMC-SH 5.x and RMC-SH 6.0:

• Register the target storage systems with RMC-SH.

• Ensure that you generate the secure key in RMC and configure the same at host when taking catalog protection of
5.0.x appliance as fallback option when any of the hosts is managed through SSH keys, and fallback when you
redeploy an RMC 5.0.x and imports the catalog.

Migration in RMC-V
Post-migration considerations
• Post migration to RMC-V 6.2.0, Remote Copy Groups in RMC-V are auto migrated as Protection Groups with remote
capability. For each Remote Copy Group, two Protection Groups are created. One for the local Group and the other for
the remote Group.
The local Snapshots of the Remote Copy Group from 5.0.x/6.x.0 are associated with local Protection Group. However,
the Remote Snapshots from 5.0.x/6.x.0 are associated with both local and remote Protection Groups in 6.2.0.
• In RMC-V 5.0.x, Remote Copy Groups and the associated Snapshots are displayed in vCenter Inventory List >
Remote Recovery Configurations screen. Post migration to 6.x.0, the Remote Copy Groups are converted to
Protection Groups and the older Remote Copy Snapshots are displayed in Protection Groups screen.
• All types of Copies created with numeric policy in RMC-V 5.0.x are not converted to time-based policies post
migration. There is no expiry or retention configured. Delete the Copies manually to expire them.
• For the datastore copies migrated from RMC-V 5.0.x to RMC-V 6.x.0, Cloning is not be supported. However, the Copies
can be mounted (using the Clone option) and VMs can be registered later.
• Starting from RMC-V 6.2.0, VMware vSphere version 6.0 and related updates are not supported by Hewlett Packard
Enterprise.
If you are using RMC-V on VMware vSphere version 6.0, you cannot upgrade from previous versions of RMC-V to
6.2.0 or later versions. To upgrade from RMC-V versions 5.x.0, 6.x.0 to version 6.2.0, ensure that you are using

Migration 51
 VMware vCenter 6.5 and later, or 6.7U1 and later. All the existing Snapshots and backups are migrated and are not
impacted due to these upgrades.

NOTE: The VMware vSphere environments where RMC-V is not used (RMC appliance and the RMC application plug-
ins) are not affected and are supported on ESXi 6.0.0U1 and later versions. For the supported VMware vSphere
environments, see SPOCK.

• VMware supports HTML5-based GUI from VMware vSphere 6.5 and onwards. Starting from version 6.2.0, RMC-V
supports only HTML5-based plug-in. RMC-V stops the support for vSphere Adobe Flash based-Web Client.
After migrating to RMC-V 6.2.0, log in to the HTML5-based plug-in to use the RMC-V features.
• Copies migrated from 5.0.x to 6.2.0 are displayed only for the resources (VMs or datastores) where Copies are
created. In 6.2.0, Copies of datastores are also displayed as Copies of VMs (in the VM Copies View).

Migrated remote Snapshots

View all the Remote Copy Group-level Snapshots in the Protection Groups screen. Alternatively, you can view the Remote
Copy Group-level Snapshots at VM or datastore level Copies View.
For a Remote Copy Group-level Snapshot, actions such as restore and mount can be performed from the associated
Protection group.

Frequently asked questions about migration

Questions Answers
Question - In RMC 5.0, user can delete individual schedule Answer - This is as per design. We will need a learning
if not required. How it is handled in RMC 6.2? In RMC 6.2 - curve similar to that of RMC 6.0. How loose policy is (This
We have to remove protection from that instance first then is specific to SQL) handled in RMC 6.2 after migration?
edit copy policy to remove particular schedule then assign
the copy policy back to the instance. This is tedious.
Question - If one out of multiple schedule is suspended in Answer -RMC 6.x workflow is marked suspended and
RMC 5.0.0 then how are we handling inRMC 6.x? hence all the schedules for the resource will be suspended.
Question - How schedule end date is managed in 6.2? (if Answer - Ideally for a resource with multiple schedules and
no end date then schedule will be running forever). different end date for each of those schedules, we would
choose the end date which is the farthest in the future or
no end date if at least one of the schedules does not have
an end date.
Question - Converting Monthly or yearly schedule to every Answer - Yearly schedules will be converted to monthly.
month in 6.x will require more resources from user like Users will have to reconfigure their schedules accordingly if
storage consumption , - user cannot expire schedules since needed.
migration task is creating every month schedules. Is there
any way to handle this so that user will not be affected like
setting expiry.
Question - Let us say, we set monthly/yearly schedule on Answer - It will skip such dates.
29th. If you convert this to every month schedule in RMC
6.2, then how it is handled for Feb month.
Question - Let us say, one out of 5 schedules set for same Answer - No end date will be set for workflow post
database are expiring soon. Then how is it handled in RMC migration, since other 4 schedules do not have end date.
6.2?

Table Continued

52 Migration
Questions Answers
Question - There is no option in RMC 6.2 to create Answer - There is a design shift between RMC 5.x and
monthly or yearly schedule by selecting particular month RMC 6.x.
and day of the month. But, this option available in RMC 5.x.
How are we going to handle this in RMC 6.2?
Question - There is no option in RMC 6.2 to create weekly Answer - Same as point 7.
schedule by selecting particular day of the week. How are
we going to handle this in RMC 6.2?
Question - There is no One-Off schedule creation option in Answer - Protect once option is available. One-off is
RMC 6.2. How One-Off schedule is handled in RMC 6.2? migrated as protect once jobs.
Question - How numeric policy is handled in RMC 6.2 after Answer - Existing copies will be migrated and we would
migration? If I set maximum snapshots, EP, and CC as 200, not set any expiry and retention of migrated copies.
then where we can check this field set in RMC 6.2?
Numeric policy is no more supported in RMC 6.2, it will be
mapped to time based policy and the mappings could be
available in migration report once completed.

Question - How loose policy (This is specific to SQL) is Answer - It is no more applicable as we moved away from
handled in RMC 6.2 after migration? numeric policy from RMC-S 6.0.
Question - There is no cloud copy specific option in RMC Answer - It will appear as cloud copy.
5.0 but we can take cloud copy in RMC 5.0 with cloud store
using Catalyst Copy option. How is this handled in RMC
6.2? Will it show as Cloud copy or Catalyst Copy in RMC
6.2?
Question - Duplicate schedules in legacy? Answer - They will be converted as is. Customers have to
unprotect and edit it post migration.
Question - Managing copy policies for legacy? Answer - RMC 6.2 prevents using same copy repositories
across copy type in copy policy. In legacy schedules if it is
done so, migration we attempt to allow using same copy
repositories across copy types in copy policy. It may fail
while editing the migrated ones on RMC 6.2. Users will
have to up-protect and edit the copy policy in such cases.
Question - More than 3 frequencies under a copy type? Answer - RMC 6.2 prevents more than 3 frequencies for
copy type in copy policy. In legacy schedules if it is done so,
migration we attempt to allow all the frequencies for copy
types in copy policy. It may fail while editing the migrated
ones on RMC 6.2. GUI might restrict to only 3 while editing.
Question - Backup Policy merging if created on same store Answer -
[handling properties like verify, streamCount, src
connectivity, and target connectivity?
Question - About legacy schedules marked as error during Answer - Users could use the reports as a reference and
migration. decide about recreating schedules or policies for resources
protected by legacy schedules and which are seen as
errored during migration.

Table Continued

Migration 53
 Questions Answers
Question - About Reports (BZ127338) Answer - For backup efficiency delta size would be having
no values.

The snapshots created (both local and remote) as part of

remote snapshot workflow in RMC 5.x are shown as remote
snapshots in RMC 6.2, whereas local snapshots created
from local recovery set are properly shown as local
snapshots. This is not incorrect to show these local
snapshots as remote after migration as they are created as
part of remote snapshot creation. Also this is triggered
from dedicated remote recovery set, not from local
recovery set with local snapshot rule.

Question - Peer copy migration Answer - If the user has only peer copy data, after
migration only the recovery sets and Snapshots will be
seen in RMC. Any schedules related to peer-copy policies,
peer Copy volumes, peer copy sets will not be seen as
these data will be lost.
Question - Migration report for peer copy migration Answer - We will not be able to download the report as all
the data related to peer copy will be lost during migration.
Question - Peer copy schedule migration Answer - All the schedules related to peer copy policies
will be lost during migration.
Question - About post migration cleanup Answer - User has to click Close to let RMC know that
migration is complete.

On "Close" from users a reference file is removed as well as

any legacy schedules would be deleted. Except for Catalog
Protection.

Question - Job Status on Volume sets page Answer - It has been noticed that due to nonexistence of
some attributes in RMC 5.X, the RMC 6.X APIs do not pull
grouped status as expected. This is only from reporting
aspect.

On newer executions, users must be able to see the counts

after migration.

54 Migration
Remote Copy or Replication configurations
HPE 3PAR, HPE Primera and HPE Nimble Storage Remote Copy feature provides Enterprise and cloud data centers with
autonomic replication and disaster recovery technology. It allows protection and sharing of data between multiple arrays
within the same or different geographical locations.

Remote Copy management by single RMC appliance

A single RMC appliance manages both local and remote HPE 3PAR systems and HPE Primera systems. To complete the
setup, register the same RMC appliance as the remote appliance.

NOTE: HPE Primera supports replication over FC link only.

Array 1 Array 2
RC Link
IP

HPE 3PAR / HPE Primera HPE 3PAR / HPE Primera

(Source) IP IP (Target)

RMC Appliance

Figure 8: Remote Copy management by single RMC appliance

Remote Copy management by RMC appliance at each site

There is one RMC appliance at each site. Appliance 1 manages the local site and Appliance 2 manages the remote site.
Register Appliance 2 as the remote appliance in Appliance 1 to complete the setup. Ensure that the RMC in local site and
the RMC in remote site are accessible to each other.

Remote Copy or Replication configurations 55

 Array 1 Array 2

RC Link

HPE 3PAR / HPE Primera HPE 3PAR / HPE Primera

(Source) (Target)

IP IP

IP
Local Appliance Remote Appliance

Appliance 1 Appliance 2

Figure 9: Individual RMC appliance at each site

Sync replication for RMC

NImble Sync replication is not supported for RMC-E, RMC-O, RMC-S, RMC-V, and RMC-SH. Whereas, Nimble Periodic
replication is supported by all RMC plug-ins.
Group
Array 1 (upstream) Array 2 (downstream)

Replication

HPE Nimble Storage HPE Nimble Storage

(Source) (Target)

IP

RMC Appliance

Supported configurations
Supported RMC RMC-V RMC-S RMC-O RMC-SH RMC-E
operations
Local Yes Yes Yes Yes Yes Yes
snapshots
Remote Yes Yes Yes Yes Yes Yes
snapshots on
homogeneous
array types

Table Continued

56 Remote Copy or Replication configurations

Supported RMC RMC-V RMC-S RMC-O RMC-SH RMC-E
operations
Express Yes Yes Yes Yes Yes Yes
Protect
Backups to
StoreOnce
Catalyst Copy Yes Yes Yes Yes Yes Yes
to second
StoreOnce
Copy to Cloud Yes Yes Yes Yes Yes Yes
Bank Storage
(Cloud Copy)
Peer Copy (to Yes No No No No No
another
Nimble, 3PAR
or Primera)
3PAR Peer No Yes Yes No No Yes
Persistence
(including 3DC
Peer
Persistence)
Primera Peer No Yes Yes No No Yes
Persistence
Nimble Yes Yes Yes Yes Yes Yes
Asynchronous
Replication
Nimble Yes No No No No No
Synchronous
Replication
Nimble Peer No No No No No No
Persistence

Considerations

• Ensure that name of each of the volume in a Synchronous Remote Copy group does not exceed 20 characters.
• RMC deployment on VMware VVol and virtual SAN data stores is not supported.
• Peer Persistence is not supported by RMC Oracle (RMC-O) and RMC SAP HANA (RMC-SH) plugins and is supported
by RMC-V, RMC-S, and RMC Exchange plugins.
• Optimized full backups are not supported on Fully Provisioned VVols (FPVVs).

Remote Copy or Replication configurations 57

Advanced Concepts
Group to role mapping
As a user with an Admin role, you can add and manage the various RMC users and assign user roles. You can also assign
RMC roles to the Active Directory groups. After you add a directory server to RMC, you have to assign Active Directory
groups with RMC roles. Only those users in the assigned groups can access RMC appliance. If a group is assigned more
than one role, the Admin role privileges take the priority. When a group is assigned all the roles, the option to assign roles
is disabled. The roles created in RMC are:

• Admin - The administrator is the super user and has all the privileges for monitoring and managing the RMC
appliance.
• Members - The members have only view privileges and cannot perform any other task.

You can use the Users and Groups option on the RMC GUI to perform a group to role-mapping task. You can add a
directory server and group from a directory server too. In the same prompt, you can select a role that you intend to assign
to the group. If a group is not assigned any role, the group is not displayed in RMC. Through the Users and Groups
option, you can add a user, set a role for it, edit a user and delete a user.

Authentication for Active Directory users

You can authenticate and authorize Active Directory users. The users can perform certain tasks depending on the role
assigned to the user group that they belong to in Active Directory. Authenticating Active Directory users eliminates the
need of adding local users in RMC.
To register the Active Directory server with RMC, your first login has to be as an RMC Admin. After the directory server is
added to RMC, you have to assign group-to-role mapping. An Active Directory group can be assigned one or more roles in
RMC.
Only a user with Admin role can add, edit, and delete a directory server and assign roles to groups.
The following illustration explains how authentication and authorization works:

AD User Login

Local Users and

User1 User2 AD Groups
Group A assigned with RMC admin Role
Group A Group A admin

User3 User4
Admin admin
Group B assigned with RMC member Role

Group B Group B member

Active Directory HPE RMC

Figure 10: Authentication for Active Directory

58 Advanced Concepts
Security
There are best practices in place to maintain and secure an RMC appliance. The following guidelines enable you to secure
the RMC appliance and its operating system:
• The appliance operating system minimizes its vulnerability by running only the required services. Internally, the
appliance operating system enforces mandatory access controls.
• The appliance maintains a firewall that allows traffic on specific ports and blocks all unused ports.
• The appliance runs only with the required privileges.
• The appliance supports self-signed certificates.
• All weak Secure Sockets Layer ciphers are disabled and all the browsers operations and REST API calls use HTTPS.
• The appliance supports secure updating. HPE digitally signs all updates to ensure integrity and authenticity.
• Configuration exports are encrypted.
• All access to the appliance is through HTTPS or SSL, which encrypts data over the network and ensures data integrity.

There are a few more security practices that are recommended for both physical and virtual environments. Hewlett
Packard Enterprise recommends a strict separation of the management LAN and production LAN using VLAN or firewall
technology or both to maintain separation. The changes in roles and responsibilities are well communicated to the
authorized users.

Firewall rules and port requirements

Source | Destination
RMC appliance MS SQL production server HPE 3PAR

RMC appliance Not applicable Not applicable Port 5783, port 5782

MS SQL production server Port 443 Port 9932 Port 5783, port 5782

HPE 3PAR Not applicable Not applicable Not applicable

Best practices for maintaining a secure appliance

The following is a partial list of security best practices that Hewlett Packard Enterprise recommends in both physical and
virtual environments.
Differing security policies and implementation practices make it difficult to provide a complete and definitive list.

• Hewlett Packard Enterprise recommends a strict separation of the management LAN and production LAN, using
VLAN or firewall technology or both to maintain the separation:

◦ Management LAN
All management processor devices (including Onboard Administrators and virtual connections through an
Onboard Administrator, iLOs, and iPDUs) are connected to the management LAN.
Grant management LAN access to authorized personnel only, such as Infrastructure administrators, Network
administrators, and Server administrators.
◦ Production LAN

Advanced Concepts 59
 All NICs for managed devices are on the production LAN.

• The appliance is preconfigured so that the nonessential services are removed or disabled in the management
environment.
• Ensure that a process is in place to determine if software and firmware updates are available, and to install updates for
all components in your environment on a regular basis.
• Ensure that the security policies and processes address the virtual environment:

◦ Educate administrators about changes to their roles and responsibilities in a virtual environment.
◦ Restrict access to the appliance GUI to authorized users.
◦ If you use an IDS (Intrusion Detection System) solution in your environment, ensure that the solution has visibility
into network traffic in the virtual switch.
◦ To reduce the effect on VLAN traffic sniffing, turn off promiscuous mode in the hypervisor and encrypt the traffic
over the VLAN.

NOTE: Usually, if promiscuous mode is disabled in the hypervisor, it cannot be used on a Virtual Machine (VM)
guest. The VM guest can enable promiscuous mode however, it will not be functional.

◦ Maintain a zone of trust, for example, a DMZ (demilitarized zone) that is separate from production machines.
◦ Ensure appropriate access controls on Fibre Channel devices.
◦ Use LUN masking on both storage and compute hosts.
◦ Ensure that LUNs are defined in the host configuration, instead of being discovered.
◦ Use hard zoning (which restricts communication across a fabric) based on port Worldwide Names (WWNs), if
possible.
◦ Ensure that communication with the WWNs is enforced at the switch-port level.

• Clearly define and use administrative roles and responsibilities.

• For local accounts on the appliance, change the passwords periodically according to your password policies. Follow
these guidelines:

◦ Limit the number of local accounts.

◦ Ensure that passwords include at least three of these types of characters:

– Numeric character
– Lowercase alphabetic character
– Uppercase alphabetic character
– Special character

• Do not connect management systems (for example, the appliance, the iLO card, and Onboard Administrator) directly
to the Internet.
• If you require access to the Internet, use a corporate Virtual Private Network (VPN) that provides firewall protection.

60 Advanced Concepts
Remote RMC appliance
Remote appliance enables you to perform Remote Copy operations. You can also use a local appliance to manage remote
array. A single RMC appliance manages both the local and remote HPE HPE 3PAR, HPE Primera or HPE Nimble Storage
systems.
Remote appliance registration helps you to manage snapshots on a remote array. As a result of registration, the RMC
appliance is registered on both the remote and local sites. You can register up to eight appliances. Remote appliance
registration is helpful in scenarios of a disaster or fails over situations.

Secured appliance access

All access to the appliance is through HTTPS (HTTP over SSL). HTTP over SSL encrypts data over the network and
ensures data integrity.

Algorithms for securing the appliance

• SHA-256 for hashing local user account passwords.

• Passwords of managed devices and servers are encrypted with AES-256 algorithm.
• The supported SSL version is TLS v1.2.

Ports for RMC

RMC requires specific ports to be made available to communicate with the appliance and appliance to manage HPE
storage devices.

Table 5: Ports required by RMC

Port number Protocol Usage Description

22 TCP Outbound SSH

53 TCP Outbound DNS

53 UDP Outbound DNS

80 TCP Inbound HTTP

123 UDP Outbound NTP time synchronization.

443 TCP Inbound Used for the HTTPS interface to user interface and
APIs.

443 TCP Outbound Used for secure SSL access for RMC REST calls.

3260 TCP Outbound For iSCSI media

8080 TCP Inbound For device calls (HPE 3PAR, HPE Primera/HPE
Nimble Storage/HPE StoreOnce Catalyst)

Table Continued

Advanced Concepts 61
 Port number Protocol Usage Description

8080 TCP Outbound For device calls (HPE 3PAR, HPE Primera/HPE
Nimble Storage/HPE StoreOnce Catalyst)

9387 TCP Outbound Command Protocol Port Number (HPE StoreOnce

Catalyst)

9388 TCP Outbound Data Protocol Port Number (SO)

8081, 16022 TCP Outbound For communication between RMC and HPE Nimble
Storage

25 TCP Outbound To check for Catalog Protection.

MS SQL server recommendations

• For RMC-S to auto discover SQL servers, ensure that the MS SQL server browser service is up and is in the running
state on the application server.
• If your firewall and security policy does not allow broadcasting of SQL server name across network, then you can
disable the setting.
• RMC-S supports MS SQL server mixed mode authentication (Windows or SQL). For the user account that is permitted
to manage SQL Server securities log in, set the server role to Sysadmin.

NOTE: It is not mandatory to enable the Sysadmin role in RMC 6.2.0.

RMC-S virtualization support

Microsoft Hyper-V environment
Microsoft Windows with virtual FC and iSCSI are supported on SQL server. Before you perform any mount operations,
ensure that the VM that is enabled with virtual FC HBA and is appropriately zoned with HPE 3PAR, HPE Primera and HPE
Nimble Storage on SQL production server.

VMware virtualization
VM with iSCSI and direct path I/O
If you are using VMDirectPath I/O or iSCSI for database and log protect, RMC-S provides full features for snapshot,
backup, and restore operations. Both VMDirectPath I/O and iSCSI options are supported for RMC-S virtualized SQL
Servers.
VMware RDM disk and VMFS
RMC-S supports all features for SQL server running on RDM disks with physical RDM, virtual RDM, and VMFS
configurations. RMC-S supports restore and all cloning features as well on the same SQL server VM and any other SQL
server VM in the virtualization environment. Hypervisor details have to be registered with RMC to perform RDM/VMFS
related operations.

62 Advanced Concepts
 WARNING:
• RMC-S does not support volume restore when the SQL databases are configured on disks with the VMFS
datastores.
• Configure at least one software-based iSCSI initiator on the ESXi server HBA for RMC-S to support all RDM
features.
• RMC-S does not support SQL databases protection on the VMs configured with VMware VVol.

The following table lists the various virtualization options and supported functionality in virtualization environments:

Virtualization Option SQL Server Functionality

iSCSI Initiator VM RMC-S provides complete features support for snapshot, backup, clone,
and restore operations.

VMDirect path I/O VM RMC-S provides complete features support for snapshot, backup, clone,
and restore operations.

Raw Device Mapping VM Physical RDM - All functionalities supported.

(RDM)
Virtual RDM - All functionalities supported.

VFMS datastore - Parent volume restore not supported.

Hyper-V virtual FC (vFC) VM RMC-S provides complete features support for snapshot, backup, clone,
and restore operations.

RMC-S support for MS SQL server on physical RDM disks

Operation MS SQL Server RDM Compatibility mode

Physical Virtual VMFS datastore

Local Snapshot Supported Supported Supported

Remote Copy Snapshot Supported Supported Supported

Protect to StoreOnce Supported Supported Supported

File Copy Restore Supported Supported Supported

Database cloning Supported Supported Supported

Snapshot Restore to Supported

Supported Not Supported
parent Volume

Express Protect Restore Supported

Supported Not Supported
to parent volume

Advanced Concepts 63
 NOTE: Database cloning and restore operations are not supported from virtualization environment to physical servers.

RMC-E Virtualization Support

The following table lists the various protocols and supported functionality in virtualization environments:

Hypervisor Protocols Supported (Yes/No) Special Notes

Hyper V ISCSI Yes

FC (vFC) Yes Ensure the VM has virtual HBA enabled

VmWare ISCSI Yes

FC (vFC/ Yes VM DirectPath I/O is preferred

VMDirectPath
I/O)

RDM No

VMFS No

RMC-O Virtualization Support

Prerequisites
• Ensure that the disk.EnableUUID property is set to True in the VM setting. If the property is not set, RMCO
fails at DB registration stage due to inability to discover the underlying devices.
• Ensure that the hypervisor server (either vCenter or ESXi) is added in the RMC. If not registered, RMCO cannot
proceed with VMFS database protection.
• Ensure that the Datafiles and the Archive log locations have their dedicated Datastores exclusively (nonshared) for an
Oracle Database.
• Ensure that the dynamic target (iSCSI server IP of the Storage Device) is configured on the ESXi host.
• Ensure that RMC has the RMC VMware service running to protect the Oracle databases on VMFS datastores.

RMC-O supports all features for Oracle running on VMFS datastores. The following operations are supported for Oracle
databases hosted on VMFS datastores:

• Local snapshot
• Remote snapshot
• Express Protect
• Catalyst Copy
• Cloud Copy
• Mount and unmount
• Virtual clone

64 Advanced Concepts
 • Physical clone
• Instant clone
• Automated restore and recovery from an RO snapshot and a backup
• Multiple virtual clones either to a different Oracle server or the same Oracle server for Oracle databases hosted on File
System and Logical Volume Manager

Limitations
• Inability to protect Oracle databases, with multiple volumes in one datastore.
• VM vMotion is supported in DRS environment, whereas, Storage vMotion is not supported.
• Multiple clones triggered simultaneously on the same ESXi result in failures. When cloned one by one (not
simultaneously), they work fine.
• Automated Restore from a clone to parent is not supported in this release.
• VM level snapshots and RMC-O snapshots cannot coexist.
• RMC-O does not support Oracle databases protection on the VMs configured with VMware VVol.

RMC-SH Important points

• VM vMotion is supported in DRS environment, Storage vMotion is not supported.
• Clone of a database on a VMFS datastore can be attached to ESXi hosts managed by vCenter hosting the VM of the
Database and in the same Datacenter.
• VM snapshots and RMC-SH snapshots cannot coexist.
• Dynamic target (iSCSI server IP of the Storage Device) must be configured on ESXi host.

Advanced Concepts 65
Websites
Website Link

www.hpe.com/assistance
Contact Hewlett Packard Enterprise Worldwide

www.hpe.com/support/e-updates
Subscription Service/Support Alerts

www.hpe.com/storage/rmc/swdepot/
Software Depot

www.hpe.com/support/selfrepair
Customer Self Repair

Documentation
www.hpe.com/info/enterprise/docs
Hewlett Packard Enterprise Information Library

www.hpe.com/storage/rmc/docs
RMC Documentation on Hewlett Packard Enterprise
Information Library

www.hpe.com/support/hpesc
Hewlett Packard Enterprise Support Center

www.hpe.com/storage/spock/
Single Point of Connectivity Knowledge (SPOCK) Storage
Compatibility Matrix

www.hpe.com/storage/whitepapers
Storage White Papers

66 Websites
Support and other resources
Accessing Hewlett Packard Enterprise Support
• For live assistance, go to the Contact Hewlett Packard Enterprise Worldwide website:
http://www.hpe.com/info/assistance
• To access documentation and support services, go to the Hewlett Packard Enterprise Support Center website:
http://www.hpe.com/support/hpesc

Information to collect
• Technical support registration number (if applicable)
• Product name, model or version, and serial number
• Operating system name and version
• Firmware version
• Error messages
• Product-specific reports and logs
• Add-on products or components
• Third-party products or components

Accessing updates
• Some software products provide a mechanism for accessing software updates through the product interface. Review
your product documentation to identify the recommended software update method.
• To download product updates:
Hewlett Packard Enterprise Support Center
www.hpe.com/support/hpesc
Hewlett Packard Enterprise Support Center: Software downloads
www.hpe.com/support/downloads
Software Depot
www.hpe.com/support/softwaredepot
• To subscribe to eNewsletters and alerts:
www.hpe.com/support/e-updates
• To view and update your entitlements, and to link your contracts and warranties with your profile, go to the Hewlett
Packard Enterprise Support Center More Information on Access to Support Materials page:
www.hpe.com/support/AccessToSupportMaterials

IMPORTANT: Access to some updates might require product entitlement when accessed through the Hewlett
Packard Enterprise Support Center. You must have an HPE Passport set up with relevant entitlements.

Support and other resources 67

Customer self repair
Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If a CSR part needs to
be replaced, it will be shipped directly to you so that you can install it at your convenience. Some parts do not qualify for
CSR. Your Hewlett Packard Enterprise authorized service provider will determine whether a repair can be accomplished by
CSR.
For more information about CSR, contact your local service provider or go to the CSR website:
http://www.hpe.com/support/selfrepair

Remote support
Remote support is available with supported devices as part of your warranty or contractual support agreement. It
provides intelligent event diagnosis, and automatic, secure submission of hardware event notifications to Hewlett Packard
Enterprise, which will initiate a fast and accurate resolution based on your product's service level. Hewlett Packard
Enterprise strongly recommends that you register your device for remote support.
If your product includes additional remote support details, use search to locate that information.

Remote support and Proactive Care information

HPE Get Connected
www.hpe.com/services/getconnected
HPE Proactive Care services
www.hpe.com/services/proactivecare
HPE Datacenter Care services
www.hpe.com/services/datacentercare
HPE Proactive Care service: Supported products list
www.hpe.com/services/proactivecaresupportedproducts
HPE Proactive Care advanced service: Supported products list
www.hpe.com/services/proactivecareadvancedsupportedproducts

Proactive Care customer information

Proactive Care central
www.hpe.com/services/proactivecarecentral
Proactive Care service activation
www.hpe.com/services/proactivecarecentralgetstarted

Warranty information
To view the warranty information for your product, see the links provided below:
HPE ProLiant and IA-32 Servers and Options
www.hpe.com/support/ProLiantServers-Warranties
HPE Enterprise and Cloudline Servers
www.hpe.com/support/EnterpriseServers-Warranties
HPE Storage Products
www.hpe.com/support/Storage-Warranties
HPE Networking Products
www.hpe.com/support/Networking-Warranties

68 Support and other resources

Regulatory information
To view the regulatory information for your product, view the Safety and Compliance Information for Server, Storage,
Power, Networking, and Rack Products, available at the Hewlett Packard Enterprise Support Center:
www.hpe.com/support/Safety-Compliance-EnterpriseProducts

Additional regulatory information

Hewlett Packard Enterprise is committed to providing our customers with information about the chemical substances in
our products as needed to comply with legal requirements such as REACH (Regulation EC No 1907/2006 of the European
Parliament and the Council). A chemical information report for this product can be found at:
www.hpe.com/info/reach
For Hewlett Packard Enterprise product environmental and safety information and compliance data, including RoHS and
REACH, see:
www.hpe.com/info/ecodata
For Hewlett Packard Enterprise environmental information, including company programs, product recycling, and energy
efficiency, see:
www.hpe.com/info/environment

Documentation feedback
Hewlett Packard Enterprise is committed to providing documentation that meets your needs. To help us improve the
documentation, send any errors, suggestions, or comments to Documentation Feedback ([email protected]). When
submitting your feedback, include the document title, part number, edition, and publication date located on the front
cover of the document. For online help content, include the product name, product version, help edition, and publication
date located on the legal notices page.

Support and other resources 69