Microsoft SQL Server Requirements
Before registering each SQL server in ECX, ensure it meets the following requirements.
|Database Versions/Types and Operating Systems||Server Types||Storage Systems||Storage Configuration|
Standalone, SQL Server Failover Clustering, and AlwaysOn configurations are supported for SQL 2012, SQL 2014, SQL 2016, SQL 2017, and SQL 2019.
Note: It is highly recommended to install the latest SQL Server patches and updates in your environment.
|Physical     ||
Note: VM Replication restore jobs can be run to store off-host copies on the storage systems listed above.
 Windows Remote Shell (WinRM) must be enabled.
 Note that Clustered Shared Volumes (CSV) are not supported.
 See System Requirements for supported VMware vSphere versions.
 Select the Physical provider type when registering the provider in ECX. Recoveries require direct access to storage. Note that NetApp ONTAP and DellEMC storage systems are not supported.
 vRDMs are supported through VM Replication jobs.
 Independent disks are supported only if the underlying storage utilizes supported storage systems. Register the SQL resource as Physical when configuring the provider in ECX. Note that independent disks do not allow snapshots to be taken in VMware virtual scenarios. The above listed IBM Spectrum Accelerate, IBM Spectrum Virtualize, and Pure Storage FlashArrays are supported for physical registration.
 When registering physical SQL servers it is recommended to register via the DNS server. The ECX appliance must be resolvable and route-able by the DNS server; the physical SQL server will communicate back to ECX through DNS.
 Recovery for target servers registered as Physical provider types requires direct access to storage.
 Any Windows node with iSCSI or Fibre Channel access to the storage can be selected as a proxy server, provided that the node is not part of the original cluster. It is recommended to select a standalone virtual or physical Windows node as a proxy server.
 For physical SQL servers you must allow outgoing connections to port 8443 on the ECX appliance from the SQL server.
 Dynamic disks are not supported.
 HPE Nimble Storage must be version 5.2 or later to support iSCSI and Fibre Channel.
 The make permanent option is not available for HPE Nimble Storage using physical disks.
 SQL PIT (point-in-time) recovery is not supported with HPE Nimble Storage.
SQL servers residing on any storage can also be protected to supported storage systems through VM Replication jobs.
For both physical and virtual SQL environments, point-in-time recoveries beyond the last snapshot taken are incompatible with workflows utilizing more than one Site. In a virtual environment, the SQL server, associated vCenter, and storage must be registered to the same site. In a physical environment, the SQL server and storage must be registered to the same site.
 On IBM Systems Storage, condense is run during maintenance jobs.
For more information about Microsoft SQL Server requirements, see Microsoft SQL Server Support FAQ.
SQL Support for VMware Virtual Machines
UUID must be enabled to perform Microsoft SQL-based backup functions. To enable, power off the guest machine through the vSphere client, then select the guest and click Edit Settings. Select Options, then General under the Advanced section. Select Configuration Parameters..., then find the disk.EnableUUID parameter. If set to FALSE, change the value to TRUE. If the parameter is not available, add it by clicking Add Row, set the value to TRUE, then power on the guest.
The virtual machine must use SCSI disks only, dynamic disks are not supported.
The latest VMware Tools must be installed on the virtual machine node.
In-Memory OLTP Requirements and Limitations
In-Memory OLTP is a memory-optimized database engine used to improve database application performance, supported in SQL 2014 and 2016. Note the following ECX requirements and limitations for In-Memory OLTP usage:
- The maximum restore file path must be less than 256 characters, which is a SQL requirement. If the original path exceeds this length, consider using a customized restore file path to reduce the length.
- The metadata that can be restored is subject to VSS and SQL restore capabilities.
The goal of seeding is to restore a secondary database by taking advantage of snapshot technology, and minimize the data movement between primary and secondary replicas.
Seeding of both virtual and physical SQL servers is supported. The seeding destination replica must be an instance of a secondary role and must be created or configured with a working mirroring endpoint before the seeding process. The seeding process restores using the original database only, and only the latest backup snapshot is supported.
Source databases must be backed up under the full recovery model, which is configured though the SQL Management Console. The full recovery model provides a granular transaction restore. Note that the transaction log can grow indefinitely unless the logs are backed up, which will automatically initiate log truncation. It is recommended to have a database administrator run maintenance to free space if necessary.
Before the seeding process, primary databases and log backups are required to ensure the LSN gap between the primary and secondary databases is acceptable by the SQL AAG framework.
The datafile and logfile paths on all replicas of an availability group must be the same. ECX requires that the original volume mount points are available on the target SQL node for seeding process. If the original volume was mounted on a volume mount point, such as a folder, the root drive letter of the mount point must exist before the restore begins.
When creating an Instant Seeding restore job definition, the destination must be a non-system drive. The SQL database and log files must be located on non-system drives.
A network share for Always On log backups must be accessible from the secondary node. The seeding restore will restore log backups directly from the original log backup target instead of the temporary snapshot.
Register each SQL server as a provider in ECX by name or IP address. When registering a SQL Cluster (AlwaysOn) node, register each node by name or IP address. Note that the IP addresses must be public-facing and listening on port 5985. The fully qualified domain name and virtual machine node DNS name must be resolvable and route-able from the ECX appliance.
The user identity must have sufficient rights to install and start the ECX Tools Service on the node. This includes "Log on as a service" rights. For more information about the "Log on as a service" right, see https://technet.microsoft.com/en-us/library/cc794944.aspx.
The default security policy uses the Windows NTLM protocol, and the user identity format follows the default domain\Name format.
You must manually create a directory to store VSS provider logs when running ECX 2.6 and earlier. Create the following directory structure on the SQL server: c:\temp\
Kerberos-based authentication can be enabled through a configuration file on the ECX appliance. This will override the default Windows NTLM protocol.
For Kerberos-based authentication only, the user identity must be specified in the username@FQDN format. The username must be able to authenticate using the registered password to obtain a ticket-granting ticket (TGT) from the key distribution center (KDC) on the domain specified by the fully qualified domain name.
Kerberos authentication also requires that the clock skew between the Domain Controller and the ECX appliance is less than 5 minutes. Note that the default Windows NTLM protocol is not time dependent.
On the SQL server, the system login credential must have public and sysadmin permissions enabled, plus permission to access cluster resources in a SQL AlwaysOn environment. If one user account is used for all SQL functions, a Windows login must be enabled for the SQL server, with public and sysadmin permissions enabled.
Every SQL instance can use a specific user account to access the resources of that particular SQL instance.
To perform log backups, the SQL user registered with ECX must have the sysadmin permission enabled to manage SQL server agent jobs. If the SQL server agent service user is the default NT user, the agent will use that account to enable/access log backup jobs.
Support for restoring SQL Always On availability groups (AG) databases to a stand alone SQL Server using ECX
Restoring SQL Always On availability groups (AG) databases to a stand alone SQL Server for recovery requires the special considerations outlined below:
- Ensure that the standalone SQL Server to be used for recovery, the NetApp CIFS server, and the source AG are in the same Active Directory (AD) domain.
- The AD account user that is registered to the standalone server in ECX requires full access rights to the CIFS share from the recovery SQL Server.
- The SQL Server and the SQL Server Agent services must have the 'Login As' property set to an AD user that has full access rights to the CIFS share.
- The 'Login As' user used above and the user used to register SQL within ECX must be granted administrator rights to the SQL Server operating system and should have the local security rights to ‘Login as a Service’.
- The 'Login As' user used above and the user used to register SQL within ECX must be defined as SQL login with ‘dbcreator’, ‘sysadmin’ and ‘public’ roles.
- The NetApp SVM containing the recovery CIFS volume should have it’s CIFS Server configured to the same domain as the source.
- The CIFS and NFS Services need to be enabled for the NetApp SVM containing the recovery CIFS volume. It should also have a LIF with both CIFS and NFS protocols defined.
Performing the recovery will create the recover shares with access set to 'Everyone' (all AD users).
Catalogic ECX™ 2.12
© 2021 Catalogic Software, Inc. | All rights reserved.