Skip to main content
Question

Best Practice for backing up SQL servers in Azure

  • September 24, 2024
  • 4 replies
  • 85 views

Forum|alt.badge.img+1

We are working through a redesign of our backup process for our ongoing migration to Azure. In vmware we have had to avoid using VSA backups for the OS/filesytem for our SQL servers due to issues caused by the stun that occurs when a snapshot is taken. SQL servers are backed up with Filesystem and SQL agents. The main problem with this is the time it takes to recover if one or more SQL servers needs to be completely recovered from backups. 

As we move to Azure, we would ideally like to back up the SQL servers using VSA and intellisnap, then the SQL agent would be used to back up the SQL data. This way we could leverage the simplicity of a VSA restore if something happened to the server/OS, and then the SQL data could be restored to a specific point in time if needed. 

Has anyone done this? Is there a better way to accomplish this that we aren’t thinking of?

The main goals are to increase the speed at which we could recover a SQL server. 



 

4 replies

Forum|alt.badge.img+15

Hello @Mike T

 

We have a large number of clients that have setups where VMware and SQL are able to deal with the stun caused by the snap. Its so minor and the application is able to deal with it without pushing the big red button. 


I would recommend trying it in your test and see if you have any loss in performance or failovers and such as you may find that MS have been working to reduce the impact these actions have on the application.

 

Kind regards

Albert Williams


Forum|alt.badge.img+8
  • Byte
  • 58 replies
  • September 27, 2024

Hello @Mike T,

 

Creating VSA jobs works just fine for all our environments, those running on vmware, aws or azure. So there might be some other factor contributing to your issues.

 

That said, I would recommend looking at azure paas to host your databases and enable Commvaults azure paas protection.


Forum|alt.badge.img+1
  • Author
  • Byte
  • 2 replies
  • September 30, 2024

Thanks for the responses here. 

It sounds like we need to revisit our policy around this and do some fresh testing. All of this was put in place before I came on board. I wanted to make sure I wasn’t completely off base in my understanding and thought that VSA backups should work here. 


Forum|alt.badge.img+7
  • Byte
  • 48 replies
  • October 8, 2024

Mike,
  We us VSA to backup our VMware SQL servers.  We had the same stun issue that our DBA’s were not comfortable with.  We were able to put in some VSS writer exclusions in the VMtools config, so VSS would not stun the SQL VSS writer.  I will have to get that setting from my VMadmins if you are interested. 
   Another interesting option our DBA’s wanted, was for us to not even backup the live DB, TLOG, TempDB volumes on the servers.  (they are each on there own drive).  Those disks are marked as independent and persistent on the VM config.   So Commvault backups up the OS drives, SQL SystemDB drive, and the SQL backup drive.

When we retore the VM, the server can boot, and SQL can start, but the other DB’s will all be ‘suspect’.  Then the DBA’s run restores of the Databases to the point in time they want.

It is a little convoluted, but got the job done for many years, until we started using our SAN replication.
 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings