Microsoft SQL Server 2012 virtual machine protection using ... · PDF fileMicrosoft SQL Server...

© Copyright IBM Corporation, 2013

Microsoft SQL Server 2012 virtual machine protection using IBM Tivoli

Storage FlashCopy Manager

For VMware ESX 5.1 environments with the IBM XIV Storage System Gen3

Eric B. Johnson

IBM Systems and Technology Group ISV Enablement

June 2013

Stay connected with IBM System Storage

Twitter | LinkedIn | Facebook | YouTube | RSS feeds | → Forum | → Community | → More communities

http://twitter.com/ibmstorage

http://www.linkedin.com/groups?about=&gid=2018491&trk=anet_ug_grppro

http://www.facebook.com/groups/37153201060/

http://www.youtube.com/ibmstorage

http://www-03.ibm.com/systems/storage/news/storage.rss

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=846

http://storagecommunity.org/

http://www-03.ibm.com/systems/storage/community/index.html

Microsoft SQL Server 2012 virtual machine protection using IBM Tivoli Storage FlashCopy Manager © Copyright IBM Corporation, 2013

Table of contents

Abstract ..................................................................................................................................... 1

Introduction .............................................................................................................................. 1

IBM XIV Storage System Gen3 ................................................................................................ 3

Recent IBM XIV Storage System Gen3 enhancements and new features ............................................. 4

VMware vSphere 5.1 ................................................................................................................. 5

Microsoft SQL 2012 AlwaysOn Availability Groups ............................................................... 5

FlashCopy Manager 3.2 new SQL protection features ........................................................... 5

Test environment description.................................................................................................. 6

IBM Tivoli Storage FlashCopy Manager prerequisites ........................................................... 7

IBM XIV pool snapshot sizing considerations .......................................................................................... 8

IBM XIV Provider for Microsoft Windows VSS v2.3.2.2 guest installation ............................................. 10

IBM XIV Provider for Microsoft Windows VSS v2.3.2.2 guest configuration ......................................... 14

Machine Pool Editor guest addition of the IBM XIV Storage System .............................. 14

Machine Pool CLI VMware configuration ........................................................................ 15

IBM XIV VSS Hardware Provider verification ........................................................................................ 16

IBM Tivoli Storage FlashCopy Manager installation ............................................................ 19

IBM Tivoli Storage FlashCopy Manager configuration ........................................................ 24

FlashCopy Manager SQL Server AlwaysOn Availability Groups data protection .............. 30

Primary replica availability data protection strategy .............................................................................. 31

Backup SQL AlwaysOn Availability Groups primary replica database ........................... 31

Restore SQL AlwaysOn Availability Groups primary replica database ........................... 32

Secondary replica availability data protection strategy .......................................................................... 39

Back up SQL AlwaysOn Availability Groups secondary replica database ...................... 40

Restore SQL AlwaysOn Availability Groups secondary replica database ...................... 41

Combined primary and secondary replica availability data protection strategy .................................... 45

Summary ................................................................................................................................. 47

Resources ............................................................................................................................... 48

Trademarks and special notices ........................................................................................... 49


1

Abstract

IBM Tivoli® Storage FlashCopy Manager takes advantage of the Microsoft Volume Shadow Copy Service (VSS) framework to provide rapid application-aware backups and restores using IBM XIV Storage System Gen3 advanced snapshot technology. This white paper describes VMware ESX 5.1 business-critical database protection for Microsoft SQL Server 2012 virtual machines (VMs). Installation, configuration and best practice guidelines are shared exclusively for guest-initiated local backups and restores of Microsoft SQL Server AlwaysOn Availability Group (AAG) databases yet many of the data protection concepts can be applied to traditional Microsoft SQL Server databases.

Microsoft database and IBM storage administrators pursuing virtual machine deployment and backup strategies are the intended audience for this technical material. Likewise, this paper is designed for mid- to large-size businesses evaluating or pursuing highly available Microsoft database solutions for VMware virtual data centers.

Advanced experience with IBM Tivoli Storage FlashCopy Manager, Microsoft SQL Server, VMware, and IBM XIV Storage System Gen3 administration is recommended. However, technical reviews and supplemental resources are provided throughout the following sections.

Introduction

Historically, challenges associated with lengthy backup and restore durations combined with the inability to

back up open files prompted Microsoft® to develop the Volume Shadow Copy Service framework,

commonly referred to as the VSS framework. VSS origins stem from an obvious realization that

simultaneously addresses customer requirements. The ability to rapidly and consistently back up and

restore data is paramount to contemporary business survival because unplanned critical data outages

often have debilitating financial consequences.

By standardizing the VSS framework, not only do customers benefit but backup software and hardware

vendors also benefit from a universal VSS architecture which minimizes financial impact for all parties by

reducing customer downtime, decreasing support requests for all parties, and paring and simplifying

backup software test and development cycles. All said, Microsoft provides the VSS foundation for all

Microsoft Windows® users (dating back to Windows Server 2003) but ultimately, the backup software and

hardware vendors must provide solution-specific snapshot technologies that embrace it.

Essentially, storage array snapshot technology enables a point-in-time block-level data copy with minimal

impact to production systems or applications typically viewed from two basic perspectives. From the

physical or virtual machine operating system (OS) perspective, snapshots are used to create crash-

consistent backups. Virtual machine crash-consistent backups are typically host-initiated and do not

account for application transaction states. From the application perspective, snapshots can be used to

create application-consistent backups. In order for this to work correctly, applications (that provide VSS

writers) are briefly quiesced to allow the disk subsystem to concurrently create snapped copies of

application data and log volumes. This helps to ensure that there is no pending I/O or uncommitted

application transactions (in memory or transaction logs) during the snapshot process which could be lost

during crash-consistent backups. Thus, all application I/O is flushed to disk during the quiesce process.

Application-consistent backups are especially important for database applications, such as Microsoft SQL

Server 2012, and are host or guest-initiated depending on individual VSS software support. Comparing

proponents of guest with host-initiated snapshot backup strategies show that both have unique, valid, and

compelling cases that merely boil down to preference.


2

This white paper simply focuses on guest-initiated virtual machine snapshot backup strategies that

represent key IBM® Tivoli® Storage FlashCopy® Manager supported data protection methods. For the

most part, this guest-initiated VM backup solution simulates familiar, comprehensive physical server

backup mechanisms by simplifying application-consistent data protection and offering numerous rich

capabilities, including the flexibility to easily remap application data and log raw device-mapping (RDM)

disks to other virtual or physical machines. Also worth mentioning, for Microsoft SQL Server 2012

AlwaysOn Availability Groups solutions that use SQL-clustered instances, VMware guest cluster support

requires RDM disks with the exception of Cluster-in-a-Box (CIB) solutions. For VMware guest clusters that

use traditional compared to CIB server solutions, Microsoft SQL Server 2012 AlwaysOn Availability

Groups solutions that use SQL-clustered instances only support guest-initiated FlashCopy Manager

application-consistent backups of RDM data and log disks.

No matter whether backups are guest- or host-initiated, the ability to use local snapshot volumes, for high-

speed data protection without negatively impacting production services combined with the ability to

eliminate network latency and bandwidth penalties, makes VSS backups very appealing. On closer

examination, (the following) four distinct VSS components make all of these rapid backup processes

possible as illustrated in Figure 1:

VSS service: The VSS service is part of the Windows operating system and acts as a

communication hub or interpreter for all of the framework components.

VSS requestor: The VSS requestor is the backup software represented by the IBM Tivoli

Storage FlashCopy Manager application.

VSS writer: The VSS writer in this solution is represented by the Microsoft SQL Server

VSS Writer service, which is installed by default during the database software installation.

VSS provider: The VSS provider is represented by the hardware/software combination

that generates the actual snapshot volume. In this case, the snapshots are generated by

the IBM XIV® Storage System VSS provider and the actual storage system itself.

Figure 1: Microsoft VSS framework

Playing a pivotal role in the VSS framework, the IBM XIV Storage System uses extremely efficient redirect-

on-write snapshot technology in comparison to the average copy-on-write snapshot design. The redirect-

on-write technology eliminates double write performance penalties commonly associated with copy-on-

write snapshots. Copy-on-write snapshots write twice, the first time to the reserved snapshot pool space


3

and the next time to the original source volume. The snapshot pool space maintains the original source

data and thus the point-in-time copy is preserved. However, the host does not receive a write

acknowledgement until both writes take place. Conversely, the redirect-on-write technology preserves the

original source data and redirects new writes or changes to the reserved snapshot pool space. The

snapshot performance is significantly improved and the creation time is greatly reduced, all while

consuming no additional disk space until the original source data changes.

IBM XIV Storage System Gen3

In addition to its VSS capabilities, the IBM XIV virtual storage design includes multi-level data protection

starting with simple host writes. To expound, a host write is temporarily mirrored between the cache of

different modules before the XIV Storage System acknowledges, and the write is received and the data is

destaged to the member disks of each individual module. Consequently, the data is always protected

against possible module failures even before the data is destaged using 1 MB XIV partitions.

IBM XIV partitions are the fundamental building blocks used to create volumes and incorporate primary

and secondary mirrored data copies mapped to separate disks. Using sophisticated data distribution

algorithms that preserve data redundancy and performance equilibrium, XIV partitions are automatically

and dynamically distributed across all disks (up to 180). As the distribution algorithms pseudo randomly

distribute the data across all of the spindles, there is no logical unit number (LUN) locality of reference to a

particular disk or subset of disks, essentially eliminating hot spots regardless of workload changes over

time. As a result, the IBM XIV Storage System self tunes in response to application I/O patterns and

configuration and capacity changes, all while maintaining maximum data protection.

Data protection is also reinforced using IBM XIV predetermined data distribution algorithms, which help

ensure fast recovery from major and minor faults using prefailure detection and proactive corrective

healing. In the event of module or disk failures, global spares striped across all disks quickly redistribute

data back to a fully redundant state. During such events, the performance impact is notably minimized and

further enhanced by the XIV core, enterprise-class data protection mechanisms.

IBM XIV multi-level data protection employs active/active N+1 redundancy of all data modules, disks,

interconnect switches, and battery backup uninterruptible power supply (UPS) units. The XIV system also

contains an automatic transfer switch (ATS) for external power supply redundancy. A built-in UPS complex

consisting of three UPS units protects all disks, cache, and electronics with redundant power supplies and

fans, which further promotes Microsoft SQL database availability and reliability.

Finally, the IBM XIV Gen3 unique and sophisticated storage design is very user-friendly and requires

minimal administrative effort. The storage management utilities are categorically intuitive and pleasant to

use so much so that IBM continues to develop almost identical graphical user interfaces (GUIs) for other

members of its storage portfolio in response to customer popularity. This unique evolutionary architecture

coupled with truly uncomplicated management software is vastly improved with the XIV Storage System

Gen3 family and helps provide the following key benefits:

Up to four times the throughput (10 GBps) of the previous XIV generation, improving

performance for business intelligence, archiving, and other I/O-intensive applications

Up to three times improved response time of the previous XIV generation, enabling faster

transaction processing and greater scalability for online transaction processing, database,

and email applications


4

Industry-leading rebuild times in the event of disk or module failures (less than 60 minutes

for 2 TB drives)

Innovative snapshot functionality that includes snap-of-snap, restore-of-snap, and a nearly

unlimited number of snapshots

Non-disruptive maintenance and upgrades

Per host/cluster quality of service (QoS) capability to prioritize workloads based on

business criticality

Power to serve even more applications from a single system with a substantial hardware

upgrade that includes an InfiniBand® interconnect, larger cache (up to 360 GB of

combined memory), faster SAS disk controllers and increased processing power—plus,

each Gen3 interface module delivers 8 Gb Fibre Channel (FC) and 1 Gb iSCSI

connectivity

Boost highly random application workloads up to 4.5 times with optional solid-state drive

(SSD) cache

With the XIV family’s all-inclusive pricing model, there are no hidden costs for multipath

software or replication features — specifically, every XIV includes the following features

with purchase: snapshot capability, thin provisioning, asynchronous and synchronous data

replication, advanced management, performance reporting, monitoring and alerting, and

full support of Microsoft technologies including GeoClustering, Volume Shadow Copy

Services and Multipath I/O (MPIO).

Recent IBM XIV Storage System Gen3 enhancements and new features

Building upon an existing strong foundation, the new XIV Gen3 enhancements provide the following

improvements:

Provided new cloud and virtualization enhancements

10 GbE iSCSI host connectivity

Microsoft Windows Server 2012 support for new features such as Hyper-V, VSS,

and failover clustering

Improved storage system self-optimization and performance

Reduce disk rebuilds by 60% during heavy workloads, fully utilized 2 TB drives

can be rebuilt in 26 minutes

Faster sequential read performance up to 13.7 GBps, enabling high service level

agreements for VM cloning, multimedia, and backup workloads

Up to 15 six-core Intel® Xeon® processors providing 90 physical cores or 180

logical cores using the Hyper-Threading technology

Decreased total cost to ownership (TCO) through greater energy efficiency and capacity

optimization

Promotes green data center strategies by lowering carbon footprints and

aggregate power consumption by up to 16% with new power supply units - now

available with model 214

Small Computer System Interface (SCSI) UNMAP space reclamation


5

VMware vSphere 5.1

As the current industry hypervisor leader, VMware presence permeates throughout countless data

centers, many of which elect to use end-to-end virtualization with IBM XIV Storage Systems. IBM XIV

storage developers work closely with VMware to provide in-depth integration with its storage products

portfolio which has resulted in the following enhancements:

vSphere APIs for Array Integration (VAAI) support

vSphere APIs for Storage Awareness (VASA) support

vCenter Server Plug-in

IBM Tivoli Storage FlashCopy Manager Data Protection for VMware vCenter plug-in

vStorage APIs for Data Protection (VADP) support with Tivoli Storage Manager for Virtual

Environments

Site Recovery Adapter for VMware Site Recovery Manager

IBM XIV native storage integration with VMware is included with standard IBM XIV licensing and many

enhancements are enabled by default. However, some require downloading additional software, drivers or

plug-ins. Furthermore, additional licensing fees are required for IBM Tivoli products and while detailed

host-initiated backups using these products are beyond the scope of this white paper, they are listed as

potential supplemental data protection solutions that can be combined to protect Microsoft SQL Server

2012 physical or virtual machines.

Microsoft SQL 2012 AlwaysOn Availability Groups

While there are many welcomed new additions to the release of Microsoft SQL Server 2012, none are

probably more appreciated than the AlwaysOn Availability Groups feature. The AlwaysOn Availability

Groups feature elevates Microsoft SQL Server high availability (HA) to the next level by coupling the host-

level protection of failover cluster instances with the database-level protection of database mirroring.

AlwaysOn Availability Groups combine these two SQL HA technologies to deliver a formidable and

incredibly reliable database solution. However, high availability designs do not prevent database

corruption or guarantee 100% uptime even for SQL AlwaysOn Availability Groups with multiple replica

databases. Thus prudent organizations always plan for possible database corruption and unavailability by

using data protection products such as IBM Tivoli Storage FlashCopy Manager together with VSS-

intelligent storage such as IBM XIV Storage System Gen3.

FlashCopy Manager 3.2 new SQL protection features

IBM Tivoli Storage FlashCopy Manager has been able to protect Microsoft SQL Server failover cluster

instances and database mirrors for quite some time. Not surprising, the latest FlashCopy Manager 3.2

release (at the time of this publication) contains several new features that include the addition of Microsoft

SQL Server 2012 AlwaysOn Availability Groups database support – the latter being the focus of this white

paper. With this development, SQL-consistent backups and restores using IBM XIV snapshots can be

performed on the primary or secondary SQL AlwaysOn Availability Groups replicas depending on the

database protection preferences. Moreover, FlashCopy Manager guest-initiated full backups of both

Microsoft SQL Server 2012 standalone and failover cluster AlwaysOn Availability Groups instances can be

performed. The following enhancements are now available with this latest release:


6

Back up and restore AlwaysOn Availability Groups databases to provide high availability

and disaster recovery at the SQL server database level, including:

− Display of AlwaysOn Availability Groups databases with group information in the

graphical user interface (GUI) and command-line interface (CLI)

− Back up and restore any SQL Server database in an AlwaysOn Availability

Groups

− Management and expiration of an availability database backup from different

replicas in a common Tivoli Storage Manager file space to maintain a single chain

of backups (this only applies when integrated with a Tivoli Storage Manager

server)

− Configuration of the replica that backs up an availability database during

scheduled backups

− Creation of copy-only full backups on primary and secondary database replicas

Back up and restore any SQL Server database by using any node in an AlwaysOn

Failover Cluster instance to provide high availability and disaster recovery at the SQL

server instance level.

Test environment description

The ensuing list of solution components was used purely for VSS backup functionality testing:

Microsoft SQL Server 2012

Windows Server 2008 R2 SP1 Guest Clustering

Note: VMware vSphere 5.1 does not support Windows Server 2012 guest clusters.

VMware ESX 5.1 hosts and a vCenter Server 5.1 VM

− SQL VM Raw Device Mapping (RDM) log and data disks configured for physical

compatibility mode only using Round Robin (VMware) managed paths due to

standalone SQL AlwaysOn Availability Groups replica instances.

Reminder: If SQL failover cluster instances are used for an AlwaysOn Availability

Groups implementation, RDM fixed (VMware) managed paths must be used as

per VMware guest cluster support guidelines.

IBM Tivoli Storage FlashCopy Manager 3.2

− FlashCopy Manager guest-initiated VSS backups only support VMware RDM

disks and host-initiated support is beyond the scope of this paper.

IBM XIV VSS Provider for Windows 2.3.2.2

IBM System x3550 M2 servers (based on hardware availability only)

Brocade 825 HBAs

IBM SAN24B-4 FC switches

IBM XIV Storage System Gen3 11.2.0.a

For detailed main product deployment guidance, refer to the “Resources” section at the end of the white

paper. Figure 2 provides the overall test solution layout:


7

Figure 2: Guest-initiated FlashCopy Manager SQL Server 2012 AlwaysOn Availability Groups VM test implementation with IBM XIV storage

IBM Tivoli Storage FlashCopy Manager prerequisites

The following list of prerequisites is required for IBM Tivoli Storage FlashCopy Manager 3.2 to successfully

back up and restore SQL Server 2012 virtual machines in a VMware 5.1 environment:

Install the VMware tools on all guests.

Confirm that the vSphere web services are running on the ESX hosts or vCenter Server

by connecting to:

https://ESX_Host_or_vCenter_IP_Address/mob

Configure a VMware user account with the following administrative privileges:

− Host > Configuration > Storage partition configuration

− Virtual machine > Configuration > Raw device

− Virtual machine > Configuration > Change resource

− Virtual machine > Configuration > Add or remove device

Note: For testing purposes, the vCenter default admin@System-Domain

account was used.

Reminder: VMware user accounts are case sensitive.

Configure the Microsoft SQL guest data and log volumes as VMware RDMs in the

physical compatibility mode only.


8

Reminder: FlashCopy Manager guest-initiated VSS backups and restores

only support RDMs that basically simulate physical server database

protection mechanisms.

Configure Windows 2008 R2 guest clustering if SQL Server 2012 AlwaysOn Availability

Group databases need to be protected. Both SQL Server standalone and failover cluster

installations are supported for SQL Server AlwaysOn Availability Group implementations.

Determine the appropriate IBM XIV pool snapshot reserve space.

Install and configure the IBM XIV VSS Provider for Windows v2.3.2.2 on each SQL 2012

guest.

Note: Only IBM solution-specific configuration guidelines are detailed in the following section as VMware

and Microsoft advanced expertise is assumed.

For further Microsoft SQL Server 2012 AlwaysOn Availability Groups information, visit the following

website:

http://msdn.microsoft.com/en-us/library/ff877884.aspx

IBM XIV pool snapshot sizing considerations

Before creating snapshots on the IBM XIV system, proper storage pool sizing should be completed to

accommodate future snapshot requirements. Estimate the necessary pool snapshot reserve size based on

data change rates, desired snapshot retention policies, and the anticipated number of snapshots.

Fortunately, IBM XIV snapshot planning accuracy is somewhat forgiving because it is rather easy to non-

disruptively modify the pool snapshot reserve space. Simple snapshot sizing adjustments can be made

periodically to avoid under- or over-allocating space.

To further assist with IBM XIV snapshot planning, there are several noteworthy considerations. After a

pool’s snapshot reserve becomes totally depleted, the IBM XIV system systematically deletes snapshots in

an orderly fashion based on deletion priorities and age until the snapshot reserve once again contains

adequate free space. Thus, it is important to ensure sufficient snapshot space to prevent unwanted

snapshot deletion from occurring, especially during backups. As a general rule of thumb, the minimum

required snapshot space is (17GB * number of desired snapshots) + 17 GB. For simple backups that

generate a single non-persistent snapshot per LUN, this rule of thumb is usually sufficient. However, if

there are frequent data changes or highly random writes to the source LUNs during the backup process,

additional snapshot space may be needed. Other considerations include host-mounted, write-enabled

snapshot volumes, asynchronous replication, snapshots saved as part of a disaster recovery rollback

strategy, and other respective snapshot growth sources.

Note: In-depth IBM XIV snapshot utilization is beyond the scope of this paper. To change the amount of IBM XIV pool space reserved for snapshots, perform the following quick steps:

1. Launch the IBM XIV GUI from the Windows Start menu:

Click Start All Programs IBM XIV GUI 4.x IBM XIV GUI and log in.

2. Click XIV System to go to the XIV Storage Management view.

3. Move the mouse over the third icon on the left side of the window to view the Pools menu and

click Storage Pools (as shown in Figure 3).


9

Figure 3: XIV Storage management pools menu

4. Right-click the storage pool and click Resize (see Figure 4).

Figure 4: XIV storage management resize pool


10

5. Enter the required snapshot size and click Update (refer to Figure 5) to finish.

Figure 5: XIV storage management resize pool dialog box

Note: When IBM XIV pools are initially created, the snapshot size defaults to 10% of the pool size. Modify

the pool snapshot size according to individual backup requirements.

IBM XIV Provider for Microsoft Windows VSS v2.3.2.2 guest installation

In order for IBM Tivoli Storage FlashCopy Manager to use hardware snapshots, the IBM XIV Provider for

Microsoft Windows VSS must be installed and configured properly for all of the SQL Server 2012 guests.

Perform the following steps on all of the database virtual machines to be protected:

1. Download and launch the IBM XIV Provider for Microsoft Windows VSS installation wizard by

double-clicking xProvSetup_2.3.2.2_for_Windows-x64.exe.

2. Select the preferred installation language and click OK (refer to Figure 6).

Figure 6: Figure 6: IBM XIV Provider for Microsoft Windows VSS InstallShield Wizard language selection


11

3. In the InstallShield Wizard that appears, click Next (refer to Figure 7).

Figure 7: IBM XIV Provider for Microsoft Windows VSS InstallShield Wizard

4. Accept the terms of the software license agreement and click Next (refer to Figure 8).

Figure 8: IBM XIV Provider for Microsoft Windows VSS InstallShield Wizard software license agreement


12

5. Use the default folder or provide a new installation destination folder and click Next (refer to

Figure 9).

Figure 9: IBM XIV Provider for Microsoft Windows VSS InstallShield Wizard destination folder

6. Retain the post install operations default selection and click Next (refer to Figure 10).

Figure 10: IBM XIV Provider for Microsoft Windows VSS InstallShield Wizard post install operations


13

7. To begin the installation, click Install (refer to Figure 11).

Figure 11: IBM XIV Provider for Microsoft Windows VSS InstallShield Wizard ready to install the program

8. Confirm the successful installation of IBM XIV Provider for Microsoft Windows VSS and click

Finish (refer to Figure 12).

Figure 12: IBM XIV Provider for Microsoft Windows VSS InstallShield Wizard completed


14

IBM XIV Provider for Microsoft Windows VSS v2.3.2.2 guest

configuration

After the IBM XIV Provider for Microsoft Windows VSS installation has successfully completed, the

Microsoft SQL guests must be configured for VSS. First, each guest operating system (OS) must be

configured to use the xProv HW VSS Provider Windows service to communicate with the actual storage

system. Second, set the additional required VMware parameters for the virtual machines within each guest

OS.

Machine Pool Editor guest addition of the IBM XIV Storage System

The Machine Pool Editor is a separate application that gets installed during the IBM XIV Provider for

Microsoft Windows VSS installation that configures the guest to connect to the storage system. The

Machine Pool Editor has both GUI and CLI versions with both demonstrated in this section.

1. From the menu bar in the Machine Pool Editor window that is launched as a result of step 6 of

the IBM XIV Provider for Microsoft Windows VSS installation, click File New System (refer to

Figure 13).

Figure 13: Machine Pool Editor menu bar selection

2. Enter an IBM XIV Storage System username, password, and IP/Hostname in their respective text

fields and click Add (refer to Figure 14).


15

Figure 14: Machine Pool Editor add storage system

Note: The default IBM XIV Storage System admin user account was used for testing and any of

the (up to three) IBM XIV management IP addresses can be entered in the IP/Hostname field.

The test environment did not use data replication. So, the Enable Replicated Snapshots check

box was not selected

3. Confirm the newly added IBM XIV Storage System and close the Machine Pool Editor (refer to

Figure 15).

Figure 15: Machine Pool Editor systems

Machine Pool CLI VMware configuration

To perform VMware guest-initiated backups and restores, an additional IBM XIV Provider for Microsoft

Windows VSS configuration step is required to establish proper communication with the vSphere web


16

services of either the ESX or vCenter server. This allows hardware snapshots to be generated from

the Microsoft SQL Server VM data and log RDM disks.

For the VMware-specific VSS guest configuration, administrators must use the Machine Pool CLI

version because the settings cannot be modified using the GUI version. Perform the Machine Pool

edits from a Windows command line using elevated local administrator privileges.

1. To determine the available commands and syntax of MachinePoolCLI.exe, view the application

help from the IBM XIV Provider for Microsoft Windows VSS installation source. All command

syntax examples use the following default installation path:

C:\Program Files\IBM\IBM XIV Provider for Microsoft Windows Volume Shadow

Copy Service\.NET

MachinePoolCLI.exe /?

Usage:

MachinePoolCLI /a <user> <password> <IP> [/rs|replicate_snapshots]

MachinePoolCLI /d <machine_serial_number>

MachinePoolCLI /l [/v]

MachinePoolCLI /ae <username> <password> <esx host|vCenter name(IP)>

MachinePoolCLI /de

MachinePoolCli /le

2. Configure guest IBM XIV VSS communication for either an ESX or vCenter server.

MachinePoolCLI.exe /ae admin@System-Domain password 192.168.101.222

Connecting to ESX Server or vCenter with SSL......

Successfully connected to ESX Server or vCenter.

Successfully added ESX Server or vCenter, url:'https://192.168.101.222/sdk',

user: 'admin@System-Domain'

3. Confirm the IBM XIV connection with the guest and the newly created VMware credentials:

MachinePoolCLI.exe /l

Serial Name Version IP(1) IP(2) IP(3) User Mirror Snapshots

7820064 N/A N/A 192.168.101.252 192.168.101.251 192.168.101.253 admin N/A

MachinePoolCLI.exe /le

ESX Server | vCenter URL: https://192.168.101.222/sdk

ESX Server | vCenter User: admin@System-Domain

For further IBM XIV Provider for Microsoft Windows VSS installation and configuration details, review the

following guide:

http://delivery04.dhe.ibm.com/sar/CMA/SDA/03q0y/0/XIV_Provider_for_MS_VSS_2.3.2_IG.pdf

IBM XIV VSS Hardware Provider verification

As a best practice, after the IBM XIV Provider for Microsoft Windows VSS has been installed, confirm

hardware-based snapshots can be triggered by the guests. There are two types of snapshots, persistent

and non-persistent, that are commonly used for backup solutions and both can be tested using the native

Microsoft Windows DiskShadow or Vssadmin utilities. As the functionality of both the utilities are

approximately the same, only the DiskShadow utility is demonstrated for both persistent and non-

persistent snapshots.

Note: This IBM Tivoli Storage FlashCopy Manager single-tier backup solution uses only local persistent

snapshots that reside on the guests and remain permanently until deleted by administrators. For multitier


17

backup solutions that use an IBM Tivoli Storage Manager server, non-persistent snapshots are used

because the data is copied remotely to the backup server.

Perform the following steps to validate the correct functioning of the guest-initiated snapshots by verifying

whether the shadow copy or snapshot provider ID matches the IBM XIV VSS HW Provider ID:

1. In the Windows Start menu, click Run.

2. Type CMD and press Enter.

3. At the command prompt, run the DiskShadow utility:

PS C:\Users\administrator.VIRTUALDOMAIN> diskshadow

Microsoft DiskShadow version 1.0

Copyright (C) 2007 Microsoft Corporation

On computer: 2008GClus01, 6/5/2013 9:20:31 PM

4. Ensure that the IBM XIV VSS HW Provider is listed as a provider:

DISKSHADOW> list providers

* ProviderID: {b5946137-7b9f-4925-af80-51abd60b20d5}

Type: [1] VSS_PROV_SYSTEM

Name: Microsoft Software Shadow Copy provider 1.0

Version: 1.0.0.7

CLSID: {65ee1dba-8ff4-4a58-ac1c-3470ee2f376a}

* ProviderID: {d51fe294-36c3-4ead-b837-1a6783844b1d}

Type: [3] VSS_PROV_HARDWARE

Name: IBM XIV VSS HW Provider

Version: 2.3.2.2

CLSID: {36b44895-4453-4238-af14-e0be34b9f1e8}

Number of providers registered: 2

5. To test for persistent snapshots, run the following commands:

DiskShadow >set context persistent

DiskShadow > add volume G:

DiskShadow > add volume H:

DiskShadow > create

Alias VSS_SHADOW_1 for shadow ID {b19ca9d0-c3b9-4a37-897e-35dc7bd26235} set as

environment variable.

Alias VSS_SHADOW_2 for shadow ID {7097f22d-a550-40a9-a3a6-691a3567e44a} set as


Alias VSS_SHADOW_SET for shadow set ID {36bba8c2-cf13-4e93-88bf-21869f45cba2} set

as environment variable.

Querying all shadow copies with the shadow copy set ID {36bba8c2-cf13-4e93-88bf-

21869f45cba2}

* Shadow copy ID = {b19ca9d0-c3b9-4a37-897e-35dc7bd26235}

%VSS_SHADOW_1%

- Shadow copy set: {36bba8c2-cf13-4e93-88bf-21869f45cba2}

%VSS_SHADOW_SET%

- Original count of shadow copies = 2

- Original volume name: \\?\Volume{5911d59e-bbdc-11e2-af9b-

0050568d5b55}\ [G:\]

- Creation time: 6/6/2013 6:51:49 PM

- Shadow copy device name: \\?\Volume{cfbc2df8-cefd-11e2-9d12-

0050568d5b55}

- Originating machine: 2008gclus02.virtualdomain.com

- Service machine: 2008gclus02.virtualdomain.com

- Not exposed

- Provider ID: {d51fe294-36c3-4ead-b837-1a6783844b1d}

- Attributes: No_Auto_Release Persistent Hardware


18

* Shadow copy ID = {7097f22d-a550-40a9-a3a6-691a3567e44a}

%VSS_SHADOW_2%

- Shadow copy set: {36bba8c2-cf13-4e93-88bf-21869f45cba2}

%VSS_SHADOW_SET%


- Original volume name: \\?\Volume{5911d5a5-bbdc-11e2-af9b-

0050568d5b55}\ [H:\]

- Creation time: 6/6/2013 6:51:49 PM

- Shadow copy device name: \\?\Volume{cfbc2df9-cefd-11e2-9d12-

0050568d5b55}



- Not exposed


- Attributes: No_Auto_Release Persistent Hardware

Number of shadow copies listed: 2

Note: Volumes G: and H: represent SQL log and data volumes. Repeat this multiple times for all guests and verify that the Windows system event logs contain no errors.

6. Additionally, run the following command to list all snapshots.

DiskShadow >list shadows all

7. Run the following command to return to the original state by deleting the snapshots:

DiskShadow >delete shadows all

8. To test for non-persistent snapshots, run the following commands:

DiskShadow > add volume G:

DiskShadow > add volume H:

DiskShadow > create

Alias VSS_SHADOW_1 for shadow ID {46815636-0716-4e49-b8e9-56128f3950ca} set as


Alias VSS_SHADOW_2 for shadow ID {8fa811ad-2a77-493f-8a66-ae1d1c45da32} set as


Alias VSS_SHADOW_SET for shadow set ID {8ed96997-563d-46b8-bea8-679cf8b2dbbe} set

as environment variable.

Querying all shadow copies with the shadow copy set ID {8ed96997-563d-46b8-bea8-

679cf8b2dbbe}

* Shadow copy ID = {46815636-0716-4e49-b8e9-56128f3950ca}

%VSS_SHADOW_1%

- Shadow copy set: {8ed96997-563d-46b8-bea8-679cf8b2dbbe}

%VSS_SHADOW_SET%


- Original volume name: \\?\Volume{5911d59e-bbdc-11e2-af9b-

0050568d5b55}\ [G:\]

- Creation time: 6/6/2013 7:35:27 PM

- Shadow copy device name: \\?\Volume{cfbc2e01-cefd-11e2-9d12-

0050568d5b55}



- Not exposed


- Attributes: Auto_Release Hardware

* Shadow copy ID = {8fa811ad-2a77-493f-8a66-ae1d1c45da32}

%VSS_SHADOW_2%

- Shadow copy set: {8ed96997-563d-46b8-bea8-679cf8b2dbbe}

%VSS_SHADOW_SET%


- Original volume name: \\?\Volume{5911d5a5-bbdc-11e2-af9b-

0050568d5b55}\ [H:\]

- Creation time: 6/6/2013 7:35:27 PM


19

- Shadow copy device name: \\?\Volume{cfbc2e02-cefd-11e2-9d12-

0050568d5b55}



- Not exposed


- Attributes: Auto_Release Hardware

Number of shadow copies listed: 2

Note: Volumes G: and H: represent SQL log and data volumes. Repeat this multiple times for all guests and verify that the Windows system event logs contain no errors.

9. Run the following command to list all snapshots.

DiskShadow >list shadows all

10. Run the following command to return to the original state by deleting the snapshots.

DiskShadow >delete shadows all

The aforementioned testing should confirm that the guest core VSS framework components are in place

and functioning properly. After successfully running the VSS snapshot tests on all of the guests, IBM Tivoli

Storage FlashCopy Manager can be installed.

Note: Separate persistent and non-persistent snapshot tests can be run during the IBM Tivoli Storage

FlashCopy Manager configuration, but familiarity with a command-line utility such as diskshadow is

recommended.

IBM Tivoli Storage FlashCopy Manager installation

IBM Tivoli Storage FlashCopy Manager must be installed on all Microsoft SQL Server 2012 VMs that

require guest-initiated database protection using hardware snapshots.

1. Launch the IBM Tivoli Storage FlashCopy Manager for Windows InstallShield Wizard by double-

clicking SetupFCM.exe located on the installation media or source package.

2. Specify the preferred installation language and click OK (refer to Figure 16).

Figure 16: IBM Tivoli Storage FlashCopy Manager InstallShield Wizard language selection

3. The InstallShield wizard prompts administrators with a pending requirement for Microsoft

ReportViewer 2010 Redistributable. Click Install (refer to Figure 17).


20

Figure 17: IBM Tivoli Storage FlashCopy Manager InstallShield Wizard pending requirement

4. The Microsoft ReportViewer 2010 Redistributable Setup launches. Click Next (refer to Figure 18).

Figure 18: Prerequisite Microsoft ReportViewer 2010 Redisnptributable Setup

5. Accept the license terms and click Install (refer to Figure 19).


21

Figure 19: Microsoft ReportViewer 2010 Redistributable Setup license terms

6. After the installation is complete, click Finish (refer to Figure 20).

Figure 20: Microsoft ReportViewer 2010 Redistributable Setup installation is complete


22

7. The IBM Tivoli Storage FlashCopy Manager - InstallShield Wizard launches. Click Next (refer to Figure 21).

Figure 21: IBM Tivoli Storage FlashCopy Manager InstallShield Wizard welcome

8. Accept the terms of the license agreement and click Next (refer to Figure 22).

Figure 22: IBM Tivoli Storage FlashCopy Manager InstallShield Wizard software license agreement


23

9. Use the default folder or provide a new installation destination folder and click Next (refer to Figure 23).

Figure 23: IBM Tivoli Storage FlashCopy Manager InstallShield Wizard destination folder

10. To begin installation, click Install (refer to Figure 24).

Figure 24: IBM Tivoli Storage FlashCopy Manager InstallShield Wizard ready to install the program


24

11. After the installation is complete, click Finish (refer to Figure 25).

Figure 25: IBM Tivoli Storage FlashCopy Manager InstallShield Wizard completed

IBM Tivoli Storage FlashCopy Manager configuration

Configure the IBM Tivoli Storage FlashCopy Manager identically for all Microsoft SQL Server guests. For

the test solution, each VM uses FlashCopy Manager to manage local system snapshots without using a

Tivoli Storage Manager server. Configure individual virtual data centers accordingly but multitier Tivoli

Storage Manager (TSM) server configuration details are beyond the scope of this white paper.

1. When the IBM Tivoli Storage FlashCopy Manager application is launched for the first time, a

configuration welcome screen appears. Select the Standalone option and click OK (refer to

Figure 26).

Figure 26: IBM Tivoli Storage FlashCopy Manager configuration wizard welcome

Note: Select the Do not show at startup check box to skip the configuration wizard each time the application starts.


25

2. Select the SQL Server check box to configure the Tivoli data protection type and click Next

(refer to Figure 27).

Figure 27: IBM Tivoli Storage FlashCopy Manager Standalone Configuration Wizard data protection selection

3. Confirm that the status of all the requirements shows passed and click Next (refer to Figure

28).

Figure 28: IBM Tivoli Storage FlashCopy Manager Standalone Configuration Wizard requirements check


26

4. Select Default as the type of VSS requestor service configuration and click Next (refer to Figure

29).

Figure 29: Tivoli Storage FlashCopy Manager Standalone Configuration Wizard for VSS Requestor services

5. Confirm that the status of all standalone configuration operations shows passed and click Next


Figure 30: IBM Tivoli Storage FlashCopy Manager Standalone Configuration details


27

6. Notice that the status of SQL Server for Tivoli Data Protection changed to Configured,

indicating successful completion of the configuration. Retain the default selection of the Run

VSS diagnostics when this wizard exits check box and click Finish (refer to Figure 31).

Figure 31: IBM Tivoli Storage FlashCopy Manager Standalone Configuration Wizard completion

7. After the FlashCopy Manager VSS Diagnostics Wizard appears, select the IBM XIV volumes to

test and review the VSS providers by clicking Show VSS Information. After clicking, the option

changes to Hide VSS Information (refer to Figure 32).

Figure 32: FlashCopy Manager VSS Diagnostics Wizard snapshot volume selection and VSS information


28

8. In the VSS information field, click Writers to view their state. After reviewing the VSS

information, click Next (refer to Figure 33).

Figure 33: FlashCopy Manager VSS Diagnostics Wizard snapshot volume selection and writers

9. Confirm that the VSS snapshot tests pass for each selected volume and click Next (refer to

Figure 34).

Figure 34: IBM Tivoli Storage FlashCopy Manager VSS Diagnostics Wizard


29

10. During the previous VSS snapshot tests, use the Windows Disk Management Microsoft

Management Console (MMC) to validate the snapshots from the guest front end (refer to Figure

35). Also, use the XIV GUI to validate the snapshots from the storage back end (refer to Figure

36).

Figure 35: Windows 2008 R2 Disk Management volumes and identically named shadow copies or snapshots

Figure 36: IBM XIV GUI volume snapshot during VSS snapshot testing

Note: The snapshot naming convention begins with VSS and the corresponding time stamp

matches the VSS Diagnostics Wizard snapshot tests.

11. Confirm the completion and successful results for all of the selected volumes and click Finish


Figure 37: IBM Tivoli Storage FlashCopy Manager VSS Diagnostics Wizard completed


30

FlashCopy Manager SQL Server AlwaysOn Availability

Groups data protection

From a guest-initiated IBM Tivoli Storage FlashCopy Manager SQL Server AlwaysOn Availability Groups

data protection perspective, there are three primary strategies for protecting the replica availability

databases. Since VSS backups minimize production disruption, all three are viable options but require

different FlashCopy Manager SQL availability database backup and restore methods.

Primary replica availability data protection strategies

Secondary replica availability data protection strategies

Combined primary and secondary replica availability data protection strategies

While these methods are somewhat obvious based on the replica backup origins, a few fundamental

concepts are shared. Beyond the obvious implications, FlashCopy Manager treats SQL availability

databases backups different than restores. FlashCopy Manager is SQL AlwaysOn Availability Groups-

aware and determines whether the guest is hosting a primary or secondary replica availability database.

FlashCopy Manager performs full backup of primary replica availability databases and copy-only full

backup of secondary replica availability databases. By and large, FlashCopy Manager treats the backups

uniquely. However, restores are mostly treated similar to standard databases with one exception.

FlashCopy Manager recognizes the type of database it is restoring and immediately evicts the availability

database or removes it from participating in the SQL AlwaysOn Availability Groups depending on the

selected restore options and replica backup origin. If a full database restore with recovery is performed for

a primary replica, an availability database eviction occurs across all replicas. At this point, Microsoft SQL

Server sees the restored database as a standard database on the restored primary guest and a restoring

database on the secondary replicas.

This results in a recovery logic that is similar to the initial SQL AlwaysOn Availability Groups creation. All

replica database copies must return to a logically consistent state in order to once again become an

availability database. Replica database logical consistency is partly determined by the initial data

synchronization preference. However, ensuring identical SQL log chains amongst all of the replica

databases is crucial to the recovery process and determines which SQL AlwaysOn Availability Groups

data synchronization method must be used in order for the replica databases to return to their previous

availability database state.

As a reminder, a SQL log chain consists of a first log sequence number (LSN) and a last log sequence

number that are used to link log backups into a consecutive chain. For SQL AlwaysOn Availability Groups

availability database candidates or replica databases to be considered logically consistent, they must

contain the same consecutive log chain as indicated by the LSNs. Following a database creation, a new

log chain starts with the first full database backup whether generated by native SQL backups or

FlashCopy Manager. From a backup and restore perspective, the log chain determines the recovery point

in time and must be played back or restored in consecutive order to maintain the original log sequence.

Therefore, it is recommended to perform a FlashCopy Manager AlwaysOn Availability Groups availability

database full backup immediately after its creation. Afterward, use the preferred method to back up the

transaction logs on a regular basis, and as an extra safety measure if required, the replica databases. This

not only minimizes the potential for database transaction losses but also enables transaction log

truncation, which usually occurs after each conventional log backup.


31

The following Microsoft SQL Server 2012 AlwaysOn Availability Groups availability database conceptual

backup and restore examples represent just a few of the elemental FlashCopy Manager backup and

restore strategies. They simply demonstrate how to perform FlashCopy Manager 3.2 SQL AlwaysOn

Availability Groups availability database backups and restores without regard to specific recovery

sequences, which vary based on the type of database failures and issues. Even though, each data

protection strategy example only demonstrates single replica backups, it is recommended to perform

multiple, periodic FlashCopy Manager replica database full backups so that the most recent or last known

good database can be restored if necessary. Similarly, the examples are meant to help build custom SQL

AlwaysOn Availability Groups data protection strategies, and not provide exact disaster recovery steps.

Similar, yet easier, FlashCopy Manager actions that can be performed on standard databases are not

covered in this white paper.

Finally, and whenever possible in the event of a primary replica database failure, the first recommended

step is to perform a SQL Server transaction log backup. This is intended to protect the tail of the log and

reduce the amount of data loss. If successful, this action allows the final log to be restored after all other

transaction logs have been applied during the recovery. This process is beyond the scope of this white

paper and omitted.

Refer to http://msdn.microsoft.com/en-us/library/ms179314.aspx for further details.

Primary replica availability data protection strategy

This primary replica availability data protection example simulates a case where the primary and

secondary replica databases have suffered catastrophic failures, but the administrator only performed

FlashCopy Manager backups of the primary replica database. This example involves using a combination

of FlashCopy Manager 3.2 and SQL Server 2012 native backups and restores. The full data

synchronization method is used to add the availability database back to the SQL AlwaysOn Availability

Groups.

Backup SQL AlwaysOn Availability Groups primary replica database

1. Launch the FlashCopy Manager (MMC) from the Windows Start menu:

Click Start All Programs Tivoli FlashCopy Manager FlashCopy Manager

Management Console

2. If the FlashCopy Manager Local Configuration Wizard welcome screen appears, click Close.

3. In the navigation tree of the MMC left pane, perform the following step to open SQL Server


Click IBM Tivoli Data Protection IBM Tivoli Storage FlashCopy Manager

Dashboard Protect and Recover Data SQL Server.

4. In the MMC center pane, click the Protect tab and click Standard Databases which converts to

Availability Databases. Select the database (refer to Figure 38).

5. In the MMC lower-right pane, under the availability database name, click Full Backup (refer to

Figure 38).

6. In the MMC middle pane, at the bottom, click the Task List or Task Details tab to view and

confirm that the availability database full backup is completed successfully (refer to Figure 38).


32

Figure 38: FlashCopy Manager AlwaysOn Availability Groups primary replica database backup

Restore SQL AlwaysOn Availability Groups primary replica database

Perform the following steps to restore SQL AlwaysOn Availability Groups primary replica databases:

1. In the MMC center pane, click the Recover tab and click DP Node Backups which converts to

AlwaysOn Node Backups. Click Show Restore Options to review the default settings, then

select Availability database full backup and click Restore (refer to Figure 39).

Figure 39: FlashCopy Manager AlwaysOn Availability Groups primary replica database restore

Note: The FlashCopy Manager RunRecovery restore option can be set to True for a SQL

RESTORE WITH RECOVERY or False for a SQL RESTORE WITH NORECOVERY. The latter

allows database administrators to place the database in a restoring state that permits additional

transaction logs to be restored using a native SQL restore on top of the FlashCopy Manager

restored database. This provides point in time recovery up to the latest transaction. For the last

primary database transaction log to be restored, use the native SQL RESTORE WITH RECOVERY


33

option, which places the database in a final, active state that is ready to be used as the source

AlwaysOn Availability Groups availability database.

2. On successful FlashCopy Manager restore, in the Microsoft SQL Server Management Studio,

confirm whether the availability database has been evicted from the AlwaysOn Availability

Groups (refer to Figure 40).

Figure 40: Microsoft SQL Server Management Studio availability database removed

3. Next, right-click the Availability Databases folder and click Add Database (refer to Figure 41).

Figure 41: Microsoft SQL Server Management Studio – adding the database


34

4. On the Introduction page of the Add Database to Availability Group wizard, click Next (refer

to Figure 42).

Figure 42: Add Database to Availability Group – Introduction page

5. Select the FlashCopy Manager restored user database for the availability group and click Next


Figure 43: Add Database to Availability Group – Select Databases page


35

6. For the data synchronization preference, select Full and click Next (refer to Figure 44).

Figure 44: Add Database to Availability Group – Select Initial Data Synchronization page

Note: A guest cluster file share is used for the native SQL AlwaysOn Availability Groups backup central repository.

7. Connect to the secondary replicas and click Next (refer to Figure 45).

Figure 45: Add Database to Availability Group – Connect to Existing Secondary Replicas page


36

8. Confirm the success of the availability group validation results and click Next (refer to Figure

46).

Figure 46: Add Database to Availability Group – Validation page

Note: The results highlighted in red color (in Figure 46) will fail until the secondary replica databases are

deleted. Take all necessary precautions before deleting the database and its corresponding files.

9. Verify the choices made in this wizard and click Finish (refer to Figure 47).

Figure 47: Add Database to Availability Group – Summary page


37

10. Confirm the successful results and click Close (refer to Figure 48).

Figure 48: Add Database to Availability Group – Results page

11. Use the Microsoft SQL Server Management Studio to confirm the status of the availability

database (refer to Figure 49).

Figure 49: Microsoft SQL Server Management Studio availability database status


38

Supplemental SQL AlwaysOn Availability Groups primary database restore concepts

It is highly recommended to configure a network file share that is accessible to all replicas to store the

native SQL AlwaysOn Availability Groups backups (both database and transaction log). All backups

from all replicas can be stored in this location with time stamps to make it easier to determine the

transaction log sequences for recovery purposes. Since guest clustering is required for SQL AlwaysOn

Availability Groups virtual solutions, a clustered file share with a RDM disk is also configured. By

selecting the full data synchronization preference, a native SQL full database and log backup occurs

for the FlashCopy Manager newly restored primary replica database. After this task is complete, the

secondary server or replica instance uses the SQL AlwaysOn Availability Groups central repository (or

clustered file share in this test configuration) backup files to locally restore the database. After the

secondary restore is complete, all replica databases are logically consistent and the primary database

becomes a SQL AlwaysOn Availability Groups availability database.

The following log excerpts reveal the native SQL backup and restore processes that were triggered as

a result of the SQL AlwaysOn Availability Groups wizard full data synchronization selections for both

the primary and secondary replica guests. Notice the first and last LSN references that are underlined.

As previously mentioned, in order for replica databases to become logically consistent, the log chain

must be identical for all replica databases. Transaction logs must always be restored consecutively as

determined by the LSNs. Do not forget to use the SQL AlwaysOn Availability Groups central backup

file time stamps to assist with restores. A combination of primary and secondary transaction logs can

be restored to the same database.

Primary replica guest Windows application event log: Log Name: Application

Source: MSSQLSERVER

Date: 5/31/2013 1:16:23 PM

Event ID: 18264

Task Category: Backup

Level: Information

Keywords: Classic

User: VIRTUALDOMAIN\Administrator

Computer: 2008gclus02.virtualdomain.com

Description:

Database backed up. Database: AdventureWorks2012, creation date(time):

2013/05/21(21:06:26), pages dumped: 24206, first LSN: 78:748:1, last LSN: 78:751:1, number

of dump devices: 1, device information: (FILE=1, TYPE=DISK:

{'\\win2008clus01FS\vFS\AdventureWorks2012.bak'}). This is an informational message only.

No user action is required.

Log Name: Application

Source: MSSQLSERVER

Date: 5/31/2013 1:16:28 PM

Event ID: 18265


Level: Information

Keywords: Classic



Description:

Log was backed up. Database: AdventureWorks2012, creation date(time):

2013/05/21(21:06:26), first LSN: 78:714:1, last LSN: 78:751:1, number of dump devices: 1,

device information: (FILE=1, TYPE=DISK:

{'\\win2008clus01FS\vFS\AdventureWorks2012_20130531201628.trn'}). This is an informational

message only. No user action is required.


39

Secondary replica guest Windows application event log: Log Name: Application

Source: MSSQLSERVER

Date: 5/31/2013 1:16:28 PM

Event ID: 18267


Level: Information

Keywords: Classic



Description:

Database was restored: Database: AdventureWorks2012, creation date(time):

2013/05/21(21:06:26), first LSN: 78:748:1, last LSN: 78:751:1, number of dump devices: 1,

device information: (FILE=1, TYPE=DISK: {'\\win2008clus01FS\vFS\AdventureWorks2012.bak'}).

Informational message. No user action required.

Log Name: Application

Source: MSSQLSERVER

Date: 5/31/2013 1:16:28 PM

Event ID: 18268


Level: Information

Keywords: Classic



Description:

Log was restored. Database: AdventureWorks2012, creation date(time): 2013/05/21(21:06:26),

first LSN: 78:714:1, last LSN: 78:751:1, number of dump devices: 1, device information:

(FILE=1, TYPE=DISK: {'\\win2008clus01FS\vFS\AdventureWorks2012_20130531201628.trn'}). This

is an informational message. No user action is required.

SQL AlwaysOn Availability Groups cluster file share central repository backup files from previous

event log entries (refer to Figure 50).

Figure 50: Guest cluster file share used as SQL AlwaysOn Availability Groups central repository

Secondary replica availability data protection strategy

This secondary replica availability data protection case simulates a primary replica that is in a normal,

healthy state. However, the secondary replica database has suffered a catastrophic failure, but the

administrator performed FlashCopy Manager backups of the secondary replica database. This example

also involves using a combination of FlashCopy Manager 3.2 and SQL Server 2012 native backup and


40

restore. The latter is primarily for regular transaction log backups. The join database to availability

group method is used to add the database back to the SQL AlwaysOn Availability Groups.

Consider the following Microsoft support restrictions:

Microsoft only supports copy-only full backups of secondary replica databases, files, or file

groups. Copy-only backups do not alter the log chain or clear the differential bitmap.

Additionally, differential backups are not supported on secondary replicas.

Microsoft also supports only regular log backups. The COPY_ONLY option is not

supported. A consistent log chain is ensured across log backups taken on any of the

replicas (primary or secondary), irrespective of their availability mode (synchronous-

commit or asynchronous-commit).

Back up SQL AlwaysOn Availability Groups secondary replica database

Perform the following steps to back up SQL AlwaysOn Availability Groups secondary replica database:

1. Launch the FlashCopy Manager MMC from the Windows Start menu:

Click Start All Programs Tivoli FlashCopy Manager FlashCopy Manager

Management Console.

2. If the FlashCopy Manager Local Configuration Wizard Welcome screen appears, click Close.

3. In the navigation tree of the MMC left pane, navigate to SQL Server (refer to Figure 51).

Click IBM Tivoli Data Protection IBM Tivoli Storage FlashCopy Manager

Dashboard Protect and Recover Data SQL Server.

4. In the MMC center pane, click the Protect tab and click Standard Databases which converts to

Availability Databases. Then, select the database (refer to Figure 51).

5. In the MMC lower-right pane, under the availability database name, click Full Backup which

simply defaults to a copy-only full backup because FlashCopy manager detects the secondary

replica role (refer to Figure 51).

6. In the MMC center pane, at the bottom, click the Task List or Task Details tab to confirm that

the availability database copy-only full backup completed successfully (refer to Figure 51).

Figure 51: FlashCopy Manager AlwaysOn Availability Groups secondary replica database backup


41

Restore SQL AlwaysOn Availability Groups secondary replica database

Perform the following steps to restore SQL AlwaysOn Availability Groups secondary replica database:

1. In the MMC center pane, click the Recover tab and click DP Node Backups which converts to

AlwaysOn Node Backups. Click Show Restore Options to set Replace to True and

RunRecovery to False; then select the availability database full backup and click Restore


Figure 52: FlashCopy Manager AlwaysOn Availability Groups secondary replica database restore

Note: For this scenario, the FlashCopy Manager RunRecovery restore option should be set to

False for SQL RESTORE WITH RECOVERY. The latter allows database administrators to place

the database in a restoring state that permits additional transaction logs to be restored using a

native SQL restore on top of the FlashCopy Manager restored database. This provides point-in-

time recovery up to the latest transaction.

Note: Because of a SQL server limitation, VSS backups cannot be restored to another SQL server

instance. Therefore, VSS backups must be restored to the source SQL server instance.

2. After successful FlashCopy Manager restore, use Microsoft SQL Server Management Studio to

confirm that the availability database has switched from a synchronized state to the restoring

state. This is due to the FlashCopy Manager RunRecovery restore option for the database

being set to False. Notice how the Availability Database is banged out, indicating that it is not

currently joined to the SQL AlwaysOn Availability Groups (refer to Figure 53).


42

Figure 53: Microsoft SQL Server Management Studio after AlwaysOn Availability Groups secondary replica

database restore

3. From the secondary replica instance, restore the transaction logs from the SQL AlwaysOn

Availability Groups central repository to make the secondary database logically consistent. For

the secondary database transaction log restores, be sure to set the option to RESTORE WITH

NORECOVERY so that multiple transaction logs can be restored. Do not forget to restore every

primary and secondary transaction log created since the last restored FlashCopy Manager full

backup. A secondary database restoring state is also required to join the secondary database

back to the SQL AlwaysOn Availability Groups.(refer to Figure 54 and Figure 55).


43

Figure 54: SQL server primary replica database transaction log restore to the secondary replica database

Figure 55: SQL server primary replica DB transaction log restore to the secondary replica - DB options


44

4. Using Microsoft SQL Server Management Studio from the secondary replica, right-click the

availability database and click Join to Availability Group (refer to Figure 56).

Figure 56: SQL Server Management Studio secondary replica DB join to availability group

5. In the Join Database to Availability Group wizard, click OK and it displays the successful

results and then will automatically close (refer to Figure 57).

Figure 57: Join Database to Availability Group screen


45

6. Use the SQL Server Management Studio to confirm that the secondary replica database is now

synchronized and participating as an availability database (refer to Figure 58).

Figure 58: SQL Server Management Studio secondary replica DB successful join to availability group

Combined primary and secondary replica availability data protection

strategy

This primary and secondary replica availability data protection example simulates a case where the

primary and secondary replica databases have suffered catastrophic failures. Since the administrator

performed FlashCopy Manager primary and secondary replica database full backups, both can be used to

restore the replica databases to each respective SQL instance. Again, this example involves using a

combination of FlashCopy Manager 3.2 and SQL Server 2012 native backup and restore. Similar to the

previous scenarios, SQL Server 2012 backups and restores are used primarily for regular transaction logs.

This example assumes that the native Microsoft SQL Server regular transaction log backups were

performed for the primary and secondary replica databases. To minimize redundant screen captures and

steps, the least complicated test case is provided in this section:

1. Using FlashCopy Manager, perform a primary replica database full backup.

2. Using FlashCopy Manager, perform a secondary replica database full backup (defaults to copy-

only).

3. Using SQL Server Management Studio, perform a secondary replica regular transaction log

backup.

4. Using SQL Server Management Studio, perform a primary replica regular transaction log

backup.


46

5. Using FlashCopy Manager, perform a primary replica database RESTORE WITH

NORECOVERY.

6. Using SQL Server Management Studio, perform a primary replica database secondary

transaction log RESTORE WITH NORECOVERY.

7. Using SQL Server Management Studio, perform a primary replica database primary transaction

log RESTORE WITH RECOVERY.

8. Using FlashCopy Manager, perform a secondary replica database RESTORE WITH

NORECOVERY.

9. Using SQL Server Management Studio, perform a secondary replica database secondary


10. Using SQL Server Management Studio, perform a secondary replica database primary


11. Using SQL Server Management Studio, run the SQL AlwaysOn Availability Groups Add

Database Wizard, similar to the previous method to successfully re-create the availability

database but select the Join only initial data synchronization method (refer to Figure 59).

12. Using SQL Server Management Studio, confirm the SQL AlwaysOn Availability Groups Add

Database Wizard completed successfully and verify whether the SQL AlwaysOn Availability

Groups availability database is now online and synchronized across all replicas.

Figure 59: Add Database to Availability Group – Select Initial Data Synchronization page


47

Summary

IBM Tivoli Storage FlashCopy Manager 3.2 successfully provides guest-initiated rapid Microsoft SQL

Server 2012 VSS backups and restores using IBM XIV Storage System Gen3 advanced snapshot

technology. For VMware ESX 5.1 business-critical database protection for Microsoft SQL Server 2012

AlwaysOn Availability Group virtual machines (VMs), the installation, configuration, and best practice

guidelines provided in this white paper can help backup administrators not only to protect traditional SQL

server databases, but also the latest Microsoft high availability database solutions. The SQL Server 2012

AlwaysOn Availability Groups data protection examples should also help providing a solid, logical

foundation to accommodate even the most complex multisite VMware guest cluster configurations using

user-friendly, yet high performance, IBM XIV Storage System Gen3 solutions.


48

Resources

The following websites provide useful references to supplement the information contained in this paper:

What’s New in SQL Server 2012 msdn.microsoft.com/en-us/library/bb500435.aspx

Overview of AlwaysOn Availability Groups (SQL Server) msdn.microsoft.com/en-us/library/ff877884.aspx

Manually Prepare a Secondary Database for an Availability Group (SQL Server) msdn.microsoft.com/en-us/library/ff878349

What’s New in VMware vSphere 5.1? vmware.com/files/pdf/products/vsphere/vmware-what-is-new-vsphere51.pdf

Microsoft Clustering on VMware vSphere: Guidelines for Supported Configurations kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037959

IBM XIV Storage System ibm.com/systems/storage/disk/xiv/index.html

IBM XIV Provider for Microsoft Installation Guide delivery04.dhe.ibm.com/sar/CMA/SDA/03q0y/0/XIV_Provider_for_MS_VSS_2.3.2_IG.pdf

IBM disk storage systems ibm.com/systems/storage/disk/?lnk=mprST-dsys-usen

IBM XIV Storage Tips for Microsoft SQL Server 2008 R2 ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101758

IBM Tivoli Storage FlashCopy Manager

ibm.com/software/tivoli/products/storage-flashcopy-mgr

FlashCopy Manager Virtualization Support ibm.com/support/docview.wss?uid=swg21433737

IBM Tivoli Storage Manager Version 6.4 Information Center pic.dhe.ibm.com/infocenter/tsminfo/v6r4/index.jsp?topic=%2Fcom.ibm.itsm.fcm.vm.doc%2Ft_protect_fcmvmw.html

Protecting Microsoft SQL Server 2012 with IBM Tivoli Storage FlashCopy Manager ibm.com/partnerworld/wps/servlet/ContentHandler/stg_ast_sto_wp_protecting_sql_server_with_flashcopy

Stay connected with IBM System Storage

Twitter | LinkedIn | Facebook | YouTube | RSS feeds | → Forum | → Community | → More communities

http://twitter.com/ibmstorage

http://www.linkedin.com/groups?about=&gid=2018491&trk=anet_ug_grppro

http://www.facebook.com/groups/37153201060/

http://www.youtube.com/ibmstorage

http://www-03.ibm.com/systems/storage/news/storage.rss

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=846

http://storagecommunity.org/

http://www-03.ibm.com/systems/storage/community/index.html


49

Trademarks and special notices

© Copyright IBM Corporation 2013.

References in this document to IBM products or services do not imply that IBM intends to make them

available in every country.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business

Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked

terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these

symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information

was published. Such trademarks may also be registered or common law trademarks in other countries. A

current list of IBM trademarks is available on the Web at "Copyright and trademark information" at

www.ibm.com/legal/copytrade.shtml.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the

United States, other countries, or both.

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States,

other countries, or both.

INFINIBAND, InfiniBand Trade Association and the INFINIBAND design marks are trademarks and/or

service marks of the INFINIBAND Trade Association.

Other company, product, or service names may be trademarks or service marks of others.

Information is provided "AS IS" without warranty of any kind.

All customer examples described are presented as illustrations of how those customers have used IBM

products and the results they may have achieved. Actual environmental costs and performance

characteristics may vary by customer.

Information concerning non-IBM products was obtained from a supplier of these products, published

announcement material, or other publicly available sources and does not constitute an endorsement of

such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly

available information, including vendor announcements and vendor worldwide homepages. IBM has not

tested these products and cannot confirm the accuracy of performance, capability, or any other claims

related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the

supplier of those products.

All statements regarding IBM future direction and intent are subject to change or withdrawal without notice,

and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the

full text of the specific Statement of Direction.

Some information addresses anticipated future capabilities. Such information is not intended as a definitive

statement of a commitment to specific levels of performance, function or delivery schedules with respect to

any future products. Such commitments are only made in IBM product announcements. The information is

presented here to communicate IBM's current investment and development activities as a good faith effort

to help with our customers' future planning.


50

Performance is based on measurements and projections using standard IBM benchmarks in a controlled

environment. The actual throughput or performance that any user will experience will vary depending upon

considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the

storage configuration, and the workload processed. Therefore, no assurance can be given that an

individual user will achieve throughput or performance improvements equivalent to the ratios stated here.

Photographs shown are of engineering prototypes. Changes may be incorporated in production models.

Any references in this information to non-IBM websites are provided for convenience only and do not in

any manner serve as an endorsement of those websites. The materials at those websites are not part of

the materials for this IBM product and use of those websites is at your own risk.

Microsoft SQL Server 2012 virtual machine protection using ... · PDF fileMicrosoft SQL Server...

Documents

Transcript of Microsoft SQL Server 2012 virtual machine protection using ... · PDF fileMicrosoft SQL Server...