I've set up Azure Site Recovery to replicate a VM using Azure-to-Azure replication. Everything is working great, but I've now added a new disk to my VM and I do not see the .vhd page blob in the replicated storage account.
How can I get the newly added disk to replicate? Do I need to remove replication and then redo it?
Currently, this feature is not available. Probably you need to redo it.
You may vote up an idea submitted by another Azure customer:
https://feedback.azure.com/forums/256299-site-recovery/suggestions/6438471-automatically-replicate-the-new-disk
All of the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
Related
I'm aware I can now do this through the portal in the storage blade however the account I need to migrate is a production account. It's just blobs, tables and queues, no VMs.
I can stomach some downtime (say an hour or 2) but am unsure how long it would take to migrate approx 750GB, does anyone have experience with the migration and an idea on the time it takes based on a similar volume size?
I also assume once migrated all my storage keys will change so I will need to update all the references in my app settings.
For anyone else wondering about this what #4c74356b41 said appears to be true.
Thanks to this post and the PowerShell command, couldn't get the ARM template to dpeloy at least not from VS, I was able to create a classic storage account. Didn't think this was still possible!
I then kicked off a 50k files container copy from another storage account in the Azure Storage Explorer container into this new classic resource and then while that was running ran the full migration including commit and the file copy carried on regardless.
Final step was to move the new resource (file copy is still ongoing at this point) from the migrated resource group back into the same resource group as the original classic storage account.
Once the move was complete the file copy was still going smoothly and all the Keys remained unchanged so this does seem to be truly seamless.
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'm a lone dev that inherited a giant undocumented mess of an azure vm without any sysadmin-like training nor a lab to test things out. This vm runs our website just fine, but I couldn't log in to VestaCp because disk space usage is at 100%.
I did setup azure to make daily backups. Now I'm wondering if azure somehow stores them on the same machine e.g. they're the cause of the full disk space.
if so, how do I remove a set of old backups?
Now I'm wondering if azure somehow stores them on the same machine e.g. they're the cause of the full disk space.
As mentioned in the official document about creating a recovery services vault for a VM:
The location of Recovery Services vault determines the geographic region where your backup data is sent.
If you have virtual machines in multiple regions, create a Recovery Services vault in each region.
There is no need to specify the storage accounts used to store the backup data--the Recovery Services vault and the Azure Backup service automatically handle the storage.
Per my understanding, your VM backup data could be stored on the storage accounts that are managed automatically by the Recovery Services vault (ARM) and the Azure Backup service (ASM).
Moreover, if this issue could not be solved by removing a set of old backups, I assumed that you could follow this tutorial to resize Azure VM OS or Data Disk created using Azure Service Manager (ASM) or this tutorial for resizing ARM VM OS & Data disk.
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.
I cannot find any information on the Azure site clarifying this - possibly it's my understanding of how these work - please can someone confirm I am correct.
If I have a VM (Windows generated from their template which I have then installed some software on) and shut it down (using the portal to deallocate it), I am no longer charged compute costs. I am still charged storage for the VHD file but there will be no storage transactions as the machine is switched off.
As and when I start it, a new instance is deployed, from the VHD I previously configured (this is important to start with the software installed still) and I will then be charged for storage transactions and compute minutes.
Also, for the storage on VHD files, is this goo-redundant or locally-redundant or do I choose when creating the VM?
If you create a storage account first, you have a choice of enabling geo-replication or not. Default value is enabled.
If you create a virtual machine, creation of a new storage account is an option. This account will default have geo-replication enabled.
You are correct on the charging.