December 18, 2023 at 11:07 am
Hello,
Some months back we migrated an Azure SQL server off Azure and onto a private cloud. The Azure instance was subsequently deleted from within Azure. We've noticed that daily SQL database backups and periodic SQL log backups are still occurring and are backing up to an Azure storage container and we can't work our how to stop them. They don't appear in any SQL jobs or maintenance plans or scheduled tasks.
Does anyone know what can be done on what is now a non-Azure SQL server to stop these backups?
Thanks in advance to anyone who can shed some light on this.
Ross
December 18, 2023 at 2:46 pm
If there are no jobs (maintenance plans are still jobs) or scheduled tasks, then I'd say something must be happening on the Azure side of things that is backing it up still. Is it possible for you to put in a firewall rule to block Azure access to/from that new server on your private cloud? Then next time the backup triggers, you would have a failure notification from SOMEWHERE and you can narrow down what is happening.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
December 18, 2023 at 2:51 pm
open a support case in your azure subscription.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
December 19, 2023 at 9:17 am
Hi Brian,
Thanks for your reply. I had already blocked the outbound traffic to the backup destination URL (e.g. https://xxxxxxxxx.blob.core.windows.net) which was preventing the backups from succeeding as it was looking to transfer 100s of GB every night. That results in the below SQL log error which makes sense as it cannot connect to the storage container:
BackupDiskFile::CreateMedia: Backup device 'https://xxxxxxxxx.blob.core.windows.net/xxxxxxx/my_database_hmm_xxx_f32277xxxxxxxxxxxxxxxea_20231218153223+00.log' failed to create. Operating system error 50(The request is not supported.).
Unfortunately this error doesn't point me in the direction what is initiating these backup requests.
It's a little more tricky to block incoming traffic from Azure as there are some servers still in Azure communicating with this non-Azure server. But your suggestion gave me the idea of looking at this out of hours and making that change to see what the effect is.
Another reply to my post has suggested raising a case with Azure which is a good shout so I'll go down that route too.
Thanks again.
Ross
December 19, 2023 at 9:18 am
Hi Johan,
Good call! Oddly I hadn't considered that but I'll raise a case with them now.
Ross
April 22, 2024 at 8:39 am
This was removed by the editor as SPAM
April 22, 2024 at 9:03 am
Thanks for the reply Kasaderatech.
The issue is more to do with Azure backups continuing to run (or at least trying to - we have blocked outbound traffic to the Azure backup destination to prevent them running now) as opposed to configuring SQL backups in the "off-Azure" environment which has been done. It's one of those low priority things for me now as the backups to Azure are no longer succeeding due to the outbound firewall rules restricting access to the Azure environment but when time permits I'll look to raise a case with Azure to get to the bottom of this.
Cheers,
Ross
April 23, 2024 at 3:45 pm
Hello,
Some months back we migrated an Azure SQL server off Azure and onto a private cloud. The Azure instance was subsequently deleted from within Azure. We've noticed that daily SQL database backups and periodic SQL log backups are still occurring and are backing up to an Azure storage container and we can't work our how to stop them. They don't appear in any SQL jobs or maintenance plans or scheduled tasks.
Does anyone know what can be done on what is now a non-Azure SQL server to stop these backups?
Thanks in advance to anyone who can shed some light on this.
Ross
query the sys.credentials catalog for any backup to URL related credentials.
Can you provide bit more detail on the migration path please, presumably it was IaaS sql instance
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 24, 2024 at 11:32 am
Hi Perry,
Thanks for the reply. I'm not much of a SQL guy so I'm not sure how to go about "query the sys.credentials catalog for any backup to URL related credentials". Any pointers would be appreciated. 🙂
Yes, the Windows 2019 server with MS SQL installed was running as a standard virtual server in Azure. It was migrated out of Azure by using Zerto which replicated it to our private cloud. Once the initial replication had been completed the Azure instance was powered off and the replicated instance was powered on and re-IPed. Once operational in our private cloud the Azure instance was simply deleted.
April 24, 2024 at 11:48 am
Hi Perry,
Thanks for the reply. I'm not much of a SQL guy so I'm not sure how to go about "query the sys.credentials catalog for any backup to URL related credentials". Any pointers would be appreciated. 🙂
challenging without basic query capacity tbh
you don’t have any sql server professional resource on this task?
does your organisation have a dba?
Yes, the Windows 2019 server with MS SQL installed was running as a standard virtual server in Azure. It was migrated out of Azure by using Zerto which replicated it to our private cloud. Once the initial replication had been completed the Azure instance was powered off and the replicated instance was powered on and re-IPed. Once operational in our private cloud the Azure instance was simply deleted.
any reason why you retained the machine state rather than simply build a new server and instance in your private cloud and then backup/restore the databases across.
these backups that you’re seeing they’re not a red herring and coming from another server to the same storage account container?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 24, 2024 at 12:13 pm
We're a hosting company but the end-user/customer has a DBA who manages these servers so I'll get him to query the sys.credentials catalog for any backup to URL related credentials.
Not sure about why the customer was not keen to restore the databases on a new instance.
The backups (or should I say attempted backups as the server's firewall is blocking the outbound traffic for them) are definitely coming from the migrated server.
I'll see what the customer's DBA comes back with re: your suggested query.
April 24, 2024 at 12:15 pm
you most likely have the Azure agent still active on your server (these are installed by default on the azure vm's depending on how they are created - or on demand afterwards if build is done manually) - and that will always try to connect to azure to do the backup.
look at the services on the server and remove those related to azure as no longer required.
April 24, 2024 at 12:26 pm
We're a hosting company but the end-user/customer has a DBA who manages these servers so I'll get him to query the sys.credentials catalog for any backup to URL related credentials.
Not sure about why the customer was not keen to restore the databases on a new instance.
The backups (or should I say attempted backups as the server's firewall is blocking the outbound traffic for them) are definitely coming from the migrated server.
I'll see what the customer's DBA comes back with re: your suggested query.
As a sysadmin query the sysjobs catalog in the msdb too, see what jobs are there.
zerto will block replicate the vm so the agent jobs should be there unless removed by an admin or job owner.
the existence of a credential for backup to URL would also be a sure sign
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 24, 2024 at 12:40 pm
This was removed by the editor as SPAM
May 14, 2024 at 6:05 am
We're a hosting company but the end-user/customer has a DBA who manages these servers so I'll get him to query the sys.credentials catalog for any backup to URL related credentials.
Not sure about why the customer was not keen to restore the databases on a new instance.
The backups (or should I say attempted backups as the server's firewall is blocking the outbound traffic for them) are definitely coming from the migrated server.
I'll see what the customer's DBA comes back with re: your suggested query.
We are getting this same issue with a server - there are sys.credentials for the old blob store, and there are no sql agent jobs or anything in sys.jobs yet every 5 minutes we get an error in event log about the backup failing.
Ross Taylor did you have any luck with this?
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply