Application Level Protection (SQL Server) using Double-Take Availability v7

Application Level Protection (SQL Server) using Double-Take Availability v7


The following video demonstrates how to protect SQL Server 2012 running on Windows Server 2012 to a standby Server, using the "Application Level" SQL protection option of Double-Take Availability 7.0.

Data and Applications running on protected servers (such as SQL Server, MS-Exchange, Oracle) are replicated and protected as part of the full server protection job and are fully available for use on the target server following fail-over... just as they were on the source server prior to fail-over.

The Source and Target servers can be physical or virtual... and the protection can be from one to another.
Example: P2V, V2V (including cross-hypervisor), V2P, P2P

The demonstration specifically details:
  • Configuring Double-Take Availability with an Application Level Protection job
  • Synchronize data from source server to target server
  • Monitor the Double-Take job
  • Fail-over from source server to target server
  • Invoke Reverse Protection while failed over
  • Fail-back to original source server

Demonstration


Youtube Video: Demonstration

Double-Take Application Level Protection (for SQL) Requirements

In addition to the Core Double-Take requirements (see User Guide), use these requirements for full server protection.
  • SQL versions—Double-Take can protect Microsoft SQL Server or Express 2005, 2008, 2008 R2, or 2012.
  • SQL and network configuration—The following requirements and limitations apply to your SQL server and network configuration.
  • All Microsoft best practices should be used for all versions of SQL.
  • You should use the same version, service pack, and architecture (32-bit or 64-bit) of SQL Server on both the source and target servers.
  • SQL 2012 is the only supported SQL version if you are using Windows 2012 in a cluster configuration.
  • If you are using SQL 2008 R2, cluster to cluster configurations are supported, however, the AlwaysOn cluster feature is not supported.
  • If you are using SQL Express 2008, you will need to enable and start the SQL Browser Service. By default, this service is set to disabled. Additionally, you will need to enable TCP/IP to accept remote connections. To do this, launch the SQL Server Configuration Manager. Expand SQL Server Network Configuration, and under Protocols enable TCP/IP.
  • If you are using SQL Express 2005, you will need to enable named pipes and TCP/IP to accept remote connections. To do this, launch the SQL Server Configuration Manager. Expand SQL Server 2005 Network Configuration, and under Protocolsenable Named Pipes and TCP/IP.
  • The SQL program files must be installed in the same location on the source and target.
  • The drive letter(s) where SQL stores its data on the source must be the same on the target.
  • The source and target servers must have named instances with the same name installed prior to configuring protection.
  • Single-label DNS domain names (those without a suffix such as .com, .corp, .net) are not supported.
  • In environments where the FIPS security policy is enabled, you must use impersonation, which requires the following.
  • The user running the Double-Take Console must have all appropriate rights to update the domain (that is, only impersonation is supported).
  • You must manually verify DNS rights by running the DFO utility with the /test parameter.
  • Microsoft Server Core is not supported.
  • If your source and target are in a domain, they 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.
  • If you are using SQL 2005 or later and are using a domain service account that is not in the domain or local Administrators security group, the replicated databases will not mount on the target after failover or on the source after restore because of security restrictions at the file system level. You need to place the SQL 2005 service account in the local Administrators group on the source and target because of the way these versions of use local groups for NTFS permissions.
  • You may want to exclude the tempdb database to reduce mirroring and replication traffic.
  • Transparent Data Encryption (TDE) is supported for SQL 2008, however the SQL service must be running with the same service account on the source and target.
  • You should use a domain user account as the Windows Service Account for SQL. See "Setting Up Windows Service Accounts" on the Microsoft web site for more information. You should include this account in the local Administrators group on your source and target to ensure that the appropriate permissions for the replicated databases and log files will be available after failover and failback.
  • Double-Take does not support a SQL default instance that is using non-default ports.
  • Snapshots—You can take and failover to Double-Take snapshots using a SQL job, however snapshots are not supported if your source and/or target is a cluster. See Core Double-Take requirements section of the User Guide for the specific snapshot requirements.



Article ID: SLN310796

Last Date Modified: 08/13/2018 07:51 AM


Rate this article

Accurate
Useful
Easy to understand
Was this article helpful?
Yes No
Send us feedback
Comments cannot contain these special characters: <>()\
Sorry, our feedback system is currently down. Please try again later.

Thank you for your feedback.