- Notes, cautions, and warnings
- Preface
- PowerProtect Data Manager Appliance for Microsoft Application Agent Overview
- PowerProtect Data Manager Appliance 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 Appliance new deployment overview
- PowerProtect Data Manager Appliance 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 Appliance 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 Appliance
- 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
- 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 Appliance 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 Appliance 5.15.0.0 Microsoft SQL Server User Guide
Backing up an Always On availability group when there are multiple instance names
When you back up an Always On availability group where the nodes contain Microsoft SQL Servers with different instance names, the backup command on each instance should reflect the available instance.
For example, consider the following scenario:
- There are two different instances:
- SQ12INST4 resides on Node1.
- SQ12INST5 resides on Node2
- Node1 is the primary replica.
- Node2 is the secondary replica.
- The Always On availability group backup preference is set to secondary.
In this scenario, the backup command on SQL2INST4 should specify the backup object as "MSSQL$SQL2INST4#sql2012-aag3:", while backup command on SQL2INST5 should specify the backup object as "MSSQL$SQL2INST5#sql2012-aag3:". After failover of Node1 and Node2, Node1 becomes secondary, and Node2 becomes primary. The backup command is the same after failover.
NOTE:When browsing the backups for a restore operation, the save sets could be in either of the instances (SQL2INST4 or SQL2INST5). The save set depends on the instance that is used for the first backup.
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: <>()\