Feature Change: Managed SQL Plug-in

[jmbi]

First, I want to call out the SQL Plug‑in support team. Those guys are rock stars.

The standalone SQL Plug‑in has been solid for us and has really helped improve our SQL backup improve our SQL recovery posture.

That said, the current V1 implementation of the managed SQL Plug‑in is significantly more limiting than the standalone deployment. I understand this is a newer feature, but after spending the last couple of weeks working closely with support, I wanted to provide feedback from a customer perspective.

We use the SQL Plug‑in not only for standard backups, but also for nightly restores into test and development environments. As part of that restore process, several permission and configuration changes are required. These are handled via SQL Agent jobs that are created using the restore plug‑in and then steps are added for the above changes by our DBA.

• We use the plug‑in to generate the SQL Agent jobs, which ensures correct syntax, naming, and consistency.
• The DBA then modifies the job with necessary additional steps.

In the managed plug‑in model, the behavior is fundamentally different, and lacks feature parity. This inconsistency is makes it difficult to adopt the managed model.

I believe a single architectural change could resolve several of the issues we are seeing today:
Deploy the SQL Plug‑in configuration at deployment time, rather than deferring it until the first backup is triggered. In this model, repository visibility would be controlled by the protection group rather than being implicitly gated by a VBR initiated backup.

This would result in the following improvements:

• Local visibility into existing SQL backups. The plug‑in would be aware of other SQL Server backups immediately, rather than only after a VBR‑initiated backup has occurred. Additionally, it should grant visibility to backups from other servers, not just individual database backups created on this specific SQL server.
• Use protection groups as plug‑in management, not just backup orchestration. Depending on one's organization's operating model, sysadmins could let VBR manage and update plug‑ins while still enabling DBAs to manage backup and restore operations locally via SQL Agent jobs. This streamlines processes while keeping capabilities we know.
• Removal of the current cost of entry requirement. Today, repositories are not available locally until a backup is triggered from VBR. This creates an artificial dependency that adds friction and complicates onboarding. Making this change would allow for the ability to backup locally from the start if desired.
• Restoration of known features and closer to feature parity. DBAs would once again be able to consistently build SQL Agent restore jobs through the local plug‑in even when backups originate from other servers. This reduces human error and significantly speeds up job creation, especially in multi‑server environments.

I am familiar with MSSQLRecoveryManager.exe, however this isn't as straight forward for the DBA to use and is more error prone than being able to select the databases from the GUI to generate the SQL Agent job.

As much as I'd like to utilize the managed SQL plug-in, it's just not in a state at this point I feel like it would benefit to use at this time.

Please let me know if you have any questions about this feedback.

[PetrM]

Hello,

First, I would like to thank you for your detailed and well-structured feedback! Posts like yours are extremely helpful for analyzing real-world needs and lead to valuable product improvements in the future. I also fully agree with your opinion about our support team: they truly are the best of the best.

While I fully understand all the points regarding the architectural changes, I’m not sure I completely grasp the challenges. Please bear with me and help me understand them better.
1.

update plug‑ins while still enabling DBAs to manage backup and restore operations locally via SQL Agent jobs.

Yes, it is possible. You can install plug-ins using the Protection Group, configure the plug-in manually, and even run backups using the SQL Server Agent job. It is not mandatory to have a backup policy on the VBR side. What makes you think this functionality is unavailable? The procedure is described on this page.

2.

repositories are not available locally until a backup is triggered from VBR.

No, you can configure a repository and run backups there. What makes you think this functionality is unavailable? I believe you can refer to the page I provided above.

3.

DBAs would once again be able to consistently build SQL Agent restore jobs through the local plug‑in even when backups originate from other servers.

This is also possible, but you need to generate a recovery token for the backup from which you want to restore data and set this recovery token on the plug-in side. Unfortunately, our user guide does not currently include a description of this procedure (I will contact the technical writers as soon as possible). You need to generate the token on the VBR side and set this recovery token on the server where you want to restore data by running the following command:

Code: Select all

MSSQLConfigTool.exe --set-auth-data-for-restore

( the procedure to set the authentication data is similar to RMAN, you can find more info here )

The requirement to use a recovery token exists for security reasons, as it is necessary to restrict access to data created by another user. In managed mode, each server authenticates using a certificate, so each server connects to VBR as a different user.

At the moment, it seems more like a documentation issue than a lack of functionality.

Thanks!

[jmbi]

@Petrm I'm gonig to PM you my ticket number for reference as here as the team was talking directly with the development team. The information from support did state that it must be in a policy before I can launch the datase backup on the host directly. Along with some of the other items you mentioned is also in the ticket. Much of what you brought up here was not discussed. I appreciate the help. Please be on the look out for my PM.