Hitachi Data Instance Director

Transcription

1 Hitachi Data Instance Director Application Guide for protecting Microsoft SQL Server MK-93HDID008-00

2 2016 Hitachi, Ltd. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including copying and recording, or stored in a database or retrieval system for commercial purposes without the express written permission of Hitachi, Ltd., or Hitachi Data Systems Corporation (collectively Hitachi ). Licensee may make copies of the Materials provided that any such copy is: (i) created as an essential step in utilization of the Software as licensed and is used in no other manner; or (ii) used for archival purposes. Licensee may not make any other copies of the Materials. Materials mean text, data, photographs, graphics, audio, video and documents. Hitachi reserves the right to make changes to this Material at any time without notice and assumes no responsibility for its use. The Materials contain the most current information available at the time of publication. Some of the features described in the Materials might not be currently available. Refer to the most recent product announcement for information about feature and product availability, or contact Hitachi Data Systems Corporation at Notice: Hitachi products and services can be ordered only under the terms and conditions of the applicable Hitachi agreements. The use of Hitachi products is governed by the terms of your agreements with Hitachi Data Systems Corporation. By using this software, you agree that you are responsible for: 1. Acquiring the relevant consents as may be required under local privacy laws or otherwise from authorized employees and other individuals to access relevant data; and 2. Verifying that data continues to be held, retrieved, deleted, or otherwise processed in accordance with relevant laws. Notice on Export Controls. The technical data and technology inherent in this Document may be subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations, and may be subject to export or import regulations in other countries. Reader agrees to comply strictly with all such regulations and acknowledges that Reader has the responsibility to obtain licenses to export, re-export, or import the Document and any Compliant Products. Hitachi is a registered trademark of Hitachi, Ltd., in the United States and other countries. AIX, AS/400e, DB2, Domino, DS6000, DS8000, Enterprise Storage Server, eserver, FICON, FlashCopy, IBM, Lotus, MVS, OS/390, PowerPC, RS/6000, S/ 390, System z9, System z10, Tivoli, z/os, z9, z10, z13, z/vm, and z/vse are registered trademarks or trademarks of International Business Machines Corporation. 2

3 Active Directory, ActiveX, Bing, Excel, Hyper-V, Internet Explorer, the Internet Explorer logo, Microsoft, the Microsoft Corporate Logo, MS-DOS, Outlook, PowerPoint, SharePoint, Silverlight, SmartScreen, SQL Server, Visual Basic, Visual C++, Visual Studio, Windows, the Windows logo, Windows Azure, Windows PowerShell, Windows Server, the Windows start button, and Windows Vista are registered trademarks or trademarks of Microsoft Corporation. Microsoft product screen shots are reprinted with permission from Microsoft Corporation. All other trademarks, service marks, and company names in this document or website are properties of their respective owners. 3

4 4

5 Contents Preface... 7 Intended audience... 8 Software version...8 Related documents... 8 Document conventions... 8 Conventions for storage capacity values...9 Accessing product documentation Getting help...10 Comments Overview...13 Backup scenarios Restore scenarios Capabilities Prerequisites Application software prerequisites Storage hardware prerequisites Backup workflows...23 Host based workflows...24 Creating application and crash consistent recovery points Block based workflows Create space efficient restore points with local snapshots Create restore points with snapshots of a local clone...28 Create restore points and disaster recovery backups with snapshots of a remote clone

6 5 Restore workflows Mount a snapshot or clone for repurposing Revert workflows Revert to a snapshot or clone...36 Revert a snapshot of a clone for MS SQL Server AAG Reference...39 Hitachi block storage Hitachi block storage agentless node dialog...40 Hitachi block storage snapshot attributes...41 Hitachi block storage replication attributes...42 Policy and data flow Snapshot operation attributes...44 Replicate operation attributes Quiescing applications during backup Synchronization groups Troubleshooting...49 CDP and Replicate operations continue to execute with a non existing database as part of its policy...50 Cannot see the Shadow copy instance freeze message for MS Exchange application Handler call failed: [...] failed to create snapshot pair [...] Handler call failed: [] snapshots that are in a different pool...50 Handler call failed: refreshlogicaldevices Failed [...] Glossary...53 Index

7 Preface This document describes how to backup MS SQL database by using Hitachi Data Instance Director. Intended audience Software version Related documents Document conventions Conventions for storage capacity values Accessing product documentation Getting help Comments Preface 7

8 Intended audience This document is intended for a system administrator who wants to protect the MS SQL Server database by using the Hitachi Data Instance Director and has knowledge on MS SQL Server, storage administration, and network administration. Software version This document revision applies to Data Instance Director version 5.5. Related documents Hitachi Data Instance Director Software Release Notes, RN-93HDID000 Hitachi Data Instance Director User s Guide, MK-93HDID001 Hitachi Data Instance Director Quick Start Guide, MK-93HDID002 Hitachi Data Instance Director Disaster Recovery Reference, MK-93HDID004 Hitachi Data Instance Director Application Guide for protecting SAP HANA, MK-93HDID006 Hitachi Data Instance Director Application Guide for protecting Oracle, MK-93HDID007 Hitachi Data Instance Director Application Guide for protecting Microsoft SQL Server, MK-93HDID008 Hitachi Data Instance Director Application Guide for protecting Microsoft Exchange Server, MK-93HDID009 Document conventions This document uses the following typographic conventions: Convention Description Bold Indicates text in a window, including window titles, menus, menu options, buttons, fields, and labels. Example: Click OK. Indicates emphasized words in list items. Italic Indicates a document title or emphasized words in text. Indicates a variable, which is a placeholder for actual text provided by the user or for output by the system. Example: pairdisplay -g group 8 Preface

9 Convention Monospace Description (For exceptions to this convention for variables, see the entry for angle brackets.) Indicates text that is displayed on screen or entered by the user. Example: pairdisplay -g oradb < > angle brackets Indicates variables in the following scenarios: Variables are not clearly separated from the surrounding text or from other variables. Example: Status-<report-name><file-version>.csv Variables in headings. [ ] square brackets Indicates optional values. Example: [ a b ] indicates that you can choose a, b, or nothing. { } braces Indicates required or expected values. Example: { a b } indicates that you must choose either a or b. vertical bar Indicates that you have a choice between two or more options or arguments. Examples: [ a b ] indicates that you can choose a, b, or nothing. { a b } indicates that you must choose either a or b. This document uses the following icons to draw attention to information: Icon Label Description Note Calls attention to important or additional information. Tip Provides helpful information, guidelines, or suggestions for performing tasks more effectively. Caution Warns the user of adverse conditions and/or consequences (for example, disruptive operations, data loss, or a system crash). WARNING Warns the user of a hazardous situation which, if not avoided, could result in death or serious injury. Conventions for storage capacity values Physical storage capacity values (for example, disk drive capacity) are calculated based on the following values: Physical capacity unit Value 1 kilobyte (KB) 1,000 (10 3 ) bytes 1 megabyte (MB) 1,000 KB or 1,000 2 bytes 1 gigabyte (GB) 1,000 MB or 1,000 3 bytes Preface 9

10 Physical capacity unit Value 1 terabyte (TB) 1,000 GB or 1,000 4 bytes 1 petabyte (PB) 1,000 TB or 1,000 5 bytes 1 exabyte (EB) 1,000 PB or 1,000 6 bytes Logical capacity values (for example, logical device capacity, cache memory capacity) are calculated based on the following values: Logical capacity unit Value 1 block 512 bytes 1 cylinder Mainframe: 870 KB Open-systems: OPEN-V: 960 KB Others: 720 KB 1 KB 1,024 (2 10 ) bytes 1 MB 1,024 KB or 1,024 2 bytes 1 GB 1,024 MB or 1,024 3 bytes 1 TB 1,024 GB or 1,024 4 bytes 1 PB 1,024 TB or 1,024 5 bytes 1 EB 1,024 PB or 1,024 6 bytes Accessing product documentation Product user documentation is available on Hitachi Data Systems Support Connect: Check this site for the most current documentation, including important updates that may have been made after the release of the product. Getting help Hitachi Data Systems Support Connect is the destination for technical support of products and solutions sold by Hitachi Data Systems. To contact technical support, log on to Hitachi Data Systems Support Connect for contact information: Hitachi Data Systems Community is a global online community for HDS customers, partners, independent software vendors, employees, and prospects. It is the destination to get answers, discover insights, and make connections. Join the conversation today! Go to community.hds.com, register, and complete your profile. 10 Preface

11 Comments Please send us your comments on this document to Include the document title and number, including the revision level (for example, -07), and refer to specific sections and paragraphs whenever possible. All comments become the property of Hitachi Data Systems Corporation. Thank you! Preface 11

12 12 Preface

13 1 Overview This application guide is intended for MS SQL Server systems and backup administrators who need to protect their MS SQL Server databases by using Hitachi Data Instance Director. It is assumed that the reader has a good working knowledge of MS SQL Server, a basic understanding of Hitachi block storage hardware, and network administration. The following figure shows Data Instance Director for MS SQL Server on a sample network: Figure 1 Data Instance Director for MS SQL Server on a sample network As you see in Figure 1, Hitachi block storage is used to protect the MS SQL Server. Overview 13

14 This guide describes how to set up SQL Server, Hitachi block storage, and Data Instance Director to implement the following data protection scenarios: Backup scenarios Restore scenarios 14 Overview

15 Backup scenarios The host based backup scenario where application data is backed up to an HDID repository is listed as follows: Backing up to a repository - creation of application and crash consistent recovery points Note: This includes batch and CDP at granular level RPO. The block based backup scenarios where application data is stored on a block storage device, which is snapshotted or replicated is listed as follows: Local snapshots - rapid creation of space-efficient recovery points Snapshots of in-system replication - restore from snapshots and from insystem replication Snapshots of a synchronous remote clone - quick recovery from snapshots and DR from the remote clone Restore scenarios The following data restoration/recovery scenarios are described: Mount a snapshot or clone - for repurposing a data base on a nonproduction server Revert to a snapshot or clone - for roll-back to a recovery point or disaster recovery Overview 15

16 16 Overview

17 2 Capabilities The Data Instance Director supports the following MS SQL Server infrastructure types: MS SQL Standalone server single instance with local or remote block storage MS SQL Standalone server multi instance with local or remote block storage MS SQL FCI single instance with local or remote block storage MS SQL Server Always on Failover Cluster Instances (FCI) multi instance with local or remote block storage MS SQL Server Always on availability Group (AAG) single instance with local or remote block storage Capabilities 17

18 18 Capabilities

19 3 Prerequisites It is important that the following prerequisites are met before you attempt to implement any of the SQL Server data protection policies described in this guide. To ensure that your hardware and software environment is fully supported, see see Hitachi Data Instance Director (HDID) Support Matrix: Host-Based, Operating System or Application. For detailed information on installing the HDID Master, Repository (ISM) and Data Source components, see Hitachi Data Instance Director User Guide. Application software prerequisites Storage hardware prerequisites Prerequisites 19

20 Application software prerequisites Before HDID can interact with MS SQL Standalone Server to protect its data, ensure that: The MS Windows updates are performed on the server node. The server is a part of the Domain Controller and the user is logged-in as a DC user for installation. The "Application Server" role is added (optional). The Media Foundation and Volume Activation Service features is added (optional). The.Net 3.5 and 4.5 packages are added. You may configure two Storage Array LUNs of minimum 30 GB are available to the server; one Storage Array LUN for the System database and the other Storage Array LUN for the User database installation. Before HDID can interact with MS SQL FCI (Failover Cluster) to protect its data, ensure that: The MS Windows updates are performed on the server nodes. The Quorum disk is configured in Microsoft Cluster Service (MSCS). The MSDTC role is configured in MSCS with IP and with block storage (Optional). The System database and User database LUNs are shared between the Source nodes. Before HDID can interact with MS SQL AAG (Always on Availability Group) to protect its data, ensure that: The MS Windows updates are performed on the server nodes. The Availability Group Listener is configured. The Quorum disk is configured in MSCS. MS SQL AAG nodes allocated with 40 GB LDEV space for System database installation, User database configuration, and AAG database configuration each. After you install SQL, complete the following steps to support HDID package: The NT Authority/SYSTEM user must be granted full access to the databases of the SQL server instance Ensure that you add the 'sysadmin' role. Ensure that you provide permission to the model database. Ensure that you update the Microsoft Service Pack as per the SQL version System CLR Types (SQLSysClrTypes.msi) Shared Management Objects (SharedManagementObjects.msi) 20 Prerequisites

21 SQL 2008/R2 with SQL 2008/R2 feature pack shipped by Microsoft SQL 2012 with SQL 2012 feature pack shipped by Microsoft SQL 2014 with SQL 2014 feature pack by shipped by Microsoft Storage hardware prerequisites If you are implementing one of the storage based backup scenarios described in this guide, before Data Instance Director can control the Hitachi block storage hardware where the MS SQL Server database file is located, ensure the following: An HDID node is assigned as a proxy node that controls the block storage device. This proxy node must be a Windows machine with: The Data Instance Director repository (ISM) capability installed CCI installed Access to a command device is set up as follows: Security disabled User authentication enabled Device group definition disabled The command device is visible to the host OS where the ISM resides The command device may be online or offline Multiple command devices may be visible to an ISM as long as each one points to a different block storage device (behaviour is undefined if multiple command devices point to the same block storage device) Multipath for command devices is supported A dedicated user for Data Instance Director has been created in the Administration user group for the storage device All paths or application data to be snapshotted or replicated exist on the same block hardware device The following licensed features are in place: Dynamic Provisioning Storage Navigator Thin Image ShadowImage TrueCopy Primary volumes are set up For application consistent snapshots, the application must be installed and configured to use HDS block P-VOLS The username specified in the VSP node's credentials must be a member of the Administration User Group on the VSP The password for authorizing a VSP node must contain only useable CCI command characters such as A-Za-z0-9'-./:@\_ Prerequisites 21

22 You must have adequate shared memory (see Provisioning and Technical Guides) Pools must be created using Storage Navigator prior to selecting the Target Storage in Data Instance Director: For Thin Image (TI) the TI Pools must be set up For ShadowImage (SI) the Dynamic Provisioning Pools must be set up For TrueCopy (TC) the Dynamic Provisioning Pools must be set up Port security must be enabled on VSP G1000 hardware Anything done directly on Hitachi block storage (outside of Data Instance Director) is not supported by Data Instance Director 22 Prerequisites

23 4 Backup workflows The following sections describe the steps required to configure policies and data flows to implement a number of different data protection scenarios. If you require a detailed introduction on how to work with the HDID user interface, see Hitachi Data Instance Director User Guide and the Reference on page 39. Host based workflows Block based workflows Backup workflows 23

24 Host based workflows This section addresses the workflows for host based backups. To ensure that all required data (such as configuration files and external index files) is available for a restore, and to ensure that a consistent state exists for all files (in the event that problems are introduced after the time of the last backup), we recommend that your site implements a suitable backup strategy. The backup strategy should include both the application classification along with a path classification, and should include all application files in the path classification, as a set of policies, as described here. If your site plans to restore a full machine, including a protected application, then in addition to the application backup, a full machine backup is required. Depending on the Recovery Point Objective (RPO, the frequency that the backup occurs) of the policies that are used, a Bare Metal Recovery (BMR) restore followed by an application restore can also be required. For information about completing a BMR, refer to the Hitachi Data Instance Director Disaster Recovery Reference. Example Policy 1: Back up the entire machine (excluding the application and application files). Set the RPO to 24 hours. Policy 2: Back up the application and application files. Set the RPO to 8 hours (or less, if required). If a finer RPO is required to restore to the latest state available, adding CDP to the policy (with an RPO of 5 minutes) will cause a repository snapshot to be created every 5 minutes. After the above policies have been implemented, all restore scenarios are available. Creating application and crash consistent recovery points In this example, a policy that utilizes CDP and Backup for the MS SQL Server application data is created. The backup operation will provide application consistent recovery points and the CDP operation will provide crash consistent recovery points. Procedure 1. Place an MS SQL Server Application Classification icon in the Classification workspace and select the MS SQL Server Database Type in the Attributes tab. 24 Backup workflows

25 Figure 2 Defining a backup policy 2. Place a CDP icon and the Backup icon in the Operation workspace. 3. Define the retention period, RPO and ensure the application is set to quiesce prior to backup (the default setting) in the Operation's Attributes tab. 4. Configure the schedule for when the CDP and backup will be taken if you require it to be done at a specific time or date, otherwise use the default settings. 5. Place the Source icon representing the MS SQL Server source node in the Data Flow workspace with the StorageGroup01 icon and connect it with the continuous mover. Backup workflows 25

26 6. Check the appropriate policies. 7. Compile and distribute the rules. Figure 3 Defining the backup data flow Block based workflows In all of the following workflows it is assumed that you have created and authorized agentless nodes that represents the: Hitachi block storage device(s) where the primary volumes (P-VOLS) are located Hitachi block storage device(s) where the secondary volumes (S-VOLS) are located - only for scenarios involving a remote site Create space efficient restore points with local snapshots Data Instance Director enables you to create a point-in-time snapshot of the MS SQL Server database by storing the changes instead of copying the whole database. The snapshot is created using Hitachi Thin Image technology. By creating a Thin Image snapshot, you can not only manage the storage space efficiently but also rapidly recover the database to a previous point in time. Because Thin Image is differential, the primary volumes are required to reconstruct the entire data set, therefore if the primary data is lost then the 26 Backup workflows

27 snapshots are of no use. For this reason, Thin Image snapshots should not be relied upon for recovery from catastrophic primary data loss. Procedure 1. Ensure that the MS SQL Server node is authorized in the HDID Master. 2. Place an MS SQL Server Application Classification icon in the Classification workspace and include the database that you want to snapshot in the associated Attributes tab. Figure 4 Defining the snapshot policy 3. Place a Snapshot operation icon in the Operation workspace and ensure the snapshot mode is set to Hardware and Hitachi Block in the associated Attributes tab. 4. Define the retention period, RPO, and ensure that the application is set to quiesce prior to backup (the default setting) in the Operation's Attributes tab. 5. Configure the schedule for when the snapshots will be taken if you require it to be done at a specific time or date, otherwise use the default settings. 6. Place the Source icon representing the MS SQL server in the Data Flow workspace and assign the snapshot policy in the associated attributes tab. A snapshot badge will be displayed close to the Source icon in the workspace. 7. Ensure that you select the pool from which snapshots will be allocated and ensure that the snapshot type is set to Differential Snapshot (using Thin Image) in the snapshot attributes tab. Backup workflows 27

28 8. Compile and distribute the rules. Figure 5 Defining the snapshot data flow 9. Manually trigger the snapshot from the Monitor window. 10. Monitor the creation of the snapshots in the Managed Storage tab of the Storage window to confirm that the policy is operating as expected. Create restore points with snapshots of a local clone Snapshot of a local clone enables both rapid recovery to a point in time by using Thin Image snapshots, while providing an additional level of protection by creating a full clone of the database by using Hitachi ShadowImage technology. Taking snapshots of the clone adds the additional benefit of being able to roll back the backup copy to a given restore point. Because Shadow Image is an in-system replication technology, it does not provide protection against a disaster at the local site, since both the primary and secondary volumes are allocated. Procedure 1. Ensure that the MS SQL Server node is authorized in the HDID Master. 2. Place an MS SQL Server Application Classification icon in the Classification workspace and include the database that you want to snapshot in the associated Attributes tab. 28 Backup workflows

29 Figure 6 Defining the snapshot of a local clone policy 3. Place Snapshot, Replicate and Snapshot Operation icons in the Operation workspace in that order. For both snapshot operations, ensure the snapshot mode is set to Hardware and Hitachi Block in the associated Attributes tab. 4. For both snapshot operations, define the retention period, RPO and ensure the application is set to quiesce prior to backup (the default setting) in the Operation's Attributes tab. 5. Leave the replicate operation attributes set to their default values. 6. Launch the Schedule Manager to create a named schedule that will tie the snapshot-replicate-snapshot operation chain together in the same synchronization group and select this named schedule in all three operations' Attributes tab. 7. Place the Source icon representing the MS SQL server and the Hitachi Block Storage icon representing the remote VSP in the Data Flow workspace and connect the MS SQL server to the VSP using a batch mover. Backup workflows 29

30 Figure 7 Defining the snapshot of a remote clone data flow 8. Assign the first snapshot operation (snapshot of the primary) to the MS SQL Server in the associated attributes tab. A snapshot badge will be displayed close to the Source icon in the workspace. 9. Assign the replication and second snapshot operation (snapshot of the remote clone) to the remote VSP node. A snapshot badge will be displayed close to the remote VSP icon in the workspace. 10. Select the pools from which local primary and remote secondary snapshots will be allocated and ensure the snapshot type is set to Thin Image in the snapshot attributes tab. 11. Select the pool from which in-system clone will be allocated and ensure that you select the Replication Configuration type as In-System Clone ShadowImage. 12. Compile and distribute the rules. 13. Monitor the creation of the snapshots and clone in the Managed Storage tab of the Storage window to confirm that the policy is operating as expected. Create restore points and disaster recovery backups with snapshots of a remote clone Snapshot of a remote clone enables both rapid recovery to a point in time by using Thin Image snapshots, while providing an additional level of protection by creating a full remote clone of the database using Hitachi TrueCopy technology. Taking snapshots of the remote clone adds the additional benefit of being able to roll back the backup copy to a given restore point from the remote site. 30 Backup workflows

31 This setup provides partial protection against a disaster at the local site and full protection at the remote site as the primary and secondary volumes are geographically separated. If necessary, production can be moved quickly to the remote site while the local site is being recovered. Procedure 1. Ensure that the MS SQL Server node is authorized in the HDID Master. 2. Place an MS SQL Server Application Classification icon in the Classification workspace and include the database that you want to snapshot in the associated Attributes tab. Figure 8 Defining the snapshot of a remote clone policy 3. Place Snapshot, Replicate and Snapshot operation icons in the Operation workspace in that order. For both snapshot operations, ensure the snapshot mode is set to Hardware and Hitachi Block in the associated Attributes tab. 4. For both snapshot operations, define the retention period, RPO and ensure the application is set to quiesce prior to backup (the default setting) in the Operation's Attributes tab. 5. Launch the Schedule Manager to create a named schedule that will tie the snapshot-replicate-snapshot operation chain together in the same synchronization group and select this named schedule in all three operations' Attributes tab. Ensure that you select the schedule for the replicate operation as anytime and select any schedule for both the snapshots. Ensure that the local and the remote snapshots have the same schedule and the replication operation has a different schedule. Note: The schedule time is the time on the source machine and not the time on the HDID Master or the HDID repository. Backup workflows 31

32 6. Place the Source icon representing the MS SQL server and the Hitachi Block Storage icon representing the VSP in the Data Flow workspace and connect the MS SQL server to the VSP by using a continuous mover. Figure 9 Defining the snapshot of a remote clone policy 7. Assign the first snapshot operation (snapshot of the primary) to the MS SQL Server node in the associated attributes tab. A snapshot badge will be displayed close to the Source icon in the workspace. 8. Assign the replication and second snapshot operation (snapshot of the clone) to the VSP node. A snapshot badge will be displayed close to the VSP icon in the workspace. 9. Select the pools from which local primary and remote secondary snapshots will be allocated and ensure the snapshot type is set to Thin Image in the snapshot attributes tab. 10. Select the pool from which remote clone will be allocated and ensure that you select the Replication Configuration type as Synchronous Remote Clone (using TrueCopy). 11. Compile and distribute the rules. 12. Monitor the creation of the snapshots in the Managed Storage tab of the Storage window to confirm that the policy is operating as expected. 32 Backup workflows

33 5 Restore workflows The following section describe the steps required to restore database volumes. In the following workflow it is assumed that you have generated snapshots or clones of the database volumes by using backup policies implemented in the Data Instance Director. Mount a snapshot or clone for repurposing Restore workflows 33

34 Mount a snapshot or clone for repurposing The mount operation is used for repurposing a clone or snapshot. It enables you to mount the database on a non-production server for development, test and analysis purposes. Mounting can be performed from the Storage - Managed Storage or Restore - Browse Backups and Snapshot windows. Repurposing of Thin Image snapshots should be done via a clone and not the production volume, to prevent affecting the performance of the production volumes. When mounting a database: It is only possible to mount a database on a host other than the source host. Data source components must be installed on the mount host. Only the backed up data files and a copy of the configuration files are provided. Data Instance Director does not start or stop any processes. When unmounting a database: Data Instance Director removes the data area but does not check, stop, or start any processes. Note: The selected mount host must have a pre-existing LUN on the corresponding storage device mounted (this is required for the autodiscover feature to work). If not, then the mount operation fails. Procedure 1. Search the Browse Backup and Snapshots tab. Results of all snapshots meeting the search criteria will be displayed. Or In the Storage window, click Managed Storage and check whether the backed up policy is listed for the MS SQL Server source. 2. Expand the tree for the policy that has been created. 3. Select a snapshot within this policy, right-click it and select Mount. 4. The Mount Snapshot Set dialog is displayed. Select from the Mount host drop down where this snapshot is to be mounted and click Mount starting with the drive radio button and select the appropriate drive. 34 Restore workflows

35 6 Revert workflows The following section describes the steps required to revert databases, bringing them back to a fully operational state. In all of the following workflows it is assumed that you have generated snapshots or clones of the database volumes using backup policies implemented in Data Instance Director. Revert to a snapshot or clone Revert a snapshot of a clone for MS SQL Server AAG Revert workflows 35

36 Revert to a snapshot or clone An SQL Server production server database can be restored to a specific point in time by using a snapshot or clone. Reverting can be performed from the Storage - Managed Storage or Restore - Browse Backups and Snapshot windows. Note: Revert overwrites the original database and destroys all data in that database as a result. Procedure 1. Search the Browse Backup and Snapshots tab, results of all snapshots meeting the search criteria will be displayed. Or In the Storage window, click Managed Storage and check whether the backed up policy is listed for the MS SQL Server source. 2. Expand the Tree and look for the policy that has been created. 3. Select a snapshot within this policy, right-click it and select Revert. 4. The Revert Warning and Confirmation dialog is displayed. To ensure the user does not accidentally perform a revert, the text REVERT must be typed in uppercase prior to clicking OK. 5. Once reversion is complete, the SQL server service must be restarted manually by the database administrator who will need to choose how to recover the database (point-in-time, last known point, and so on). Result The SQL server service will be shutdown prior to the reversion. Once reversion is complete, the SQL server service must be restarted manually by the database administrator. Revert a snapshot of a clone for MS SQL Server AAG You cannot directly revert a snapshot of an MS SQL Server AAG by using the revert option in the Data Instance Director. To revert the database that is participating in an Availability Group, you must perform the following steps. Procedure 1. Remove the database from Always On Availability Group by using the SQL Server Management Studio on the primary replica. 2. Delete the database from the secondary replicas. 3. Mount the latest snapshot of the primary replica node. 36 Revert workflows

37 4. Stop all SQL services. 5. Copy the AAG database from the mounted location to the primary replica node where the original AAG database was residing. 6. Start all SQL services. 7. Add the database to Always On Availability Group. Result The reverted database is now accessible. Revert workflows 37

38 38 Revert workflows

39 7 Reference This section provides salient reference information that supports the workflows detailed in this guide. Hitachi block storage Policy and data flow Reference 39

40 Hitachi block storage The following topics describe the details pertinent to configure the Hitachi block storage. Hitachi block storage agentless node dialog The following dialog is displayed when configuring a Hitachi block storage agentless node: Figure 10 Hitachi block storage agentless node dialog 40 Reference

41 The following table describes the attributes in the Hitachi block storage agentless node dialog: Item Node Name Node Type Storage Proxy Serial Number Authenticatio n Virtual LDEV Range Provisioning Ports (optional) Description Identifies the node on a data flow diagram. Displays the type of the node. Displays the repository (ISM) node controlling the storage device via CII software and the command device (CMD). The command device must only have user authentication enabled. Identifies the block storage device. Provides the credentials for the block storage device. Note that the password must contain only those characters useable for CCI commands. Specifies the allowable range from which snapshots and replications are provisioned. Enables specific ports to be identified for provisioning Note: The Username specified in the credentials of the VSP node must be a member of the Administration User Group on the VSP. For Data Instance Director version 5.3 and later versions, if more than one provisioning port is selected, the port with the least amount of LUNs will be used. However, if a TI Snapshot already exists, the pool for the existing snapshot set will be used. Hitachi block storage snapshot attributes The following attributes tab is displayed when a Hitachi Block Storage Hardware Snapshot operation is assigned to a node in the Data Flow workspace that is selected in the Classification workspace: Reference 41

42 Figure 11 Hitachi block storage snapshot attributes The following table describes the attributes in the Hitachi Block Storage Hardware Snapshot operation: Item Pool Resource Group Differential Snapshot (using Thin Image) Floating device (if available) Create secondary device Use consistency group Full Clone (using ShadowImage) Description Specifies the target storage pool from which snapshot LDEVS are allocated. The browse icon displays a dialog from which a pool can be selected. Specifies the group of resources from where the storage pool is selected. Specifies that the snapshots are created as a differential, insystem snapshots by using Hitachi Thin Image. If this option is selected, it specifies that VSP G400/VSP G600/VSP G1000 storage devices are used to store a larger number of snapshots by using this feature. If this option is selected, it specifies that the standard method of provisioning of SVOLS from the TI pool is used. If this option is selected, it makes a truly crash consistent snapshot by using the hardware path classification. The hardware has a limited number of consistency groups available so they should be used sparingly. Specifies that the snapshots are created as a cloned, in-system volumes by using Hitachi ShadowImage. Hitachi block storage replication attributes 42 Reference

43 The following attributes tab is displayed when a Hitachi block storage hardware replicate operation is assigned to a node in the Data Flow workspace is selected in the Classification workspace: Figure 12 Hitachi block storage replication attributes The following table describes the attributes in the Hitachi block storage hardware replicate operation: Item Type Description Specifies any of the following replication types: In-System Cone (using ShadowImage) - Specifies that the replication is created as a cloned, in-system volume using Hitachi ShadowImage. Refreshed Snapshot (Thin Image, In-System Batch Only) - Specifies that the replication is created as a single, differential, in-system snapshot using Hitachi Thin Image. The snapshot is refreshed on each batch resync rather than creating a new snapshot for each resync. Asynchronous Remote Clone (using Universal Replicator) - Specifies that the replication is created as a journalled, remote, asynchronous copy using Universal Replicator. Note: The selected journals must be unique to each operation and policy in the data flow. Source Journal specifies the journal on the source side of the replication. The browse icon displays a dialog from which a source journal can be selected. Target Journal specifies the journal on the target side of the replication. The browse icon displays a dialog from which a target journal can be selected. Synchronous Remote Clone (using TrueCopy) - Specifies that the replication is created as a remote, synchronous copy using Hitachi TrueCopy. On destination write failure: Ignore (Fence Level Never) - When writing to the primary volumes, confirm the write regardless of whether the data has been copied successfully to secondary volumes. Reference 43

44 Item Description Fail source write (Fence Level Data) - Only confirm primary volume writes if the data is successfully copied to the secondary volume, generate a write error if not. Fail source write if not in error status (Fence Level Status) - Only generate a write error if the data is not successfully copied to the secondary volume and the replication has not been put into an error status (PSUE). Active-Active Remote Clone (Global-Active Device) - Specifies that the replication allows volume consistent, remote, active-active replication. Unlike TrueCopy, read/ write operations are permitted on both the primary and secondary volume even in the replicating state, hence both sides of the replication pair are said to be active. Mirror Pool Resource Group Copy Pace Specifies the type of allocation use for mirroring. Specifies the target storage pool from which replication LDEVS are allocated. The browse icon displays a dialog from which a pool can be selected. Specifies the group of resources used to allocate the storage pool. Determines how quickly the storage array copies data (1 is slowest, 15 fastest). The array's default is 3, HDID defaults to 8. Policy and data flow The following topics describe the details pertinent to configure the Data Instance Director policies and data flows. Snapshot operation attributes The following attributes tab is displayed when a Snapshot operation icon is selected in the Operation workspace: 44 Reference

45 Figure 13 Snapshot operation attributes The Snapshot operation is used to trigger snapshots of entire volumes. Created snapshots can be accessed using the Restore window where they can be mounted or used for reverting a volume to a previous state. The following table describes the Snapshot operation attributes: Item Name Retention and Recovery Point Objective Mode Description Used to identify the operation when the policy is used in the Data Flow diagram. Set to a specified period. These controls are used in conjunction with the Run controls. If no schedules are defined, then a snapshot is created on the source node whenever the Recovery Point Objective time is reached. The times and/or dates that these snapshots are or are not created can be controlled by using the Schedule Manager to define a schedule. This schedule can then be selected with the Schedules combo box. Specifies any of the following modes: Software - for snapshots of paths, MS Exchange or MS SQL using the appropriate VSS provider. This option is only available on Windows nodes. Hitachi V2I - for snapshots of VMware nodes using V2I. Hardware - for snapshots of attached storage. If Hardware mode is selected then the Hardware type can be set to: Hitachi Block for VSP and HUS VM block storage Hitachi NAS for Hitachi NAS file storage Source options Source options contain options designed to ensure snapshot consistency. A pre script and post script can be specified to ensure consistent state prior to the snapshot. Reference 45

46 Note: Snapshot operations always apply to the whole selected volume. Any associated data classifications are ignored. Snapshots will be automatically retired after the given retention period, indexed by the Metadata Store and can be mounted and reverted using the Restore window. Replicate operation attributes The following attributes tab is displayed when a Replicate operation icon is selected in the Operation workspace: Figure 14 Replicate operation attributes The Replicate operation is used to keep an identical copy of the latest data in the policy. Only the latest version of each file is retained. The replica can be stored either in a mirror or in a repository on the destination node. The following table describe the Replicate attributes: Item Name Software Replication Type Batch Only Options Description Used to identify the operation when the policy is used in a Data Flow diagram. Specifies how the file system operations on the matching data classifications are logged. You can either choose the Asynchronous or the Asynchronous journaled option. Replication can be performed in real time using a mirror mover or in batch mode using a batch mover. Described below are only relevant when using a batch mover. Schedules section contains the Schedule Manager and a combo box that lists predefined and user defined schedules. Source Options group contains options designed to ensure consistency of application files prior to mirroring. If the Quiesce configured applications before backup option is checked and any Exchange Server, MS SQL Server, MS Hyper-V, Oracle or SAP HANA classifiers are included in the policy, then these applications will be temporarily quiesced into a consistent state prior to being 46 Reference

47 Item Description mirrored. A pre script and post script can also be specified to ensure consistent state for other applications. Quiescing applications during backup Ordinarily, when a snapshot is performed, the state of the snapshot consists of the exact state of the file system at the point in time at which the snapshot was triggered. This can be problematic when the snapshot is eventually restored, as some applications that were running at the time cannot, for example, have flushed all their in memory file buffers, and their data files on disk could therefore be in an inconsistent state. To resolve this, it is possible to request certain applications to quiesce into a safe state prior to a snapshot being triggered, and then to restore their previous active state after the snapshot is triggered. This ensures their state during the snapshot is consistent and that they can run as expected if the snapshot is restored. If an application cannot be quiesced, a snapshot of its files is said to be in a crash-consistent state, as if the application had crashed while running. Crash consistent snapshots can, depending on the application, be used to restore state to some point prior to the snapshot. Synchronization groups The purpose of synchronization groups is to ensure that, if required, multiple snapshots or batch replications of source data can be created on multiple nodes by using the same schedule and yet remain consistent with each other and with the source data. To this end any two operations in the same policy using the same schedule name will be placed in the same synchronization group. When a dataflow is created, any nodes implementing operations using that synchronization group will be scheduled all as one. Note: The RPO of all snapshot operations in the same synchronization group must be identical. The rules compiler checks the RPO settings and if found inconsistent, it generates error 10356: Policy policyname contains multiple hardware snapshot operations with different RPO settings but all use schedule schedule In a simple case of a batch dataflow A -> B -> C where B and C both implement a replicate operation within policy P then if both those operations share the same schedule name S they will be both be part of the same synchronization group and be scheduled as one. This ensures that the replica of B that is created on C is created only when the replica of A created on B has been completed and so the replicas on B and C remain identical. Reference 47

48 When mixing live and batch data flows or implementing different schedules (synchronization groups) at different points of the data flow, the basic rule for implementing these is that any operation is traced back towards the source, and if an operation sharing the same synchronization group is implemented on an immediately preceding node, then they will be scheduled together by the first preceding node that does not use that synchronization group. Note that live replications are considered to be in all synchronization groups since they should always match the source. 48 Reference

49 8 Troubleshooting CDP and Replicate operations continue to execute with a non existing database as part of its policy Cannot see the Shadow copy instance freeze message for MS Exchange application Handler call failed: [...] failed to create snapshot pair [...] Handler call failed: [] snapshots that are in a different pool Handler call failed: refreshlogicaldevices Failed [...] Troubleshooting 49

50 CDP and Replicate operations continue to execute with a non existing database as part of its policy When you execute a CDP or a Replicate operation with a non existing database, the following warning message appears: Note: This warning message appears only once when the operation starts and there are no further notifications in the log for further activities on the same policy for the defined RPO or re-synchronization. Message: Warning creating snapshot: Database doesn't exist: <DBName> Ensure that the database name that is entered for the CDP or Replicate operation is correct. Cannot see the Shadow copy instance freeze message for MS Exchange application This issue occurs when a single policy has been configured with two or more applications that includes MS Exchange, Filesystem, and MS SQL on a single server with backup operation (with default quiesce configured applications option enabled). For example, if a policy with MS SQL, MS Exchange, and Filesystem has been created on a single server by using the quiesce configured applications with the backup operation, the Windows Event Viewer Application logs do not display the Shadow copy instance freeze message for MS Exchange application. However, we recommend you to create individual policies for each application to resolve this issue as Data Instance Director does not handle multiple writers at the same time through a single policy. Handler call failed: [...] failed to create snapshot pair [...] VSP has a limit of 1024 snapshots per LDEV. When this limit is reached, no more snapshots can be created. If you set an overly aggressive RPO combined with long retention times then this limit can be quickly reached. Handler call failed: [] snapshots that are in a different pool VSP will only allow one pool to be used for snapshots (S-VOL) per primary volume (P-VOL). This error message indicates that the P-VOL in question already has a pool assigned for snapshots, and this is not the same pool as defined in the policy. 50 Troubleshooting

51 Handler call failed: refreshlogicaldevices Failed [...] This error message occurs where the user account does not have permission to access the LDEV because the LDEV is not in the resource group the user account can access. This can be confirmed by running raidcom manually: C:\HORCM\etc>raidcom.exe get ldev -ldev_id I0 raidcom: [EX_EGPERM] Permission denied with the Resource Group Troubleshooting 51

52 52 Troubleshooting

53 Glossary A Archive A copy that is created for long-term retention. Asynchronous journaling Transactions are written to disk and also placed in a journal log file, to protect against data loss in the event of a system failure. Transactions from the log file are sent to the destination machine. Asynchronous replication Transactions are held in memory before being sent over the network. If the network is unavailable then transactions are written to disk and sent to the destination machine when the connection is re-established. Asynchronous replication is optimal for connections with sporadic efficiency. B Backup A copy that is created for operational and disaster recovery. Bandwidth throttling Used to control when and what proportion of available network bandwidth is used by Data Instance Director for replication. Batch backup A process by which the repository is updated periodically using scheduled resynchronizations. This method involves a scan of the source machine's file system, but only the changed bytes are transferred and stored. This method is useful for data that does not change often, such as data contained on the operating system disk. Linux based source nodes are only able to perform batch backups. See CDP below. Glossary 53