For the most part, this meant that the developers were responsible for their own VMs. In one enterprise, the development teams had their own Azure subscription where their development occurred. Real-world Test/Dev ScenarioĪs a systems administrator for many years working with Azure, I was becoming more and more routine in my daily work. Now let’s dive into a real-world scenario where a system being used for development did not have backups. But Microsoft will not backup your data by default. The thinking is: only allow administrators to deploy VMs, and Microsoft will provide you with tools that can be used to back up your VMs. Dev/test can still include data that is needed long-term, similar to on-premises. The reality of these mindset challenges is that they are misconceptions. Production or not, Microsoft backs up my VMs by default.This isn’t production, so power users and developers are allowed to deploy whatever VMs they need.We are only deploying dev/test machines, I don’t care about the data.While there are many similarities across cloud vendors, today we will focus on Microsoft Azure. There are several mindset challenges that need to be overcome when thinking about backup and recovery of cloud-based servers. In my experiences working in the enterprise, companies that move and/or deploy their virtual machines into any cloud often start slow and then ramp up over a period of time. Previously we looked at major disasters gone both right and wrong, ransomware, Exchange online, and even Exchange on-premises. Now let’s take a look at Azure VMs, native Microsoft options, and then wrap things up with how Cohesity 6.4 can help protect your cloud virtual machines. If you didn’t catch some of the other posts on similar topics, you should take a look.
Continuing along in our series of why enterprises need great backups, today we are going to dive into the virtual weeds and look at backup and recovery of Azure virtual machines (VMs).
0 kommentar(er)
