Linking SQL Server dSources with Delphix managed backups

Getting started

The Data Management page of the link wizard for SQL Server dSources provides the option to enable Delphix Managed Backups.

It possible to enable this feature here at link time or toggle it on after the link for future syncs. If you enable this feature, the dSource can only use copy-only full backups taken by the Delphix Engine to stay in sync with its source; the Delphix Engine will prohibit syncing using existing backups. Checking the Enabled box results in the following changes to the Data Management page:

The initial load option is set to a copy-only full backup taken by the Delphix Engine
The ability to provide a backup path disappears
A SnapSync policy selection screen appears in the Policies page

You can select from the list of existing SnapSync policies if the one you want doesn't exist you will need to create a new one on the Policies page under the Manage dropdown. Proceeding through the remainder of the link wizard will create a dSource with Delphix-managed backups enabled. You can confirm that a dSource has the feature by selecting the dSource and going to the Configuration > Data Management tab after creation and checking the Delphix Managed Backups section, as displayed below:

To disable/enable this feature after linking:

Toggling Delphix Managed backups is supported for SQL Server dSources. This means a dSource that was previously created with Delphix Managed Enabled can have regular validated sync and similarly a dSource that had external backups can use Delphix Managed Backups.

To disable Delphix Managed Backups for a specific dSource, select that specific dataset and go to Data Management tab under the Configuration tab.

Click the edit button and uncheck this feature. Then update all new inputs.

To enable this feature just go to the same edit menu.

When to use Delphix managed backups?

There are a number of situations where Delphix managed backups are not the best solution. Delphix released a new feature called Staging Push in version 6.0.13.0 that offers users more control over ingesting backups from source databases.

Method	Pros	Cons
Delphix managed backups	Good for smaller databases when Delphix doesn’t support a certain backup provider.	Network bandwidth. As we describe in this KB article ( https://support.delphix.com/Continuous_Data_Engine_(formerly_Virtualization_Engine)/MSSQL_Server/Configuring_Compression_in_Delphix_Managed_Backups_(KBA3799) ), Delphix-managed backups transit the network 4 times so a 1TB database ends up consuming 4TB of network bandwidth for the duration of the SnapSync job. Delphix backs up the database onto storage provided by the Delphix Continuous Data Engine. The backup will exist on Delphix storage for as long as it takes to restore it into the dSource’s staging database. This may require additional capacity on your Delphix Engine. For example, if you run two Delphix Managed Backups simultaneously for two 4 TB databases that are TDE encrypted, Delphix will need 8 TB of data to temporarily store these backups. A large database that is encrypted with TDE will consume as much disk space as it takes to store the full, encrypted backup on the Delphix Engine for the duration of the SnapSync job. Delphix-managed backups can be slow compared to other solutions. All of the solutions will rely on network throughput, network latency, and storage performance. However, since the Delphix-managed backup must be created before it can be restored, this can easily double the amount of time it takes for the SnapSync job to compete. Other methods save a lot of time by ingesting existing backups. If the engine lives in a cloud environment (AWS, Azure, GCP, etc.) that is subject to instance type limitations, running several Delphix Managed Backups could exceed throughput limits for the instance type resulting in the provider throttling the Delphix Engine’s I/O (slowing the disk reads and writes). All of the other source database ingestion solutions might run into instance type limitations but the Delphix Managed Backup solution must write the full backup to its storage which adds time to the ingestion. There is an increased chance of having simultaneous, multi-day ingestions overlapping and hitting the instance type limits.
Staging Push	Good for larger databases. Cuts backup ingestion times by restoring existing backups because Delphix does not have to take a backup of the database in the first place. Reduces the load on the network. Please check this article for more details, refer to the Configuring Compression in Delphix Managed Backups). Reduces the amount of storage each Delphix Engine requires for storing the Delphix-managed backups.	End users are responsible for scripting the “RESTORE” syntax for their backup provider. An example is given in the Delphix SQL Server Staging Push documentation: https://cd.delphix.com/docs/latest/staging-push-implementation-for-sql-server#id-(28.0.0.0)StagingpushimplementationforSQLserver-Procedure.2