I have a couple of VMs that I want to backup and restore easily and often. Preferably as a group.
I have tried default Azure backup and restore but noticed that it doesn't seem to do much. It is easy to create and schedule backups but it is not clear to me how these backups can be used to bring a VM back to its original state.
The use cases for the default backup / restore seem to be very different from what I expected. I expected something somewhat similar to VirtualBox: take a snapshot and then restore takes the VM back to the snapshot.
Restore of VM in Azure does not seem to be a supported use case. I think the idea is more to clone / duplicate the machine.
The default "restore" is a feature to create another VM because it you try to restore Azure shows an error message
A virtual machine with the same already exists in the selected resource group. Please change the virtual machine name or select a new resource group.
There is an option to restore disks. This seems to work at first. Restore job completes successfully but nothing it restored. The file system is the same as before restore.
There is no detailed log so there is no way to determine what is happening. There is only exit status: success restore completed successfully.
Are there other ways to mimic VirtualBox functionality? Take snapshots and restore VM's using such snapshots?
Does MS have plans to enhance backup in such way that it also supports restore?
Snapshot works by capturing image state of a virtual machine. In Azure, you can snapshot your VHD and restore that snapshot whenever you'd like. Get started with snapshot here https://learn.microsoft.com/en-us/azure/virtual-machines/windows/snapshot-copy-managed-disk
Disk snapshot works best in case your virtual machine uses one disk (for the OS). Or if that virtual machine has more than one disk, disk snapshot is still useful, but takes time and may result disk management overhead. In that case, you could go with image generalization to capturing the whole virtual machine's state at once using tool like sysprep (https://learn.microsoft.com/en-us/azure/virtual-machines/windows/capture-image-resource)
From your screenshot, the problem is exactly what is highlighted in red. You cannot overwrite your virtual machine to the existing one in the same resource group. You must restore it somewhere else.
Azure Site Recovery and Backup is designed to work with large deployment of virtual machines, with some capabilities of automation and disaster recovery.
Related
We have webserver & database are on azure VM machines. MySQL is installed on the azure VM machine. Recently, we had an issue with the database corrupt. And, asked Azure to restore the backup from old dates when everything working fine. Azure takes backup of the whole machine on daily basis. They restore the old backup on a separate machine. We supposed that the database will be fine there because the backup is of old date.
But, the issue is still the same.
So, my questions are:
How exactly VM takes backup of the whole machine?
And, does it reference the existing machine while restoring on some new VM machine?
How could I get the correct restored database files?
Note: MySQL logs are also attached.
The whole VM backup means that a point-in-time snapshot is taken. With a running database like MySQL this might mean that the database files are in an inconsistent state at the time of back-up. Extra configuration on the Virtual Machine is needed to provide a consistent backup in the form of pre- and post scripts. Microsoft details how to do this in this documentation
That however seems of little use in the situation you are in at the moment. As stated in the InnoDB recovery documentation a good option would be to force manual InnoDB recovery. Documentation for manual recovery can be found here.
I can't get my VM disk restored in Azure: it is only "converted" to the Storage Account linked to my VM.
Does anyone know how to get a VM fully restored from a Recovery Service Vault backup in Azure please?
Edit :
For additional precision, I made a simple Linux VM hosting a test website in order to experience Azure's backup and restore feature.
So once the test website was online, I waited for a backup job to be done.
Then I deliberately broke the test website inside the VM, and launched a disk restore.
Unfortunately, the restore did nothing to the VM. I checked on the jobs and restore was marked as "Successful", and a VM restart did nothing.
Anyway, I can find the "vhd" in the Conainer tab of the Storage Account. But I can't find a way to attach it to the VM...
Is the disk restoration feature even supposed to work like intended ?
I tried to replicate a backed up restore of a virtual machine using Azure Site Recovery.
When you restore the virtual machine you have the option to select if you want to restore the disks or the virtual machine.
Selecting here to restore as a VM, will create the VM for you.
You can check that status of the restore by going to the jobs section of the machine in ASR.
For reference, see this page for more detailed instructions.
This likely flies in the face of what Azure thinks it can do, but have you tried to create the VM first and then just restore your data? Other possible options are:
The user you are logged in as does have the correct permissions to create a VM in that space as well as restore the data, yes?
And you did select Recovery Service vaults in the portal, correct?
check if the original VM had any special conditions, such as multiple NICs or a load balancer. Any custom VM configurations, including HUB licensing, will not be duplicated with the Create Virtual Machine option as it uses Quick Create. You will need to use PowerShell to attach the restore disks to your chosen VM configuration. You can get additional information on PowerShell and Azure backups here.
And in the link that kim provided above, scroll down to the "Create a new VM from a restore point" section and review the options and notes for creating a new VM. You can get more information on ASR at this page.
I am using two Microsoft Azure Virtual Machines (marked as classic), both running on Linux. One is used for test purposes and internal demos, the other is production and running few of clients' instances.
What I would like to do is change the size of Virtual Machine. I understand this is quite common process and can easily be done from the Azure Management Portal and that this is not affecting data. However, when I have changed the size of our testing machine, exactly this has happened and we have lost all data.
Azure Support answer received was:
"We recommend you delete the VM by keeping the attached disks and create a new VM with the required size." Not sure why this would be better?
Any data stored on the ephemeral (internal-to-chassis) scratch disk is at risk, as it's a non-durable disk (and will in all likelihood be destroyed/recreated upon resizing a VM).
The only way to have durable data is to use Azure Storage (blobs, vhd as attached disk, Azure File storage) or external database. Azure Storage is durable (minimum 3 copies), and is not stored with your VM.
One more thing: The VM's OS Disk is a VHD in Azure Storage (so the OS disk is durable, just like attached vhd's).
You have more than one way to do that and keep in mind what David said, data on OS disks, attached disks and blobs is the only durable one.
To prevent losing data and since you're using Classic VMs, you can do the following:
1- Go to your VM on portal and capture an image out of it.
2- Go to your new image and create a new VM out of it, while specifying the new specs that you need.
3- When done, connect to your new VM while keeping the old one without termination.
4- Check if all your data is there, if yes, then you can remove the old one. (In case you need the old IP, you can still assign it to the new one).
Cheers.
Could someone please help me understand this? I created Virtual Machine in Azure running Windows Server 2012. I noticed Azure created a storage account automatically. When I go inside that storage account, click Containers tab, and under vhds name it shows a name-name2-2014-12-05.vhd which is 127 GB and it always has recent Last modified date. What is that for? Is that my live backup image of my entire server deployment? If so where can I see how often it backs up?
When I go inside that storage account, click Containers tab, and under
vhds name it shows a name-name2-2014-12-05.vhd which is 127 GB and it
always has recent Last modified date. What is that for?
Virtual Machines in Azure are Stateful in nature. What that means is that any changes you make to the Virtual Machines like installing software, creating files etc. are persisted. The way Azure achieves this is by storing the Virtual Machine VHD as a page blob in Azure Storage. What you see as name-name2-2014-12-05.vhd is the VHD using which Azure launches your VM.
Is that my live backup image of my entire server deployment?
It is your VM and not the backup image. If by mistake you delete it (though Azure makes it real hard for you to delete it but its possible), your VM is gone. If you want, you can take a backup of this and store it in some other place. Search for Create Azure Virtual Machine Images and you will find ample resources.
If so where can I see how often it backs up?
By default Azure keeps 2 extra copies (a total of 3 including the main) of it in the data center and if you have enabled geo-redundancy, then Azure keeps additional 3 copies in a separate datacenter. However please keep in mind that it is not a backup. Any changes you make to your VM are replicated to all the copies. You would need to come up with your backup approach.
My recommendation would be to read more about Azure Virtual Machines. I'm sure if you search for it, you will get plentiful of resources.
I have an instance medium in windows azure.
I need an image to make new instance large, so when I create an image, It say you must delete it as part of operation.
So, how can i make image instance medium without deleting current virtual machine??
note: Amazon cloud service can make image without deleting instance. That includes microsoft server.
Actually how to do create image with minimum downtime. That's the true purpose of this question.
There are a couple of objectives I read from this. The first is that you want to make a medium instance large. You can change the size of a virtual machine without deleting it. Go to the configure tab for the VM and change the size. This will require a reboot, but it will keep your virtual machine in tact.
The second is to create an image with minimum downtime. As you know, this is not possible without destroying your existing VM. The details of sysprepping a machine are the reason (won't go into those details here). You could create a new virtual machine from your existing one and sysprep that copy though. At least that way you're not losing any downtime while you're creating the image. Not sure how helpful that is for your scenario. Personally, I would just re-size your existing VM if that's all you need. Regardless, here are the steps.
Copy the VHD to a backup container in the same storage account.
Create a new disk from the copy of the VHD.
Create a new virtual machine based off the new disk. You can also specify the size at this step too.
Login and sysprep the new virtual machine.
Shutdown and capture the image of the new virtual machine.
This will get you an image without impacting your existing VM.
There are two types of images: Specialized and Generalized.
You can check the detail in VM Image.
For your scenario, you want to change the size of your vm. So you'll need a Generalized image which has been removed the original provision data, such as vm size, the admin user password, etc.
But in order to capture a Generalized image, you have to do deprovision on the original running vm.
For Windows in Azure:
%windir%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe
For Linux in Azure:
$ sudo waagent –force –deprovision
$ shutdown –h now
Note: After deprovison, the original VM is useless for you and just like an orphan, and you lost the control for it since it has been removed a lots of original provision data. That's why Azure deletes the vm automatically after capturing image successfully.
I agree with you AWS EC2 is more powershell than Azure. A lot of services are inconvenient in Azure.
There is VHD blob container which contains your VM OS disk and VM data disks. You can copy the data disks and attach to any VM.
When you are creating the image, you need to do sysprep which deletes everything from your VM even login. So anyways your VM is of no use. Now once the image is there you can create your VM selecting the image which you have created and data disk if you want old data to be there also. And you can create as many copies as you want.