Figure 1 - Availability Machines dashboard
 *** ## Availability Machine home page Selecting any of the database services from the AM dashboard takes you to the home page of that availability machine. Every AM has a separate home page with its statistics. On the Availability Machine home page, the status of the source DB is displayed next to its name. On the top right-side, you see the following options: #### **DB Service** Click to go to the My Services home page of the database service. #### **Dataflix** Click to go to the Dataflix home page of the database service. #### **Update RPO Policy** The Recovery Point Objective (RPO) policy dictates the frequency and retention policies for Tessell captured automated DB service snapshots and logs. This is done to ensure DB recoverability and data protection. 1. Click this option to update the recovery point objective policy.\ **Update RPO Policy and Schedule** window opens to update the RPO policy and apply the changes: 2. **Include Transactional Logs** — Selecting this check box indicates the Tessell platform takes backup of transaction logs. **Schedule Snapshots** — Toggle this option to schedule snapshots. 1. Select the configuration type for RPO policy, Standard or Custom. 2. For Standard policy: 1. Specify the snapshot retention days in the range of 1 to 35 days. 2. Pick a time you wish to take the snapshot of your database service. 3. For Custom policy: 1. Choose an RPO policy from the dropdown list. To use an RPO policy, ensure that you have created an RPO policy in the **DB governance** application under the **Governance** app family. 2. Pick a time you wish to take the snapshot of your database service.\ RPO Policy Details window displays the details related to chosen RPO policy, including: * Description of the policy if available * Type of the policy, Standard or Custom * Whether PITR is enabled for your policy 4. Select the desired frequency for the RPO Policy to create and store snapshot backups. * **RPO Policy** — Displays the selected RPO Policy. The possible options are one or more from Continuous Recovery (PITR), Daily Snapshots, Weekly Snapshots, Monthly Snapshots, and Yearly Snapshots, as per the option selected in the RPO policy field above. * **Every** — Depending on the schedule type, select the frequency of the snapshot. For Daily Snapshots, this field provides the scheduled time. For PITR, this is disabled. * **Keep for** — Displays the number of days for which a snapshot or a backup needs to be retained as per the selected RPO policy. **Schedule Native Backups** — Toggle this option to schedule native backups for SQL Server. Native backups use SQL Server's built-in backup mechanisms to produce full and differential backup files (.bak) that are stored in the object storage of your cloud account (S3 for AWS, Blob Storage for Azure). When a new DB is added in between RPO schedule, FULL backups for ALL databases are triggered and baseBackup of current chain gets resets to new base. > **Note:** For SQL Server, native backup scheduling via RPO policy is supported on Standard shapes. For HPC shapes, native backups are part of the snapshot workflow itself — a standard full backup is taken on the configured backup day and differential backups on subsequent days over a 7-day cycle. 1. For native backup RPO scheduling on Standard shapes: 1. Select the configuration type, Standard or Custom. 2. For Standard policy: 1. Specify the backup retention days in the range of 7 to 35 days. 2. Choose a day from the **Full backup day** dropdown list. 3. Pick a time from the **Full backup time** dropdown list. 4. Pick a time from the **Incremental backup time** dropdown list. 3. For Custom policy: 1. Choose an RPO policy from the dropdown list. 2. Choose a day from the **Full backup day** dropdown list. 3. Pick a time from the **Full backup time** dropdown list. 4. Pick a time from the **Incremental backup time** dropdown list. 4. Select the desired backup frequency for your RPO Policy. * **Policy Frequency** — The possible options are one or more from Daily Backups, Weekly Backups, Monthly Backups, and Yearly Backups. For daily backups, a combination of full and differential backups is taken. For weekly, monthly, and yearly backups, a full backup is taken. * **Every** — Depending on the schedule type, provides the frequency of the backup. * **Keep for** — Displays the number of days for which a backup needs to be retained as per the selected RPO policy. > **Note:** Snapshot and native backup windows cannot overlap on Standard shapes. If a regular snapshot and native backup conflict, the native backup queues and runs after the snapshot completes, and vice versa. Native backup is resource intensive and hence it should be scheduled during lean operation time. 3. Select the **Update** button at the bottom to apply the changes. ### Summary Expanding the top bar on the AM gives a summary of the AM.\ Summary includes the following details: #### **RPO Policy and DB details** * **RPO Policy** — Displays the number of retention days and type of backup as per the policy. * **Transaction Logs** — Displays whether transaction logs are enabled. * **Source DB Status** — Displays the status of the source DB service for this AM. The possible values are Ready, Stopped, and Deleted. #### **Cloud details** * **Cloud** — Displays the name of the cloud hosting your database service (AWS or Azure). * **Region** — Displays the name of the cloud region hosting your database service. #### **User details** * **Owner** — Displays the username of your Tessell account's owner. * **My role** — Displays your role for the database service. The possible values are Owner, Co-owner, or Read-only. * **TRN** — Displays the Tessell resource name. The TRN is a globally unique ID. Use the copy button to copy the TRN. When you click a database service in the AM dashboard, various tabs are displayed on the AM home page that include: Data Flow, Snapshots, Sanitization, Native Backups, Access Policies, Clones, and Sharing. Let us discuss each of these tabs in the next steps.Figure 2 - Availability Machine home page
 *** ## Data Flow The Data Flow tab displays how the data is moving in the system. The data owner can configure an RPO policy and Data Access Policies (DAP) for the AM. This tab displays the flow of the data from your database service (source DB) to AM and from AM to different regions as per the configured RPO policy and DAPs. The main box represents your source DB. The central box is your AM that is acting as the central data management construct. The box with a hand-shake icon shows your configured RPO policy. There is a continuous stream of data flowing from source DB box to AM box representing that data from the source DB is captured via snapshots and transaction logs are continuously captured and retained as per the configured RPO policy. If your database service is configured as multi-AZ (HA), then the snapshots and transaction log backups are taken from the primary node and replicated to the replica region boxes and retained as per the configured RPO policy for that particular region. The data flow from AM to different region boxes is different as per the configured RPO policy and DAP policies for that region. The region with manual snapshots does not have any continuous data flow from AM as the manual snapshots are retained until you delete them manually. You can zoom in or out using the **+** or **-** icons from the bottom left corner of the page. Also, you can view the Data Flow in full screen using the expand screen icon from the bottom left of the page. *** ## Snapshots Snapshots of your SQL Server database service are automatically taken as per the configured RPO policy. You can also manually create an ad hoc snapshot at any time. The Snapshots tab displays all the details of the created snapshots for your database service. On the top, you can specify the name of your snapshot in the search bar and search for the particular snapshot and its details. You can filter the snapshots according to the status using the **Status** field next to the search bar. The possible status values are: * **All** — Displays all the snapshots with any of the possible status (default). * **Available** — Select this option to list all the available snapshots. * **Queued** — Select this option to list all the snapshots that are scheduled and waiting. * **Creating** — Select this option to list all the snapshots that are in progress. * **Failed** — Select this option to list all the snapshots that did not complete. * Click **Clear** to clear the applied filters. By default, it displays the list of all the manual snapshots and their details. To take a manual snapshot: 1. Click **+ Take Snapshot** button at the top right corner. 2. Specify the snapshot name and then click **Submit**.\ **Note:** Tessell does not automatically delete manual snapshots. You must return to this tab and delete them manually. As an alternative method, use the code to take a manual snapshot. 1. Use the Code button at the bottom-left corner to view the ‘Code for Take snapshot’ window. 2. On the left-hand side of the window, you can view the API, its type and the payload. 3. On the right-hand side of the window, you can view the code to take snapshot in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using respective buttons. 5. Use the Close button to return to the main window. Select **Automatic Snapshots** to list all the automatic snapshots and their details. The automatic snapshots are taken as per the RPO policy configured for your database service. > * For **Standard shapes**, snapshots use VDI-based backups. > * For **HPC shapes**, snapshots use standard full backups on the selected backup day and differential backups on subsequent days for 7 days. The table on **Manual Snapshots** and **Automatic Snapshots** displays the following details for each snapshot: * **Snapshot Name** — Displays the name of the snapshot. * **Availability** — Displays the number of regions for which the snapshot is available. Select the region for a particular snapshot to view: * **Region** — Name of the region where the snapshot is available. If a DAP is configured, this shows all the regions where the snapshot is replicated. * **Status** — Availability status of the snapshot in that region. * **Access Policy** — Name of the access policy defined for your database service. * **Shared with** — Name of the user(s) with whom the snapshot is shared. It displays **No users** if not shared. * **Status** — The possible options are Available, Queued, Creating cloud snapshot, and Failed. * **Size (GiB)** — Displays the size of the snapshot. * **Snapshot Time** — Displays the exact date and time when the snapshot was taken. Each manual snapshot can be removed using the **Delete** option from the ellipsis icon at the end of each row. Automatic snapshots are deleted as per the RPO policy. You can update the number of retention days and the time for automatic snapshots using **Update RPO Policy** at the top right corner.Figure 3 - Snapshots tab
 *** ## Sanitization Tessell offers database sanitization as both an on-demand and an automated scheduled workflow. The sanitization workflow is designed to mask/sanitize sensitive information (such as credit card data, PII data, and so on) before copies of databases are created for lower environments. You can sanitize the snapshots manually or create a schedule to sanitize them automatically. Sanitized snapshots are useful for application testing or user training when a full production dataset is not required. These snapshots can be used or shared as needed. As you know your data best, you are expected to provide the SQL scripts which mask the data before creating a snapshot for a lower environment.\ You need a masking SQL script added to your script library to sanitize a snapshot. For more information, see Script Library app. Whenever a snapshot sanitization request is submitted, a workflow is run at the backend which creates a clone VM using the source snapshot. After creating a clone VM, the masking SQL script is run against the SQL Server databases on the clone VM. After the script is run successfully and the data is masked, it captures a snapshot from the clone VM and provides a sanitized snapshot. On top of the Sanitization tab, you can specify the name of your sanitized snapshot in the **Search** bar and search for the particular snapshot and its details.\ You can filter the sanitized snapshots according to the status using the **Status** field next to the search bar. The possible status values are: * **All** — Displays all the sanitized snapshots (default). * **Available** — Lists all the available sanitized snapshots. * **Queued** — Lists sanitized snapshots that are scheduled and waiting. * **Creating** — Lists sanitized snapshots that are in progress. * **Failed** — Lists sanitized snapshots that did not complete. You can also filter the snapshots based on a particular script. The possible values are **All**, and the list of available scripts for your database service.\ You can select the **Clear** button to clear the applied filters. By default, the table displays the list of all the sanitized snapshots and their details: * **Snapshot Name** — Name of the sanitized snapshot. * **Status** — Status of the sanitized snapshot (Available, Queued, Creating, or Failed). * **Schedule Name** — Name of the schedule through which this snapshot was sanitized. * **Size (GiB)** — Size of the sanitized snapshot. * **Script Name/Version** — Script name and version used to sanitize the data. * **Availability** — Number of regions for which the sanitized snapshot is available. Select to view: * **Region** — Region name. * **Status** — Availability status. * **Access Policy** — Name of the access policy. * **Shared with** — Users with whom the sanitized snapshot is shared. Shows **No users** if not shared. * **Snapshot Time** — Exact date and time when the sanitized snapshot was taken. **Sanitize Snapshot** 1. Click **+ Sanitize Snapshot** to create a sanitized snapshot: 1. Specify a name in the **Sanitized snapshot name** field. 2. Choose a source snapshot from the dropdown list.\ Both manual and automated snapshots are available. 3. Choose a data masking script from the dropdown list.\ You are responsible for providing the sanitization script. 4. Choose a version available for your script. 5. Click **Submit**. Select **Show Schedules** to see the list of all the schedules and their details for sanitized snapshots. * **Schedule Name** — Name of the schedule. * **Script info** — Name and version of the script used. * **Retention** — Number of days for which the sanitized snapshot is retained. * **Snapshot Name Prefix** — Snapshot prefix name given at creation time. * **Create on** — Date and time when the snapshot was sanitized. ### **Create Schedule** 1. Click **+ Create Schedule** to create a schedule for automated sanitization: 1. **Schedule Name** — Specify the name. 2. **Description** — Optionally, specify a description. 3. **Frequency** — Select from: * **Daily** — Sanitize snapshots daily. * **Weekly** — Sanitize snapshots weekly. Further, select the days. 4. **Keep each snapshot for** — Specify the retention period in days or weeks. 5. **Snapshot name prefix** — Specify a prefix name. Default is 'Sanitized'. 6. **Script** — Select the masking script. 7. **Script version** — Select the version. 8. Click **Save**. As an alternative method, use the code to create a sanitized snapshot or sanitization schedule. 1. Use the Code button at the bottom-left corner to view the Code for respective action. 2. On the left-hand side of the window, you can view the API, its type and the payload. 3. On the right-hand side of the window, you can view the code in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using respective buttons. 5. Use the Close button to return to the main window.Figure 4 - Sanitization tab
 *** ## Native Backups For SQL Server, native backups produce standard .bak files using SQL Server's built-in backup mechanisms. Tessell supports taking native backups either directly from the source database or from existing snapshots to avoid loading the source database. When a backup is created from a snapshot, a clone VM is created from the source snapshot and SQL Server's native backup utilities are run on the clone VM. Automated native backups run on the same vm and not on clone VM. You can search the backups list by providing the backup name in the **Search** bar on the native backups tab. ### Create backup 1. Click **+ Create Backup** on the native backups tab to create a manual backup.\ The **Create Manual Backup** window pops-up. 2. Specify the name of the backup in the **Backup Name** field. 3. Choose whether to take the backup from Database or Snapshot. * Database — Takes a native backup directly on the running SQL Server service (source\_type: DATABASE). Suitable for on-demand, up-to-the-minute backup captures. * Snapshot — Creates a clone VM from a selected snapshot and runs native backup utilities on it (source\_type: SNAPSHOT). This avoids any load on the production database. 4. If Snapshot is chosen, Select the source snapshot from the dropdown list.\ Both manual and automated snapshots are available. 5. Click **Create** to submit.\ A workflow runs at the backend and captures the backup for your database service using SQL Server native backup utilities. > **Note:** Manual native backups can be downloaded and deleted from the UI. Automated backups generated via RPO schedules cannot be deleted manually; they are managed by the RPO retention policy. As an alternative method, use the code to take a manual backup. 1. Use the Code button at the bottom-left corner to view the ‘Code for Create new Backup’ window. 2. On the left-hand side of the window, you can view the API, its type and the payload. 3. On the right-hand side of the window, you can view the code to create backup in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using respective buttons. 5. Use the Close button to return to the main window. The automatic backups are taken as per the RPO policy configured for your database service. The table on the backups tab lists all the backups and their details: * **Backup Name** — Name of the backup given at the time of creation. * **Status** — Status of the backup: * **Available** — The backup is ready for use. * **Queued** — The backup is scheduled and waiting. * **Creating** — Backup creation is in progress. * **Failed** — The backup did not complete. * **Size** — Size of the backup in GiB. * **Type** — Whether it is a full backup or differential backup. * **Availability** — Number of regions where this backup is available. Select to view region details, status, access policy, and sharing info. * **Created on** — Date and time when the backup was taken. * **Shared With** — Users with whom the backup is shared. Select the ellipsis icon on the right-side to delete the backups using the **Delete** icon on each row. ### Downloading native backups For manually triggered native backups, use the **Download** button in the Dataflix tab to generate a pre-signed URL for downloading the backup files from S3 or Blob Storage. This allows you to restore the database outside of Tessell — on-premises, on another cloud VM, or in a different environment — supporting Tessell's no-lock-in principle. > **Note:** For RPO-scheduled native backups, individual database-level backup files are maintained in object storage. The Download button is available only for manually triggered native backups. ### Transaction log retention Tessell provides configurable retention for transaction logs on the local disk, which is especially important for customers using tools like AWS DMS that require logs to remain on disk for continuous replication. A scheduled cleanup task runs every 30 minutes and uses configurable thresholds (disk usage ceiling, floor limit, and retention time) to manage local log files. Customers can customize retention via a config file at `T:\tessell_custom_configs\custom_archive_config.json`. If disk cleanup is insufficient, Tessell raises a proactive alert so the SRE team can intervene and resize the disk.Figure 5 - Native Backups tab
 *** ## Access Policies The Data Access Policy (DAP) is one of the key data management services that helps data owners manage the availability of database snapshots and/or transaction logs for lower environments like DR, testing, staging, and so on. They can be made available for backup, archiving, data sharing, or migration in the same region or across regions within the same subscription and same cloud account. Production snapshots can be shared as-is, or they can be masked or processed before they are made available. Using the DAP, a data owner can define where the database snapshots or logs can be made available. As part of the configuration, the data owner can define which users or user-groups can access the data for the specified policy. You can make use of the shared data (snapshots/logs) to create a secondary copy of the database. If the DAP has continuous recovery enabled, you can also create a point-in-time database copy. The DAP can also be used to refresh lower environments on a regular basis or a defined cadence. > **SQL Server–specific considerations:** > > * For SQL Server snapshot DAPs, database recovery depends on .dmp metadata files that must be accessible in the target region or subscription. Tessell handles replication of these metadata files automatically. > * Cross-subscription DAP clone is not yet supported for SQL Server. > * DAP content for native backups (manual and automated) can also be shared via access policies. You can search the access policy list by providing the policy name in the **Search** bar on the access policies tab.\ The table on the access policies tab lists all the policies and their details: * **Policy Name** — Displays the access policy name. * **Status** — Whether the policy is active or inactive. * **Shared Across** — Number of subscriptions the data is shared across. * **Content Type** — Whether it is as-is data, sanitized data, or backups. Also displays whether the data shared is automated or manual. * **Available Content** — Frequency and retention period in days for the content availability. Click the ellipsis icon on the right-side to see the following options: **Manage Access** 1. Select **Manage Access** to add more users. 2. Specify the names of the users to grant access. 3. Click **Update Access**. **Update** — Select this option to update policy details like name, target subscription, and content settings. **Delete Policy** 1. Select **Delete Policy** to delete the policy. 2. Select the confirmation box, **Remove the access policy**. 3. Click **Remove**.\ This action revokes user access to the shared snapshot through this policy. The underlying cloud snapshot is also deleted from the target regions. ### **Create Policy** 1. Specify a policy name: 1. Click **+ Create Policy**. 2. Specify a name in the **Policy Name** field. 2. Select target subscription: 1. Choose a subscription from the dropdown list. 2. Choose the desired target region for data replication. 3. Choose an encryption key from the dropdown list. 4. If another region is available, you can add it. 5. In the **Add users to grant access** field, select the users. 3. Select data access mode: **As-Is Data**\ Share the source snapshots (and PITR logs) as-is, without processing. 1. Select whether to share automated or manual snapshots. 2. If automated, select frequency and retention period. 3. Toggle the switch to change retention days for PITR and daily frequency. 4. If manual, select from the available manual snapshot list. **Sanitized Data**\ Share the source snapshots post processing (sanitized/masked copy). 1. Select whether to share automated or manual sanitized snapshots. 2. If automated, choose a schedule from the dropdown list. 3. Select frequency and retention period. 4. If manual, select from the available manual sanitized snapshot list. > **Note:** PITR is only possible in as-is data access mode. **Backups**\ Share native backup access for complete recovery. 1. Select whether to share automated or manual backups. 2. If automated, select frequency and retention period. 3. If manual, select from the available manual backups list. 4. Click **Submit** to share the data as per the configured access policy. As an alternative method, use the code to create an access policy. 1. Use the Code button at the top-right corner to view the ‘Code for Create new access policy’ window. 2. On the left-hand side of the window, you can view the API, its type and the payload. 3. On the right-hand side of the window, you can view the code for adding new policy in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using respective buttons. 5. Use the Close button to return to the main window.Figure 6 - Access Policies tab
 *** ## Clones You can create clones of SQL Server databases running in Tessell using the Availability Machine and Dataflix applications. On top of the Clones tab, you can specify the cloned service name in the **Search** bar.\ To filter cloned services by owner, use the **Owner** field.\ Click **Clear** to reset filters. The Clones tab displays the following details: * **Name** — Cloned service name. * **Status** — Status of the cloned service (Creating, Ready, Stopped, or Deleted). * **Cloud/Region** — Cloud provider and region for the cloned service. * **Source** — Source snapshot with name, time, and content type (For example, as-is). * **Infrastructure** — Compute shape of the cloned service. * **Created** — Date and time when the clone creation was requested. ### **Create clone** 1. Click **+ Create Clone**.\ This takes you to the Dataflix application where you see a list of available snapshots with timestamp, storage size, and number of regions. 2. Select from the available snapshots to view details like creation timestamp, size, number of databases, and cloud details. 3. Click **Clone** at the bottom right corner. 4. Configure the following options for your cloned service: * Service name, description, and tags * Cloud provider settings * Compute shape (parent database server configuration is displayed; storage cannot be changed for clones) * Database instance configuration * Additional settings including refresh schedule, maintenance window, performance insights, and availability machine > **Note**: Clone Refresh (also called Dev Refresh) lets you keep a cloned database service automatically updated with fresh data from its source database. Instead of creating a new clone every time you need current data in your dev/test environment, you set up a refresh schedule on an existing clone, and Tessell periodically restores it with the latest snapshot or PITR data from the source. * In **Refresh schedule**, select **No schedule** or **Automatic refresh**. * For automatic refresh, select the refresh day(s) and time. * Select the refresh mode: **Snapshot** or **PITR**. > **Note:** > > * In snapshot mode, the database is refreshed to the snapshot available at the selected time. If no snapshot is available, the refresh is skipped. > * In PITR mode, the database is refreshed to the latest available data at the selected time. If no data is available, the refresh is skipped. * In the **Custom Scripts for Refresh schedule** panel, select pre and post scripts from the respective dropdown list.\ To use a custom script, ensure that you have uploaded scripts in the **Script Library** application. 5. Click **+ Clone Service** at the bottom of the form. The following steps are performed automatically: * Request is submitted to clone the database service * Creates compute instance(s) * Configures the database * Availability Machine is set up * Triggers first snapshotFigure 7 - Clones tab
 *** ## Sharing The Sharing tab allows you to share your availability machine with other users. You can search the users list by providing the user's name in the **Search** bar on the Sharing tab. The following details are displayed: * **User** — List of usernames with whom the availability machine is shared. * **Role** — The user's defined role: Co-owner or Read-only. Click the ellipsis icon on the right-side of the user details to see the following options: **Change Role** 1. Click this option to change the role. 2. Select the role from the dropdown list (Co-owner or Read-only). 3. Click **Update**. **Remove User** 1. Click this option to remove the user. 2. Select the user to remove and click **Remove**. To share an availability machine: 1. Click **Share** on the top right corner. 2. Choose a role from the dropdown list (Co-owner or Read-only). 3. Use the **Search** bar to search for specific users. 4. Move users from the left **Choices** column to the right **Chosen** column.\ Only users with Data Owner roles appear in the **Choices** column.\ **Note:** Users and roles are managed in the **IAM** application under the **Governance** app family. 5. Click **Save** to share your availability machine data.Figure 8 - Sharing tab
 *** ## Glossary | Term | Definition | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Clone | A duplicate of an existing database created from a snapshot, native backup, or PITR recovery point. Typically used for testing, development, or troubleshooting without affecting the production database. | | Data Access Policy (DAP) | Defines rules for accessing database data. It controls who can access snapshots, logs, and backups, what actions they can perform, and under what conditions. | | Native Backup | A backup created using SQL Server's built-in backup mechanisms, producing standard .bak files. Supports full and differential backups. For Standard shapes, these can be scheduled independently via RPO policy. For HPC shapes, they are part of the snapshot workflow. | | Recovery Point Objective (RPO) Policy | Specifies the maximum acceptable data loss, measured in time. It defines how frequently snapshots, native backups, and transaction log captures occur. | | Snapshot | A point-in-time copy of a database service's storage volumes. For SQL Server, Tessell uses VDI on Standard shapes and full/differential native backups on HPC shapes. Snapshots are application consistent. | | Sanitization | The process of creating a secure version of production data by applying data masking SQL scripts to the snapshots. Ensures that snapshots can be safely used for development, testing, or analytics without exposing confidential information. | | Transaction Logs | Sequential records of all SQL Server database transactions. Backed up every 5 minutes using sql log backup and stored in S3 (AWS) or Blob Storage (Azure). Used for point-in-time recovery and continuous data protection. Configurable on-disk retention supports integration with tools like AWS DMS. | | VDI | The SQL Server Virtual Device Interface (VDI) is an Application Programming Interface (API) designed by Microsoft to allow third-party software vendors to integrate high-performance backup and restore capabilities directly with SQL Server. |