- Notes, cautions, and warnings
- Preface
- PowerProtect Data Manager for Microsoft Application Agent Overview
- PowerProtect Data Manager overview
- Introducing the Microsoft application agent
- Microsoft SQL Server application agent and File System agent coexistence
- VM Direct limitations
- Prerequisites
- Supported Internet Protocol versions
- Encryption in-flight
- PowerProtect Data Manager new deployment overview
- PowerProtect Data Manager existing deployment overview
- Security configuration
- Enabling the Microsoft Application Agent for Microsoft SQL Server
- Microsoft SQL Server data protection and replication requirements
- Microsoft SQL Server operational log files for backup and restore operations
- Protecting a stand-alone Microsoft SQL Server
- Protecting Microsoft SQL Server clustered environments
- Install, update, and uninstall the application agent
- Prerequisites
- Install the Microsoft application agent with the wizard
- Install the Microsoft application agent with a silent installation
- Update the Microsoft application agent
- Update the application agent in the PowerProtect Data Manager UI
- Uninstall the Microsoft application agent with the setup file
- Uninstall the Microsoft application agent with a silent uninstallation
- Required privileges for Application Direct backup and recovery
- Stagger Microsoft SQL Server discovery jobs in host scale-out environments
- Configure the database backup stripe level
- Enable multi-stream backups for Microsoft SQL Server protection policy
- Manage the Microsoft application agent
- Configurable ports for Microsoft SQL Server
- Support for existing Microsoft application agent backups with PowerProtect Data Manager
- Microsoft application agent for application-aware protection
- Managing Storage, Assets, and Protection
- Enable an asset source
- Delete an asset source
- Disable the Microsoft application agent
- Reinstall the Microsoft application agent
- Setting the sysadmin privilege for Microsoft SQL Server hosts
- Discover a Microsoft SQL Server application host
- Protection policies for Microsoft SQL Server database protection
- Supported protection policy purposes
- Supported protection policy objectives
- Replication triggers
- Roadmap for planning a Microsoft SQL Server database protection policy
- Before you add a protection policy for Microsoft SQL Server database protection
- Add a protection policy
- Asset-level configuration for protection policies
- Extended retention for protection policies created in PowerProtect Data Manager 19.11 or earlier
- Protection rules
- Cancel a Microsoft SQL application agent protection or restore job
- Edit the retention period for backup copies
- Delete backup copies
- Host CPU throttling
- Enable the Microsoft application agent after Internet Protocol change
- Enable the Microsoft application agent after hostname change
- Enable the Microsoft application agent after host IP address change
- Enable the Microsoft application agent after reusing IP address from a different host
- Enable the Microsoft application agent after migration to a different Microsoft SQL Server host
- Enable the Microsoft application agent after Microsoft SQL Server upgrade
- Enable the Microsoft application agent after operating system upgrade
- Manage the PowerProtect agent service
- About the PowerProtect agent service
- Start, stop, or obtain the status of the PowerProtect agent service
- Troubleshooting PowerProtect agent service installations
- Troubleshooting PowerProtect agent service operations
- Register the PowerProtect agent service to a different server address on Windows
- Recovering the PowerProtect agent service from a disaster
- Manage the cloud tier operations with PowerProtect Data Manager for application agents
- Performing Self-Service Application Direct Backups of Microsoft SQL Server Databases
- Performing self-service Microsoft SQL Server database backups
- Overview of Application Direct with Microsoft SQL Server backups
- Best practices to back up Microsoft SQL Server with Application Direct
- Naming conventions for backups with Application Direct
- Circumstances that promote Microsoft SQL Server backups to level full
- Scheduling backup jobs
- Scheduling Microsoft SQL Server backups by using SQL Server Agent
- Configuring the SQL Server Agent to schedule jobs
- Changing the SQL Server Agent service login credentials
- Creating a proxy for the CmdExec subsystem
- Scheduling a CmdExec job
- Scheduling a CmdExec job on a single Microsoft SQL Server
- Scheduling a CmdExec job on multiple Microsoft SQL Servers
- Configuring primary and target SQL Server Agents
- Running a job on the target servers
- Scheduling a T-SQL job
- Scheduling Microsoft SQL Server backups by using Windows Task Scheduler
- Scheduling Microsoft SQL Server backups by using SQL Server Agent
- Performing manual backups
- Perform backups with the Microsoft app agent for Application Direct SSMS plug-in
- Back up Microsoft SQL Server with the Application Direct backup command
- Perform backups with T-SQL scripts
- Performing Self-Service Application Direct Restores of Microsoft SQL Server Databases
- Restoring a Microsoft SQL Server application host
- Best practices to restore Microsoft SQL Server with Application Direct
- Restoring Microsoft SQL Server databases
- Performing table-level recovery
- Performing Microsoft SQL Server disaster recovery
- Performing Centralized Restores of Application Direct Backups
- Centralized restores of Microsoft SQL Server Application Direct backups
- Considerations for centralized Microsoft SQL Server Application Direct restores
- Centralized restore of Microsoft SQL Server system databases
- Centralized restore of a Microsoft SQL Server stand-alone database
- Centralized restore of a Microsoft SQL Server AAG database
- Centralized restore of multiple Microsoft SQL Server databases
- Performing Self-Service Restores of Virtual Machine Backups
- Restoring a Microsoft SQL Server virtual machine backup
- Overview of Microsoft SQL Server virtual machine restore operations
- Prerequisites
- Restoring Microsoft SQL Server databases to a virtual machine
- Performing Microsoft SQL Server table-level recovery to a virtual machine
- Performing an instant access recovery
- Performing Centralized Restores of Virtual Machine Backups
- Centralized restores of Microsoft SQL Server virtual machine backups
- Considerations for centralized Microsoft SQL Server application-aware restores
- Centralized restore of Microsoft SQL Server system databases
- Centralized restore of a Microsoft SQL Server stand-alone database
- Centralized restore of a Microsoft SQL Server AAG database
- Centralized restore of multiple Microsoft SQL Server databases
- Protecting Virtual Machines Using the Transparent Snapshots Data Mover
- Overview of Transparent Snapshots Data Mover
- vSphere Installation Bundle monitoring and management
- Transparent snapshots data mover system requirements
- Prerequisites to virtual machine protection with the Transparent Snapshots Data Mover
- Configuring Microsoft SQL Server application-aware protection with TSDM
- Troubleshooting and limitations for SQL application aware policies with TSDM
- Migrating assets to use the Transparent Snapshots Data Mover
- Microsoft SQL Server Best Practices and Troubleshooting
- Glossary
PowerProtect Data Manager 19.15 Microsoft SQL Server User Guide
Creating VMkernel ports for Transparent Snapshots Data Mover
For backup and restore of virtual assets from the ESXi hosts and their respective virtual machines using the Transparent Snapshots Data Mover (TSDM) protection engine, It is strongly recommended that you create a dedicated VMkernel port for all ESXi hosts in the cluster to facilitate data transfer.
Before you begin:
- For optimal data transfer between ESXi hosts and protection storage, use the same network subnet that is used for backup storage.
- For each ESXi host in the cluster, it is recommended to use a 10G physical network adapter port for TSDM backup traffic.
- Plan a unique network subnet to use exclusively for TSDM protection engine that does not overlap with any other existing network subnets. This subnet must contain the following:
- An IP address for each VMkernel port in each ESXi host.
- An IP address for each port in protection storage target interfaces.
Complete Create a VMkernel port for a standard vSwitch configuration or Create a VMkernel port for a distributed vSwitch configuration. Use the switch and IP settings recommended above.
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\