Backup of enterprise applications (Microsoft stack, IBM Db2, MongoDB, Oracle, PostgreSQL, SAP)
Post Reply
jmbi
Influencer
Posts: 17
Liked: 3 times
Joined: Mar 26, 2020 1:52 pm
Contact:

Moving from "old" SQL Plug-in to the managed mode?

Post by jmbi »

I made a poor assumption that the jobs we had today would just be managable once we moved to V13. All back end magic to get from standalone to managed. :D

Given we have jobs in place today, and I've updated the plug-in on all the VMs housing our SQL servers, what's the guidance from here to move from standalone to managed? The user guide isn't overly helpful in getting from A to B. More just, this is how you install fresh.
Can I manage these jobs at all?
Do we lose our jobs or need to reconfigure them?
Our are old backups still valid?
Since the plug-in is already installed is the best way to utilize the Veeam deployment kit? We have AD, but we don't have an admin account designated for connecting this way (and I don't prefer this unless we can utilize a gMSA account anyway).
PetrM
Veeam Software
Posts: 4050
Liked: 699 times
Joined: Aug 28, 2013 8:23 am
Full Name: Petr Makarov
Location: Prague, Czech Republic
Contact:

Re: Moving from "old" SQL Plug-in to the managed mode?

Post by PetrM »

Hello,

Best wishes for the new year!

1) No, you cannot manage backup jobs that were created in standalone mode.

2) No, you will not lose these jobs, and you don't need to reconfigure them. However, I recommend making sure that your backup scripts or SQL Server Agent jobs on the SQL Server side are disabled to avoid any scheduling conflicts between the existing jobs and the backup policies you’ll create on the VBR side when you switch to managed mode.

3) Yes, of course, your old backups are still valid.

4) When operating in managed mode, you create a Protection Group, and VBR will connect to the VM to deploy a certificate that will be used for future authentication attempts.

Thanks!
jmbi
Influencer
Posts: 17
Liked: 3 times
Joined: Mar 26, 2020 1:52 pm
Contact:

Re: Moving from "old" SQL Plug-in to the managed mode?

Post by jmbi »

Best wishing to you as well!
And thank you for the response, this is very helpful.
It would be nice to have some scenarios in the user guide for differentiating these so that it's more clear, or is there anywhere else I can find a deeper dive that may answer these questions?

I think the only remaining questions I have as follow ups. Are:

With regards to #2, can standalone jobs still run if needed, obviously as long as they don't overlap with the managed jobs? I'm assuming the Plug-In is the same, so I would assume this to be the case. I haven't gotten far enough with it at this point to know whether I can do automated restores centrally. Even if we didn't use the managed jobs, I could still use the protection group to maintain the plug-in deployment.

Protection groups are related more to plug-in deployment and management. I'm assuming best practice is that unless there's a need to differentiate, you just create a Protection Group that's dedicated to all your SQL servers for example . There's generally no reason to dedicate a protection group to each SQL Cluster or each machine based on how I understand protection groups working.
PetrM
Veeam Software
Posts: 4050
Liked: 699 times
Joined: Aug 28, 2013 8:23 am
Full Name: Petr Makarov
Location: Prague, Czech Republic
Contact:

Re: Moving from "old" SQL Plug-in to the managed mode?

Post by PetrM »

Yes, I think it's a good idea to describe this scenario in our user guide, let me work with the technical writers team, we'll update it soon.

With regards to #2: yes, you can still run standalone jobs. However, please consider 2 possible scenarios:
A) Create a policy and process all databases on this server by policy (the same approach as implemented for SAP and Oracle).
In this case, existing standalone jobs will require a full backup on the file system (note: this full backup can also be created by a policy). This will create a new backup chain in a new folder: "PolicyName" / "ServerName". If a full backup exists, standalone jobs will continue to work and will create their backups in the location associated with the policy.

B) Create a policy for some databases, but process other databases that are not added to a policy using standalone jobs (new functionality available for SQL only).
To do this, you need to configure a repository for standalone jobs using the following configuration tool command:
--set-repository
After that, you can specify which databases you want to process in manual mode only:
MSSQLConfigTool --exclude-from-managed-mode --instance "INSTANCE" --d "database"
If you select the same repository as was used for standalone jobs, these jobs will continue working and will not require a full backup.

Answering other questions:
1. Speaking of automated restores, it is possible to run automated restores centrally using PowerShell for Veeam Explorer for SQL Server.

2. When you create a protection group, VBR takes "ownership" of the plug-in server, and it starts operating in managed mode. In managed mode, as I mentioned above, you can still run standalone jobs, but please keep in mind scenarios A and B.

3. There is no need to create a protection group for each SQL Server or cluster unless there is a specific need to differentiate them, such as different sites, rescan schedules, or other options.

Thanks!
jmbi
Influencer
Posts: 17
Liked: 3 times
Joined: Mar 26, 2020 1:52 pm
Contact:

Re: Moving from "old" SQL Plug-in to the managed mode?

Post by jmbi »

Awesome, thanks, I was having some gaps in knowledge in the user guide that I'm sure others may have as well!

Your last answer sparked one additional question.
You mention for different sites. We have an always-on cluster that spans sites. In the cluster there is one active node and the other 2 are passive nodes.
Site 1: SQLSERVER1(active) and SQLSERVER2(passive-automatic failover)
Site 2: SQLSERVER3(passive-manual failover)

While the site is different for SQLSERVER3, we aren't doing any backups from this server short of VM level storage snapshots with application aware copy-only backups without log truncation. Which is all done outside of the SQL Plug-in.
In this scenario, I don't see any issue with using a single protection group. I'm assuming when you say two sites, this would be in the case of stand-alone SQL servers in different sites where the repo was local.

Additional assumptions I'm making:
Even though SQL backups may be managed, the DBA can still see and restore from the SQL Plug-In on the local SQL server and automate the restore with SQL Agent Jobs for developmental purposes?

And the Schedule for the Application Backup policy has no bearing on the log processing running every 15 minutes? The schedule would only be for the full backup trigger and the file maintenance.
If this is the case, and I have a scenario where I need to run a full backup every 6 hours, would you just set the Advanced Settings to Weekly Every Day and then set the job to run every 6 hours at the permitted times 6 and 12?
Post Reply

Who is online

Users browsing this forum: No registered users and 19 guests