HP StorageWorks Storage Mirroring Recover Users Guide HP Part Number: T5437-96021 Published: November 2010
© Copyright 1996-2010 Hewlett-Packard Development Company, L.P. and Double-Take Software, Inc. All rights reserved. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Table of Contents Storage Mirroring Recover overview Core operations 15 16 Mirroring 17 Replication 18 Failure monitoring and failover 19 Restoration 20 Storage Mirroring Recover workloads 21 Full-server workloads 22 Application workloads 23 Virtual workloads 24 Cluster workloads 25 Supported configurations 27 One-to-one, active/standby 28 One-to-one, active/active 29 Many-to-one 30 One-to-many 31 Chained 32 Storage Mirroring Recover requirements General source and target ser
Application workload requirements 46 Exchange protection requirements 48 SQL protection requirements 52 BlackBerry protection requirements 54 File Server protection requirements 55 Virtual workload requirements 56 Physical or virtual to Hyper-V requirements 57 Physical or virtual to ESX requirements 59 Hyper-V to Hyper-V requirements 61 ESX to ESX requirements 63 Cluster workload requirements 65 Storage Mirroring Console requirements 67 Installation 68 Installation and upgrade note
Viewing server details 92 Viewing server events 94 Providing server credentials 95 Managing VirtualCenter servers 96 Console options 97 Setting the frequency of console refreshes 98 Setting the console communications port 99 Other consoles 100 Replication Console 101 Logging on and off 102 Managing the Replication Console tree 105 Creating groups 106 Removing groups 107 Moving Servers 108 Inserting Servers 109 Removing Servers 110 Hiding Servers 111 Unhiding Servers 112 S
Configuring the level of detail to log 124 Clearing maintained security credentials 125 Configuring how servers are added to the Full-Server Failover Manager 126 Saving and reusing configuration options 127 Application Manager 128 Adding or managing servers 129 Changing Application Manager options 130 Storage Mirroring Recover for Virtual Infrastructure console 131 Managing activation codes 132 Managing VirtualCenter servers 133 Managing ESX servers 134 Setting up an e-mail server 135
Queuing data 173 Configuring source data processing options 177 Configuring target data processing options 180 Specifying the Storage Mirroring Recover database storage files 183 Specifying file names for logging and statistics 185 Supplying credentials for script processing 187 E-mailing event messages 188 Full-server protection 191 Finding a compatible target 192 Establishing full-server protection 195 Optional full-server protection settings 197 Including and excluding data to be pr
Configuring failover monitoring 226 Taking snapshots of the target 229 Application connection settings 230 Routing data transmissions 231 Protection configuration 232 Configuring Exchange storage group protection 233 Configuring SQL database protection 235 Configuring file server protection 239 Configuring BlackBerry database protection 240 Mirroring data Application advanced settings 242 243 Configuring the replication set 244 Configuring scripts 246 Configuring Active Directory 24
Optional ESX protection settings 290 Scheduling protection 291 Changing the name of the protection job 292 Setting transmission options 293 E-mailing notifications 295 Updating VirtualCenter credentials 296 Configuring restart and threshold options 297 Using firewalls with virtual workloads 298 Virtual workload ports 299 Microsoft Windows ports 300 Hardware ports 301 Cluster protection Protecting a standard cluster 302 303 Establishing your connection on Windows 2003 309 Establishi
WINS replication DNS 342 343 Windows DNSCMD command 344 Storage Mirroring Recover DFO utility 346 Non-Microsoft DNS 350 Macintosh shares 352 NFS Shares 354 Workload monitoring Data workloads Monitoring a data workload 355 356 357 Connection statistics 358 Connection and server display 363 Monitoring failover monitoring 366 Monitoring a full-server workload 369 Monitoring an application workload 371 Monitoring virtual workloads 374 Monitoring virtual workloads in the Storage Mirrori
Log files Viewing the log file 396 397 Viewing the log file through the Replication Console 398 Viewing the log file through a text editor 401 Filtering the log file 403 Configuring the properties of the log file 405 Storage Mirroring Recover log messages 406 Monitoring event messages 413 Event messages 414 E-mailing event messages 441 Statistics 444 Configuring the properties of the statistics file 445 Viewing the statistics file 447 Statistics 449 Performance Monitor 456 Monito
Failing over virtual workloads in the Storage Mirroring Console 495 Failing over virtual workloads in the Storage Mirroring Recover for Virtual Infrastructure console 497 Failback and restore Data workload failback and restoration 498 499 Restoring then failing back 500 Failing back then restoring 506 Failing back and restoring a full-server workload 511 Full-server workload diagram 511 1A. Preparing a new source by reinstalling Windows 513 1B. Reusing your source 513 2.
Removing orphan files Replication 546 549 Replication capabilities 550 Replication sets 554 Creating a replication set 558 Creating or modifying replication rules manually 560 Modifying a replication set 562 Renaming and copying a replication set 563 Calculating replication set size 564 Deleting a replication set 566 Starting replication 567 Inserting tasks during replication 568 Verification 569 Verifying manually 570 Verifying on a schedule 572 Configuring the verification log
Managing full-server and application snapshots Recommended optimizations 609 611 Planning 612 Installation 614 General optimizations 616 Performance optimizations 616 General manageability 618 Anti-virus protection 620 Hardware configurations 620 Application workloads 621 General applications 621 Exchange 622 SQL 622 Cluster workloads Security 624 625 Security credentials 626 Adding users to the security groups 628 Changing the account used to run the Storage Mirroring service
Initiating failback 648 Restoring your data 650 Evaluating full-server protection 652 Establishing full-server protection 653 Monitoring the activity and completion of the initial mirror 655 Changing data to cause replication and verifying the data changes 656 Simulating a failure 657 Starting failover 658 Index 660
Storage Mirroring Recover overview Storage Mirroring Recover ensures the availability of critical workloads. Using real-time replication and failover, you can protect data, individual applications, entire servers, or virtual machines. Identify your critical workload on your production server, known as the source, and replicate the workload to a backup server, known as the target. The target server, on a local network or at a remote site, stores the copy of the workload from the source.
Core operations Storage Mirroring Recover performs four basic types of operations.
Mirroring Mirroring is the process of transmitting user-specified data from the source to the target so that an identical copy of data exists on the target. When Storage Mirroring Recover initially performs mirroring, it copies all of the selected data, including file attributes and permissions. Mirroring creates a foundation upon which Storage Mirroring Recover can efficiently update the target server by replicating only file changes.
Replication Replication is the real-time transmission of file changes. Unlike other related technologies, which are based on a disk driver or a specific application, the Storage Mirroring Recover replication process operates at the file system level and is able to track file changes independently from the file’s related application. In terms of network resources and time, replicating changes is a more efficient method of maintaining a realtime copy of data than copying an entire file that has changed.
Failure monitoring and failover Failover is the process in which a target stands in for a failed source. As a result, user and application requests that are directed to the failed source are routed to the target. Storage Mirroring Recover monitors the source status by tracking network requests and responses exchanged between the source and target. When a monitored source misses a user-defined number of requests, Storage Mirroring Recover assumes that the server has failed.
Restoration Restoration provides an easy method for copying replicated data from the target back to its original location on the source. The process only requires you to select the source, target, and the appropriate replication set. There is no need to select files or to remember where the data came from on the source since that information is maintained by Storage Mirroring Recover.
Storage Mirroring Recover workloads Building on Storage Mirroring Recover core operations, you can protect specific workloads to meet your protection goals. l l l Full-server workloads—You can protect an entire server, including the data and system state, which is the server's configured operating system and applications. In the event of a failure, the target becomes the source.
Full-server workloads Full-server workload protection provides high availability for an entire server, including the system state, which is the server's configured operating system and applications. You identify your source, which is the server you want to protect, and your target, which is the server that will stand-in for the source in the event the source fails. Once the two servers are selected and their configurations validated, Storage Mirroring Recover monitors the source for a failure.
Application workloads Application workload protection provides high availability for Exchange, SQL, BlackBerry, and a Windows file server. You identify your source, which is the server running the application, and your target, which is the server that will stand-in for the source in the event the source fails. Storage Mirroring Recover will gather information from your environment (Active Directory, DNS, and so on) about the application being protected and automatically protect the application.
Virtual workloads Virtual workload protection provides high availability to Hyper-V or ESX virtual servers. You identify your source, which is the server you want to protect. Your source can be a physical server, a virtual machine where you want to protect the data within the guest operating system, or a virtual machine where you want to protect the host-level virtual disk files (.vhd or .vmdk files). Your target is a Hyper-V or ESX server that will host a virtual machine that is a replica of the source.
Cluster workloads In a standard cluster configuration, a single copy of data resides on a SCSI disk that is shared between cluster nodes. Data is available without users knowing which node owns a cluster resource. MSCS handles failover between nodes of the cluster. By adding Storage Mirroring Recover to this cluster environment, you can further protect your data by replicating the cluster data to a target. In the event the cluster fails, your cluster data will be available on the target.
In a GeoCluster configuration, data is stored on volumes local to each node and replicated to each node in the cluster using Storage Mirroring Recover. Resources and groups are handled in the same manner as a standard cluster. Instead of assigning one group by SCSI drive, you assign one group per logical volume. If a server, disk, group, or network interface should fail, MSCS relocates the failed group to another node, which contains the replicated copy of the data, thus maintaining availability.
Supported configurations Storage Mirroring Recover is an exceptionally flexible product that can be used in a wide variety of network configurations. To implement Storage Mirroring Recover effectively, it is important to understand the possible configuration options and their relative benefits. Storage Mirroring Recover configurations can be used independently or in varying combinations.
One-to-one, active/standby Description One target server, having no production activity, is dedicated to support one source server. The source is the only server actively replicating data. Applications l l This configuration is appropriate for offsite disaster recovery, failover, and critical data backup. This is especially appropriate for critical application servers such as Exchange, SQL Server, and web servers. This is the easiest configuration to implement, support, and maintain.
One-to-one, active/active Description Each server acts as both a source and target actively replicating data to each other Applications This configuration is appropriate for failover and critical data backup. This configuration is more cost-effective than the Active/Standby configuration because there is no need to buy a dedicated target server for each source. In this case, both servers can do full-time production work.
Many-to-one Description Many source servers are protected by one target server. Applications This configuration is appropriate for offsite disaster recovery. This is also an excellent choice for providing centralized tape backup because it spreads the cost of one target server among many source servers. Considerations l l l The target server must be carefully managed. It must have enough disk space and RAM to support replication from all of the source systems.
One-to-many Description One source server sends data to multiple target servers. The target servers may or may not be accessible by one another. Applications This configuration provides offsite disaster recovery, redundant backups, and data distribution. For example, this configuration can replicate all data to a local target server and separately replicate a subset of the missioncritical data to an offsite disaster recovery server.
Chained Description The source servers sends replicated data to a target server, which acts as a source server and sends data to a final target server, which is often offsite. Applications This is a convenient approach for integrating local high availability with offsite disaster recovery. This configuration moves the processing burden of WAN communications from the source server to the target/source server.
Storage Mirroring Recover requirements Each Storage Mirroring Recover server must meet minimum requirements. If you are protecting certain workloads, your servers may need to meet additional requirements. Verify that each server meets the general requirements and any additional requirements for your workload type. Additionally, the machine where you will be running the console must also meet several requirements.
General source and target server requirements Verify that each server meets the following general source and target requirements, and then confirm your servers meet any additional requirements for your workload type. l Operating system—There are different Storage Mirroring Recover editions depending on the operating system you are using. Be sure you have the correct Storage Mirroring Recover edition for your operating system. Note: Microsoft Server Core is supported for data workloads.
on. Additionally, on a target server, you need sufficient disk space to store the replicated data from all connected sources, allowing additional space for growth. Note: The program files can be installed to any volume while the Microsoft Windows Installer files are automatically installed to the operating system boot volume. l l Server name—Storage Mirroring Recover includes Unicode file system support, but your server name must still be in ASCII format.
installed, you will need to review the patches available on the Microsoft web site and install those that correct the Volume Shadow Copy service memory leaks. l l Snapshot file system—Your servers must be using the NTFS file system. If you are using a FAT file system, the FAT volumes will not be included in the snapshot set, and when the snapshots are reverted, the FAT volume will not be time-consistent with the NTFS volumes.
Foundation Edition Windows 2003 and 2003 R2 operating systems l Storage Server Edition l Small Business Server Windows 2008 and 2008 R2 operating systems l Storage Server Edition i386 and x64 l Small Business Server Standard and Premium x64 l Foundation Server with SAK l Essential Business Server x64 Virtual server protection There is no virtual server (guest-level or host-level) protection with the Foundation Edition.
Standard Edition Windows 2003 and 2003 R2 operating systems l Storage Server Edition l Small Business Server l Web Edition i386 and x64 l Standard Edition i386 or x64 Windows 2008 and 2008 R2 operating systems l Storage Server Edition i386 and x64 l Small Business Server Standard and Premium x64 l Foundation Server l Essential Business Server x64 l Web Server i386 and x64 l Standard Edition i386 and x64 Virtual server guest-level protection The Standard Edition can run inside one virtual
Advanced Edition Windows 2003 and 2003 R2 operating systems l Storage Server Edition l Small Business Server l Web Edition i386 and x64 l Standard Edition i386 or x64 l Enterprise Edition i386 and x64 Windows 2008 and 2008 R2 operating systems l Storage Server Edition i386 and x64 l Small Business Server Standard and Premium x64 l Foundation Server l Essential Business Server x64 l Web Server i386 and x64 l Standard Edition i386 and x64 l Enterprise Edition i386 and x64 Virtual serve
Premium Edition Windows 2003 and 2003 R2 operating systems l Storage Server Edition l Small Business Server l Web Edition i386 and x64 l Standard Edition i386 or x64 l Enterprise Edition i386 and x64 l Enterprise Itanium IA64 l Datacenter i386, x64, IA64 Windows 2008 and 2008 R2 operating systems l Storage Server Edition i386 and x64 l Small Business Server Standard and Premium x64 l Foundation Server l Essential Business Server x64 l Web Server i386 and x64 l Standard Edition i386
Virtual Guest 5-Pack Edition Windows 2003 and 2003 R2 operating systems l Storage Server Edition l Small Business Server l Web Edition i386 and x64 l Standard Edition i386 or x64 l Enterprise Edition i386 and x64 l Enterprise Itanium IA64 l Datacenter i386, x64, IA64 Windows 2008 and 2008 R2 operating systems l Storage Server Edition i386 and x64 l Small Business Server Standard and Premium x64 l Foundation Server l Essential Business Server x64 l Web Server i386 and x64 l Standard
Virtual Host Standard Edition Windows 2008 and 2008 R2 operating systems l Standard Edition Virtual server guest-level protection There is no virtual server guest-level protection with the Virtual Host Standard Edition. Virtual server host-level protection protection The Virtual Host Standard Edition runs outside the virtual server to protect the virtual disk (.vmdk or .vhd) and its associated files stored on the host operating system.
Virtual Host Advanced Edition Windows 2008 and 2008 R2 operating systems l Standard Edition l Enterprise Edition Virtual server guest-level protection There is no virtual server guest-level protection with the Virtual Host Advanced Edition. Virtual server host-level protection protection The Virtual Host Advanced Edition runs outside the virtual server to protect the virtual disk (.vmdk or .vhd) and its associated files stored on the host operating system.
Virtual Host Premium Edition Windows 2008 and 2008 R2 operating systems l Standard Edition l Enterprise Edition l Datacenter Edition Virtual server guest-level protection There is no virtual server guest-level protection with the Virtual Host Premium Edition. Virtual server host-level protection protection The Virtual Host Premium Edition runs outside the virtual server to protect the virtual disk (.vmdk or .vhd) and its associated files stored on the host operating system.
Full-server workload requirements If you will be protecting an entire server, the general source and target server requirements apply. However, keep in mind that a target server may meet these requirements but may not be suitable to stand-in for a source in the event of a source failure. See Finding a compatible target for additional information regarding an appropriate target server for your particular source.
Application workload requirements If you will be protecting an application, the general source and target server requirements apply. In addition, you must meet the application requirements below. l Server and network configuration—Application protection requires the following server and network requirements. l l l l l l l l l The application program files must be installed in the same location on the source and target.
the Storage Mirroring Recover installation, or from a copy you have obtained manually from the Microsoft web site. l Applications—In addition to these general application requirements, you must also meet the requirements for the application you are protecting. See Exchange, SQL, BlackBerry, or File Server for those requirements.
Exchange protection requirements In addition to the general application requirements, you must also meet the following requirements to protect Exchange. l Exchange versions—Storage Mirroring Recover can protect Microsoft Exchange 2003 or Exchange 2007, with the following requirements and limitations. l l l l l The version of Exchange on the source and target must be identical. Storage Mirroring Recover does not check the edition of Exchange 2007 (Enterprise or Standard).
Microsoft Knowledge Base articles 822179, 332097, 305065, 304403, and 875427. l l l l The source and target servers must be part of the same Exchange Administrative Group. The Exchange configurations on the source and target servers must be identical for the following components: storage groups, location of storage groups (log and data files), log file prefixes, database locations (log and data files), Message Transfter Agent (MTA) location, and queue paths.
l Like-named cluster protection—If you are using Exchange 2003, you can protect a cluster with a like-named cluster, also known as a standby cluster. Storage Mirroring Recover will move the Exchange virtual server from the source cluster to the target cluster. The process of moving users and public folders from one server to another is not needed because users will continue to use the same mail store on the target as they were on the source.
control to the target in the Configuration Naming Context in order to move users during failover. Second, grant Full control to the target in the Domain Naming Context in order to move Service Principal Names, which will allow users to access their e-mail after a failover. l Application Manager Console—The following limitations apply to the Application Manager Console when protecting Exchange.
SQL protection requirements In addition to the general application requirements, you must also meet the following requirements to protect SQL. l SQL versions—Storage Mirroring Recover can protect Microsoft SQL Server or Express 2000 with Service Pack 4 or later, Server or Express 2005, or Server or Express 2008, with the following requirements and limitations. l l l l l l If you are using Windows 2008, you can protect SQL Server or Express 2005 or 2008.
l l l l l l l l l l The source and target servers should be in the same domain. If they are not, the SQL Server service on both the source and target servers must be configured to start with the same domain user account. If your source and target are in a workgroup, make sure the source server's NIC does not register the IP addresses with DNS.
BlackBerry protection requirements In addition to the general application requirements, you must also meet the following requirements to protect BlackBerry. l l BlackBerry versions—Storage Mirroring Recover can protect BlackBerry Enterprise Server 4.1.4 through 4.1.6 for Microsoft Exchange. Server and network configuration—The following requirements and limitations apply to your BlackBerry server and network configuration.
File Server protection requirements In addition to the general application requirements, you must also meet the following requirements to protect a file server. l l l You can use a one-to-one configuration for file server protection. You cannot use a one-to-many, many-to-one, or chained configuration. The target must be a dedicated, stand-by server which does not host any critical applications. During failback, the Server service is restarted, which may also restart any dependent services.
Virtual workload requirements When you are protecting virtual server workloads, the general source and target server requirements still apply, however, the requirements and limitations are more strict depending on your virtual configuration. Select a link to see the requirements that correspond with your virtual configuration.
Physical or virtual to Hyper-V requirements Use these requirements if your source is a physical or virtual server, you want to protect the volumes from the physical server or volumes from within the virtual guest operating system, and your target is an automatically provisioned virtual server on a Hyper-V server. This means Storage Mirroring Recover will automatically create the virtual server on the Hyper-V target if failover is triggered.
will also need version 3.5.1. You can install this version from the Storage Mirroring Recover CD, via a web connection during the Storage Mirroring Recover installation, or from a copy you have obtained manually from the Microsoft web site.
Physical or virtual to ESX requirements Use these requirements if your source is a physical or virtual server, you want to protect the volumes from the physical server or volumes from within the virtual guest operating system, and your target is an automatically provisioned virtual server on an ESX server. This means Storage Mirroring Recover will automatically create the virtual server on the ESX target if failover is triggered.
and system state of the source. Since the virtual recovery appliance maintains its own identity, it can be reused for additional failovers.) l l l l l l l The virtual recovery appliance must have the same or newer operating system than the source (not including service pack level). The virtual recovery appliance must have Storage Mirroring Recover installed and licensed on it.
Hyper-V to Hyper-V requirements Use these requirements if your source is a virtual server on a Hyper-V server, you want to protect the host-level virtual disk files, and your target is a virtual server on a Hyper-V server. l l l l l Source and target host operating system—Your source and target host servers can be any Windows 2008 or 2008 R2 operating system from the supported server operating systems that has the Hyper-V role enabled.
l l l l l Windows Management Instrumentation (WMI)—The host and guest operating systems must have the WMI service enabled. User Access Control (UAC)—UAC must be disabled on the guest operating system. Name resolution—You must establish name resolution for the guest operating system. Ports—In addition to the standard Storage Mirroring Recover ports that must be opened, you must also open port 135 for communication between the client and the servers. Microsoft .
ESX to ESX requirements Use these requirements if your source is a virtual server on an ESX server, you want to protect the host-level virtual disk files, and your target is a virtual server on an ESX server. l ESX servers—The ESX servers that will host your source and target can be any of the following operating systems. l ESX 3.5.x Standard, Advanced, Enterprise, or Enterprise Plus l ESX 4.0.x or 4.
l l Microsoft .NET Framework—The source and target servers require the Microsoft .NET Framework version 3.5 Service Pack 1. This version is not included in the .NET version 4.0 release. Therefore, even if you have .NET version 4.0 installed, you will also need version 3.5.1. You can install this version from the Storage Mirroring Recover CD, via a web connection during the Storage Mirroring Recover installation, or from a copy you have obtained manually from the Microsoft web site.
Cluster workload requirements Make sure your cluster meets the general source and target server requirements as well as the standard or GeoCluster requirements below, depending on your cluster configuration. l Standard cluster—If you will be protecting a standard cluster configuration, with a shared SCSI disk, there are two additional requirements.
l l Queuing—The Storage Mirroring Recover disk queue, configured during installation, should use a local volume for each node in the cluster. Virus software—You should configure your virus software to delete or quarantine viruses because cleaning them can cause an access denied retrying operation error. Additionally, configuring virus software to scan outgoing traffic will lessen performance impacts.
Storage Mirroring Console requirements There are various Storage Mirroring Recover consoles, many of which are being phased out over time. To help consolidate the consoles and help you locate the necessary workflows to complete your work, use the console called Storage Mirroring Console. You must meet the following requirements for the Storage Mirroring Console. l l l Operating system—The Storage Mirroring Console can be run from a source or target.
Installation Before beginning the installation, review the Storage Mirroring Recover requirements and Installation and upgrade notes. Use the installation instructions appropriate for the type of workload you are protecting l l l Data, full-server, and application workloads—If you are protecting a data workload, full-server workload, or an application workload, you can install using the standard installation program or the command-line automatic installation process.
Installation and upgrade notes Review the following installation and upgrade notes before beginning your installation or upgrade. l l l l l Since Storage Mirroring Recover installs device drivers, it is recommended that you update your Windows Recovery Disk, before installing or making changes to your servers. For detailed instructions on creating a recovery disk, see your Windows reference manuals. Make sure that you select the option to backup the registry when building the repair disks.
l l l l When performing a rolling upgrade, update the target servers first. After the upgrade is complete, the sources will automatically reconnect to the targets. Upgrade the sources when convenient. If you are using a chained configuration, update the last target first, then update the middle server acting as both a source and target, and update the production source last.
Installing or upgrading Storage Mirroring Recover Use these instructions to install Storage Mirroring Recover or upgrade an existing Storage Mirroring Recover installation. 1. Close any open applications. 2. Start the installation program using the appropriate instructions, depending on your media source. l l CD—Load the Storage Mirroring Recover CD into the local CD-ROM drive. If auto-run is enabled, the installation program will start automatically.
8. Click Next to continue. 9. You will be prompted to enter your activation code information. Your Activation Code is a 24-character, alpha-numeric activation code which applies the appropriate license to your installation. You must have a valid activation code to use Storage Mirroring Recover. Enter your code and click Add. 10. Click Next to continue. 11. The next screen will depend on the activation code you entered.
16. During the installation, you may be prompted to add an exception to the Windows Firewall for Storage Mirroring Recover. Click OK to add the port exception. If you Cancel the port modification, you will have to manually modify your firewall settings for Storage Mirroring Recover processing. 17. After the files have completed copying, click Finish to exit the installation program.
Installing or upgrading Storage Mirroring for Virtual Infrastructure In a typical Storage Mirroring Recover installation, you install the server components on each source and target server. However, when you are protecting the host-level virtual disk files (the .vmdk files) from an ESX source to an ESX target, you need to install the server components on another machine.
5. When the Storage Mirroring Recover for Virtual Infrastructure installation begins, click Next. 6. Review and accept the HP license agreement to continue with the installation program. Click Next to continue. 7. Specify where the Storage Mirroring Recover for Virtual Infrastructure files will be installed. Click Next to continue. 8. Select the type of installation you would like to perform on this machine.
Installing Storage Mirroring Recover automatically The Storage Mirroring Recover installation program can accept command-line parameters which allow you to automate the installation or upgrade process by running an unattended, or silent, installation. The automatic process allows you to pass parameters through to the installation program instead of entering information manually during the installation or upgrade.
QMemoryBufferMax Any integer representing the amount of system memory, in MB, to use for memory-based queuing DiskQueueFolder Any valid path to the location of the disk-based queue.
Installing or upgrading automatically to a local machine 1. Create a temporary directory on the server. For example, create c:\temp_install. 2. On the CD, locate the files in a subdirectory under \setup\hpsm that is appropriate for your architecture, either i386, x64, or IA64. Copy the files from that subdirectory to the temporary directory. 3. From a command prompt, remove the read-only attributes from the files in the temporary directory by using the command attrib *.* -r. 4.
Installing or upgrading automatically to a remote machine 1. Create a temporary directory on the primary site server. For example, create z:\temp_install. 2. Share the temporary folder. 3. On the CD, locate the files in a subdirectory under \setup\hpsm that is appropriate for your architecture, either i386, x64, or IA64. Copy the files from that subdirectory to the temporary directory. 4.
Configuring your cluster for GeoCluster installation If you want to use a GeoCluster configuration, where data is stored on volumes local to each node and replicated to each node in the cluster, complete the cluster configuration appropriate for the operating system you are using.
Configuring your Windows 2003 cluster In a typical Windows 2003 MSCS shared disk cluster configuration, the quorum resource, by default, is the Local Quorum and is located on the first shared disk in the cluster. Because in a GeoCluster configuration there is no shared physical disk, the Local Quorum will not work as the quorum resource. You will need to choose one of the other Windows quorums.
Configuring your Windows 2008 cluster The default quorum resource in a Windows 2008 environment will vary depending on your configuration (number of nodes, shared disks, and so on). The recommended quorum resource to use for GeoCluster is the Node and File Share Majority. There are other quorum types available. Review the following list to determine which quorum is appropriate for your environment. l l l l Node Majority—This quorum is recommended for clusters with an odd number of nodes.
8. From Failover Cluster Management, create your application or service group. Note: If you are creating a file server using clustered file shares, the path for the file share in the Failover Cluster Management wizard is case-sensitive. If the drive letter is uppercase, the path in the clustered file share wizard must also be uppercase. If the case does not match, the wizard will fail stating the path does not exist.
Storage Mirroring Console The Storage Mirroring Console is used to protect and monitor your servers and connections. Each time you open the Storage Mirroring Console, you start at the Home page. This page provides a high-level overview of the status of your connections. The appearance of the Home page is the same for all users. However, other console pages may have variances in the appearance or you may not see some pages at all. The pages and views depend on the HP products that you have installed.
Starting the console After you have installed the console, you can launch it by selecting Start, Programs, HP Storage Mirroring, HP Storage Mirroring Console.
Getting started The first time you start the console, it is empty. In order to protect and monitor your servers, you must insert your servers in the console. You can insert servers manually, through Active Directory discovery, or from a console server configuration file.
Inserting servers manually 1. Select Get Started from the toolbar. 2. Select Add servers and click Next. 3. On the Manual Entry tab, specify the server information. l l l Server—This is the name of the server to be added to the console. User name—Specify a user that is a member of the Double-Take Admin or Double-Take Monitors security group on the server. Password—Specify the password associated with the User name you entered. 4. If necessary, specify the domain or protocol under More Options.
Inserting servers through Active Directory discovery 1. Select Get Started from the toolbar. 2. Select Add servers and click Next. 3. Select the Automatic Discovery tab. 4. Click Discover to search Active Directory for servers running Storage Mirroring Recover. 5. If you need to remove servers from the list of Servers to be added, highlight a server and click Remove. You can also remove all of them with the Remove All button. 6. When your list of Servers to be added is complete, click OK.
Inserting servers from a server configuration file You can share the console server configuration between machines that have the Storage Mirroring Console installed. The console server configuration includes the server name, server communications ports, user name, encrypted password, and other internal processing information. 1. To export a server configuration file, select File, Export. 2. Specify a file name and click Save. After the configuration file is exported, you can import it to another console.
Managing servers To manage the servers in your console, select Manage Servers from the toolbar. The Manage Servers page allows you to view, add, edit, or remove servers from your console. Column 1 (Blank) The first blank column indicates the status of communications between the console and the server or cluster. The console is attempting to communicate with the server or cluster. The server or cluster is online and the console is communicating with it.
Activation Code The activation codes associated with the products licensed for the server Add Servers Add a new server. This button leaves the Manage Servers page and opens the Add Servers page View Server Details View detailed information about a server. This button leaves the Manage Servers page and opens the View Server Details page Remove Server Remove the server from the console Provide Credentials Change the login credentials for a server View Server Events View event messages for a server.
Viewing server details To view details about a specific server, select View Server Details from the toolbar on the Manage Servers page. The View Server Details page allows you to view details about a particular server. Server name The server name or IP address as added to the console Status There are many different Status messages that keep you informed of the server activity. Most of the status messages are informational and do not require any administrator interaction.
Licensing Licensing information for the server l Product—The product associated with the license l Serial number—The serial number associated with the license l Expiration date—The date the license expires, if there is one l Code—The activation code Source connections A list of any connections from this server. Double-clicking on a connection in this list will automatically open the View Connection Details page. Target connections A list of any connections to this server.
Viewing server events To view events associated with a specific server, select View Server Events from the toolbar on the Manage Servers page.The View Server Events page displays the same messages that are logged to the Windows Event Viewer. The list of events are displayed in the top pane of the page, although the Description is limited. When you highlight an event, the event details, including the full Description, are displayed in the bottom pane of the page.
Providing server credentials To update the security credentials used for a specific server, select Provide Credentials from the toolbar on the Manage Servers page. When prompted, specify the User name, Password, and Domain of the account you want to use for this server. Click OK to save the changes.
Managing VirtualCenter servers To manage your VirtualCenter servers, select Go, Manage VirtualCenter Servers. The Manage VirtualCenter Server page allows you to view, add, remove, or edit credentials for your VirtualCenter servers available in the console. VirtualCenter Server The name of the VirtualCenter server Full Name The full name of the VirtualCenter server User Name The user account being used to access the VirtualCenter server Add VirtualCenter Servers Add a new VirtualCenter server.
Console options There are several options that you can set that are specific to the Storage Mirroring Console. To access these console options, select Options from the toolbar.
Setting the frequency of console refreshes To access the console refresh rate, select Options from the toolbar. On the Options page, Monitoring interval specifies how often, in seconds, the console refreshes the monitoring data. The servers will be polled at the specified interval for information to refresh the console.
Setting the console communications port To access the console communications port, select Options from the toolbar. On the Options page, Default port specifies the port that the console will use when sending and receiving data to Storage Mirroring servers. By default, the port is 6325. Changes to the console port will not take effect until the console is restarted. Note: If you are using an older Storage Mirroring version, you will need to use the legacy protocol port.
Other consoles There are various Storage Mirroring Recover consoles, many of which are being phased out over time. To help consolidate the consoles and help you locate the necessary workflows to complete your work, use the console called Storage Mirroring Console. To access this console, select Start, Programs, Storage Mirroring, Storage Mirroring Console. Select Get Started from the toolbar and then select the type of workload protection you want to establish.
Replication Console To open the Replication Console, select Start, Programs, HP Storage Mirroring, HP Storage Mirroring Replication Console. From the Replication Console, you can manage, monitor, and control your data workload connections. The Replication Console is a two pane view. The views in the panes change depending on what is highlighted.
Logging on and off To ensure protection of your data, Storage Mirroring Recover offer multi-level security using native operating system security features. Privileges are granted through membership in user groups defined on each machine running Storage Mirroring Recover.
3. Specify your Username, Password, Domain, and whether you want your password saved. 4. Click OK and verify your access by the resulting icon and log on again if necessary. Note: When logging in, the user name, password, and domain are limited to 100 characters. If your activation code is missing or invalid, you will be prompted to open the Server Properties General tab to add or correct the code.
Monitor rights This icon is a computer with a magnifying glass and it indicates the Storage Mirroring Recover security is set to monitor only access. No rights This icon is a lock and it indicates the Storage Mirroring Recover security is set to no access. 5. To log off of a Storage Mirroring Recover machine, right-click the machine name on the left pane of the Replication Console and select Logout.
Managing the Replication Console tree To better manage the servers that appear in the Replication Console, you can customize the server display to fit your needs. You can create groups and move servers to those groups to help you organize your environment. Within the groups, you can insert, remove, hide or unhide servers. Each of these functions is detailed in the following sections. l l Groups—The left pane of the Replication Console is a tree view of the Storage Mirroring Recover servers.
Creating groups Use one of the following methods to create a new group: l l Right-click anywhere on the left pane of the Replication Console and select New, Group. Right-click on a group icon on the right pane of the Replication Console and select New, Group. l Click Add Group on the toolbar. l Use the menu bar and select Insert, Group. The location of the new group that is created will depend on what was highlighted.
Removing groups l Use one of the following methods to remove a group. l Right-click on a group on the left of the Replication Console and select Remove. l Right-click on a group on the right pane of the Replication Console and select Remove. l Click Remove Item on the toolbar. l Highlight a group and press the Delete key. You will prompted to confirm the removal of the group and its subgroups and any servers (displayed or hidden) contained in them. Click OK.
Moving Servers Servers that are auto-populated can be moved to different groups within the Replication Console tree. You can move servers to groups by either of the following methods l l Drag and drop a server into the desired group. With this method you can move one server at a time in the left pane of the Replication Console. You can move more than one server at a time by using this method from the right pane of the Replication Console. Insert a server into the desired group.
Inserting Servers If a machine is not displayed on the Replication Console, it can be manually inserted. This feature is useful for machines that are across a router or on a different network segment. Note: If a machine is manually inserted into the Replication Console, it will automatically be saved in your workspace and will appear the next time the Replication Console is started. Use the following instructions to insert a server into the Replication Console. 1.
Removing Servers If you do not want to see a server in the Replication Console, it can be permanently removed from the display. You might need to remove a server that was manually added, if that server is no longer needed. Or if there are servers within the network that another administrator is responsible for, you can remove them from your display. If a server is listed in Active Directory and Active Directory discovery is enabled, a removed server will automatically be added back to the server list .
Hiding Servers If you do not want to see a server in the Replication Console and do not want to disable Active Directory discovery, you can hide the server from view. This keeps the server in the Replication Console’s internal list of servers, but does not display it in the server tree, any dialog boxes, or any field/menu selections. To hide a server, right-click on a server in the left or right pane of the Replication Console and select Hide.
Unhiding Servers You can unhide, or display, a hidden server at any time you want to access that server. The server will be displayed in the server tree, all dialog boxes, and field/menu selections. To unhide, or display, a hidden server, you can insert the server or use the following instructions. 1. Select View, Unhide Servers. 2. Select one or more servers by using Ctrl-click or Shift-click. You can also click Select All to select all of the servers in the list. 3. Click Unhide.
Sharing group and server configuration All of the group and server information is stored on the local machine for each user. When you close the Replication Console, the group information is saved and will be persisted the next time you open the Replication Console on this machine. If you want to share the group configuration with another user or machine, you can export the group configuration information (File, Export server group configuration) to an .xml file.
Workspaces The Replication Console workspace contains the display of the panes of the Replication Console and any servers that may have been inserted. Multiple workspaces can be used to help organize your environment or to view settings from another machine.
Saving a workspace As you size, add, or remove windows in the Replication Console, you can save the workspace to use later or use on another Storage Mirroring Recover client machine. Select File and one of the following options. l l Save Workspace—Save the current workspace. If you have not previously saved this workspace, you must specify a name for this workspace. Save Workspace As—Prompt for a new name when saving the current workspace.
Opening a workspace From the Replication Console, you can open a new workspace or open a previously saved workspace. Select File and one of the following options. l l New Workspace—Open an untitled workspace with the default Storage Mirroring Recover window settings. Open Workspace—Open a previously saved workspace.
Clearing maintained security credentials To remove cached credentials, select File, Options and select the Security tab. To remove the security credentials, enable Clear Cached Security Credentials and then click OK.
Failover Control Center To open the Failover Control Center, select Start, Programs, HP Storage Mirroring, Recover, HP Storage Mirroring Failover Control Center. The Failover Control Center should be run from your target server or a client machine. Do not run the Failover Control Center from your source server. From the Failover Control Center, you can manage, monitor, and control failover for your Storage Mirroring Recover servers.
Configuring communication ports The Failover Control Center uses port 6320, by default for Storage Mirroring Recover communications. To view or modify the port settings in the Failover Control Center, select Settings, Communications.
Configuring the console refresh rate The failover client periodically requests information from the source and target. Depending on the type of information, the request may be a machine-specific request, like obtaining the Time to Fail status from a target, or may be a general request, like determining which machines are running Storage Mirroring Recover. The rate at which these requests are made can be modified through the Failover Control Center refresh rate dialog box. Select Settings, Refresh Rate.
Clearing maintained security credentials To remove cached credentials, access the credentials security option, by selecting Settings, Security. To remove the security credentials, enable Clear Cached Security Credentials and then click OK.
Full-Server Failover Manager To open the Full-Server Failover Manager, select Start, Programs, HP Storage Mirroring, Recover, HP Storage Mirroring Full-Server Failover Manager. The Full-Server Failover Manager allows you to create your source and target connection, monitor your full-server workload protection, manage your full-server snapshots, and initiate full-server failover. The client is a simple interface with four numbered steps.
Configuring the console refresh rate Select File, Options. By default, the main window of Full-Server Failover Manager will automatically update every five (5) seconds. If desired, you can modify the Refresh Interval. You can also refresh the main window manually by selecting File, Refresh.
Configuring the level of detail to log Select File, Options. By default, Full-Server Failover Manager creates a log that maintains all processing information. If desired, you can disable the option Enable Verbose Logging so that only basic processing information is logged.
Clearing maintained security credentials Select File, Options. By default, Full-Server Failover Manager will save the user credentials supplied for each servers. If desired, you can enable Clear cached credentials on exit so they are not saved when the console is closed. You can also clear the user credentials manually by selecting File, Clear Cached Credentials and then closing the Full-Server Failover Manager.
Configuring how servers are added to the Full-Server Failover Manager Select File, Options. By default, Full-Server Failover Manager will use ICMP pings to check for available servers to add to the Full-Server Failover Manager. If you do not want to use ICMP pings, select Do not use ICMP Ping. When this option is selected, the FullServer Failover Manager will use the Storage Mirroring service to check for available servers.
Saving and reusing configuration options After you have created a protection pair and configured any of the optional settings you can save those settings so that you can reuse them for future pairs of servers. Once you have the settings the way you want them, save them by selecting File, Defaults, Save Current Settings as Defaults. This creates a file called FFMDefaults.
Application Manager To open the Application Manager, select Start, Programs, HP Storage Mirroring, Recover, HP Storage Mirroring Application Manager. Note: You can also start the Application Manager from the command line. l l To start it in standard mode, run the command dtam /application, where /application is /exchange, /sql, /fileprint, or /blackberry. To start it in advanced mode, run the command dtam /application /advanced, where /application is /exchange, /sql, /fileprint, or /blackberry.
Adding or managing servers Step 2 of the application protection workflow is to select your source and target servers. If no servers are populated in the lists (perhaps the server you need is in a child domain), click Advanced Find to add servers to the lists. Advanced Find is not available for all application protections. 1. Click Search to locate all the application servers that Application Manager can discover in the domain.
Changing Application Manager options To modify Application Manager options, select Tools, Options and modify any of the following options. l l l l l l l l l l l l Service Listen Port—This is the port used for Storage Mirroring Recover communications. This port must be the same on the client machine and the source and target servers.
Storage Mirroring Recover for Virtual Infrastructure console To open the Storage Mirroring Recover for Virtual Infrastructure console, select Start, Programs, HP Storage Mirroring, Recover, Storage Mirroring Recover for Virtual Infrastructure. The first time you use the console or if you have not saved your login information, you will be prompted to provide login information.
Managing activation codes You can manage your Storage Mirroring Recover for Virtual Infrastructure activation codes by selecting Go, Manage activation codes. Enter a new activation code and click Add. To remove a code, highlight in the list and click Remove. Each activation code corresponds to a number of slots, where each slot represents the capacity to protect a single virtual machine in your environment.
Managing VirtualCenter servers To manage your VirtualCenter servers, select Manage VirtualCenter servers from the left pane of the console. l l l Adding a VirtualCenter server—Click Add VirtualCenter server on the toolbar. On the Add VirtualCenter server page, specify the IP address or DNS Name of the VirtualCenter server and supply a User name and Password. Click Save to insert the VirtualCenter server.
Managing ESX servers To manage your ESX servers, select Manage ESX servers from the left pane of the console. Storage Mirroring Recover for Virtual Infrastructure scans to find ESX servers that are VMotion destination candidates, based upon SAN connectivity. The Credentials Cached column in the table identifies servers that need to have credentials added. To add the credentials, highlight a server in the list and click Configure ESX server on the toolbar.
Setting up an e-mail server To set up an e-mail server, select Set up e-mail server from the left pane of the console. E-mail configuration applies to all protection jobs. Specify the e-mail server configuration. l l l l From address—Specify the e-mail address that you wan to appear in the From field of each message. SMTP server—Specify the SMTP server using the full Active Directory DNS name, the IP address, or the NetBIOS short name.
Workload protection Storage Mirroring Recover flexible configurations allow you to protect different workloads depending on the needs of your organization. l l l l l Specific data—You can protect specific data (volumes, directories, files, and/or wildcards). In the event of a failure, the data you protected is available on the target. Entire server—You can protect an entire server, including the data and system state, which is the server's configured operating system and applications.
Data protection Protecting specific data consists of two main tasks - creating a replication set (to identify the data to protect) and connecting that replication set to a target. You have the following data protection options. l l l l Automated process—If you would like to use an automated process that walks you through both the replication and connection tasks, you only need to complete the steps Establishing a connection using the automated Connection Wizard.
Establishing a connection using the automated Connection Wizard The Connection Wizard guides you through the process of protecting your data. It helps you select a source, identify the data from your source that will be included in the replication set, and select a target. 1. From the Replication Console, start the Connection Wizard to establish your connection. If you have just opened the Replication Console, you can click Make a connection from the right pane of the Replication Console.
selected. If it is not, select the Storage Mirroring Recover target. This is your backup server that will protect the source. Note: Storage Mirroring Recover will automatically attempt to log on to the selected target using the identification of the user logged on to the local machine. If the logon is not successful, the Logon dialog box will appear prompting for your security identification. When logging in, the user name, password, and domain are limited to 100 characters. 6. Click Next to continue. 7.
l l l Send all data to a single path on the target—This option sends all selected volumes and directories to the same location on the target. The default location is \source_name\replication_set_name\volume_letter. Send all data to the same path on the target—This option sends all selected volumes and directories to the same directories on the target. For example, c:\data and d:\files on the source will go to c:\data and d:\files on the target.
Creating a replication set Before you can establish a connection, you must create a replication set. 1. From the Replication Console, highlight a source in the left pane of the Replication Console and select Insert, Replication Set from the menu bar. You can also rightclick on the source name and select New, Replication Set. 2. A replication set icon appears in the left pane under the source. By default, it is named New Replication Set.
Note: Be sure and verify what files can be included by reviewing Replication capabilities. 5. After selecting the data for this replication set, right-click the new replication set icon and select Save. A saved replication set icon will change from red to black.
Establishing a connection manually using the Connection Manager After you have created a replication set, you can establish a connection through the Connection Manager by connecting the replication set to a target. 1. From the Replication Console, open the Connection Manager to establish the connection. l Highlight the replication set and select Tools, Connection Manager. l Right-click on the replication set and select Connection Manager. l Drag and drop the replication set onto a target.
l l l l l l l l Source Server—Specify the source server that contains the replication set that is going to be transmitted to the Storage Mirroring Recover target. Replication Set—At least one replication set must exist on the source before establishing a connection. Specify the replication set that will be connected to the target. Target Server—Specify which Storage Mirroring Recover target will maintain the copy of the source’s replication set data.
amount of disk space available must be equal to or greater than the on-disc size of the sparse file. If you are mirroring and replicating multiple mount points, your directory mapping must not create a cycle or loop. For example, if you have the c: volume mounted at d:\c and the d: volume mounted at c:\d, this is a circular configuration. If you create and connect a replication set for either c:\d or d:\c, there will be a circular configuration and mirroring will never complete.
l l Full Mirror—All files in the replication set will be sent from the source to the target. File Differences—Only those files that are different based on date, time, and/or size will be sent from the source to the target. l Send data only if Source is newer than Target—Only those files that are newer on the source are sent to the target. Note: If you are using a database application, do not use the newer option unless you know for certain you need it.
Note: Stopping, starting, pausing, or resuming mirroring contains a comparison of how the file difference mirror settings work together, as well as how they work with the global checksum setting on the Source tab of the Server Properties.
Note: Database applications may update files without changing the date, time, or file size. Therefore, if you are using database applications, you should use the File Differences with checksum or Full option. l Calculate Replication Set size on connection—Determines the size of the replication set prior to starting the mirror. The mirroring status will update the percentage complete if the replication set size is calculated. 4. Click Connect to establish the connection.
Establishing a connection across a NAT or firewall If your source and target are on opposite sides of a NAT or firewall, you will need special configurations to accommodate the complex network environment. Additionally, you must have the hardware already in place and know how to configure the hardware ports. If you do not, see the reference manual for your hardware.
l Storage Mirroring Recover failover can use ICMP pings to determine if the source server is online. If you are going to use ICMP pings and a router between the source and target is blocking ICMP traffic, failover monitors cannot be created or used. In this situation, you must configure your router to allow ICMP pings between the source and target. Since there are many types of hardware on the market, each can be configured differently.
Simulating a connection Storage Mirroring Recover offers a simple way for you to simulate a connection in order to generate statistics that can be used to approximate the time and amount of bandwidth that the connection will use when actively established. This connection uses the TDU (Throughput Diagnostics Utility), which is a built-in null (non-existent) target to simulate a real connection. No data is actually transmitted across the network.
l l l l l l l l Source Server—Specify the source server that contains the replication set that is going to be simulated to the TDU. Replication Set—At least one replication set must exist on the source before establishing a connection. Specify the replication set that will be connected to the TDU. Target Server—Select the Diagnostics target. Route—After selecting the Diagnostics target, the Route will automatically be populated with Throughput Diagnostics Utility (TDU).
Data workload failover When you established your data workload protection, you only protected the data. You still need to establish failover monitoring, so that the target can stand in for the source in the event of a source failure, and your end users can access the data from the target.
Configuring failover monitoring 1. Open the Failover Control Center from your target server or a client machine. Do not run the Failover Control Center from your source server. 2. Click Add Target and enter a name or IP address (with or without a port number) of your failover target. 3. Click OK. 4. Click Login to login to the selected target. 5. Select a source machine to monitor by clicking Add Monitor. The Insert Source Machine dialog box appears in front of the Monitor Settings dialog box. 6.
9. Highlight an IP address that you have selected for monitoring and select a Method to Monitor for Failover. l l l l Network Service—Source availability will be tested for by a Storage Mirroring Recover network response Replication Service—Source availability will be tested for by a Storage Mirroring service response. Network and Replication—Source availability will be tested for by both a Storage Mirroring Recover network response and a Storage Mirroring service response.
13. If you are monitoring multiple IP addresses, highlight the source name and specify the Failover Trigger. l l All Monitored IP Addresses Fail—Failover begins when all monitored IP addresses fail. If there are multiple, redundant paths to a server, losing one probably means an isolated network problem and you should wait for all IP addresses to fail. One Monitored IP Address Fails—Failover begins when any one of the monitored IP addresses fails.
l Revert to Last Good Snapshot if Target Data is Bad—If the target data is in a bad Storage Mirroring Recover state, Storage Mirroring Recover will automatically revert to the last good Storage Mirroring Recover snapshot before failover begins. You will lose any data between the last good snapshot and the failure. If the target data is in a good state, Storage Mirroring Recover will not revert the target data. Instead, Storage Mirroring Recover will apply the data in the target queue and then failover.
source's subnet will be changed at failover, the source server must be the only system on that subnet, which in turn requires all server communications to pass through a router. Additionally, it may take several minutes or even hours for routing tables on other routers throughout the network to converge. l l Server Name—Failover is performed on the server name. If you specify the server name to be failed over, first Storage Mirroring Recover checks the hosts file and uses the first name there.
.SHR Share Mapping File check box is selected if you would like to use the Storage Mirroring Recover share mapping file to create shares on the target during failover. If this option is not selected, shares will be created using the information gathered when the machine was selected as a source to be monitored. Note: If the Shares selection under Items to Failover is not selected, shares will not be failed over to the target regardless of the Use .SHR Share Mapping File selection. 18.
l l l l If you want to pass any arguments to your script, specify the arguments. If you want to delay the failover or failback processes until the associated script has completed, mark the appropriate check box. If you want the same scripts to be used as the default for future monitor sessions, mark the appropriate check box. If you want to specify a user account to run the scripts, specify the credentials for the source and target.
Updating shares on the target Share information on the target can be manually updated from the Failover Control Center window. To manually update the share information, highlight a source machine in the Monitored Machines tree and click the Update Shares button.
Editing failover monitoring configuration If you want to edit the monitor settings for a source that is currently being monitored, highlight that source on the Monitored Machines tree on the main Failover Control Center screen and click Edit. The Monitor Settings dialog box will open. Follow the Configuring failover monitoring instructions.
Removing failover monitoring configuration If you want to discontinue monitoring a source, highlight that machine on the Monitored Machines tree on the main Failover Control Center screen and click Remove Monitor. No additional dialog boxes will open.
Server settings Most of the Storage Mirroring Recover server settings are located in the Replication Console Server Properties dialog box. To access this dialog box, right-click a server in the left pane of the Management Console and select Properties. The Server Properties dialog box contains multiple tabs with the Storage Mirroring Recover server settings. For information on the server settings not available through the Replication Console, see the Scripting Guide.
Identifying a server From the Replication Console, you can see server identity information, including a server's Storage Mirroring Recover activation code. 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the General tab. 4. Specify the server identity information. Some of the fields are informational only.
l l l l l l Parent Group—This is the group in the Replication Console server Addresses—The IP address(es) for this server are listed in this field. This information is not modifiable and is displayed for your information. The machine’s primary address is listed first. Client Transmit Port—This field displays the port that the Replication Console uses to send commands to a server. This port cannot be modified.
Licensing a server From the Replication Console, you can manage your server activation codes. The activation code is the Storage Mirroring Recover license which is required on every Storage Mirroring Recover server. The activation code is a 24 character, alpha-numeric code. You can change your activation code without reinstalling, if your license changes. There are different licenses available. l l l Evaluation—An evaluation license has an expiration date built into the activation code.
3. Select the Licensing tab. 4. Enter an activation code and click Add. Repeat for each activation code. 5. Highlight an activation code in the list to display any status messages for that code below the list display. 6. If you need to remove a code from the server, highlight it in the list and click Remove. 7. Click OK to save the settings.
Configuring server startup options From the Replication Console, you can configure server startup options for each Storage Mirroring Recover server. 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the Setup tab. 4. Specify the server setup and source startup options.
various points during the replication of data. Because the tasks are userdefined, you can achieve a wide variety of goals with this feature. For example, you might insert a task to create a snapshot or run a backup on the target after a certain segment of data from the source has been applied on the target. This allows you to coordinate a point-in-time backup with real-time replication.
applications, you should use the File Differences with checksum or Full option. l Server Shutdown Timeout—This setting indicates the amount of time, in seconds, for the service to wait prior to completing a shutdown so that Storage Mirroring Recover can persist data on the target in an attempt to avoid a remirror when the target comes back online. A timeout of zero (0) indicates waiting indefinitely and any other number indicates the number of seconds.
Configuring network communication properties for a server 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the Network tab. 4. Specify the network communication properties. l l Default Address—This option specifies the default target IP address to connect to when a connection is created. Windows will determine what IP address is used on the source based on the IP address specified for the target.
Queuing data You should configure queuing on both the source and target. 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties. 3. Select the Queue tab. 4. Specify the queue settings for the server. l Folder—This is the location where the disk queue will be stored. Storage Mirroring Recover displays the amount of free space on the volume selected.
l l l l l Select a dedicated, physical, non-boot volume. Select a location on a non-clustered volume that will have minimal impact on the operating system and applications being protected. Select a location that is on a different volume as the location of the Windows pagefile. Do not select the root of a volume. Do not select the same physical or logical volume as the data being replicated.
amount of physical memory available but has a minimum of 32 MB. By default, 128 MB or 512 MB of memory is used, depending on your operating system. If you set it lower, Storage Mirroring Recover will use less system memory, but you will queue to disk sooner which may impact system performance. If you set it higher, Storage Mirroring Recover will maximize system performance by not queuing to disk as soon, but the system may have to swap the memory to disk if the system memory is not available.
Note: The Maximum disk space for queue and Minimum Free Space settings work in conjunction with each other. For example, assume your queues are stored on a 10 GB disk with the Maximum disk space for queue set to 10 GB and the Minimum Free Space set to 500 MB. If another program uses 5 GB, Storage Mirroring Recover will only be able to use 4.5 GB so that 500 MB remains free.
Configuring source data processing options 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the Source tab. 4. Specify how the source will process data. l l Replication Packets to 1 Mirror Packet—You can specify the ratio of replication packets to mirror packets that are placed in the source queue.
(SID). By replicating Windows security by name, you can transmit the owner name with the file. If that user exists on the target, then the SID associated with the user will be applied to the target file ownership. If that user does not exist on the target, then the ownership will be unknown. By default, this option is disabled. l l Domain security model—If you are using a Windows domain security model by assigning users at the domain level, each user is assigned a security ID (SID) at the domain level.
l l l Maximum Pending Mirror Operations—This option is the maximum number of mirror operations that are queued on the source. The default setting is 1000. If, during mirroring, the mirror queued statistic regularly shows low numbers, for example, less than 50, this value can be increased to allow Storage Mirroring Recover to queue more data for transfer. Size of Mirror Packets—This option determines the size of the mirror packets that Storage Mirroring Recover transmits.
Configuring target data processing options 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the Target tab. 4. Specify how the target will process data. l l Target Mirror Capacity High Percentage—You can specify the maximum percentage of Windows system memory that can contain mirror data before the target signals the source to pause the sending of mirror operations. The default setting is 20.
l l Retry Delay for Incomplete Operations (seconds)—This option specifies the amount of time, in seconds, before retrying a failed operation on the target. The default setting is 3. Block Target Path(s) on Connection—You can block writing to the data located in the target paths. This keeps the data from being changed outside of Storage Mirroring Recover processing.
Do not include the Recycler directory in your replication set if you are moving deleted files. If the Recycler directory is included, Storage Mirroring Recover will see an incoming file deletion as a move operation to the Recycle Bin and the file will not be moved as indicated in the Move deleted files setting. Alternate data streams that are deleted on the source will only be moved if the location you specified is on the same volume as the replica data.
Specifying the Storage Mirroring Recover database storage files 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the Database tab. 4. Specify the database files that store the Storage Mirroring Recover replication set, connection, and scheduling information. l l Folder—Specify the directory where each of the database files on this tab are stored.
l l Connection—This database file maintains the active source/target connection information. The default file name is connect.sts. Schedule—This database file maintains any scheduling and transmission limiting options. The default file name is schedule.sts. 5. Click OK to save the settings.
Specifying file names for logging and statistics 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the Logging tab. 4. Specify the location and file names for the log and statistics files. l l Folder—Specify the directory where each of the log files on this tab are stored. The default location is the directory where the Storage Mirroring Recover program files are installed.
l l l l l l l l l l Messages & Alerts, Maximum Files—Specify the maximum number of Storage Mirroring Recover alert log files that are maintained. The default is 5, and the maximum is 999. Verification, Filename—The verification log is created during the verification process and details which files were verified as well as the files that are synchronized. This field contains the base log file name for the verification process. The replication set name will be prefixed to the base log file name.
Supplying credentials for script processing 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties 3. Select the Script Credentials tab. 4. If you will be using any customized scripts (mirroring, failover, task command processing, and so on) specify a Username, Password, and Domain to use when running the scripts. If you do not specify any security credentials, the account running the Storage Mirroring service will be used. 5.
E-mailing event messages You can e-mail Storage Mirroring Recover event messages to specific addresses. The subject of the e-mail will contain an optional prefix, the server name where the message was logged, the message ID, and the severity level (information, warning, or error). The text of the message will be displayed in the body of the e-mail message. 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties. 3.
Note: Any specified notification settings are retained when Enable notification is disabled. 5. Specify your e-mail settings. l l l l l Mail Server (SMTP)—Specify the name of your SMTP mail server. Log on to SMTP Server—If your SMTP server requires authentication, enable Log on to SMTP Server and specify the Username and Password to be used for authentication. Your SMTP server must support the LOGIN authentication method to use this feature.
the list. Note: You can test e-mail notification by specifying the options on the E-mail Notification tab and clicking Test. (By default, the test will be run from the machine where the Replication Console is running.) If desired, you can send the test message to a different e-mail address by selecting Send To and entering a comma or semicolon separated list of addresses. Modify the message text up to 1024 characters, if necessary. Click Send to test the e-mail notification.
Full-server protection Before you can protect your entire source, you need to select a target that is suitable to become the source, in the event of a source failure. Storage Mirroring Recover will validate the target you select and identify any incompatibilities. Errors will disqualify the target as a suitable server. First you will need to find a compatible target, then you can establish full-server protection.
Finding a compatible target Review the table below to determine if your server is a compatible target. Operating system version The source and target must have the same operating system. For example, you cannot have Windows 2003 on the source and Windows 2008 on the target. The two servers do not have to have the same level of service pack or hotfix. Windows 2003 and 2003 R2 are considered the same operating system, however the Windows 2008 and 2008 R2 releases are considered different operating systems.
Memory The target memory should be within 25% (plus or minus) of the source. If the target has much less memory than the source, there will be performance impacts for the users after failover. Network adapters You must map at least one NIC from the source to one NIC on the target. If the source has more NICs than the target, some of the source NICs will not be mapped to the target.
Boot volume configuration The target boot volume cannot be a dynamic disk configuration. The boot volume is the disk volume that contains the Windows operating system and supporting files. By default, the operating system files are in the \Windows folder, and the supporting files are in the \Windows\System32 folder. The boot volume might be the same volume as the system volume, but that configuration is not required. System path The source and the target must have the same system path.
failover, the failover will continue. If not, you will either have to select a different target or delete files on the target to free disk space. Establishing full-server protection Use the following instructions to establish protection for your entire source. 1. Login as a user that is a member of both the Double-Take Admin and local Administrators security groups. 2. Open the Full-Server Failover Manager. 3. Enter your source and target servers.
6. Double-click on any of the validation items to see details. You must correct any errors before you can enable protection. Depending on the error, you may be able to click Fix or Fix All and let Storage Mirroring Recover correct the problem for you. For those errors that Storage Mirroring Recover cannot correct automatically, you will need to modify the target to correct the error, or you can select a different target.
Optional full-server protection settings Optional protection settings are available when configuring a full-server protection connection, but they are not required. If you want to configure the optional settings, make sure you have a valid source and target specified, then click Configure protection from the main Full-Server Failover Manager page. You have the following optional configuration settings available.
Including and excluding data to be protected 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Protection tab. 2. Specify that data you want to include and/or exclude. l l Volumes to include—Select the volumes that you want to protect. You must have the same volumes on the source and target. You cannot deselect the boot volume.
Stopping services on the target when protection is enabled 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Protection tab. 2. Storage Mirroring Recover determines what services are currently running on the target. You can specify which services you want to keep running and those services you want to stop when you enable your protection.
Taking snapshots of the target 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Protection tab. 2. A snapshot is an image of data taken at a single point in time. Snapshots allow you to view files and folders as they existed at points of time in the past, so you can, for example, recover from cases where corrupted source data was replicated to the target.
Configuring failover monitoring and processing 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Failover tab. 2. Specify how you want to handle failover monitoring and processing. l l l Manual intervention required—By default, you will be notified when a failover is necessary, but the failover process will not start until you manually initiate it.
Mapping network configuration on the target for post-failover 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Failover tab. 2. Specify how you want to handle network configurations on the target after failover. l l l l l l l Apply source network configuration to the target—If you select this option, the source IP addresses will be failed over to the target.
Routing data transmissions 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Advanced tab. 2. By default, Storage Mirroring Recover will select the default route for transmissions. If desired, select a different IP address on the target that will be used for full-server connection transmissions. 3. Click OK to save the settings.
Mirroring data 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Advanced tab. 2. Select the type of Storage Mirroring Recover mirroring process you want to perform. A Full mirror will transmit all files from the source to the target. A Checksum mirror will transmit only the blocks of data that are different between the source and target. 3. Click OK to save the settings.
Compressing data 1. Make sure you have a valid source and target specified, click Configure protection from the main Full-Server Failover Manager page, and then select the Advanced tab. 2. Compression allows you to reduce the amount of bandwidth needed to transmit data from the source to the target. The data is compressed before being transmitted and then is uncompressed before it is written on the target. Typically, compression is used in WAN environments, but not in LAN environments.
Using NAT or firewalls with full-server workloads If your source and target are on opposite sides of a NAT or firewall, you will need to configure your hardware to accommodate full-server workload communications. You must have the hardware already in place and know how to configure the hardware ports. If you do not, see the reference manual for your hardware.
Full-server ports By default, Storage Mirroring Recover uses port 6320 for all TCP and UDP communications. To verify or modify the ports, you must use the Replication Console. 1. Open the Replication Console. 2. Locate your servers in the server tree in the left pane of the Replication Console. 3. Right-click the server in the left pane of the Replication Console and select Properties. 4. On the Network tab, verify or modify the Communications Port as needed.
Microsoft Windows ports Full-server workload protection uses WMI (Windows Management Instrumentation) which uses RPC (Remote Procedure Call). By default, RPC will use ports at random above 1024, and these ports must be open on your firewall. RPC ports can be configured to a specific range by specific registry changes and a reboot. See the Microsoft Knowledge Base article 154596 for instructions. Full-server workload protections also rely on other Microsoft Windows ports.
Hardware ports You need to configure your hardware so that the full-server ports and Microsoft Windows ports are open. Since communication occurs bidirectionally, make sure you configure both incoming and outgoing traffic. There are many types of hardware on the market, and each can be configured differently. See your hardware reference manual for instructions on setting up your particular router.
Application protection Protecting an application consists of three main tasks - configuring the protection, validating the protection, and enabling the protection. The processes are similar for the different application types, however, there are some variances. Optional protection settings are available when configuring application protection, but they are not required.
Protecting an application 1. Open the Application Manager. 2. Verify the Setup tab is selected and then from the Tasks list on the left pane, select the type of application you want to protect. Note: The fields in the Application Manager console will vary depending on the type of application you are protecting. 3. Application Manager will automatically identify the root domain where the Application Manager is running and populate the Domain Name field.
Note: If you have previously used this source and target pair, you will be prompted to reuse the previous configuration. If you select Yes, your previous configuration settings will be used. If you do not want to use the previous configuration settings (perhaps the source or target configuration has changed since you configured the connection), select No to use the default configuration settings. If you select a source that is currently unavailable, you will be prompted to select the target first.
If you are protecting multiple Exchange virtual servers, you can configure multiple like-named cluster protection connections, or you can failover multiple Exchange virtual servers to preexisting Exchange virtual servers on the target. In this case, select the target Exchange virtual server. If you are protecting Exchange in a like-named cluster scenario, select the same server for the source and target. The target server name will automatically be appended with the suffix likenamed.
If you will be configuring DNS failover, the login account must be a member of the domain DnsAdmins security group. Exchange Note: The login account must be an Exchange Full Administrator at the organizational level, as delegated via the Exchange System Manager at the user level or have delegated rights via the Application Manager Delegate Rights feature (select Tools, Delegate Rights).
black exclamation point (!) inside a yellow triangle. A successful validation is designated by a white checkmark inside a green circle. Unknown items are a white question mark inside a blue circle. Double-click on any of the validation items to see details. Application Manager can automatically fix errors and warnings marked with a yellow gear. Highlight a single item and click Fix to have Application Manager fix that one issue. Click Fix All to have Application Manager correct all of the issues.
9. If you are protecting BlackBerry, a Complete BlackBerry Protection dialog will appear after the validation is complete. Select the name of the Exchange server under step 2 of the dialog box and you will be able to complete the application protection process again in order to protect your Exchange server. 10. Once the validation passes without errors, click Enable Protection. View the status of the protection on the Monitor tab.
issue, either modify the failover script to use the domain controller that Exchange uses when the Information Store service is started or mount the stores manually and run the Replace replicas PowerShell call from the failover script to update the PF replicas (if applicable). If you are protecting Exchange on a cluster and the target cluster has more than one IP address resource for the virtual Exchange server you may experience the following issue.
Optional application protection settings Optional protection settings are available when configuring application protection, but they are not required. If you want to configure the optional settings, make sure you have a valid domain and servers specified, then click Configure from the main Application Manager page. You have the following optional configuration settings available.
Configuring failover processing 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Failover tab. Note: The fields on the Failover tab will vary depending on the type of application you are protecting. 2. Specify the Failover Type which is the name resolution method that will be used to redirect users to the target in the event the source fails.
3. Application Manager automatically determines the appropriate application services or resources to start and stop based on the application you are protecting, your operating system, and your application configuration. If necessary, modify the list of services or resources. a. Click Add to insert a service or resource into the list. Specify the service or resource name and make sure that Service must be stopped on target is enabled so that replication can update files on the target. b.
Configuring DNS failover Application Manager will automatically determine default DNS failover settings. Use the following instructions to modify the DNS failover settings. 1. The DNS Server list contains all DNS IP addresses for the source and target servers. The label after the IP address indicates if the DNS IP address belongs to the source, target, or both. To additional DNS servers to the list, enter an IP address into the DNS Server field and click Add.
address for DNS updates. Exchange Note: If you are protecting Exchange and one or more IP addresses are configured for the SMTP virtual server on the target, the first IP address will be the default target IP address for all source IP addresses. 3. You can specify the length of time, in seconds, that the source's DNS A records are cached in the Time to Live. Enable Update TTL and specify a number of seconds. Ideally, you should specify 300 seconds (5 minutes) or less.
l l l l If you have a NIC designated only for Storage Mirroring Recover traffic, DNS registration for that NIC should be disabled. If you are protecting Exchange and your server is using a public IP address to receive e-mail, you will have to change the public advertised DNS MX record to reflect the target IP address. Consult your service provider for instructions.
Configuring identity failover Application Manager will automatically determine default identity failover settings. Use the following instructions to modify the identity failover settings. 1. Under Source IP address to failover, map a Source IP address to a Target NIC. The target NIC will assume the source IP address during failover. The Target IP addresses list displays the IP address(es) of the selected Target NIC. 2.
SQL Note: If you are protecting SQL, do not failover the server name. File Server Note: You cannot failover file shares from a parent to child domain. 3. Click OK to save your settings.
Configuring failover monitoring 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Monitoring tab. 2. To enable the target to monitor the source for a failure, enable Active Monitoring Enabled. If this option is disabled, you will need to manually monitor the source and initiate failover if the source fails. 3. To help you better control when failover occurs, enable Manual Intervention Required.
l l l Application Monitoring—In non-cluster environments, you can monitor an application via a monitoring script. The script can be WMI, PowerShell, Visual Basic, or JScript. Monitor Interval—This setting identifies the number of seconds between the monitor requests sent from the target to the source to determine if the source is online. The default setting depends on the Method to Monitor for Failover.
script that will monitor the application. The custom script can be PowerShell, Visual Basic, or JScript. Once your script is identified, you can click Edit to open a text editor to view or modify the script. Note: A sample Visual Basic script for application monitoring is available in the \Application Manager\Samples subdirectory where Storage Mirroring Recover is installed. If you are using a PowerShell script, PowerShell must be installed on the target.
Taking snapshots of the target 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Snapshot tab. Note: Snapshots are not available in cluster environments. 2. A snapshot is an image of data taken at a single point in time. Snapshots allow you to view files and folders as they existed at points of time in the past, so you can, for example, recover from cases where corrupted source data was replicated to the target.
Application connection settings You can configure routing and mirroring settings for your application connection. In addition, there are application specific settings that you can configure. The fields on the Connection tab will vary depending on the type of application you are protecting.
Routing data transmissions 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Connection tab. Note: The fields on the Connection tab will vary depending on the type of application you are protecting. 2. By default, Storage Mirroring Recover will select the default Route for transmissions. If desired, select a different IP address on the target that will be used for transmissions.
Protection configuration Application specific protection options are available on the Configure Protection Connection tab. The fields on the Connection tab will vary depending on the type of application you are protecting.
Configuring Exchange storage group protection If you are protecting Exchange, you can specify which storage groups, mailboxes, and public folder stores that you want to protect. 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Connection tab. Note: The fields on the Connection tab will vary depending on the type of application you are protecting. 2.
The Protected Storage Groups list will be disabled if you have enabled Override Generated Rules on the Advanced tab. 3. If desired, you can select additional data to protect under the Volumes folder. 4. Click Refresh if you need to refresh the items in the tree view. 5. Click OK to save the settings.
Configuring SQL database protection If you are protecting SQL, you can protect the SQL instance or only the database only. 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Connection tab. Note: The fields on the Connection tab will vary depending on the type of application you are protecting. 2. Select if you want to protect the SQL Instance or the Database Only.
l l l l l l The servers must have the same named instances, unless you are running Application Manager in advanced mode. In this case, you can identify instances to protect that are offline or do not exist on the target. The Manage SQL Server Instances dialog will only appear if you two or more SQL instances (default plus one or more named instances or two or more named instances with no default instance). The TcpPort for the named instances will be different. This is acceptable.
*.ldf, and so on). Any attempts to manually attach the database may fail if the user account does not yet have NTFS permissions to access the physical files. To change the permissions on an individual file, perform these steps on each file that is part of the database's file list. a. In Windows Explorer, right-click the folder that contains the physical files for the database that needs to be manually attached. b. Select Properties. c.
unique target path for \level1\level2\database.mdf, the target path for level1\level2\level3\database.mdf will also be in that path. Click the ellipsis (...) button to search for a target path and click Apply to save the setting. 4. If desired, you can select additional data to protect under the Volumes folder. 5. Click Refresh if you need to refresh the items in the tree view. 6. Click OK to save the settings.
Configuring file server protection If you are protecting a file server, you can specify the file shares that you want to protect. 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Connection tab. Note: The fields on the Connection tab will vary depending on the type of application you are protecting. 2. By default, all non-administrative file shares will be selected.
Configuring BlackBerry database protection 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Connection tab. Note: The fields on the Connection tab will vary depending on the type of application you are protecting. 2. Select the databases that you want to protect. Note: You cannot deselect the databases containing the BES or MDS information.
service(s). 7. Under BlackBerry Services, Application Manager automatically determines the appropriate BlackBerry services to start and stop. If necessary, modify the list of services. a. Click Add to insert a service into the list. Specify the service name and make sure that Service must be stopped on target is enabled so that replication can update files on the target. b. Click Remove to remove a service from the list. You can only remove services that you have manually added. c.
Mirroring data 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Connection tab. Note: The fields on the Connection tab will vary depending on the type of application you are protecting. 2. Specify your Mirror Settings. l l Mirror Type—Select the type of Storage Mirroring Recover mirroring process you want to perform. A Full mirror will transmit all files from the source to the target.
Application advanced settings You can configure advanced settings for you application connection. The advanced settings that are available will depend on the application you are protecting. Therefore, the fields on the Advanced tab will vary. In addition, the fields will vary depending on if you launched Application Manager in standard or advanced mode.
Configuring the replication set Application Manager automatically creates a replication set with a name based on the application you are protecting. The list below contains the default replication set names, where source and target are the names of the respective servers.
if you launched Application Manager in standard or advanced mode. 2. To modify the replication set definition, select Override Generated Rules. When this option is selected, the application controls (storage groups or protected databases) on the Connection tab will be disabled. 3. To add a new replication set rule, click Add. 4. Specify a path, wild card, or specific file name. Application Manager will not verify the rule you are adding. 5. Select to Include or Exclude the file. 6.
Configuring scripts Scripts are executed at different points during failover, failback, and restoration. The scripts perform actions to make your applications available on the appropriate server. Editing scripts is an advanced feature. Do not modify the scripts unless you are familiar with Storage Mirroring Recover, your application, and scripting. Any edits should be made carefully and tested prior to deployment to ensure the changes are correct. Incorrect script changes could cause failover issues. 1.
Configuring Active Directory If you are protecting Exchange, you can configure several settings for Active Directory. 1. Make sure you have a valid domain and servers specified, click Configure from the main Application Manager page, and then select the Advanced tab. Note: The fields on the Advanced tab will vary depending on the type of application you are protecting. In addition, the fields will vary depending on if you launched Application Manager in standard or advanced mode. 2.
This setting is cleared when protection is enabled, which prevents SMTP queuing issues when trying to deliver messages to the target, but is never restored. If you want to have an active target server, you can use this command to restore it to an Application Manager state.
Configuring items to failover If you are performing an identity failover, then you have already selected the Items to Failover. Changing any of the Items to Failover on the Advanced tab will automatically make the same change on the Failover tab Configure Identity Failover page. However, if you are performing DNS failover, you may want to modify the items that you are failing over using the instructions below. 1.
Configuring default connection parameters Several default connection options are available which allow you to disable or enable the creation of default connection parameters. Ideally, you want Application Manager to create the default parameters. However, if you have modified any of the parameters manually and you do not want your modifications overwritten by the defaults, then you may want to disable the creation of the default connection parameters. 1.
Using NAT or firewalls with application workloads If your source and target are on opposite sides of a NAT or firewall, you will need to configure your hardware to accommodate application workload communications. You must have the hardware already in place and know how to configure the hardware ports. If you do not, see the reference manual for your hardware.
Application workload ports By default, Storage Mirroring Recover uses port 6320 for all TCP and UDP communications. To verify or modify the ports, use the following instructions. 1. In the Application Manager, select Tools, Options. 2. Verify or modify the Service Listen Port as needed. All servers and clients in your application workload protection must be using the same port. Storage Mirroring Recover uses ICMP pings to monitor the source for failover.
Microsoft Windows ports Application workload protection uses WMI (Windows Management Instrumentation) which uses RPC (Remote Procedure Call). By default, RPC will use ports at random above 1024, and these ports must be open on your firewall. RPC ports can be configured to a specific range by specific registry changes and a reboot. See the Microsoft Knowledge Base article 154596 for instructions. Application workload protections also rely on other Microsoft Windows ports.
Hardware ports You need to configure your hardware so that the application workload ports and Microsoft Windows ports are open. Since communication occurs bidirectionally, make sure you configure both incoming and outgoing traffic. There are many types of hardware on the market, and each can be configured differently. See your hardware reference manual for instructions on setting up your particular router.
Exchange Failover Utility When you configure Exchange for protection, Application Manager creates customized scripts based on the settings you choose. The scripts are based on the Exchange Failover Utility (EFO). Generally, you do not need to run the Exchange Failover Utility from the command line or modify the scripts that Application Manager creates, however, the syntax for the utility is provided below in case that need arises.
be able to locate this file which could impede assistance through Technical Support. l NORUS—Do not change the Recipient Update service l NORM—Do not change the Routing Master l NOSPN—Do not change the Service Principal Name l l l l l NOOAB—Do not change the siteFolderServer for the offline address book NOADREPLICATION—Do not force Active Directory replication MAXREPWAIT minutes—Maximum time, in minutes, to wait for Active Directory replication to complete before continuing failover or failback.
l DC domain_name | IPaddress—Name or IP address of the domain controller to make updates on l SDOMAIN—Source domain name l TDOMAIN—Target domain name l ?—Displays the Exchange Failover utility syntax l ??—Displays a description of the Exchange Failover utility options l exchfailover -failover -s alpha -t beta l exchfailover -failback -s alpha -t beta l exchfailover -failover -s alpha -t beta -r -onlypublicfolders Examples l exchfailover -failover -s alpha -t beta -u administrator:password
Virtual server protection Select a link to jump to instructions that correspond with your virtual configuration. l l l Physical or virtual (guest level) to Hyper-V or ESX virtual—If your source is a physical or virtual server, and you want to protect the volumes from the physical server or the volumes from within the virtual guest operating system, and your target is a virtual server on a Hyper- V or ESX server, then see Protecting an entire physical or virtual server to a Hyper-V or ESX server.
Protecting a physical or virtual server to a Hyper-V or ESX server Use these instructions to protect a physical or virtual server, where you want to protect the volumes from the physical server or the volumes from within the virtual guest operating system, to a virtual server on a Hyper-V or ESX server. 1. Open the Storage Mirroring Console by selecting Start, Programs, Storage Mirroring, Storage Mirroring Console. 2. Click Get Started from the toolbar. 3. Select Storage Mirroring Recover and click Next. 4.
Your source can have no more than four NICs enabled, except if your source is ESX version 4.x. In that case, you can have up to ten NICs. l l User name—Specify a user that is a member of the Double-Take Admin and local administrator security groups on the source. If you want to use a domain user account, enter a fully-qualified domain name in the format domain\username or username@domain. Password—Specify the password associated with the User name you entered. 6. Click Next to continue. 7.
l Server—Specify the name or IP address of the target server. You can click Browse to select a server from a network drill-down list. Note: If you enter the target server's fully-qualified domain name, the Storage Mirroring Console will resolve the entry to the server short name. If that short name resides in two different domains, this could result in name resolution issues. In this case, enter the IP address of the server.
l l l l VirtualCenter Server—Select your VirtualCenter server from the list. If your VirtualCenter server is not in the list, click Add VirtualCenter Server, specify the server and valid credentials, and click Add. If you are not using VirtualCenter, select None. ESX Server—Specify the name or IP address of the ESX server. User name—This field will only be available if you are not using VirtualCenter.
l l Select the volume on the target server—Select one of the volumes from the list to indicate which volume on the target where you want to store the new virtual server when it is created. The target volume must have enough Free Space to store the source data. The minimum size is noted at the bottom of the page. Full path where the replica virtual machine will be stored—Specify a location on the selected volume to store the replica of the source.
l l Select the datastore on the target ESX server—Select one of the volumes from the list to indicate where on the target you want to store the new virtual server when it is created. The target volume must have enough Free Space to store the source data. The minimum size is noted at the bottom of the page. Use pre-existing virtual disks—You can reuse an existing virtual disk on your ESX target, rather than having Storage Mirroring Recover create a virtual disk for you.
In order for Storage Mirroring Recover to find the pre-existing disk, the virtual disk file names must be formatted using the convention SourceServer_ DriveLetter. For example, if your source server is Alpha and you are protecting drives C and D, Storage Mirroring Recover will look for the file names Alpha_C.vmdk and Alpha_D.vmdk. If you are using IP addresses, substitute the IP address for the server name. For example, if the IP address for server Alpha is 172.31.10.
l l l l l Replica virtual machine display name—Specify the name of the replica virtual machine. This will be the display name of the virtual machine on the host system. Number of processors—Specify how many processors to create on the new virtual machine. The number of processors on the source is displayed to guide you in making an appropriate selection. If you select fewer processors than the source, your clients may be impacted by slower responses.
Gateways, and DNS Server addresses. If you do not specify any network configuration, the replica virtual machine will be assigned the same network configuration as the source. 17. Click Next to continue. 18. Configure the volumes on the replica virtual machine that will be created on the target. l Replica Disk Size—For each volume you are protecting, specify the size of the replica virtual machine on the target. Be sure and include the value in MB or GB for the disk.
Note: The system volume must be an IDE controller. In addition, up to two more volumes can be attached to an IDE controller. If you are protecting more than three volumes on the source, you will need to install the Hyper-V Integration Components to acquire a SCSI device. See your Hyper-V documentation for more information.
The fields on this screen will vary depending on if you are using an ESX target or a Hyper-V target. l l l l l l l Compress data at this level—Specify the level of compression that you want to use for your transmissions from the source to the target. If compression is enabled, the data is compressed before it is transmitted from the source. When the target receives the compressed data, it decompresses it and then writes it to disk.
where redundant interfaces and high-speed, reliable network links are available to prevent the false detection of failure. If the hardware does not support reliable communications, lower values can lead to premature failover. To achieve longer delays before failover, choose higher values. This may be necessary for servers on slower networks or on a server that is not transaction critical. For example, failover would not be necessary in the case of a server restart. 20. Click Next to continue. 21.
Protecting a Hyper-V server to a Hyper-V server Use these instructions to protect a virtual machine on a Hyper-V server or cluster, where you want to protect the host-level virtual disk files (the .vhd files), to a virtual server on a Hyper-V server. 1. Open the Storage Mirroring Console by selecting Start, Programs, Storage Mirroring, Storage Mirroring Console. 2. Click Get Started from the toolbar. 3. Select Storage Mirroring Recover and click Next. 4.
l l User name—Specify a user that is a member of the Double-Take Admin and local administrator security groups on the source. If you want to use a domain user account, enter a fully-qualified domain name in the format domain\username or username@domain. Password—Specify the password associated with the User name you entered. 6. Click Next to continue. 7. Choose the virtual machine on the Hyper-V source that you want to protect.
l Server—Specify the name or IP address of the Hyper-V target server. You can click Browse to select a server from a network drill-down list. Note: If you enter the target server's fully-qualified domain name, the Storage Mirroring Console will resolve the entry to the server short name. If that short name resides in two different domains, this could result in name resolution issues. In this case, enter the IP address of the server.
l Full path where the replica virtual machine will be stored—Specify a location on the selected Volume to store the replica of the source. By specifying an existing folder, you can reuse an existing virtual machine on your Hyper-V target created by a previous protection job. This can be useful for pre-staging data on a virtual machine over a LAN connection and then relocating it to a remote site after the initial mirror is complete.
l l l Replica virtual machine display name—Specify the name of the replica virtual machine. This will be the display name of the virtual machine on the host system. Map source virtual switches to target virtual switches—Identify how you want to handle the network mapping after failover. The Source Network Adapter column lists the virtual networks from the source. Map each one to a Target Network Adapter, which is a virtual network on the target.
be prompted to provide credentials for the virtual machine. Enter the DNS Name/IP Address, User name, and Password and click Save. l Advanced settings for network configuration—These options are only displayed if you have enabled the advanced settings and supplied valid credentials. For each Source virtual machine network adapter, you can specify Target IP addresses, Default Gateways, and DNS Server addresses.
the source. When the target receives the compressed data, it decompresses it and then writes it to disk. l l l l Limit bandwidth—Bandwidth limitations are available to restrict the amount of network bandwidth used for Storage Mirroring Recover data transmissions. When a bandwidth limit is specified, Storage Mirroring Recover never exceeds that allotted amount. The bandwidth not in use by Storage Mirroring Recover is available for all other network traffic.
l Require manual intervention before actually failing over—When selected, you will be prompted for failover when a failure condition is met. If this option is not selected, failover will automatically occur when a failure condition is met. 15. Click Next to continue. 16. The Protection Summary page displays all of the options you selected in your workflow. If you want to make any changes to any of the workflow settings, click Back to return to previous pages of the workflow.
Configuring Hyper-V Pro tip integration for failover notification Microsoft System Center Virtual Machine Manager (SCVMM) provides centralized administration for your Hyper-V virtual machines. Within SCVMM, Performance and Resource Optimization (PRO) provides a basic set of monitors that can alert you to situations where you may want or need to modify a virtual machine configuration in order to optimize the host or virtual machine.
Protecting an ESX server to an ESX server Use this process to protect a virtual machine on an ESX server, where you want to protect the host-level virtual disk files (the .vmdk files), to a virtual server on an ESX server. In this scenario, you have several steps to complete. 1. Port configuration—You must configure your ESX servers, your VirtualCenter server(s), and the machine running the Storage Mirroring Recover for Virtual Infrastructure service. These steps only need to be performed once. 2.
Configuring ports 1. Because the Storage Mirroring Recover for Virtual Infrastructure console uses SSH to communicate with the VMware ESX host(s), and the ESX hosts also use it to connect to each other, you must configure SSH port communication on both your source and target ESX servers. a. Using the VMware Virtual Infrastructure Client, select the host ESX server. b. On the Configuration tab, select Security Profile. c. In the Firewall Properties, verify that SSH Client is selected and click OK. d.
Configuring root or non-root login You must configure both your source and target ESX servers to allow either root or nonroot login. If you are not using VirtualCenter, you must use root account credentials. If you want to use non-root credentials, VirtualCenter is required. In addition to using nonroot credentials, VirtualCenter allows you to use VMotion to move the virtual machine. l Root account login—If you are not using VirtualCenter, you must use root account credentials. 1.
Establishing ESX to ESX protection 1. Open the Storage Mirroring Recover for Virtual Infrastructure console by selecting Start, Programs, Storage Mirroring, Recover, Storage Mirroring for Virtual Infrastructure. 2. If prompted, connect to the Storage Mirroring Recover for Virtual Infrastructure server. This prompt will appear if this is the first time you have accessed the console, if there are no valid, saved credentials, or if you have intentionally disconnected from a server.
l l Source VirtualCenter server—Select the VirtualCenter server that administrators the virtual machine you want to protect. If you are not using VirtualCenter, select None. Virtual machine to protect—Specify the name of the virtual server you want to protect. You can click Browse to select a server from a network drill-down list or to search for a server. Once you have specified a virtual server to protect, the IP address or DNS of the ESX server will be displayed.
l l User name—Specify the user account that will log in to the ESX server. Password—Specify the password associated with the User name you entered. 7. Click Next to continue. 8. Specify the target ESX server that will store the replica virtual machine. l l l l Target VirtualCenter server—Select the VirtualCenter server that administrators the target replica virtual machine.
l l Choose a target datastore—Select a datastore in the table that is large enough to hold the source virtual machine. The minimum size is noted at the bottom of the page. Enter the path for the replica virtual machine—Specify a location to store the replica of the source virtual machine. By default, the location will be named the source virtual machine name. Note: The replica virtual path cannot contain any of the following special characters.
3. Click View replica virtual machine disk mapping to determine the proper location on the target to copy the .vmdk files. 4. Copy the source .vmdk files to the target using the exact locations and filenames specified in the mapping file. Make sure that your copy method does not modify the size of the file. The size of the .vmdk files on the source and target must match. 5. Remove the original snapshot. 6. Modify the protection start time to begin immediately.
l l l l Map replica virtual network adapters to target VSwitches—Identify how you want to handle the network mapping after failover. The Source VSwitch column lists the virtual networks from the source. Map each one to a Target VSwitch, which is a virtual network on the target. Number of processors—Specify how many processors you want on the replica virtual machine. The number of processors on the source is displayed to guide you in making an appropriate selection.
may generate unpredictable results on the source and target virtual machines. Storage Mirroring Recover for Virtual Infrastructure supports generic SCSI device mappings in virtual machines, however, the generic SCSCI device will not be created on the target virtual machine during failover because the target virtual machine will fail to start if the SCSI device hardware does not exist on the target ESX host.
Optional ESX protection settings Optional protection settings are available when configuring an ESX to ESX protection job, but they are not required. The options are available at the end of the workflow when you are establishing protection or from the Monitor protection page when you click Configure Protection.
Scheduling protection 1. From the Protection summary page, click Schedule. 2. If you want to start the protection immediately, select Start this protection immediately. 3. If you want to delay the start of the protection, select Schedule this protection to start. 4. Select a date and time for the protection job to start. 5. Click Save.
Changing the name of the protection job 1. From the Protection summary page, click Change in the Name section. 2. Specify a new name for the protection job. 3. Click Save.
Setting transmission options 1. From the Protection summary page, click Change in the Data transmission section. 2. Specify any of the following data transmission options. l l l Chose when to use compression—Specify the level of compression you want to use. Compression reduces the amount of bandwidth needed to transmit data from the source to the target. The data is compressed before being transmitted and then is uncompressed before it is written on the target.
l Limit bandwidth—Bandwidth limitations are available to restrict the amount of network bandwdith used for Storage Mirroring Recover for Virtual Infrastructure data transmissions. When a bandwidth limit is specified, Storage Mirroring Recover for Virtual Infrastructure never exceeds that allotted amount. The bandwidth not in use by Storage Mirroring Recover for Virtual Infrastructure is available for all other network traffic. Enter a value in kilobits per second to limit data transmission.
E-mailing notifications 1. From the Protection summary page, click Change in the E-mail notifications section. Note: In order to use e-mail notification, you may need to complete any or all of the following on the Storage Mirroring Recover for Virtual Infrastructure server. l Disable anti-virus software l Open port 25 in your anti-virus software to allow SMTP e-mail l Enable outbound e-mail messages l Exclude VI_Service.exe from blocked processes for sending outbound email messages. 2.
Updating VirtualCenter credentials 1. If you configured VirtualCenter servers when you established protection, you can select Change in the VirtualCenters section on the Protection Summary page. 2. Modify the User name and Password associated with either the source or target VirtualCenter server. The changes will be applied to this protection job only. 3. Click Save.
Configuring restart and threshold options 1. From the Protection summary page, click Change in the Restart and thresholds section. 2. Specify any of the following options. l l Restart this protection automatically if there is a problem—This option specifies if Storage Mirroring Recover for Virtual Infrastructure will attempt to restart the protection job if there is a problem. If you enable this option, specify the Number of times to attempt to restart.
Using firewalls with virtual workloads If your source and target are on opposite sides of a firewall, you will need to configure your hardware to accommodate communications. You must have the hardware already in place and know how to configure the hardware ports. If you do not, see the reference manual for your hardware. These firewall instructions are for the following protection scenarios.
Virtual workload ports By default, Storage Mirroring Recover uses port 6320 for all TCP and UDP communications. To verify or modify the ports, you must use the Replication Console. 1. Open the Replication Console. 2. Locate your servers in the server tree in the left pane of the Replication Console. 3. Right-click the server in the left pane of the Replication Console and select Properties. 4. On the Network tab, verify or modify the Communications Port as needed.
Microsoft Windows ports Virtual workload protection uses WMI (Windows Management Instrumentation) which uses RPC (Remote Procedure Call). By default, RPC will use ports at random above 1024, and these ports must be open on your firewall. RPC ports can be configured to a specific range by specific registry changes and a reboot. See the Microsoft Knowledge Base article 154596 for instructions. Virtual workload protections also rely on other Microsoft Windows ports.
Hardware ports You need to configure your hardware so that the Storage Mirroring Recover ports and Microsoft Windows ports are open. Since communication occurs bidirectionally, make sure you configure both incoming and outgoing traffic. There are many types of hardware on the market, and each can be configured differently. See your hardware reference manual for instructions on setting up your particular router.
Cluster protection Your cluster protection will depend on the type of cluster configuration you are using. l l Standard cluster configuration—If you are using a standard cluster, where a single copy of data resides on a SCSI disk that is shared between cluster nodes, you will be using the Double-Take Source Connection cluster resource to protect your cluster.
Protecting a standard cluster Use the following steps to protect a standard cluster, where a single copy of data resides on a SCSI disk that is shared between cluster nodes. You will be using the Double-Take Source Connection cluster resource to protect your standard cluster. 1. If your source is a cluster, create a virtual server (including resources for an IP address, network name, and physical disk) on the source cluster.
Note: If your source is a cluster, you need to create the replication set on the node which currently owns the group with the virtual server you want to protect. a. Open the Replication Console. b. Right-click the source in the left pane of the Replication Console and select New, Replication Set. c. A replication set icon appears in the left pane under the source. By default, it is named New Replication Set.
f. After selecting the data for this replication set, right-click the new replication set icon and select Save. A saved replication set icon will change from red to black. 4. If your source is a cluster, you need to create a duplicate replication set on each of the other nodes in the cluster. Because the other nodes do not currently own the files, you will not be able to browse to select the data like you did on the first node. Therefore, you will have to manually enter the replication set data.
b. Record the exact drive and directories of each path displayed, including where the rule is included or excluded and if recursion is applied. c. Right-click a non-owning node and select New, Replication Set. d. Enter the exact, case-sensitive name for the replication set as specified on the owning node and press Enter. e. Right-click the replication set that you just created and select Properties. f. Click Add. g. Enter the exact same replication set rules you recorded from the owning node.
5. On your cluster (source and/or target), you need to disable the standard Storage Mirroring Recover connection controls so that the MSCS resource that you will be configuring later can control the Storage Mirroring Recover connections. a. In the Replication Console, right-click a node of the source cluster and select Properties. b. Select the Setup tab. c. By default, the Automatically Reconnect During Source Initialization check box will be selected. Disable this option by clearing the check box. d.
7. If your source is a cluster, establish your connection by creating and bringing online a Double-Take Source Connection resource. These instructions will vary depending on your operating system.
Establishing your connection on Windows 2003 1. From the Cluster Administrator, right-click on the group and virtual server you are protecting and select New, Resource. l l l l Name—Specify a name that indicates this is the Storage Mirroring Recover virtual server connection. Description—You can optionally add a more detailed description for this resource. Resource type—Specify Double-Take Source Connection. Group—The resource group name should be selected. If it is not, select the correct group name.
l l l l Replication Set—Select the Storage Mirroring Recover replication set that you want to use. If the replication set you want to use is not listed, click Update List to refresh the list of replication sets from the source. Double-Take Target—Specify the name or IP address of the target. If your target is a cluster, this is the virtual name or virtual IP address of the virtual server you created on the target cluster.
l Fixed Bandwidth Limit—Data will be transmitted according to the userspecified bandwidth configuration. By default, the Unlimited checkbox is enabled. This configuration is identical to selecting No Bandwidth Limit. If you want to limit your bandwidth usage, clear this checkbox. To limit the bandwidth usage, enter the maximum amount of data you want to transfer per second.
l File differences—Only those files that are different based size or date and time will be sent from the source to the target. l Send data only if Source is newer than Target—Only those files that are newer on the source are sent to the target. Note: If you are using a database application, do not use the newer option unless you know for certain you need it. With database applications, it is critical that all files, not just some of them that might be newer, get mirrored.
l l l Initial Verification Start—Specify when you want a verification process to be performed. You can select the immediate date and time by clicking Now, or enter a specific Date and Time. The down arrow next to Date displays a calendar allowing easy selection of any date. Time is formatted for any AM or PM time. Reverification Interval—Select this option to repeat the verification process at the specified interval. Specify an amount of time and choose minutes, hours, or days.
Establishing your connection on Windows 2008 1. From the Failover Cluster Management applet, right-click on the group and virtual server you are protecting and select Add a resource, More resources, Add Double-Take Source Connection. 2. Right-click on the new resource and select Properties. 3. On the General tab, specify a Resource Name that indicates this is the Storage Mirroring Recover virtual server connection. 4. Select the Dependencies tab.
l l l l Replication Set—Select the Storage Mirroring Recover replication set that you want to use. If the replication set you want to use is not listed, click Update List to refresh the list of replication sets from the source. Double-Take Target—Specify the name or IP address of the target. If your target is a cluster, this is the virtual name or virtual IP address of the virtual server you created on the target cluster.
l l No Bandwidth Limit—Data will be transmitted using all available bandwidth. Fixed Bandwidth Limit—Data will be transmitted according to the userspecified bandwidth configuration. By default, the Unlimited checkbox is enabled. This configuration is identical to selecting No Bandwidth Limit. If you want to limit your bandwidth usage, clear this checkbox. To limit the bandwidth usage, enter the maximum amount of data you want to transfer per second.
8. Select the Orphans tab and specify your Storage Mirroring Recover orphan file parameters. By default, the orphan files feature is disabled. To enable it, select Move/Delete Orphan Files. Specify if you want to delete or move the files. If you select the move option, identify the location where these orphan files will be located.
9. Select the Compression tab and specify your Storage Mirroring Recover compression parameters. By default, compression is disabled. To enable it, select Enable Compression. Depending on the compression algorithms available for your operating system, you may see a slider bar indicating different compression levels. Set the level from minimum to maximum compression to suit your needs.
10. Select the Mirror Properties tab and specify how you want to mirror the data. l l Full Mirror—All files in the replication set will be sent from the source to the target. File differences—Only those files that are different based size or date and time will be sent from the source to the target. l Send data only if Source is newer than Target—Only those files that are newer on the source are sent to the target.
applications, it is critical that all files, not just some of them that might be newer, get mirrored. l l Use block checksum—For those files flagged as different, the mirror performs a checksum comparison and only sends those blocks that are different. Calculate Replication Set size prior to mirror—Determines the size of the replication set prior to starting the mirror. The mirroring status will update the percentage complete if the replication set size is calculated. 11.
calendar allowing easy selection of any date. Time is formatted for any AM or PM time. l l Reverification Interval—Select this option to repeat the verification process at the specified interval. Specify an amount of time and choose minutes, hours, or days. Remirror files to the target automatically—When this option is enabled, Storage Mirroring Recover will verify the data, generate a verification log, and remirror to the target any files that are different on the source.
Protecting a GeoCluster The GeoCluster Replicated Disk resource allows for the real-time copy of data to be available on other nodes in the cluster. In the event of a failure and another node takes ownership, the GeoCluster Replicated Disk resource is also moved to the other node and it continues to replicate data, in real-time, to the remaining nodes in the cluster. The instructions for creating this resource are different depending on your operating system.
Creating the GeoCluster Replicated Disk Resource on Windows 2003 1. Select Start, Programs, Administrative Tools, Cluster Administrator. 2. Right-click the group that you want to add a replicated disk to and select New, Resource. 3. Specify the following fields on the New Resource dialog box. l l l l Name—Specify a name that identifies which application, file set, disk, and so on that you are protecting. This name must be unique within the cluster.
Mirroring Recover and your public traffic. If you have three routes, separate the public traffic and then separate Storage Mirroring Recover from the cluster heartbeat. l Orphan files—An orphan is a file that exists in the target location but is not in the source location. You can enable the resource to remove or delete orphans during a mirror. If you choose to move orphan files, specify the location where you want to move them.
Creating the GeoCluster Replicated Disk Resource on Windows 2008 1. Select Start, Programs, Administrative Tools, Failover Cluster Management. 2. Right-click the application group where you want to add a replicated disk to and select Add a resource, More resources, Add GeoCluster Replicated Disk. 3. Right-click on the resource and select Properties. 4. On the Connection Parameters tab, specify the GeoCluster Replicated Disk connection parameters using the settings below.
l l Delay connection until resources dependent on this one are online— This option allows you to delay a Storage Mirroring Recover connection until any resources that have the GeoCluster Replicated Disk resource as a dependency are online.
Bringing the resource online The GeoCluster Replicated Disk resource will appear offline after it is created. When you bring it online, the following actions occur. 1. A Storage Mirroring Recover replication set is created with the same name that was assigned to the resource. 2. The replication set is connected to all of the possible owners specified in the resource. 3. A mirror is initiated to create the baseline copy of data from the active node to all of the possible owners. 4.
Taking the resource offline When you take the GeoCluster Replicated Disk resource offline, the following actions occur. 1. Real-time replication from the active node to the possible owners stops. 2. The read-only limitation is removed from the corresponding drive letters on the possible owners. 3. The replication set is disconnected from all of the possible owners. 4. The replication set is deleted. If you are using Windows 2003, right-click the resource and select Take offline.
GeoCluster resource properties Resource properties are displayed differently in Windows 2003 and Windows 2008. For example, the possible owners of a resource is listed on the General tab of the resource properties in Windows 2003, while in Windows 2008 they are listed on the Advanced Policies tab. For both operating systems, right-click the resource and select Properties, when you want to view or modify the resource properties.
GeoCluster Replicated Disk properties on Windows 2003 There are six properties tabs for the GeoCluster Replicated Disk resource on Windows 2003. 1. General—This tab identifies the Name and Description of the resource and the Possible Owners. If you change the name of the resource, the replication set name will not change until the next time the resource is brought online. The GeoCluster Replicated Disk resource must have at least two possible owners to function properly.
to remain in a pending state before it fails. If the resource takes longer than the time specified to be brought online or taken offline, the resource fails. For more information on the Advanced Settings options, see your Windows documentation. 4. Connection parameters—This tab controls disk replication, network routing, and orphan files for GeoCluster.
algorithms available for your operating system, you may see a slider bar indicating different compression levels. Set the level from minimum to maximum compression to suit your needs. 6. Mirror Properties—This tab controls the Storage Mirroring Recover mirroring process. l l Full Mirror—All files in the replication set will be sent from the source to the target. File differences—Only those files that are different based size or date and time will be sent from the source to the target.
GeoCluster Replicated Disk properties on Windows 2008 There are eight properties tabs for the GeoCluster Replicated Disk resource on Windows 2008. 1. General—This tab identifies the Name and Resource type of the resource. It also displays the current state of the resource and an additional detailed status message. 2. Dependencies—By default, the GeoCluster Replicated Disk resource is not dependent on any other resources. 3. Policies—This tab controls how and when MSCS handles a failure of the resource.
The GeoCluster Replicated Disk resource must have at least two possible owners to function properly. l l l Basic resource health check interval—This setting is formerly known as the Looks Alive poll interval. It specifies how often the resource is polled to determine whether it is still running on the active node. You can choose the standard time period of 5 seconds, or you can specify your own value. Thorough resource health check interval—This setting is formerly known as the Is Alive poll interval.
are attempting to open files exclusively while GeoCluster is mirroring those files is removed. l Enable orphans—An orphan is a file that exists in the target location but is not in the source location. You can enable the resource to remove or delete orphans during a mirror. If you choose to move orphan files, specify the location where you want to move them. You should not select the system volume for the orphan files because it could impact the stability of the cluster service. 6.
Configuring failover monitoring If you are configuring failover monitoring for a cluster workload, use the same process for a data workload, except note the following changes. l l If your source is a cluster, you must use the Custom option when identifying the source machine and specify the virtual network name and virtual IP address on the source cluster. You must use a pre-failback and post-failover script.
Special configurations Storage Mirroring Recover can be implemented with very little configuration necessary in small or simple networks, but additional configuration may be required in large or complex environments. Because an infinite number of network configurations and environments exist, it is difficult to identify all of the possible configurations. Select a link to review configuration information for particular network environments.
Domain controllers Failover of domain controllers is dependent on the Storage Mirroring Recover functionality you are using. l l l Domain controller role—If you want to failover a domain controller, including the roles of the domain controller, you should create full-server or virtual workload protection. Non-domain controller role—If you are only protecting data, you can failover a domain controller, but the roles of the domain controller are not included.
NetBIOS Because NetBIOS is not available on Windows 2008, if you are using Windows 2008 in a workgroup environment and do not have DNS host records, there may be a delay of up to five minutes before the failed over source server name is available for client access. See About the NetBIOS Interface in the MSDN library.
WINS When Storage Mirroring Recover failover occurs, Windows initiates WINS registration with the target’s primary WINS server to associate the source server’s name with the target’s primary IP address. In an environment with just one WINS server, no additional processing is required. In an environment with more than one WINS server, WINS replication will distribute the updated WINS registration to other WINS servers on the network.
WINS registration WINS registration can be added to your failover and failback scripts by using the Windows NETSH command with the WINS add name context. Add the following command to your failover and failback scripts for each additional WINS server in your environment (excluding the target’s primary WINS server). netsh wins server wins_server_IP_address add name Name=source_server_name RecType=1 IP={IP_address} Use the following variable substitutions.
WINS replication WINS replication can be added to your failover and failback scripts by using the Windows NETSH command with the WINS set replicate context. Add the following command to your failover and failback scripts. netsh wins server target’s_primary_wins_server_IP_address set replicateflag 1 Use the following variable substitution. l target's_primary_wins_server_IP_address—The IP address of the target's primary WINS server For example, suppose you had the following environment.
DNS If you are using a Microsoft DNS server, when Storage Mirroring Recover failover occurs, DNS is not automatically updated. If the end-users use DNS to resolve server names and the source IP address was not failed over to the target, additional DNS updates will be required because the host records for the source will remain intact after failover. You can automate this process by scripting the DNS updates in the failover and failback scripts. You have two options for scripting the DNS updates.
Windows DNSCMD command DNS updates can be added to your failover and failback scripts by using the Windows DNSCMD command as long as dynamic updates are enabled on the DNS zone and the account running the Storage Mirroring service is a member of the DNSAdmins security group. (See your Microsoft documentation to verify if dynamic updates are enabled.
l Fully qualified domain name of the DNS server—DNSServer.domain.com l DNS zone—domain.com You would add the following to your failover script to delete the host and reverse lookup entries and add new entries associating the source to the target. dnscmd DNSServer.domain.com dnscmd DNSServer.domain.com alpha.domain.com /f dnscmd DNSServer.domain.com dnscmd DNSServer.domain.com /RecordDelete domain.com alpha A 192.168.1.108 /f /RecordDelete 192.168.in-addr.arpa 108.1 PTR /RecordAdd domain.
Storage Mirroring Recover DFO utility DNS updates can be added to your failover and failback scripts by using the Storage Mirroring Recover DFO utility as long as the utility has been registered and the proper privileges are configured. 1. Extract the DFO utility to the location where the Storage Mirroring Recover program files are installed on the target. 2.
syntax.
l l l l l l l l l l l l l Workload protection PASSWORD password—The password associated with the user account DNSZONE zone_name—The name of the DNS zone or DNS container, used to refine queries DNSDOMAIN domain_name—The name of the DNS domain, used to refine queries LOGFILE file_name—The name of the log file FAILBACK fb_switch—Denotes a failback procedure, performed after a failed source is recovered or restored (required for failback).
l l l l l ADDOMAIN active_directory_domain_name—The name of the Active Directory domain SOURCEDN source_domain_name—The name of the source's domain TEST—Runs in test mode so that modifications are not made, only listed DEBUG—Forces DFO to write the DNS resource record as-is to the dfolog.log file prior to any DFO modify or list activity. HELP—Displays the syntax of the DNS Failover utility Examples l l l l l l Workload protection dfo /dnssrvname gamma.domain.com /srcname alpha.domain.
Non-Microsoft DNS If you are using a non-Microsoft DNS server (such as Unix) or if you are in a non-domain configuration (such as a workgroup), when Storage Mirroring Recover failover occurs, DNS is not automatically updated. If the end-users use DNS to resolve server names and the source IP address was not failed over to the target, additional DNS updates will be required because the host records for the source will remain intact after failover.
11. Add the following line to the failback script file, substituting your Storage Mirroring Recover directory for install_location. nsupdate.exe "c:\install_location\dnsback.txt" 12. Save the failback script file. 13. Create a text file, called dnsback.txt in the Storage Mirroring Recover directory. 14. Add the following lines to the dnsback.txt file, substituting your target name, fullyqualified domain name, source name, and source IP address as appropriate. update delete target_server_name.
Macintosh shares A share is any volume, drive, or directory resource that is shared across a network. During failover, the target can assume or add any source shares so that they remain accessible to the end users. Automatic share failover only occurs for standard Windows file system shares. Other shares, including Macintosh volumes, must be configured for failover through the failover scripts or created manually on the target. 1. On your target, set the File Server for Macintosh service to manual startup.
rem The following command starts the File Server for Macintosh service net start "File server for Macintosh" rem The following command changes the name of the server back to its rem original name. You will need to replace :\\ with rem the location of your Storage Mirroring Recover chngname utility. \\chngname /t In the event of a failure, the Macintosh clients must remap the volume in order to access it.
NFS Shares A share is any volume, drive, or directory resource that is shared across a network. During failover, the target can assume or add any source shares so that they remain accessible to the end users. Automatic share failover only occurs for standard Windows file system shares. Other shares, including NFS shares, must be configured for failover through the failover scripts or created manually on the target. 1. On your target, set the NFS service to manual startup.
Workload monitoring Once a workload protection is established you will want to monitor the protection. You can monitor the workload protection using the same Storage Mirroring Recover client that you used to establish the workload protection, or you can use several general monitoring tools that are available for all workload types.
Data workloads When you are working with data workloads, you can monitor the connection and you can monitor the status of failover monitoring.
Monitoring a data workload When a source is highlighted in the left pane of the Replication Console, the connections and their statistics are displayed in the right pane. Additionally, colors and icons are used for the connections, and the Storage Mirroring Recover servers, to help you monitor your connections.
Connection statistics 1. You can change the statistics that are displayed by selecting File, Options and selecting the Statistics tab. 2. The statistics displayed in the Replication Console will be listed with check boxes to the left of each item. Mark the check box to the left of each statistic that you want to appear, and clear the check box to the left of each statistic that you do not want to appear. 3. The statistics appear on the Replication Console in the order they appear on the Statistics tab.
Target Data State l l l l l OK—The data on the target is in a good state. Mirroring—The target is in the middle of a mirror process. The data will not be in a good state until the mirror is complete. Mirror Required—The data on the target is not in a good state because a remirror is required. This may be caused by an incomplete or stopped mirror or an operation may have been dropped on the target. Restore required—The data on the source and target do not match because of a failover condition.
Mirror Status l Mirroring—If the file size of the replication set has not been calculated and the data is being mirrored to the target machine, the Mirror Status will indicate Mirroring. l Idle—Data is not being mirrored to the target machine. l Paused—Mirroring has been paused.
Sent (Bytes) The sent (bytes) statistic indicates the total number of mirror and replication bytes that have been transmitted to the target. Sent Compressed (Bytes) The sent compressed (bytes) statistic indicates the total number of compressed mirror and replication bytes that have been transmitted to the target. If compression is disabled, this statistic will be the same as sent (bytes).
compression is disabled, this statistic will be the same as sent mirror (bytes). Skipped Mirror (Bytes) The skipped mirror (bytes) statistic is the total number of bytes that have been skipped when performing a difference or checksum mirror. These bytes are skipped because the data is not different on the source and target machines. Remaining Mirror (Bytes) The remaining mirror (bytes) statistic is the total number of mirror bytes that are remaining to be sent to the target.
Connection and server display You can configure when the icons and colors change to accommodate your network environment. For example, a slow or busy network may need longer delays before updating the icons or colors. 1. Select File, Options. On the Configuration tab, you will see Site Monitor and Connection Monitor. The Site Monitor fields control the icons on the left pane of the Replication Console and the icons on the right pane when a group is highlighted in the left pane.
—A red X on a server icon indicates the Replication Console cannot communicate with that server or there is a problem with one of the server’s connections. If the connection background is gray, it is a communication issue. If the connection also has a red X, it is a connection issue. —Two red vertical lines on a server icon indicates the target is paused. —A red tree view (folder structure) on a server icon indicates a restore is required because of a failover.
once communications have stopped. Once communications have been reestablished, the connection background will change back to white. The following icons are displayed in the right pane when a group is highlighted in the left pane. —An icon with a network cable between two servers on the right pane indicates there are no established Storage Mirroring Recover connections to this server. This icon also indicates that communications between the Replication Console and the server are working properly.
Monitoring failover monitoring Since it can be essential to quickly know the status of failover monitoring, Storage Mirroring Recover offers various methods for monitoring failover monitoring.
The Failover Control Center does not have to be running for failover to occur. The following table identifies how the visual indicators change when the source is online. Time to Fail Countdown The Time to Fail counter is counting down and resetting each time a response is received from the source machine. Status Bar The status bar indicates that the target machine is monitoring the source machine. Colored Bullets The bullets are green.
Status Bar The status bar displays the source machine and IP address currently being assumed by the target. Colored Bullets The bullets are red. Desktop Icon Tray The Windows desktop icon tray contains a failover icon with red and green computers. The following table identifies how the visual indicators change when failover is complete. Time to Fail Countdown The Time to Fail counter is replaced with a failed message. Status Bar The status bar indicates that monitoring has continued.
Monitoring a full-server workload After you have enabled full-server protection, you can monitor the protection from the Full-Server Failover Manager, and you can review the log file generated by Full-Server Failover Manager. The Protection Status is displayed in the right center of the Full-Server Failover Manager. You can tell the status of your protection from this field. l l l l l l l l l l Disabled—Protection for the source has not been started.
determine the status of the source. If the source is still up and users are accessing it, you need to resolve the communications errors between the source and target. Once the communication issue is resolved, the status will update to the appropriate state. If the source is indeed down and users are unable to access it, start failover. l l Failing over (% complete)—The target is in the process of failing over for the source. The percentage indicates how much of the failover has been completed.
Monitoring an application workload After you have enabled application protection, you can monitor the protection from the Application Manager Monitor tab.
l l Restoring—Data is being restored from the target to the source Unknown—The mirror status could not be determined Mirror Remaining The percentage of the mirror remaining Replication Status l Replicating—Data is being replicated to the target machine l Ready—There is no data to replicate to the target machine l Stopped—Replication has stopped l Out of Memory—Kernel memory has been exhausted Transmit Mode l Started—Data is being transferred to the target machine l Paused—Data transmission has
l Target path unblocked—Target path blocking is disabled l Unknown—The state could not be determined Connected Since The date and time indicating when the current connection was made Transmitted The amount of data transmitted from the source to the target Compressed The amount of compressed data transmitted from the source to the target Source Queue The amount of data in queue on the source Target Queue The amount of data in queue on the target Workload monitoring Page 373 of 677
Monitoring virtual workloads When you are working with virtual workloads, you can monitor the connection and you can monitor the status of failover monitoring. If you are protecting host-level virtual disk files (the .vmdk files) from an ESX source to an ESX target, you will need to use the Storage Mirroring Recover for Virtual Infrastructure console to monitor your protection. For all other virtual workloads, use the Storage Mirroring Console to monitor your protection.
Monitoring virtual workloads in the Storage Mirroring Console Click Monitor Connections from the main Storage Mirroring Console toolbar. The Monitor Connections page allows you to view information about your connections. You can also manage your connections from this page.
Overview connection information displayed in the top pane The top pane displays high-level overview information about your connections. Column 1 (Blank) The first blank column indicates the state of the connection. The connection is in a healthy state. The connection is in a warning state. The connection is in an error state. The connection is in an unknown state. Connection The name of the connection Source Server The name of the source.
l l Percentage Complete—If the amount of data to be mirrored has been calculated and data is actively being mirrored to the target, the Mirror Status will display the percentage of data that has been sent. Waiting—Mirroring is complete, but data is still being written to the target. l Idle—Data is not being mirrored. l Paused—Mirroring has been paused. l Stopped—Mirroring has been stopped. l Removing Orphans—Orphan files on the target are being removed or deleted depending on the configuration.
Filtering the connections displayed in the top pane You can filter the connections displayed in the top pane using the toolbar buttons in that pane. View Connection Details Leave the Monitor Connections page and open the View Connection Details page Filter Select a filter option from the drop-down list to only display certain connections. You can display Healthy Connections, Connections with warnings, or Connections with errors. To clear the filter, select All connections.
Detailed connection information displayed in the bottom pane The details displayed in the bottom pane of the Monitor Connections page will depend on the type of protection workload that is highlighted in the top pane. Name The name of the server Activity There are many different Activity messages that keep you informed of the connection activity. Most of the activity messages are informational and do not require any administrator interaction. If you see error messages, check the connection details.
Protection status The status of the workload protection Protected volumes The volumes that are being protected Target datastore or Target path The location on the target where the source replica is being stored Automatic failover Indicates if failover will be automatic and the number of retries that have been attempted if the source is unresponsive Workload monitoring Page 380 of 677
Connection controls available in the bottom pane The connection controls available in the bottom pane of the Monitor Connections page will depend on the type of protection workload that is highlighted in the top pane. Configure Opens the Protection Summary page Delete Removes configuration information for the selected connection If you no longer want to protect the source and no longer need the replica of the source on the target, select the appropriate delete option when prompted.
Stop protection Stops the selected connection Failover Initiate failover by shutting down the source and starting the replica of the source on the target Undo Failover For some workload types, you can undo failover after it has occurred. This resets the servers and the job back to their original state. Reverse protection For some workload types, you can reverse the protection. The connection will start mirroring in the reverse direction with the connection name and log file names changing accordingly.
Viewing connection details The View Connection Details page allows you to view information about a specific connection. Connection name The name of the connection Description The connection status Health The connection is in a healthy state. The connection is in a warning state. The connection is in an error state. The connection is in an unknown state. Activity There are many different Activity messages that keep you informed of the connection activity.
Target data state l l l l l OK—The data on the target is in a good state. Mirroring—The target is in the middle of a mirror process. The data will not be in a good state until the mirror is complete. Mirror Required—The data on the target is not in a good state because a remirror is required. This may be caused by an incomplete or stopped mirror or an operation may have been dropped on the target. Restore required—The data on the source and target do not match because of a failover condition.
l l l Mirroring—If the file size of the replication set has not been calculated and the data is being mirrored to the target machine, the Mirror Status will indicate Mirroring. Percentage Complete—If the file size of the replication set has been calculated and the data is being mirrored to the target machine, the Mirror Status will display the percentage of the replication set that has been sent. Waiting—Mirroring is complete, but data is still being written to the target.
l l Failed—The Storage Mirroring service is not receiving replication operations from the Storage Mirroring driver. Check the Event Viewer for driver related issues. Unknown—The console cannot determine the status.
Monitoring virtual workloads in the Storage Mirroring Recover for Virtual Infrastructure console Select Monitor protection from the left pane of the console. The Monitor protection page allows you to view information about your connections. You can also manage your connections from this page.
Overview connection information displayed in the top pane The top pane displays high-level overview information about your connections. Name The name of the connection Status A description of the current status of the protection Bytes Pending The remaining amount of data (.
Detailed connection information displayed in the bottom pane When the View protection details button in the toolbar is toggled on, the bottom pane displays detailed connection information.
Connection controls The connection controls are available in the toolbar of the Monitor protection page. —Opens the Protection Summary page allowing you to modify some protection settings. —Deletes the selected connection. You will be prompted to keep or delete the associated replica virtual machine on the target. If you do not need the replica on the target, you can delete it.
Monitoring a cluster workload In a standard cluster configuration, where a single copy of data resides on a SCSI disk that is shared between cluster nodes, the Double-Take Source Connection resource keeps the data synchronized between your source and target. Use the standard Windows cluster tools to monitor the status of the resource.
Resolving an online pending GeoCluster Replicated Disk resource When the GeoCluster Replicated Disk resource is in an online pending state, you are protected from possible data corruption. If you are using Windows 2003, review the description of the GeoCluster Replicated Disk Status resource to see why the GeoCluster Replicated Disk resource is in the online pending state.
Windows 2008 Menu Discard Queue Description If you have data in the target queue, you can discard that data. If you discard the queued data, you will lose the changes associated with that data made on the previously owning node. A Storage Mirroring Recover connection will be established to replicate the node’s data (without the data that was in queue) to the other nodes.
Windows 2003 Menu Accept Data Windows 2008 Menu Accept Description If you accept the data, the current data on the node will be used, and a Storage Mirroring Recover connection will be established to replicate the current node’s data to the other nodes. If any other nodes in the cluster contain more recent data, this node will overwrite that data and it will be lost.
GeoCluster Replicated Disk Status Resource The function of the GeoCluster Replicated Disk Status resource (also displayed as GRD Status) varies between Windows 2003 and Windows 2008. In both operating systems, it is automatically created when the first GeoCluster Replicated Disk resource is created in a group. Once the status resource is created, it will exist as long as there is a GeoCluster Replicated Disk resource in the group.
Log files Various Storage Mirroring Recover components (Storage Mirroring service, Replication Console, Failover Control Center, and the Command Line Client) generate a log file to gather alerts, which are notification, warning, and error messages. The log files are written to disk. Each log file consists of a base name, a series number, and an extension. l l l Base Name—The base name is determined by the application or process that is running.
Viewing the log file You can view the Storage Mirroring Recover log file through the Replication Console or through any text editor. You can view any of the other component log files through any text editor.
Viewing the log file through the Replication Console 1. Open a new message window using any of the following methods. l l l Right-click on the server that you want to monitor in the left pane and select New, Message Window. Select the Message Window icon from the toolbar. Select Monitor, New Message Window and identify the Server that you want to monitor. 2. Repeat step 1 if you want to open multiple message windows. Note: The standard appearance of the message window is a white background.
3. To control the window after it is created, use one of the following methods to access the control methods listed in the following table. l Right-click on the message window and select the appropriate control. l Select the appropriate toolbar control. l Select Monitor, the name of the message window, and the appropriate control. Close Closes the message window Clear Clears the message window Pause/Resume Pauses and resumes the message window.
4. To change which server you are viewing messages for, select a different machine from the drop down list on the toolbar. If necessary, the login process will be initiated. 5. To move the message window to other locations on your desktop, click and drag it to another area or double-click it to automatically undock it from the Replication Console.
Viewing the log file through a text editor The log files can be viewed, from the location where Storage Mirroring Recover is installed, with a standard text editor. The following list describes the information found in each column of the log file. 1. Date the message was generated 2. Time the message was generated 3. Process ID 4. Thread ID 5. Sequence number is an incremental counter that assigns a unique number to each message 6.
Mirroring Servers 09/11/2010 12:45:53.9580 704 1032 3 2 0 Adding default group: Storage Mirroring Servers\ Auto-Discovered Servers 09/11/2010 12:46:08.3390 704 1032 4 210004 Evaluation license expires in 95 day(s).
Filtering the log file Log file output can be filtered using the LogViewer utility. Use the LogViewer command from the directory where Storage Mirroring Recover is installed.
l NOID—Does not display the LogViewer ID in the output l HELP—Displays the command options l LogViewer -type 2 l LogViewer -include 200,400-500,10000-15000 Examples Notes The default setting is -type 2 which displays both type 1 and 2 messages.
Configuring the properties of the log file 1. To modify the maximum file size and the number of Storage Mirroring Recover log files that are maintained, access the Server Properties dialog box by right-clicking a machine name in the left pane of the Replication Console and selecting Properties. 2. Select the Logging tab. 3. At the top of the window, Folder indicates the directory where the log files are located. The default is the directory where the Storage Mirroring Recover program files are installed. 4.
Storage Mirroring Recover log messages The following list describes some of the standard Storage Mirroring Recover alerts that may be displayed in the log files. Note: In this information, con_id refers to the unique connection ID assigned to each connection between a source replication set and a target. There are several log messages with the ID of 0. See the description in the Message column in the log file. 7 Synchronous ioctl returned STATUS_PENDING 7 Failed to reset Replication Flags.
73 Connected to ip://xxx.xxx.xxx.xxx A source machine has successfully connected a replication set to a target machine. 74 Connection paused with ip://xxx.xxx.xxx.xxx A network connection between the source and the target exists and is available for data transmission, but data is being held in queue and is not being transmitted to the target. This happens because the target machine cannot write data to disk fast enough.
81 Schedule transmit start to target A scheduled transmission of data from a source machine to a target machine has started. See the description in the Message column in the log file. 82 Schedule transmit end to target A scheduled transmission of data from a source machine to a target machine has ended. See the description in the Message column in the log file.
94 Verification started con_id The verification process of confirming that the Storage Mirroring Recover data on the target is identical to the data on the source has started. 95 Verification ended con_id The verification process of confirming that the Storage Mirroring Recover data on the target is identical to the data on the source has ended. 97 Restore started con_id The restoration process of copying the up-to-date data from the target back to the original source machine has started.
10003 Activation code violation with machine machine_name Duplicate single-server activation codes are being used on the servers, and Storage Mirroring Recover is disabled. 10004 Valid activation key detected A valid activation code was identified when the Storage Mirroring service was started. 51001 Source module failed to load The Storage Mirroring Recover source module failed to load. Look at previous log messages to determine the reason.
l (112) Disk full: The disk to which data is being written on the target is full. This issue may be resolved by deleting files on the target machine or by adding another disk. 52501 Target module loaded successfully The Storage Mirroring Recover target module was loaded successfully. 52502 Target module already loaded The Storage Mirroring Recover target module was already loaded. 52503 Target module stopped The Storage Mirroring Recover target module stopped.
503010 Asyncloctl for status thread 178 terminated, terminating the status thread A Storage Mirroring Recover process monitors the state of the Storage Mirroring Recover driver. When the Storage Mirroring service is shut down, the driver is shut down, and this process is terminated. (No user action required.) 600002 Unified login provides ADMIN access 600002 User has level access (x) l Using the current login grants ADMIN access. l The listed user has listed access level and access level ID.
Monitoring event messages An event is a significant occurrence in the system or in an application that requires administrators to be notified. The operating system writes notifications for these events to a log that can be displayed using the Windows Event Viewer. Three different log files are generated: application, security, and system. 1. To access the Event Viewer, select Programs, Administrative Tools, Event Viewer. 2.
Event messages The following table identifies the Storage Mirroring events. 1 This evaluation period has expired. Mirroring and replication have been stopped. To obtain a license, please contact your vendor. Error—Contact your vendor to purchase either a single or site license. 2 The evaluation period expires in %1 day(s). Information—Contact your vendor before the evaluation period expires to purchase either a single or site license. 3 The evaluation period has been activated and expires in %1 day(s).
1003 The Double-Take counter DLL could not open the "Performance" key in the Double-Take section of the registry. Error—Run the installation and select Repair. Contact technical support if this event occurs again. 1004 The Double-Take counter DLL could not read the "First Counter" value under the Double-Take\Performance Key. Error—Run the installation and select Repair. Contact technical support if this event occurs again.
4006 Service has aborted due to the following unrecoverable error: %1 Error—Restart the Storage Mirroring service.
4018 %1, however, mirroring and replication have been disabled as a restore is required due to a previous failover. Warning—Perform a restoration. 4019 Service has started a mirror to %1 (%2) for Replication Set %3, ID: %4 Information—No action required. 4020 Service has paused a mirror to %1 (%2) for Replication Set %3, ID: %4 Information—No action required. 4021 Service has resumed a mirror to %1 (%2) for Replication Set %3, ID: %4 Information—No action required.
4030 RSResource.dll has an unknown error. The product functionality has been disabled. Error—Reinstall the software, using the installation Repair option, to install a new copy of the RSResource.dll. Contact technical support if this error persists. 4031 RSResource.dll could not be opened. The product functionality has been disabled. Error—Reinstall the software, using the installation Repair option, to install a new copy of the RSResource.dll. Contact technical support if this error persists.
4037 Error verifying the vendor URL name. The product functionality has been disabled. Error—Reinstall the software, using the installation Repair option, to install a new copy of the RSResource.dll. Contact technical support if this error persists. 4038 Error verifying the product code. The product functionality has been disabled. Error—Reinstall the software, using the installation Repair option, to install a new copy of the RSResource.dll. Contact technical support if this error persists.
4044 An error was encountered and replication has been stopped. It is necessary to stop and restart the service to correct this error. Error—Contact technical support if this error persists. 4045 %1 value must be between 1025 and 65535. Using default of %2. Error—Verify that the Storage Mirroring port value you are trying to use is within the valid range. If it is not, it will automatically be reset to the default value. 4046 This service failed to start because of a possible port conflict.
4054 Service has paused a restore task to %1 (%2) for Replication Set %3, ID: %4 Information—No action required. 4055 Service has resumed a restore task to %1 (%2) for Replication Set %3, ID: %4 Information—No action required. 4056 Service has stopped a restore task to %1 (%2) for Replication Set %3, ID: %4 Information—No action required. 4057 Service has completed a restore task to %1 (%2) for Replication Set %3, ID: %4 Information—No action required.
4066 The product code requires a virtual server environment. The product functionality has been disabled. Error—The activation code you are using is for the Virtual SystemsTM edition. This code will not work on non-virtual server environments. 4067 No replication ops have been received from the driver for an extended period of time. Error—Check other messages for errors with the Storage Mirroring drivers, and correct as required.
4098 The control device %2 was not created. Communication with the service will be disabled. Reboot the server and contact technical support if this error occurs again. The last Word in the Data window is the NT status code. Error—Reboot your server and contact technical support if this event occurs again. 4099 The driver detected a hard link for a file on drive %2. Hard links are not supported. Changes to this file will not be replicated. Warning—Hard links are not supported.
4111 Target can not write %1 due to a sharing violation. Operation will be retried (%2 times or forever) Warning—A sharing violation error is prohibiting Storage Mirroring from writing on the target. The operation will be retried according to the TGExecutionRetryLimit setting. 4112 Target can not write %1 due to access denied. Operation will be retried (%2 times or forever) Warning—An access denied error is prohibiting Storage Mirroring from writing on the target.
scenarios did not cause the task to be discarded, contact technical support. 4202 Running %1 in band script: %2 (task %3 submitted from %4 by %5 at %6) Information—No action required. 4203 Completed run of in band script: %1 (exit code %2) Information—No action required. 4204 Error running in band script: %1 Error—Review the task and its associated script(s) for syntax errors. 4205 Timeout (%1 seconds) running in band script: %2 Warning—The timeout specified for the script to complete has expired.
4306 Target paths for source %1 (%2) Connection id: %3 are already blocked Warning—No action required. 4307 Target paths for source %1 (%2) Connection id: %3 are already unblocked Warning—No action required. 4308 Error loading target paths for blocking, registry key %1 has been corrupted. Error—If you need to block your target paths, contact technical support. 4400 Failed to create snapshot set for source %1 (%2) Connection ID: %3. Error: %4 Error—The snapshot could not be created.
4407 Disabled snapshot schedule for source %1 (%2) connection %3. Information—No action required. 4408 %1 was unable to move some orphans for source %2 on connection ID %3. Check the %1 logs for further details. Warning—Orphan files could not be moved. For example, the location could be out of disk space. Check the Storage Mirroring log for more information. 4409 %3 was unable to delete some orphans for source %1 on connection ID %2. Check the %3 logs for further details.
5103 Started adding drive shares from %1 to %2. Information—No action required. 5104 %1 drive shares were taken over by %2. Information—No action required. 5105 Attempting to run the %1 script. Information—No action required. 5106 The %1 script ran successfully. Information—No action required. 5107 Error occurred in running %1 script. Error—Verify that the script identified exists with the proper permissions. 5108 The source machine %1 is not responding to a ping.
5302 Drive share information for %1 has been updated on the target machine. Information—No action required. 5303 The application monitor script has started successfully. Information—No action required. 5304 The application monitor script has finished successfully. Information—No action required. 5305 The application monitor has found the %1 service stopped. Warning—Application Manager will attempt to restart the service. 5306 The application monitor has restarted the %1 service. Warning—No action required.
5503 E-mail notification could not be processed. Check to make sure the correct version of SMTPMail.DLL is registered on the system (error code: %1). Warning—If you are using Storage Mirroring 4.4.2.1 or earlier and Windows NT 4.0, e-mail notification requires Windows Management Instrumentation (WMI) to be installed. Verify that you have it installed on the Storage Mirroring server. 5504 Could not load LocalRS.dll (for e-mail notification).
7107 The driver was unable to get valid name information from the Filter Manager for a file. It cannot be replicated. Please contact technical support. Error—Contact technical support. 8100 The driver encountered an unrecoverable internal error. Contact technical support. The last Word in the Data window is the internal error code. Error—Contact technical support. 8192 Driver failed to allocate Kernel memory. Replication is stopped and server must be rebooted for replication to continue.
repeatedly, contact technical support. The last Word in the Data window is the NT status code. Warning—Contact technical support if this event occurs again. 9100 The driver encountered an error opening a file from the service. Check the Event Viewer Application log for additional service information or contact technical support. The last Word in the Data window is the exception code. Error—Check for related service messages. Contact technical support if this event occurs again.
9106 The driver encountered an error writing file security data to the service input buffer. Check the Event Viewer Application log for additional service information or contact technical support. The last Word in the Data window is the exception code. Error—Check for related service messages. Contact technical support if this event occurs again. 9107 The driver encountered an error querying for an allocated range from the service input buffer.
9112 The driver encountered an error writing a directory query to the service input buffer. Check the Event Viewer Application log for additional service information or contact technical support. The last Word in the Data window is the exception code. Error—Check for related service messages. Contact technical support if this event occurs again. 9113 The driver encountered an error querying a stream from the service input buffer.
information or contact technical support. The last Word in the Data window is the exception code. Error—Check for related service messages. Contact technical support if this event occurs again. 9119 The driver encountered an error writing extended attributes status to the service input buffer. Check the Event Viewer Application log for additional service information or contact technical support. The last Word in the Data window is the exception code. Error—Check for related service messages.
or contact technical support. The last Word in the Data window is the exception code. Error—Check for related service messages. Contact technical support if this event occurs again. 9125 The driver encountered an error writing fsctl status to the service input buffer. Check the Event Viewer Application log for additional service information or contact technical support. The last Word in the Data window is the exception code. Error—Check for related service messages.
10005 Node %1 is taking ownership of the group %2. The group will be brought online on this node. Information—No action required. 10006 The cluster notification thread failed to start on node %1 for resource %2. The resource should be taken offline and brought back online. Warning—Take the resource offline and bring it back online. 10007 The user %1 has reverted a snapshot for the %2 resource on node %3. Warning—No action required. The snapshot you selected will be reverted.
10102 The driver could not recall the file. The last Word in the Data window is the exception code. Error—Contact technical support if this event occurs again. 11000 Service has started an archive to %1 (%2) for Replication Set %3, ID: %4 Information—No action required. 11001 Service has completed an archive to %1 (%2) for Replication Set %3, ID: %4, %5 Information—No action required. 11002 Service has started a recall from %1 (%2) for Replication Set %3, ID: %4 Information—No action required.
11011 Service has aborted the archive preview operation. Warning—Verify the activation code on the source and target is valid for archiving. Reboot an unlicensed server. 12000 The service has started. Information—This message refers to the Storage Mirroring Recall service. No action required. 12001 The service failed to start. Error—Check the user name and password for the Storage Mirroring Recall service to ensure validity. Reinstall the software if this event occurs again. 12002 The service has stopped.
16384 The driver encountered an unrecoverable error. Contact technical support. Error—Contact technical support 16385 The driver encountered an unexpected internal result. Contact technical support. The last Word in the Data window is the NT status code. Error—Contact technical support. 16393 The driver encountered an internal error. Contact technical support. The last Word in the Data window is the internal error code. Error—Contact technical support.
E-mailing event messages You can e-mail Storage Mirroring Recover event messages to specific addresses. The subject of the e-mail will contain an optional prefix, the server name where the message was logged, the message ID, and the severity level (information, warning, or error). The text of the message will be displayed in the body of the e-mail message. 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties. 3.
Note: Any specified notification settings are retained when Enable notification is disabled. 5. Specify your e-mail settings. l l l l l Mail Server (SMTP)—Specify the name of your SMTP mail server. Log on to SMTP Server—If your SMTP server requires authentication, enable Log on to SMTP Server and specify the Username and Password to be used for authentication. Your SMTP server must support the LOGIN authentication method to use this feature.
the list. Note: You can test e-mail notification by specifying the options on the E-mail Notification tab and clicking Test. (By default, the test will be run from the machine where the Replication Console is running.) If desired, you can send the test message to a different e-mail address by selecting Send To and entering a comma or semicolon separated list of addresses. Modify the message text up to 1024 characters, if necessary. Click Send to test the e-mail notification.
Statistics Statistics logging is the process of taking snapshots of Storage Mirroring Recover statistical data. The data can be written to a file for future use. Changes to the statistics file configuration are detected and applied immediately without restarting the Storage Mirroring service. The statistics log file created is a binary file. To view the log file, you must run the DTStat utility from the command prompt.
Configuring the properties of the statistics file 1. Right-click a machine in the left pane of the Replication Console and select Properties. 2. Select the Logging tab. 3. At the top of the tab, specify the Folder where the log files for messages, alerts, verification, and statistics will be saved. 4. Under Statistics, specify the following information. l l Filename—The name of the statistics log file. The default file name is statistic.sts. Maximum Length—The maximum length of the statistics log file.
l Write Interval—The frequency in which Storage Mirroring Recover writes the statistical data to the statistics log file. The default is every 5 minutes. 5. Select the Setup tab. 6. Verify that Log Statistics Automatically is enabled. If disabled, statistics will not be logged. 7. Click OK to save the settings.
Viewing the statistics file The statistics log file created is a binary file. To view the log file, you must run the DTStat utility from a command prompt. From the directory where Storage Mirroring Recover is installed, run the DTStat command.
l l -STOP mm/dd/yyyy hh:mm—Filters out any data after the specified date and time -SERVER ip_address port_number—Connects DTStat to the specified IP address using the specified port number instead of to the local machine Examples l DTStat -i 300 l DTStat -p -i 300 -t AlphaStats.sts l DTStat -f AlphaStats.sts -s AlphaStats.csv -start 02/02/2007 09:25 l DTStat -server 206.31.4.51 1106 l This command is not case-sensitive.
Statistics The following table identifies the Storage Mirroring statistics. Note: The categories you see will depend on the function of your server (source, target, or both). If you have multiple IP addresses connected to one target server, you will see multiple Target sections for each IP address. If you convert your statistics output to an ASCII, comma-delimited file using the dtstat -s option, keep in mind the following differences.
Kernel, SourceState l 0—Source is not running l 1—Source is running without the replication driver l 2—Source is running with the replication driver Kernel, TargetState l 0—Target is not running l 1—Target is running Kernel, Start Time Date and time stamp indicating when the Storage Mirroring service was loaded Kernel, RepOpsGenerated The number of replication operations generated by the file system driver. An op is a file system operation.
Kernel, FailedMirrorCount The number of mirror operations that failed due to an error reading the file from the disk Kernel, FailedRepCount The number of replication operations that failed due to an error reading the file from the disk Kernel, ActFailCount The number of activation code failures when loading the source or target. Activation codes can be bad for reasons such as: expiration of evaluation codes, duplicate codes, incorrect codes, etc.
Target, Ops Remaining The total number of operations that are left in the target queue Target, Orphan Files Removed The number of orphan files removed from the target machine Target, Orphan Directories Removed The number of orphan directories removed from the target machine Target, Orphan Bytes Removed The number of orphan bytes removed from the target machine Target, Bytes In Target Queue The number of bytes currently in the system memory queue on the target Target.
Connection, conPeerAddress The IP address of the target machine Connection, connectTime The time that this connection was established Connection, conState The state of the active connection l l l l l 0—None. This indicates a connection has not been established. Statistics are still available for the source and target machines. 1—Active. This indicates that the connection is functioning normally and has no scheduling restrictions imposed on it at this time.
Connection, conBytesInRepQueue The number of replication bytes remaining to be transmitted to the target Connection, conOpsTx The number of operations transmitted to the target. This is the total number of operations that Storage Mirroring has transmitted as a source. In other words, the cumulative number of operations transmitted by this source to all connected targets.
changes to a file, then it will indicate the number of bytes it did not send for this file in this field. Connection, conMirrorBytesRemaining The number of mirror bytes remaining to be transmitted Connection, conMirrorPercent The percentage of the mirror that has been completed. This field is determined if the replication set size was calculated.
Performance Monitor Performance Monitor is the Windows graphical tool for measuring performance. It provides charting, alerting, and reporting capabilities that reflect both current activity and ongoing logging. Storage Mirroring Recoverstatistics are available through the Performance Monitor.
Monitoring Performance Monitor statistics 1. To access the Performance Monitor, select Start, Programs, Administrative Tools, Performance. 2. Specify the data to monitor by right-clicking and selecting Add or using the Add button on the toolbar. 3. Choose one of the following Storage Mirroring Recover Performance Objects. l Double-Take Connection l Double-Take Kernel l Double-Take Security l Double-Take Source l Double-Take Target 4. Select the statistics you want to monitor, and click Add.
Performance Monitor statistics The following table identifies the Storage Mirroring Performance Monitor statistics. Note: If you have multiple IP addresses connected to one target server, you will see multiple Target statistic sections for each IP address.
Connection, Operations received The number of operations received by the target since the last Performance Monitor refresh Connection, Operations resent The number of operations re-sent since the last time the Storage Mirroring service was restarted on the source Connection, Operations transmitted The number of operations transmitted from the source Connection, Task commands queued The number of task commands queued on the source Connection, Task commands submitted The number of task commands submitted on t
sources connected to this target. If the value grows larger than the number of currently executing differences mirrors, that indicates there is an error condition.
Kernel, Replication Kbytes generated The number of replication kilobytes generated on the source by the file system driver Kernel, Replication operations generated The number of replication operations generated on the source by the file system driver Security, Failed logins Number of failed login attempts since the last time the Storage Mirroring service was restarted Security, Successful logins Number of successful login attempts since the last time the Storage Mirroring service was restarted Source, Auto
Target, Orphan Bytes The number of orphan bytes removed from the target Target, Orphan Directories The number of orphan directories removed from the target Target, Orphan Files The number of orphan files removed from the target Target, Retries The number of retries performed on the target since the last time the Storage Mirroring service was restarted on the target Target, Tasks failed The number of task commands that have failed on the target.
SNMP SNMP, Simple Network Management Protocol, is the Internet's standard for remote monitoring and management of hosts, routers and other nodes and devices on a network. Storage Mirroring Recover provides an SNMP sub-agent that can be managed from an SNMP Management Console. Storage Mirroring Recover installs two components to work with SNMP. l l The sub-agent is a program that installs and runs on the same machine as Storage Mirroring Recover and gathers statistics, data, and traps.
Configuring SNMP on your server SNMP must be installed on a server before Storage Mirroring Recover in order for the Storage Mirroring RecoverSNMP components to be added during the Storage Mirroring Recoverinstallation. If SNMP is installed on a server after Storage Mirroring Recover is installed, run a repair install to install the SNMP components. The Storage Mirroring Recover .mib file will need to be loaded into your SNMP Management Console.
SNMP traps The following table lists the Storage Mirroring SNMP traps.
Connection, dttrapConnectionFailed The source to target connection was not successful Connection, dttrapConnectionLost The source to target connection has been disconnected Connection, dttrapMemoryLimitReached The Storage Mirroring memory pool limit has been reached Connection, dttrapMemoryLimitRemedied The memory pool usage is below the maximum limit specified Connection, dttrapAutoReconnect Auto-reconnect needs to make a new connection Connection, dttrapScheduledConnectStart A scheduled connection has bee
Mirroring, dttrapMirrorStop Mirroring has stopped Mirroring, dttrapMirrorPause Mirroring has paused Mirroring, dttrapMirrorResume Mirroring has resumed Mirroring, dttrapMirrorEnd Mirroring has ended Verification, dttrapVerificationStart Verification has started Verification, dttrapVerificationEnd Verification has ended Verification, dttrapVerificationFailure Verification has failed Restoration, dttrapRestoreStarted Restoration has started Restoration, dttrapRestoreComplete Restoration is complete Replicatio
SNMP statistics The following table lists the Storage Mirroring SNMP statistics.
General, dtDriverQueuePercent The amount of throttling calculated as a percentage of the stop replicating limit Source, dtSourceState 0—Source is not running 1—Source is running without the replication driver 2—Source is running with the replication driver.
1—Active. This indicates that the connection is functioning normally and has no scheduling restrictions imposed on it at this time. (There may be restrictions, but it is currently in a state that allows it to transmit.) 2—Paused. This indicates a connection that has been paused. 4—Scheduled. This indicates a connection that is not currently transmitting due to scheduling restrictions (bandwidth limitations, time frame limitations, and so on). 8—Error.
Connection, dtconBytesCompressedTx The total number of compressed bytes transmitted to the target Connection, dtconOpsRx The total number of operations (create, modify, or delete) received from the target Connection, dtconBytesRx The total number of bytes received from the target Connection, dtconResentOpCount The number of operations that were resent because of acknowledgement errors Workload monitoring Page 471 of 677
Error codes The following table contains error codes that you may see in the various user interfaces or in log files.
-125 Connection is replicating -126 Connection is not replicating -127 Replication set is enabled -128 Schedule is not defined -129 Replication set is changed -130 Replication set is in use -131 No Storage Mirroring target identified -132 Memory is low -133 Memory is sufficient -134 Replication is pending -135 Invalid option supplied -136 Replication set rule does not exist -137 Mirror queue is full -138 Insufficient security access -139 Schedule command is invalid -140 Source path is invalid -141 Replicati
-154 Transmission is active -155 Target does not support the command -156 Command conversion to accommodate a different Storage Mirroring version has failed -157 Incompatible source and target Storage Mirroring versions -158 Incompatible source and target operating system versions -159 NAS server to non-NAS server is not a supported configuration -160 Target module is not loaded -161 Operation or command is not supported -162 Target is paused -163 Target is pending -164 Target is active -165 Target is retry
-183 Connection ID specified is invalid -184 No command objects are in the queue -185 Target is discarding operations from the target queue -186 Target is not discarding operations from the target queue -187 Schedule is paused -188 Schedule is resumed -189 Target state has changed -190 Target name has changed -201 Monitor name exists -202 Monitor name does not exist -203 Monitor configuration exists -204 Monitor configuration does not exist -205 Monitor configuration is in use -206 Monitor configuration is
-223 Script timeout met -224 No replication timeout met - connection is bad -225 Invalid path -226 Kernel module is not loaded -2201 Error communicating with e-mail server -2202 Error connecting to e-mail server -2203 E-mail notification is disabled -2204 E-mail notification is enabled -2205 E-mail notification requires Internet Explorer version 5.0 and WMI -2206 E-mail notification requires Internet Explorer version 5.0 (E-mail notification no longer requires Internet Explorer 5.0 or later.
-2401 Snapshot module is not loaded -2402 Error reading the snapshot .
Failover Your failover process will depend on the type of workload you are protecting.
Failing over data workloads, application workloads configured for identity failover, and cluster workloads The failover process, including script processing, can be tested at any time. To force unavailability, disconnect the network cable from a monitored machine, wait for the Time to Fail counter to decrease to zero and failover begins. To avoid the countdown delay, highlight the monitored machine name in the Failover Control Center window and select Failover.
Select an option based on the table below. You may want to check the amount of data in queue on the target by reviewing the Statistics or Performance Monitor. Apply Data in Target Queues Then Failover All of the data in the target queue will be applied before failover begins. Advantages—All of the data that the target has received will be applied before failover begins. Disadvantages—Depending on the amount of data in queue, the amount of time to apply all of the data could be lengthy.
After failover is complete, clients will be rerouted to the target, which is standing in for the source. Exchange Note: Users using Outlook or Outlook Web Access to receive e-mail can connect after the changes have propagated through your environment. Users that had Outlook open during failover will need to restart the Outlook client (excluding Outlook Web Access clients on a LAN).
After failing over SQL 2008, you may not be able to take the SQL database offline. If this occurs, stop and restart the SQL Server Management Studio application, and then you can take the database offline. After failing over in a SQL workgroup, you will not be able to connect to the source server instance of SQL. You can work around this issue by creating an alias on the target with the source server’s name.
Full-server workload failover Full-server failover can be initiated through the Full-Server Failover Manager client or by using a command line interface.
Failing over using the Full-Server Failover Manager When a failover condition is met, you will want to start failover. Additionally, you can start it without a failover condition, as long as protection is enabled. For example, you may want to force failover when upgrading to a better source server. 1. To start failover, click Failover. 2. If Storage Mirroring Recover determines there is a possibility that the data on the target is incomplete, you will be warned before failover begins.
l Revert to specified snapshot—Select this option, and then select a snapshot. The data on the target will be reverted to the selected snapshot. This option will not be available if there are no snapshots on the target or if the target does not support snapshots. To help you understand what snapshots are available, use the Type and Status columns. The Status indicates the state of the connection between the source and target at the time the snapshot was taken. The Type indicates the kind of snapshot.
l KMS volume licensing—Key Management Service (KMS) licensing allows IT professionals to complete activations on their local network without contacting Microsoft. 1. View or download the Microsoft Volume Activation Deployment Guide from the Microsoft web site. 2. Using an administrative user account, open a command prompt and follow the instructions from the deployment guide to convert a MAK activation client to a KMS client. Multiple reboots may be necessary before you can access a command prompt.
Failing over from the command line You can configure connections and initiate failover without using the Full-Server Failover Manager user interface. The same executable that launches the user interface can be used from a command prompt with options. The command line execution opens the user interface, passes through specified parameters, and initiates specified processes.
l LOGLEVEL number—Specifies the level of detailed logged based on the following numbers. l 2—Informational messages are logged l 3—Informational and error messages are logged l 4—Informational, error, and exception messages are logged l l l 5—Informational, error, exception, and debug messages are logged. This is the default setting. 6—Informational, error, exception, debug, and internal coding messages are logged CONFIG filename—Name of the file that contains the failover options.
1. View or download the Microsoft Volume Activation Deployment Guide from the Microsoft web site. 2. Using an administrative user account, open a command prompt and follow the instructions from the deployment guide to activate MAK clients. Multiple reboots may be necessary before you can access a command prompt. You may need access to the Internet or to call Microsoft to complete the activation.
Failing over application workloads configured for DNS failover When a failover condition has been met, failover will be triggered automatically if you configured automatic failover when establishing protection. If you configured manual intervention before failover, you can use the Application Manager to initiate failover for application workloads configured for DNS failover.
3. Specify if you want to perform an immediate or graceful failover. An immediate failover begins immediately without waiting for the data queues on the source and target to empty. A graceful failover waits until the queues are emptied before continuing. If you select the graceful failover, specify how often you want the failover prompt to continue asking for failover while there is still data in the queues.
l Revert to specified snapshot—Select this option, and then select a snapshot. The data on the target will be reverted to the selected snapshot. To help you understand what snapshots are available, use the Type and Status columns. The Status indicates the state of the connection between the source and target at the time the snapshot was taken. The Type indicates the kind of snapshot. l l l Scheduled—This snapshot was taken as part of a periodic snapshot.
Outlook Web Access is not needed, contact technical support for a workaround. If you SMTP gateway is configured to send e-mail to a specific IP address that address is not failed over to the target, you will need to update the IP address after failover. Mail stores or storage groups created after a failover will not be failed back. SQL Note: After failover, linked databases in the SQL instance will be unavailable until the service master key is updated.
Virtual workload failover When a failover condition has been met, failover will be triggered automatically if you configured automatic failover when establishing protection. If you configured manual intervention before failover, you can failover your protection from the console you used to establish protection. If you are protecting host-level virtual disk files (the .
Failing over virtual workloads in the Storage Mirroring Console 1. On the Monitor Connections page, select the connection that you want to failover. 2. In the lower pane, click Failover in the toolbar. 3. Select the type of failover to perform. l l Live failover—Select this option to initiate a full, live failover. This option will shutdown the source virtual machine (if available), stop the protection job, and start the replica virtual machine on the target with full network connectivity.
shutdown and the protection job will be restarted performing a file differences remirror.
Failing over virtual workloads in the Storage Mirroring Recover for Virtual Infrastructure console 1. Make sure your protection job is in an active (non-stopped) state. 2. On the Monitor protection page, select the connection that you want to failover and click Failover in the toolbar. 3. Select the type of failover to perform. l l Live failover—Select this option to initiate a full, live failover.
Failback and restore Your failover and restoration process will depend on the type of workload you are protecting.
Data workload failback and restoration Failover occurred because the target was monitoring the source for a failure, and when a failure occurred, the target stood in for the source. User and application requests that were directed to the failed source are routed to the target. While the users are accessing their data on the target, you can repair the issue(s) on the source. Before users can access the source again, you will need to restore the data from the target back to the source and perform failback.
Restoring then failing back Restoring before failing back allows your users to continue accessing their data on the failed over target, which is standing in for the source, while you perform the restoration process. The key to this process is to keep the users off of the source, but allow the source and target to communicate to perform the restoration. 1. Locate the file connect.sts on the source where you installed Storage Mirroring Recover and rename it to connect.sts.old.
9. From your target, confirm the Replication Console is communicating with the source using the new IP address. a. From the Replication Console on the target, right-click the source and select Remove. b. Depending on your configuration, the source may be automatically inserted back into the Replication Console. If it is not, select Insert, Server. Specify the source server and click OK. 10. Begin your restoration process. a. From the Replication Console, select Tools, Restoration Manager. b.
functionality (Microsoft failover from node to node) available during the restoration process, you will have to create a resource, like you did for your original connection, for the restoration process. See Protecting a standard cluster. Keep in mind when restoring, your target will function as your source, sending data to the target, which will be your original or new source. d. Replication Set contains the replication set information stored on the target machine (the machine in Restore From).
l l Overwrite existing files during restore—This option restores all existing files by overwriting them. Any files that do not exist on the source are written also. If this option is disabled, only files that do not exist on the source will be restored. Only if backup copy is more recent—This option restores only those files that are newer on the target than on the source. The entire file is overwritten with this option.
11. After the Mirror Status is Idle, schedule a time for failback. User downtime will begin once failback is started, so select a time that will have minimal disruption on your users. 12. When you are ready, begin the failback process. User downtime starts now. a. Deny user access to the target, so that no additional updates can be made to the data on the target. b. Stop all applications on the target, allowing the data to become quiescent. c.
k. Also on the source, change the source name back to its original name and reboot, or restart the Workstation, Server, and any other services you were prompted to stop. l. Once the source is back online, users can reconnect to the source. 13. Confirm the Replication Console is communicating with the source using the original IP address. a. Right-click the source and select Remove. b. Depending on your configuration, the source may be automatically inserted back into the Replication Console.
Failing back then restoring Failback before restoration can be a simpler process, but it may require additional downtime. The amount of downtime will depend on the amount of data to be restored. Users must be kept off of the source and target during this entire process. 1. Locate the file connect.sts on the source where you installed Storage Mirroring Recover and rename it to connect.sts.old. This will keep the original connection from reconnecting when you bring the source online. 2.
Note: The source must be online and Storage Mirroring Recover must be running to ensure that the source post-failback script can be started. If the source has not completed its boot process, the command to start the script may be lost and the script will not be initiated. 7. Stop any applications that may be running on your source. The files must be closed on the source so that updated files from the target will overwrite the files on the source. 8. Now you can begin your restoration process. a.
Note: If your target is a cluster, you can specify just one node in the cluster and restore only from that node. If you need to have the cluster functionality (Microsoft failover from node to node) available during the restoration process, you will have to create a resource, like you did for your original connection, for the restoration process. See Protecting a standard cluster.
i. Select the Restore Replication Set check box to restore the target’s copy of the replication set database to the source during the restoration process. j. Select the restoration conditionals that you want to use. l l Overwrite existing files during restore—This option restores all existing files by overwriting them. Any files that do not exist on the source are written also. If this option is disabled, only files that do not exist on the source will be restored.
9. Because there are no users accessing the target data, the restoration process is complete when the Mirror Status is Idle. When the Mirror Status is Idle, disconnect the restoration connection from the target. 10. Your original connection on the source, if it still exists in the Replication Console, will be in a Mirror Required state. Right-click the connection and select Mirror, Start. Select the type of mirror you wish to perform and click OK. When prompted to start replication, click Yes. 11.
Failing back and restoring a full-server workload After your target has failed over and becomes your source, you can continue running from the failed over server indefinitely. However, in some instances, it may be necessary or desired to go back to using the original hardware after you have failed over. Because the source identity now exists on the network (step 1 of the diagram), failback and restoration requires manual preparation of the original or a new server (step 2 of the diagram).
Preparation of your original source or a new server source is key to this process. The type of preparation required will depend on the role of the original source server, the applications that were used on the original server, whether the original source was a physical or virtual server, and the failure or event that occurred. l l l Server role—If your original source was a domain controller, a Cluster Service server, or a Certificate Service server, you will have to reinstall Windows.
remaining instructions. Note: If possible, you can attach any virtual hard disks that survived the failure event to a new virtual guest. Reusing any undamaged disks will decrease the time required to restore data because you can use a difference mirror. As an alternative to manually creating a new virtual guest, you can let Storage Mirroring Recover automatically provision (create) the new virtual guest for you.
4. Stop all application services on the original source and set them to manual. 5. Using the Replication Console, insert the original source server into the server list, if it is not automatically discovered, by clicking Insert, Server and specifying the server name of the original source server. 6. Right-click on the server in the server list, select Properties, and select the Licensing tab. 7. Enter the activation code from the original target server and click Add.
2. Mirroring and replicating from the source to the original or new source and failing over 1. Using the Full-Server Failover Manager, establish full-server protection from your source to the original or new source. In the console, specify your source in the Select source server field. Specify your original or new source that you built or modified in step 1A or 1B above in the Select target server field.
Application failback and restoration When protecting application workloads, your failback and restoration process will depend on if you configured your application for identity or DNS failover. l l Identity failover—If your application is configured for identity failover, you will need to stop your application services and then you have the choice of restoring and then failing back or failing back and then restoring. See Failback and restoration for applications configured for identity failover.
steps as a guideline for rebuilding the source server. 1. Install Windows, and any service packs, using the same name and IP address configuration as the original source, and then join the domain. See your Windows documentation for more information. 2. Install SQL using the same drive and directory settings as the original source. 3. Install Storage Mirroring Recover, and then continue with failback and restoration.
Failback and restoration for applications configured for identity failover For application workloads that were configured for identity failover, you need to stop the services on your source that correspond with your application before you begin the failback and restoration process. Use the table below as a guideline for the services to stop. After you have stopped the services on the source, use the instructions for data workload failback and restoration to complete your application failback and recovery.
Exchange 2003 l MSExchangeSA l MSExchangeMGMT l POP3SVC l IMAP4SVC l ResVC l MSExchangeES l W3SVC l SMTPSVC l MSSqlServer l SQLServerAgent l MSSearch (SQL 2000) l MSFteSQL (SQL 2005) l MSSQLServerADHelper l MSDTC l MSSQLServerOLAPService l MSDTSServer l SQLWriter l SQLBrowser (SQL 2005) l BlackBerry Router l BlackBerry Server Alert l BBAttachServer l BlackBerry Controller l BlackBerry Database Consistency Service l BlackBerry Dispatcher l BlackBerry Policy Se
File Server l Server l Computer Browser Failback and restore Page 520 of 677
Restoring then failing back applications configured for DNS failover For application workloads that were configured for DNS failover, you can use the Application Manager to initiate failback and, if desired restore data from the target back to the source. In order to minimize downtime, the restoration process is completed before the failback. 1.
l l l l l Source IP Address—Select an IP address on the source to handle the restoration data. In a cluster environment running Exchange, select the name of Exchange virtual server dependent IP address. Restore target data prior to failback—Select this option to restore data from the target back to the source. If you are certain that there is no data that you want to restore or you are willing to lose any data changes on the target, you can disable this option.
4. Click Initiate Failback to being the failback process. Exchange Note: If you deslected any mail stores during your failover configuration, you may see a message during failback about potential errors (unpaired mail stores). This message can be disregarded. If you created any new mail stores on the target after failover, they will not be failed back.
Restoring then failing back virtual workloads 1. Open the console you used to establish protection. 2. On the Monitor Connections or Monitor protections page (depending on your console), select the connection that you want to restore and failback. 3. Click Reverse Protection in the toolbar. The flow of mirroring and replication data will change. Data will be transmitted from the replica virtual machine on the target back to the source. 4.
Connections A unique connection ID is associated with each Storage Mirroring Recover connection. The connection ID provides a reference point for each connection. The connection ID is determined by sequential numbers starting at one (1). Each time a connection is established, the ID counter is incremented. It is reset back to one each time the Storage Mirroring service is restarted.
Data queues During the Storage Mirroring Recover installation, you identified the amount of disk space that can be used for Storage Mirroring Recover queuing. Queuing to disk allows Storage Mirroring Recover to accommodate high volume processing that might otherwise fill-up system memory. For example, on the source, this may occur if the data is changing faster than it can be transmitted to the target, or on the target, a locked file might cause processing to back up.
has 10 KB left until the limit and the next operation to be applied to that file is greater than 10 KB, a new transaction log file will be created to store that next operation. Also, if one operation is larger than the defined size limit, the entire operation will be written to one transaction log. 3. When system memory is full, the most recent changed data is added to the disk queue, as described in step 2. This means that system memory contains the oldest data.
Queuing data You should configure queuing on both the source and target. 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties. 3. Select the Queue tab. 4. Specify the queue settings for the server. l Folder—This is the location where the disk queue will be stored. Storage Mirroring Recover displays the amount of free space on the volume selected.
l l l l l Select a dedicated, physical, non-boot volume. Select a location on a non-clustered volume that will have minimal impact on the operating system and applications being protected. Select a location that is on a different volume as the location of the Windows pagefile. Do not select the root of a volume. Do not select the same physical or logical volume as the data being replicated.
amount of physical memory available but has a minimum of 32 MB. By default, 128 MB or 512 MB of memory is used, depending on your operating system. If you set it lower, Storage Mirroring Recover will use less system memory, but you will queue to disk sooner which may impact system performance. If you set it higher, Storage Mirroring Recover will maximize system performance by not queuing to disk as soon, but the system may have to swap the memory to disk if the system memory is not available.
Note: The Maximum disk space for queue and Minimum Free Space settings work in conjunction with each other. For example, assume your queues are stored on a 10 GB disk with the Maximum disk space for queue set to 10 GB and the Minimum Free Space set to 500 MB. If another program uses 5 GB, Storage Mirroring Recover will only be able to use 4.5 GB so that 500 MB remains free.
Auto-disconnect and auto-reconnect While disk queues are user configurable and can be extensive, they are limited. If the amount of disk space specified for disk queuing is met, additional data could not be added to the queue and data would be lost. To avoid any data loss, the auto-disconnect and auto-reconnect processes occur. l l l l Exhausted queues on the source—If disk queuing is exhausted on the source, Storage Mirroring Recover will automatically start disconnecting connections.
l Target service shutdown—If the target service is stopped and restarted, there could have been data in the target queue when the service was stopped. To prevent any loss of data, the Storage Mirroring service will attempt to persist to disk important target connection information (such as the source and target IP addresses for the connection, various target queue information, the last acknowledged operation, data in memory moved to disk, and so on) before the service is stopped.
Reconnecting automatically Use the following steps to configure automatic reconnections. 1. Open the Replication Console and right-click the server on the left pane of the Replication Console. 2. Select Properties and select the Setup tab. 3. Verify that the check box Automatically Reconnect During Source Initialization is marked to enable the auto-reconnect feature. 4. Click OK to save the settings.
Pausing and resuming target processing You can pause the target, which queues incoming Storage Mirroring Recover data from the source. The data will not be committed until the target is resumed. Note: Pausing the target only pauses Storage Mirroring Recover processing, not the entire server. For example, you must pause the target while you perform a backup of database files stored on the target because the database and log files must be backed up when they are at the exact same point in time.
Blocking writing to the target paths You can block writing to the paths on the target that contain the copy of the replication set data. This keeps the data from being changed outside of Storage Mirroring Recover processing. To block the replication set data paths on the target, open the Replication Console, and right-click the connection on the right pane of the Replication Console. Select Block Target Path(s). To unblock the paths, right-click the connection and deselect Block Target Path(s).
Disconnecting a connection To disconnect a Storage Mirroring Recover connection, open the Replication Console, and right-click the connection on the right pane of the Replication Console. Select Disconnect. The source and target will be disconnected. Note: If a connection is disconnected and the target is monitoring the source for failover, you will be prompted if you would like to continue monitoring for a failure.
Mirroring Mirroring is one of the key components of Storage Mirroring Recover. You can perform the following functions to manage mirroring.
Stopping, starting, pausing, or resuming mirroring After a connection is established, you need to be able to control the mirroring. You can start, stop, pause and resume mirroring. open the Replication Console, and right-click the connection on the right pane of the Replication Console. Select Mirroring and the appropriate mirror control.
File difference mirror options compared l l l File Differences—Any file that is different on the source and target based on the date, time, and/or size is transmitted to the target. The mirror sends the entire file. File Differences and Only if Source is Newer—Any file that is newer on the source than on the target based on date and/or time is transmitted to the target. The mirror sends the entire file.
Mirroring automatically In certain circumstances, for example if the disk-based queues on the source are exhausted, Storage Mirroring Recover will automatically disconnect connections (called auto-disconnect) and then automatically reconnect them (called auto-reconnect). In order to ensure data integrity on the target, Storage Mirroring Recover will perform an automatic mirror (called an auto-remirror) after an auto-reconnect. Note: Auto-remirror is a per source option.
l Full—All files are sent to the target. Note: Database applications may update files without changing the date, time, or file size. Therefore, if you are using database applications, you should use the Differences with checksum or Full option. Stopping, starting, pausing, or resuming mirroring contains a comparison of how the file difference remirror settings work together, as well as how they work with the global checksum setting on the Source tab of the Server Properties. 6.
Running scripts during mirroring You can customize your mirroring process by running customized scripts on the target at predefined points in the mirroring process. Scripts may contain any valid Windows command, executable, batch, or script file. The scripts are processed using the same account running the Storage Mirroring service, unless you provide specific credentials on the Server Properties Script Credentials tab for the target server. There are three types of mirroring scripts.
4. For each of the three predefined points in the mirroring process, specify the following information. l l l l l Script path—Specify the path and filename for each script. Arguments—If needed, specify any arguments that are required to execute your script. The arguments must be valid for your script. Allow interaction with the Desktop—Enable this option if you want the script processing to be displayed on the screen. Otherwise, the script will execute silently in the background.
establish additional connections to the same target using the same target path location, the mirror scripts will automatically be applied to those subsequent connections. If you select a different target path location, the mirror scripts will have to be reconfigured for the new connection(s).
Removing orphan files An orphan file is a file that exists in the target’s copy of the replication set data, but it does not exist in the source replication set data. An orphan file can be created when you delete a file contained in the source replication set while there is no Storage Mirroring Recover connection. For example, if a connection was made and a mirror was completed and then the connection was stopped and a file was deleted on the source, an orphan file will exist on the target.
4. To configure orphan files for processing during a mirror, verify, or restore, use the following instructions. a. Right-click the connection on the right pane of the Replication Console and select Connection Manager. b. Select the Orphans tab. c. Specify if you want to log the name of the orphan files to the Storage Mirroring Recover log file on the target by marking Log Orphaned Files to Target Log. d. By default, the orphan files feature is disabled. To enable it, mark Move/Delete Orphan Files. e.
so that the orphan files are only moved once. f. Specify if you want to Remove All Orphans or Remove Orphans not modified within the following time period. If you select the time-based option, only orphans older than the time you specify will be removed. g. Click OK to save the settings.
Replication Replication is one of the key components of Storage Mirroring Recover. This section contains the following replication topics. l l l l Replication capabilities—Review this list to learn what Storage Mirroring Recover supports for replication. Replication sets—This section contains instructions for creating and using Storage Mirroring Recover replication sets.
Replication capabilities Storage Mirroring Recover replicates file and directory data stored on any Windows file system (FAT, FAT32, NTFS4, and NTFS5). Replicated items also include Macintosh files, compressed files, NTFS attributes and ACLs (access control list), dynamic volumes, files with alternate data streams, sparse files, and encrypted files. Files can be replicated across mount points, even though mount points are not created on the target.
3. If you select a dynamic volume and you increase the size of the volume, the target must be able to compensate for an increase in the size of the dynamic volume. 4. If you select files with alternate data streams, keep in mind the following. a. Alternate data streams are not included in the replication set size calculation. Therefore, you may see the mirror process at 99-100% complete while mirroring continues. b. The number of files and directories reported to be mirrored will be incorrect.
where the encrypted file is located is out of space, when it actually may be the location where the temporary file is trying to be created that is out of disk space. 6. If you are using mount points, keep in mind the following. a. By default, the mount point data will be stored in a directory on the target. You can create a mount point on the target to store the data or maintain the replicated data in a directory.
restoration is complete and replication will continue from the target to the source. e. If you have restored your data before starting the failback process, make sure the restoration process does not have pending transactions and is complete before starting failback. If you are restoring your data after the failback the process has completed, users will not be accessing the data once failback occurs, so there are no opportunities for pending transactions. 8.
Replication sets A replication set defines the data on a source machine that Storage Mirroring Recover protects. Replication sets are defined by volumes, directories, files, or wild card combinations. Creating multiple replication sets allows you to customize sets of data that need to be protected. When working with data workloads, you need to define the replication set data yourself.
l Calculating replication set size l Deleting a replication set Keep in mind the following notes when creating and working with replication sets and connections. l Limitations l l l l Replication set rules are limited in length meaning that the entire volume\directory\filename including slashes, spaces, periods, extensions, cannot exceed 259 characters.
l l l If you rename the root folder of a connected replication set, Storage Mirroring Recover interprets this operation as a move from inside the replication set to outside the replication set. Therefore, since all of the files under that directory have been moved outside the replication set and are no longer a part of the replication set, those files will be deleted from the target copy of the replication set. This, in essence, will delete all of your replicated data from the target.
replication set to ensure the data is replicated to the correct location. (The second file can be a zero byte file if desired.) l Backups l l Storage Mirroring Recover does not replicate the last access time if it is the only thing that has changed. Therefore, if you are performing incremental or differential backups on your target machine, you need to make sure that your backup software is using an appropriate flag to identify what files have been updated since the last backup.
Creating a replication set Before you can establish a connection, you must create a replication set. 1. From the Replication Console, highlight a source in the left pane of the Replication Console and select Insert, Replication Set from the menu bar. You can also rightclick on the source name and select New, Replication Set. 2. A replication set icon appears in the left pane under the source. By default, it is named New Replication Set.
Note: Be sure and verify what files can be included by reviewing Replication capabilities. 5. After selecting the data for this replication set, right-click the new replication set icon and select Save. A saved replication set icon will change from red to black.
Creating or modifying replication rules manually There may be times when you cannot browse for data when creating a replication set. For example, you can create a replication set rule for a directory or file that does not exist. Since you cannot browse for the location, you have to create replication set rule manually. At other times, the data you want to replicate cannot be easily selected from the Replication Console. For example, you may want to select all .db files from a specific volume or directory.
l l l Inc—Include indicates that the specified path is to be included in the files sent to the target Exc—Exclude indicates that the specified path is not to be included in the files sent to the target Rec—Recursion indicates the rule should automatically be applied to the subdirectories of the specified path. If you do not select this option, the rule will not be applied to subdirectories. 4. From the Replication Set Properties dialog box, click Add. 5. Specify a path, wild card, or specific file name.
Modifying a replication set Storage Mirroring Recover allows you to make modifications to a replication set when you want to change the data you wish to protect. This allows you to add, remove, or modify any replication set rules without having to create a new replication set. 1. Open the Replication Console. 2. In the left pane, highlight the replication set you want to modify and expand the volume and directory levels as needed. 3.
Renaming and copying a replication set To rename or copy a replication set, open the Replication Console. Click once on a highlighted replication set name to edit the field. Specify a unique name and press Enter. The process is similar to renaming a folder in Windows Explorer. If the original replication set has not been saved (red icon), the new name replaces the original name. If the original replication set is saved (black icon), the new name creates a copy of the original replication set.
Calculating replication set size While Storage Mirroring Recover is mirroring, the right pane of the Replication Console displays statistics to keep you informed of its progress. If the size of the replication set is determined before the mirror is started, Storage Mirroring Recover can display the percentage of the replication set that has been mirrored in the Mirror Status column. If the size was not calculated prior to starting the mirror, the column displays Mirroring. 1. Open the Replication Console.
Note: You can also configure the replication set calculation when establishing a connection through the Connection Manager by selecting Calculate Replication Set size on connection on the Mirroring tab. If your replication set contains a large number of files, for example, ten thousand or more, you may want to disable the calculation of the replication set size so that data will start being mirrored sooner. If calculation is enabled, the source calculates the file size before it starts mirroring.
Deleting a replication set You can only delete a replication set if it is not currently connected. If the replication set is connected, you must disconnect the connection and then delete the replication set. To delete a replication set, open the Replication Console. Right-click the replication set icon and select Delete. Additionally, you can highlight the replication set and press the Delete key on the keyboard.
Starting replication Starting replication when establishing a connection is the default and recommended configuration. If replication is not started, data is not added to the queue on the source, and source/target data integrity is not guaranteed. To start replication, open the Replication Console. Right-click the connection on the right pane of the Replication Console and select Replication, Start.
Inserting tasks during replication Task command processing is a Storage Mirroring Recover feature that allows you to insert and run tasks at various points during the replication of data. Because the tasks are user-defined, you can achieve a wide variety of goals with this feature. For example, you might insert a task to create a snapshot or run a backup on the target after a certain segment of data from the source has been applied on the target.
Verification Verification is the process of confirming that the data on the target is identical to the data on the source. Verification creates a log file detailing what was verified as well as which files are not synchronized. If the data is not the same, Storage Mirroring Recover can automatically initiate a remirror. The remirror ensures data integrity between the source and target.
Verifying manually A manual verification can be run anytime a mirror is not in progress. 1. Open the Replication Console. 2. Right-click the connection on the right pane of the Replication Console and select Verify. 3. Select the verification options that you would like to perform. l l l Verify only—This option verifies the data and generates a verification log, but it does not remirror any files that are different on the source and target.
blocks (not the entire files) that are different will be identified in the log and remirrored to the target. Note: Database applications may update files without changing the date, time, or file size. Therefore, if you are using database applications, you should use the block checksum comparison to ensure proper verification and remirroring. 4. Click OK to start the verification.
Verifying on a schedule Verification can be scheduled to occur automatically at periodic intervals. 1. Open the Replication Console. 2. Right-click the connection on the right pane of the Replication Console and select Connection Manager. 3. Select the Verify tab. 4. Specify when you want to start the initial verification. Select the immediate date and time by clicking Now, or enter a specific Date and Time. The down arrow next to Date displays a calendar allowing easy selection of any date.
7. If you are remirroring your files, you can specify Only if Source file is newer than Target copy so that only files that are newer on the source than on the target are remirrored. Note: If you are using a database application, do not use the newer option unless you know for certain you need it. With database applications, it is critical that all files, not just some of them that might be newer, get mirrored. 8.
Configuring the verification log A verification log is created on the source during the verification process. The log identifies what is verified as well as which files are not synchronized. 1. Open the Replication Console. 2. Right-click the source server on the left pane of the Replication Console and select Properties. 3. Select the Logging tab. 4. At the top of the window, Folder identifies the location where the log files identified on this tab are stored.
name. For example, since the default is DTVerify.log, the verification log for the replication set called UserData would be UserData DTVerify.log. 6. Specify the Maximum Length of the log file. The default is 1048576 bytes (1 MB). When the log file reaches this limit, no additional data will be logged. 7. By default, the log is appended to itself each time a verification process is completed. Clear the Append check box if you do not want to append to the previous log file.
File: beta\users\vincent\training.doc DIFFERENT ON TARGET Source Attributes: Timestamp = 1/12/2010 3:28:20 PM Size = 17 Mask = [0x20] Target Attributes: Timestamp = 1/20/2010 5:05:26 PM Size = 2 Mask = [0x20] 17 BYTES OUT OF SYNC Completion Time: 1/24/2010 12:37:44 PM for connection 2 (Sales data for alpha --> 206.31.65.40 : 1100) Elapsed Time (seconds): 1320.
1. Each mask begins with 0x. Identify the hexadecimal number after the constant 0x. For example, if the mask is 0x23, then the hexadecimal number you are interested in is 23. The hexadecimal number may be up to four digits. 2. Convert the hexadecimal number to its 16-digit binary equivalent. You can use the Windows calculator for this conversion. a. Select Start, Programs, Accessories, Calculator. b. Switch to scientific view, if it is not already in that view, by selecting View, Scientific. c. Select Hex.
0000000000100011, indicates read only, hidden, and archive. Another example might be mask 0x827 which converted to binary is 0000100000100111. Positions 1-3, 6, and 12 are all enabled which indicates the file is read only, hidden, archive, and compressed. Note: Files that were replicated with the Replicate NT Security by Name feature enabled, will be identified as different in the log file because of the local name attribute. The files will be the same.
Verify applications on the target The application verification process confirms that an Exchange or SQL application database on the target is viable for failover. Note: The application verification process can only be performed on active connections that are in a good state and are not failed over. 1. Verify that you have installed the Volume Shadow Copy Service SDK. 2. Verify that your current volumes have adequate space to contain snapshots of your target.
your environment, is available in the \Samples sub-directory of your Storage Mirroring Recover installation. l Script to run before restoring normal protection—Specify a script, located in the Storage Mirroring Recover installation folder on the target, to run before stopping the application on the target. A sample script to move users, that you can modify to fit your environment, is available in the \Samples subdirectory of your Storage Mirroring Recover installation. 7.
Verifying applications on the target from the command line If desired, you can verify your application on the target by using the TDV utility from the command line.
the services you configured for application failover will be started when the test is performed. Use the ALL option if you have an application add-on such as BlackBerry. l l l l l l l l l l l ADDONSVC
Notes l l l l l Verification The application verification process from the command line is not available for Exchange or SQL in a cluster environment. If you have a cluster environment, complete your application verification process using the Application Manager. The application verification process can only be performed on active connections that are in a good state and are not failed over.
Data transmission Storage Mirroring Recover data is continuously transmitted to the target machine. Although the data may be queued if the network or target machine is slow, the default transmission setting is to transmit the data as soon as possible. You can modify the transmission to suit your environment.
Stopping, starting, pausing, and resuming transmission To start, pause, or resume the transmission of data from the source to the target, open the Replication Console. Right-click an established connection, select Transmit and the appropriate transmission control.
Scheduling data transmission Using the Connection Manager Transmit tab, you can set start and stop criteria along with a schedule window. Note: Storage Mirroring Recover checks the schedule once every second, and if a userdefined criteria is met, transmission will start or stop, depending on the option specified. Any replication sets from a source connected to the same IP address on a target will share the same scheduled transmission configuration. 1. Open the Replication Console. 2.
l l l Transmission session start—This option establishes a date and time of the day to begin transmitting data. For example, you may want to specify a transmission time that corresponds to a low bandwidth usage time. Once started, Storage Mirroring Recover will continue to transmit data until the queue is empty or until another limitation stops the transmission. Specify a Date and Time to start transmitting data.
cannot continue to queue data causing an auto-disconnect and the potential for loss of data. To avoid using the entire queue, you can configure Storage Mirroring Recover to begin transmitting data to the target when the queue reaches a certain point. This point can be defined as a percentage of the disk queue that must be in use or the number of bytes in the disk queue.
l l Time Limit—The time limit specifies the maximum length of time for each transmission period. Any data that is not sent during the specified time limit remains on the source queue. When used in conjunction with the session interval start option, you can explicitly define how often data is transmitted and how long each transmission lasts. Specify the maximum length of time that Storage Mirroring Recover can continue transmitting by indicating a length of time and choosing minutes, hours, or days.
will be established when there is 10 MB of data in the queue. The data will be transmitted and when the 10 MB Byte Limit is reached, the network connection closes. This is useful in configurations where metered charges are based on connection time. 6. Schedule a transmission window to establish a period of availability for all Storage Mirroring Recover transmissions. You can specify a begin and end time for all Storage Mirroring Recover transmissions.
l l l Enable Transmission Window—This option specifies whether a transmission window is in use. Open window time—Specifies the time, formatted for AM or PM, when the transmission window will open, allowing transmission to begin. Close window time—Specifies the time, formatted for AM or PM, when the transmission window will close, stopping all transmission. 7. Click OK to save the settings.
Limiting transmission bandwidth Bandwidth limitations are available to restrict the amount of network bandwidth used for Storage Mirroring Recover data transmissions. The network administrator specifies a percentage of bandwidth that is available or an absolute bandwidth limit for Storage Mirroring Recover transmissions and Storage Mirroring Recover never exceeds that allotted amount. The bandwidth not in use by Storage Mirroring Recover is available for all other network traffic.
4. You have three bandwidth choices. l l l No Bandwidth Limit—Data will be transmitted at all times using all available bandwidth. Fixed Bandwidth Limit—Data will be transmitted at all times according to the user-specified bandwidth configuration. Scheduled Bandwidth Limit—Data will be transmitted according to the user-specified schedule and the user-specified bandwidth configuration. 5. If you want to transmit data at all times using all of the available bandwidth, select No Bandwidth Limit. 6.
7. If you want to transmit data according to a schedule using limited bandwidth, select Scheduled Bandwidth Limit. a. Click New Event to create a bandwidth schedule event. 1. Specify a name for the bandwidth schedule event. 2. Select the day(s) of the week that you want this event to be initiated on. 3. Specify the time when you want this event to start. 4. Specify the bandwidth limitation. By default, the Unlimited checkbox is enabled.
Note: You can establish a bandwidth schedule and then disable or override it by selecting No Bandwidth Limit or Fixed Bandwidth Limit. The schedule criteria will be saved and will not be reactivated until you reselect Scheduled Bandwidth Limit. You can modify the bandwidth limits applied to a connection that is already established by right-clicking on the connection and selecting Set Bandwidth.
Compressing data for transmission To help reduce the amount of bandwidth needed to transmit Storage Mirroring Recover data, compression allows you to compress data prior to transmitting it across the network. In a WAN environment this provides optimal use of your network resources. If compression is enabled, the data is compressed before it is transmitted from the source. When the target receives the compressed data, it decompresses it and then writes it to disk.
3. By default, compression is disabled. To enable it, select Enable Compression. 4. Depending on the compression algorithms available for your operating system, you may see a slider bar indicating different compression levels. Set the level from minimum to maximum compression to suit your needs. 5. Click OK to save the settings.
Snapshots A snapshot is an image of data taken at a single point in time. Snapshots allow you to view files and folders as they existed at points of time in the past, so you can, for example, recover files that were accidentally deleted or overwritten. You could also compare a current revision of a file with an older revision. Storage Mirroring Recover utilizes snapshot functionality by allowing you to create snapshots of the replicated data stored on the Storage Mirroring Recover target.
functionality may have on Storage Mirroring Recover. For example, if you change the location where the shadow copies are stored and an error occurs, it may appear to be a Storage Mirroring Recover error when it is in fact a Volume Shadow Copy error. Be sure and review any events created by the VolSnap driver and check your Volume Shadow Copy documentation for details.
Snapshots for data workloads l Snapshot states explains the various states of data workload snapshots. l Automatic snapshots explains when automatic snapshots are taken. l Scheduling snapshots contains instructions for scheduling periodic snapshots. l Taking snapshots manually contains instructions for taking manual snapshots.
Snapshot states A snapshot may not necessarily be useful if the data on the target is in a bad state. You only want snapshots of data that is in a good state. Therefore, you need to understand when the data is in a good or bad state. Mirror started l l l l State—Bad Description—Mirroring has started, but is not complete. The data on the source and target will not be synchronized until the mirror is complete.
Write operation retried l l l l State—Good Description—An operation cannot be written to the hard drive on the target. For example, the file could be in use by another application on the target. Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will occur normally, although the operation that is being retried will not be included in the snapshot.
l l Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will occur normally. User interaction required for manual snapshots—Manual snapshots can be taken normally. Target restarted without connection persistence l l l l State—Bad Description—The target service has been restarted and was unable to persist connection information, therefore, operations that were in the queue have been lost.
l l Automatic action taken for scheduled and automatic snapshots—Scheduled and automatic snapshots will be delayed until a restore is completed or the Snapshot Reverted state is overruled by a mirror. Once the restoration or mirror is complete, automatic and scheduled snapshots will occur normally. User interaction required for manual snapshots—Restore the target data back to the source or override the Snapshot Reverted state by performing a mirror.
Automatic snapshots When Storage Mirroring Recover transitions from a good state to a bad state, it will automatically attempt to take a snapshot of the data before it leaves the good state and enters the bad state. For example, if your data is in a good state and you start a mirror, before the mirror is started, Storage Mirroring Recover will automatically take a snapshot of the target.
Scheduling snapshots You can schedule snapshots of your target data to fit your environment and needs. If the target data is in a bad state at the time of a scheduled snapshot, the snapshot will be delayed until the data on the target reaches a good state. If multiple scheduled snapshots are delayed, only one snapshot will be taken when the data reaches a good state. 1. Open the Replication Console. 2. Right-click the connection on the right pane of the Replication Console and select Connection Manager. 3.
6. Specify if you want the snapshots to start immediately. Otherwise, enter a date and time for when the snapshot schedule will begin. 7. Click OK to save the settings.
Taking snapshots manually You can manually take a snapshot of the data on the target at any time. If an automatic or scheduled snapshot is currently in progress, Storage Mirroring Recover will wait until that one is finished before taking the manual snapshot. Open the Replication Console, right-click the connection, and select Snapshot Now.
Managing full-server and application snapshots Snapshots can be created for full-server and application protections. If enabled, the default Snapshot interval is every 60 minutes. This may lead to numerous snapshots on the target that you may want to manage. You can do that from the Full-Server Failover Manger by selecting Actions, Snapshot Manager or from the Application Manager by selecting Tools, Manage Snapshots.
l l l l l l Enable periodic snapshots—This option will not be available if you do not meet snapshot requirements. If you disable or do not have access to snapshots, the data on the target at the time of a failure will be used. Snapshot Interval—By default, a snapshot of the target data is taken every 60 minutes. If desired, increase or decrease the interval between snapshots. Start now—If you want to start taking snapshots immediately after the protection is established, select Start now.
Recommended optimizations Storage Mirroring Recover is an exceptionally flexible product that can be used in a wide variety of network configurations. However, this flexibility can make implementing Storage Mirroring Recover effectively difficult. There is a often a balance that must be found between various configuration options and their relative benefits. Through years of testing and implementing in diverse environments, HP has compiled the following list of recommended optimizations.
Planning Before you begin your Storage Mirroring Recover installation, you should plan your implementation strategy. Ask yourself the following questions. l l l l l What is the role of each server? Will this server be a source? Will this server be a target? Is the source server a Domain Controller? Or does it have another very specific role or configuration? You may want consider protecting the entire server in these cases.
l l Create a connection to the Diagnostics target. This connection uses a built-in null (non-existent) target to simulate a real connection. No data is actually transmitted across the network. Since there is no true connection, this connection type helps you plan your implementation strategy. After the connection has run for hours, or even days, use DTStat to convert the statistics file to a .csv file, which can be opened in a spreadsheet for analysis.
Installation Make sure you review all of the Storage Mirroring Recover requirements, including the general source and target requirements and the requirements that are specific to your workload type. When you perform the installation, you will have several decisions to make. l l l l Login—Always log on to the server with an account that is in the local Administrators group before starting the installation. Components—Decide what components to install and where to install them.
l Upgrades—Keep the following caveats in mind when upgrading. l l l l If the connection was created with the Application Manager or Full Server Failover Manager, disable protection to disconnect the connection prior to upgrading and then re-enable protection after the upgrade. If Storage Mirroring Recover does not function correctly after the upgrade, run the Storage Mirroring Recover Setup, select the Repair option, and reboot the server.
General optimizations The following are general optimizations that can be used for any Storage Mirroring Recover workload type. l Performance optimizations l General manageability l Anti-virus protection l Hardware configurations Performance optimizations l Initial mirror across slow network—A large amount of data that is being mirrored across a slow network may take days to complete the initial mirror, depending on the amount of data and the available bandwidth.
l l l l l l Low bandwidth and queuing—In low bandwidth environments, you may need to revisit the queuing configuration you established when you were installing Storage Mirroring Recover. See the installation optimizations and Queuing data for more details on the memory and disk queues. High latency and mirror packet size—In a high latency environment (greater than 100 ms response times), you may want to consider increasing the size of the packets of mirror data. The default value is 65536 bytes.
l Disable root encryption—If the top-level folders in your replication sets are not encrypted, you can gain a performance improvement by disabling root encryption. This option is available under HKEY_LOCAL_ MACHINE\SOFTWARE\NSISoftware\DoubleTake\CurrentVersion\EnableRootEncryption. The value is hexadecimal. The valid values are 0 to disable root encryption or 1 to enable root encryption. See Server Settings in the Scripting Guide for more details on this option.
l l l l E-mail notification—Enable e-mail notification through the Server Properties Email Notification tab so that you are notified when a Storage Mirroring Recover message is written to the Event log for that server. Target path blocking—Target path blocking prevents the modification of the copy of the source data on the target until failover has occurred or protection is disabled.
Anti-virus protection l l Storage Mirroring Recover queues—Exclude the Storage Mirroring Recover queue directory on the source and target from any real-time scanning or scheduled system scans. If a queue file is deleted by a process other than Storage Mirroring Recover, unexpected results may occur, including an auto-disconnect due to the loss of queued data. The files in the source queue directory have already been scanned (cleaned, deleted, or quarantined) in their original storage location.
Application workloads Review the following optimizations when you are protecting applications on your source. l General applications l Exchange l SQL General applications l l l l l Application services on the target—Ensure that all application services on the target are stopped and set to manual. Connection mappings—When protecting an application server, select the One To One mapping in the Connection Manager.
Exchange l l l l Exchange 2003 and 2007—Use the Storage Mirroring Recover Application Manager for Exchange 2003 and 2007, which will automatically identify all of the relevant Exchange items that are needed for protection and includes numerous checks to ensure the source and target are configured correctly. Exchange 2010—Use the full-server protection if you are using Exchange 2010. /3GB and /userva switches—The /3GB and /userva switches in the boot.
SQL Service Principal Names (SPNs) during failover and failback. If you have to use different accounts, Kerberos authentication will require the Service Principal Names to be failed over. See the technical support article 3084 for details on failing over the Service Principal Names. l Use block checksum for all files during a difference mirror—Configure each source for the block checksum all option.
Cluster workloads You should carefully review Microsoft documentation and resources for properly configuring your cluster before implementing Storage Mirroring Recover on a cluster. The Microsoft TechNet articles Failover Clusters and Installing and Upgrading Cluster Nodes are two resources you can start with. There are many other resources available on the Microsoft TechNet web site.
Security To ensure protection of your data, HP products offer multi-level security using native operating system security features. Privileges are granted through membership in user groups defined on each machine. To gain access to a source or target, the user must provide a valid operating system user name and password and the specified user name must be a member of one of the Storage Mirroring Recover security groups.
Security credentials When a client machine attempts to access a source or target machine running on Windows, it will attempt to automatically logon to the source or target using the three methods below. l l The security credentials of the user currently logged into the client machine are sent to the source or target machine. From the security credentials, the source or target machine determines if the user is a member of the security groups and if so, grants the appropriate level of access.
Note: If a user name exists both on the local machine and on the network, Windows first attempts to login to the machine with the local user name and password and ignores the domain. If this fails, it then tries to login with the network user name, password and domain.
Adding users to the security groups The security groups are automatically created during the installation process. The groups are assigned specific case-sensitive names. l Double-Take Admin l Double-Take Monitors The local administrator and the domain administrator are automatically added to the Double-Take Admin group. Note: If Storage Mirroring Recover is installed on a member servers, it will use the local groups.
Changing the account used to run the Storage Mirroring service By default, the Storage Mirroring service is configured to log on as the system account. If you want to select a specific account to run the service, use these instructions. Note: If you are protecting full-server workloads, you cannot modify the account used to run the Storage Mirroring service. Otherwise, the full-server protection will not function correctly. 1. Modify the user account that the Storage Mirroring service is using. a.
3. Add the domain account to the local administrator group. a. Select Start, Programs, Administrative Tools, Computer Management. b. Expand the Local Users and Groups folder and highlight the Groups folder. c. Right-click on the Administrators group on the right pane of the screen and select Add to Group. d. Click Add. e. Locate the domain account that you are using for the Storage Mirroring service. Select that account and click OK. f. Click OK to close the Administrators Properties dialog box. g.
Evaluations You may want to evaluate Storage Mirroring Recover before implementing it in your production environment. This is a good process for users who want to see, first-hand, the benefits that Storage Mirroring Recoverhas to offer. The evaluation processes walk you through a step-by-step process to assess the key Storage Mirroring Recover features. Select a link below based on the type of evaluation you would like to perform.
Evaluating data protection The following evaluation procedure has eleven tasks containing step-by-step instructions for evaluating the data protection functionality of Storage Mirroring Recover. Before starting this evaluation procedure, make sure you have reviewed the server requirements and that you have installed the software on both the source and target. Also, you should have approximately 500 MB to 1 GB of data on the source for testing.
Establishing a connection 1. Open the Replication Console. 2. Click Make a connection from the right pane of the Replication Console. If that quick launch screen is no longer visible, select Tools, Connection Wizard. Note: If the Storage Mirroring Servers root is highlighted in the left pane of the Replication Console, the Connection Wizard menu option will not be available. To access the menu, expand the server tree in the left pane, and highlight a server in the tree. 3.
logon is not successful, the Logon dialog box will appear prompting for your security identification. When logging in, the user name, password, and domain are limited to 100 characters. 6. On the next screen, verify Create a new replication set with this name is selected. 7. Enter a name for your replication set, and click Next to continue. 8. A tree display appears identifying the volumes and directories available on your source. Mark the check box of the volumes and/or directories you want to protect.
Monitoring the activity and completion of the initial mirror View your new connection in the Replication Console by highlighting the source on the left pane. The connection will appear on the right pane. Use the horizontal scroll bar at the bottom of the right pane to view the status columns. Pay attention to the Mirror Status column which shows the status of the mirroring operation. During the mirroring process, you will see a percentage of the mirror that has been completed.
Changing data to cause replication In order to test replication, you need to change the data on your source. This includes modifying existing files, creating new files, deleting files, and changing permissions and attributes. 1. On the source, browse through the directories and files contained in your replication set. 2. Select four files from your source and record the file name, date, time, and file size for each file. 3.
Note: Many user applications typically save an entire file even though only a portion of the file may have changed. Therefore, the replication statistics will show the entire file being transmitted, not just the changed data. To confirm that replication only transmits the changed segments of files, you must use an application, such as a database application, or a command, such as the echo command, to save only the changed portions of a file.
Verifying the data changes on the target Now that you have modified some of the files, you want to be sure that the file modifications were applied correctly. Note: Because of the way the Windows Cache Manager handles memory, machines that are doing minimal or light processing, as you are in this evaluation, may have file operations that remain in the cache until additional operations flush them out. This may make Storage Mirroring Recover files on the target appear as if they are not synchronized.
Just like when you were monitoring the mirror and replication processes, you can monitor the verification process. Notice that the Mirror Status column changes to Verifying while the verification process occurs. When the verification is complete, Storage Mirroring Recover will have created a log file for you to review. 5. Wait until your Mirror Status has returned to Idle and then open the file DTVerify.log located in the Storage Mirroring Recover installation directory on your source.
Testing your target data At this point in your evaluation, you may want to test your target data. The type of testing you will need to perform will depend on the type of data you are protecting. l l User data—If you are protecting user files, you can use the associated application to open the files on the target. Open one or more of the files to test the integrity of the data.
you do want the newer files on the target to be overwritten by the files from the source. Click OK to begin the mirror. When the mirror is complete, your source and target will again be synchronized and you can continue with your evaluation.
Configuring failover monitoring The following instructions will configure failover monitoring. 1. Open the Failover Control Center. 2. Select your target from the Target Machine list box. 3. Click Login to login to the selected target. 4. Click Add Monitor. The Insert Source Machine dialog box appears in front of the Monitor Settings dialog box. 5. Type in your source machine name and click OK.
to Active Directory on the target. If you are using Active Directory, enable this option or you may experience problems with failover. 8. Failback Hostname returns the host SPN on the source and target back to their original settings on failback. If you are using Active Directory, enable this option or you may experience problems with failback. 9. If you are failing over or failing back hostnames, you need to specify an Active Directory user that has update privileges within Active Directory.
Monitoring failover Since it can be essential to quickly know the status of failover, Storage Mirroring Recover offers various methods for monitoring the state of failover. When the Failover Control Center is running, you will see four visual indicators.
The Failover Control Center does not have to be running for failover to occur. Monitoring failover monitoring contains more information on the Failover Control Center visual indicators.
Simulating a failure To fully evaluate failover, you need to simulate a failure. The Failover Control Center does not have to be running in order for failover to occur, but for the purpose of this evaluation, make sure that it is running so that you can see each step of the process. 1. Ping the source’s IP address from a client machine. 2. Ping the source’s machine name from a client machine. 3. Disconnect the network cable(s) on the source.
Simulating data changes after failover While your source is failed over to your target, end users continue to work without interruption and the data on the target will be updated. To fully evaluate the next step, restoration, simulate the changes that the end users would have made on the target while the source was unavailable. 1. Identify the file that you edited earlier on the source. 2. Locate that same file on the target and make edits to it. Save the changes. 3.
Initiating failback When failover occurs, a source machine has failed. The steps below must be used to complete failback, which releases the source identity from the target. 1. If this were a real failure scenario and not an evaluation, you would first verify that your source machine is not connected to the network. If it is, you would have to disconnect it from the network. 2. Next you would resolve the source machine problem that caused the failure.
6. At this time, you would connect the source to the network. For this evaluation, reconnect the network cable(s) on the source that you disconnected to simulate the failure. 7. After the source is online, select Stop in the Failover Control Center to indicate that you do not want to continue monitoring the source. At this time, your target is back to its original identity and the source is back online.
Restoring your data The Replication Console provides an easy method for restoring replicated data from the target back to the original source or to a new source server. You are only required to input the original source, the target, and the name of the replication set you want to restore. Storage Mirroring Recover handles the rest, including selecting the files in the replication set and restoring them to the correct location. 1. From the Replication Console, select Tools, Restoration Manager. 2.
5. Select the Restore To machine. For this evaluation, select the original source. This is the machine where the copy of the data will be sent. 6. The Restore To and Restore From paths will automatically be populated when the replication set is selected. The restore to path is the directory that is the common parent directory for all of the directories in the replication set. If the replication set crosses volumes, then there will be a separate path for each volume.
Evaluating full-server protection The following evaluation procedure has five tasks containing step-by-step instructions for evaluating the full-server protection functionality of Storage Mirroring Recover. Before starting this evaluation procedure, make sure you have reviewed the server requirements and that you have installed the software on both the source and target. Also, make sure that the target you select is compatible to stand-in as the source.
Establishing full-server protection 1. Login as a user that is a member of both the Double-Take Admin and local Administrators security groups. 2. Open the Full-Server Failover Manager. 3. Enter your source and target servers. You can click Browse when selecting either server to locate it by drilling down through your network. After you have specified a server name, enter login credentials when prompted.
6. Double-click on any of the validation items to see details. You must correct any errors before you can enable protection. Depending on the error, you may be able to click Fix or Fix All and let Storage Mirroring Recover correct the problem for you. For those errors that Storage Mirroring Recover cannot correct automatically, you will need to modify the target to correct the error, or you can select a different target.
Monitoring the activity and completion of the initial mirror After you have enabled full-server protection, you can monitor the protection from the Full-Server Failover Manager. The Protection Status is displayed in the right center of the Full-Server Failover Manager. You can tell the status of your protection from this field. 1. Watch as the mirroring percentage increases. When the mirroring is complete, the status will change to Enabled. 2. Look at your target and you will see the data from the source.
Changing data to cause replication and verifying the data changes In order to test replication, you need to change the data on your source. This includes modifying existing files, creating new files, deleting files, and changing permissions and attributes. 1. On the source, browse through the directories and files. 2. Select four data files from your source and record the file name, date, time, and file size for each file. 3.
Simulating a failure To fully evaluate failover, you need to simulate a failure. To do this, power off the source. Watch as the status changes to Failover condition met.
Starting failover When a failover condition is met, you will want to start failover. You can actually start failover without a failover condition, as long as protection is enabled. For example, you may want to force a failover when upgrading to a better source server. Note: If you are testing failover and your source is a domain controller, do not let the domain controller communicate with any other production domain controllers after failover.
failover, the target will be rebooted automatically. After the reboot, the target will no longer exist, since it will become the source. Note: Because the Windows product activation is dependent on hardware, you may need to reactivate your Windows registration after failover. Follow the on-screen prompts to complete the reactivation. After your target has failed over and becomes your source, you can stay with that configuration long term.
Index . .
scripts snapshots storage group workload Application Manager auto-disconnect 246 229, 609 233 21, 23, 136, 218 128, 130 532 auto-reconnect 532, 534 auto-remirror 143, 541 B backup 535 bandwidth ESX 259, 293 Hyper-V 259, 271 limiting 592 standard cluster 303 BIND DNS client 350 BlackBerry protection requirements 232 54 C chained configuration 27 cluster failover 336 monitoring 391 requirements workload compression application workload Index 45, 48, 52, 65 21, 25, 136, 302-303, 322
ESX 259, 293 files 550 full-server workload 205 GeoCluster 322, 329 Hyper-V 259, 271 standard cluster 303 using 596 configurations chained 27 many-to-one 27 one-to-many 27 one-to-one 27 connection applications 230, 250 block target path writing 536 Connection Manager 143 Connection Wizard 138 console 383 controls 375 database storage file 183 disconnect 537 firewall 149 ID 525 NAT 149 overview 525 reconnect 534 simulating 151 target processing 535 Connecti
Connection Wizard console 137-138 84, 100 Application Manager 128 connections 383 credentials 95 ESX 131 Failover Control Center 118 Full-Server Failover Manager 122 options Replication Console requirements 97 101 67 servers 90, 92 starting 85 credentials 211 Failover Control Center 121 Full-Server Failover Manager 125 Replication Console 117 scripts 187 D data evaluating 632 failover 153 failover monitoring 366 monitoring server settings workload database storage files
disk signature DNS 195 221, 343 A records 221 alternate 350 failback 521 MX records 221 non-Microsoft 350 primary server 221 reverse lookup 221 zone 221 domain controllers Double-Take Source Connection dynamic volumes 338 25, 303 550 E e-mail notification data 188, 441 ESX 135, 295 EFO 255 encrypted files 550 error codes 472 ESX activation codes 132 console 131, 134 e-mail notification 135, 295 installation 74 login 282 monitoring 374 ports 281 protection Index
requirements 56, 59, 63 scheduling 291 servers 134 transmission 293 VirtualCenter 96, 133, 296 evaluations data workload 632 full-server workload 652 overview 631 event messages 94, 188, 413-414, 441 Exchange protection requirements verification Exchange Failover utility exporting server configuration file 232 48 581 255 86, 88-89 F failback application data workload 516 499-500, 506 DNS 521 full-server 511 identity 518 virtuals 524 workload 498 failover Active Directory appl
cluster workload 336 data 153, 479 DNS 221, 343 domain controllers full-server Macintosh shares monitoring NFS shares 338 201, 483-484, 487 352 154, 162-163, 366 354 overview 16, 478 PRO tips 279 scripts 154 shares 154, 161 special configurations undo virtuals WINS 337 495, 497 494-495, 497 340 Failover Control Center overview 118 ports 119 refresh rate 120 security credentials 121 starting 118 file attributes 550 file differences mirror establishing a connection 143 options
requirements 55 file shares 232, 239 file system 34 filters firewall 94, 375 34, 137, 149, 206, 251, 298 full-server compatible target 192 compression 205 evaluating 652 failover 201, 483-484, 487 firewall 206 mirroring 204 monitoring 369 NAT 206 network communications 202 requirements 45 server data 198 snapshot 609 snapshots 200 target services 199 transmission route 203 workload 21-22, 136, 191, 195, 197 Full-Server Failover Manager log file 124 monitor method 1
starting 122 G GeoCluster compression 322, 329 monitoring 391 online pending 329 orphan files requirements resource properties Windows configuration workload getting started 322, 329 65 329 80 21, 25, 302, 322 86, 88-89 H hosts file 221 Hyper-V monitoring protection requirements 374 258, 271 56-57, 61 I ICMP 149 identity failover 224 importing server configuration file installation 86, 88-89 74 automatic process 76 notes 69 overview 68 process 71 Index Page 668 of 677
J junction points 550 L licensing 167 logging event messages filtering log file 413-414 403 185, 396, 405 messages 406 verification 574 viewing log file 397 logging on and off Replication Console LogViewer 102 403 M Macintosh files 550 shares 352 many-to-one configuration 27 memory requirements 34 mirroring 143 application workload 242 automatically 541 controls 539 full-server workload 204 overview scripts Index 16, 538 543 Page 669 of 677
Monitor Connections page 375 monitoring application 371 cluster 391 data 356 data workload 357 ESX 374, 387 failover data 366 full-server 369 Full-Server Failover Manager 126 Hyper-V 374 virtual 374 workload 355 mount points 550 MX records 221 N named pipes NAT NetBIOS 102 137, 149, 206, 251 339 network communications data workload 172 full-server workload 202 NFS shares 354 O one-to-many configuration 27 one-to-one configuration 27 operating system requirements Inde
options console 97 orphan files GeoCluster 322, 329 removing 546 standard cluster 303 overview 15-16, 21-25, 27, 84 P path Performance Monitor ports 375 456-458 61, 63, 99, 280 application workload 251 ESX 281 Failover Control Center 119 full-server workload 206 NAT 206, 251 NAT or firewall 149 server 172 virtual workload 298 pre-requisites See requirements pre-staging 259 PRO tips 279 protection application 211 cluster 302 data 137 ESX 258-259 full-server Hyper-V
virtual 258 Q queues auto-disconnect 532 auto-reconnect 532 overview 526 queuing data 173, 528 R reconnecting automatically refresh rate 534 98 remirror 143 reparse points 550 replication capabilities overview 550 16, 549 starting 567 tasks 568 Replication Console group and server configuration 113 logging on and off 102 message window 397 overview 101 security credentials 117 starting 101 tree 105 workspaces 114 replication set application Index 244 Page 672 of 677
calculating size 564 copying 563 creating 141, 558, 560 database storage file 183 deleting 566 limitations 554 modifying 560, 562 overview 554 renaming 563 requirements 33-34, 45-46, 48, 52, 54-57, 59, 61, 63, 65, 67 restoration application data workload 516 500, 506 full-server 511 overview 16 virtuals 524 route application 231 ESX 259, 293 Hyper-V 259, 271 S scheduling 291, 586 scripts application 246 credentials 187 data failover 154 mirroring 543 security cred
Failover Control Center 121 Full-Server Failover Manager 125 groups 628 overview 625 Replication Console 117 service 629 server configuration file 86, 88-89 server identity 165 server settings 164 shares silent install simulating a connection 154, 161, 352, 354 76 137, 151 snapshots application 229, 609 automatic 605 data 600 ESX 293 full-server 200, 609 manual 608 overview 598 requirements 34 scheduling 606 states 601 SNMP configuration 464 overview 463 statistic
source data processing options 177 definition 15 requirements 34 server startup options 169 SQL protection requirements verification statistics file 232 52 581 375 185, 445, 447 output 449 overview 444 Performance Monitor SNMP 457-458 468 storage group 233 symbolic links 550 synchronization 16 T target block writing 536 data processing options 180 definition pause requirements 15 535 34 resume 535 verify data 579 target data verification TDU Index 581 137, 151 Page 675 of
TDV time to live transactional NTFS operations (TxF) See target data verification 48, 221, 343 550 transmission bandwidth compression 592 205, 596 controls 585 network communications 172 overview 584 route full-server 203 schedule database storage file 183 TTL TxF (transactional NTFS operations) See time to live 550 U UDP undo failover 149 495, 497 upgrade notes 69 overview 68 process 71 V verification application 581 application target data 579 log file 185, 574 manual 570 o
virtual failback 524 failover 494-495, 497 firewall 298 monitoring 374 PRO tips 279 protection 258 requirements restoration workload VirtualCenter VMotion 56 524 21, 24, 136 59, 63, 96, 133, 259, 296 59, 134, 282 W WINS 340 workload monitoring overview protection Index 355 21-25 136 Page 677 of 677
