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.
Related
In Azure, is it possible to have master VM that writes to a disk which has read-only slave replicas on other VMs?
Our app needs to download ~100GB of files when scaling to a new VM. This is loaded slowly from an external provider but we want to make it available quickly when we scale out more VMs.
I don't think you can do streaming replication (which I think is what you're asking for), or read only slave through the Azure service without implementing this yourself over network or through a relational database management system.
As of this writing, one disk cannot be connected to multiple Azure VMs (See FAQ for Managed Disks. One option would be to create a snapshot of the disk, and create a new disk from the snapshot. You could automate this via the Azure Managed Disk Service API (eg: an Azure Powershell script), and it would have to happen on a VM that isn't running.
If your data is same and doesn't change per new VM created then you can have it stored on the Azure File Storage Standard/ Premium. Then have Azure File storage attached to every new VM whenever it is created. snapshot disk will make it pretty complex. Azure Files Storage is good choice in this scenario.
I am new to Azure and setting up the backup of multiple Azure VM's, all on the Location. 2 of the 3 VM's have additional data disks attached to them.
Will the Recovery Services Backup policy also back up the data on these disks or do I need to setup a separate backup policy to manage these? Thanks
Azure Backup for VMs include automatically all disks attached to the VM.
Note, there is some limitations to how quickly it can do the backup if there are multiple disks attached. See e.g. Plan your VM backup infrastructure in Azure for more infromation.
All attached data disks will be included in any VM which is enrolled into backups. Few limitations to take note of below.
There's also a private preview currently running for data disks which are 1TB+ in size, link below.
For Azure VM backup, each VM can have up to 16 data disks with each data disk being of size 1024GB or less.
Azure Backup (Private Preview) Support Disks up to 4TB
Azure Backup FAQ
I'm an azure newbie and just trying to understand Azure better. My questions are specific to backing up Linux VMs in Azure. Please help me in understanding it better.
I read that Azure backup takes snapshots and then uploads them to the vault. I'm trying to understand how using 'Azure backup' to backup a VM is different from taking the snapshots of OS Disk and data disk of azure VM via "az vm" cli commands?
What exactly is the vault here? Is it internally implemented as a storage account with blob container or is it something similar to the Glacier in AWS?
Which is better cost wise, azure backup or osdisk snapshots?
If both the options are similar, i.e using azure backup or taking a snapshot of OS disk/Data disks. Is there an advantage of using one over the other?
Are the Snapshots of OS disk taken in Azure global in nature? Can they be accessed from any other geos?
In the azure portal, snapshots, what is "snapshot state"? Why is the snapshot state "Unattached" for me even after spinning off a VM from the snapshot disk?
I'm trying to understand how using 'Azure backup' to backup a VM is different from taking the snapshots of OS Disk and data disk of azure VM via "az vm" cli commands?
Azure backup works as disaster recovery service(DRaaS). It is a managed service and more easier to use. You don't need to worried where and how the backup files are stored. If the VM is running, Azure Backup service uses the VMSnapshotLinux extension to take a point-in-time snapshot in Linux. Otherwise, the Backup service takes a snapshot of the underlying storage.
What exactly is the vault here?
A backup vault is an managed storage service that stores all the backups that have been created over time. It also contains the backup policy applied to the protected VMs.
Is it internally implemented as a storage account with blob container or is it something similar to the Glacier in AWS?
It is a managed service, it hasn't been announced how it is worked.
Which is better cost wise, azure backup or osdisk snapshots?
Azure backup has extra charge than the storage consumed charge. For more information, link below is for your reference.
Backup Pricing
Is there an advantage of using one over the other?
If you want to take a snapshot and the VM is running, we suggest you shutdown the VM first to take a clean and consistent snapshot. Azure backup service will use a extension to do it, we don't need to shutdown the VM.
Are the Snapshots of OS disk taken in Azure global in nature? Can they be accessed from any other geos?
A snapshot is a read-only blob, it can be accessed from any other geos.
In the azure portal, snapshots, what is "snapshot state"?
The 'Unattached' is the state of image/disk. It means that the disk haven't attached to any VM.
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.
We are using Azure Virtual machines to host our application in the cloud.
Couple of virtual machines are hosting web front-end(state-less) and one virtual machine is hosting SQL Server (data is stored in Data Disk).
As we all know, these virtual machines consist of OS Disk and Data Disk(optional) which uses VHD files stored in blob storage. We are using geo-redundant blob storage which stores these VHD files.
We are now planning for disaster recovery for our cloud application. So if a Microsoft data center is down, is it possible to spin up virtual machines in another data center with the help of OS Disk and Data Disk stored in geo-replicated storage?
You are not supposed to use geo-replicated storage with SQL Server data disks. This is documented at https://msdn.microsoft.com/library/azure/dn133149.aspx. Specifically, the document states "When creating a storage account, disable geo-replication as consistent write order across multiple disks is not guaranteed. Instead, consider configuring a SQL Server disaster recovery technology between two Azure data centers".
Currently you can not control if/when Microsoft fails over to the secondary (geo-replicated) storage account. Microsoft controls that.
As I understand it, in the event that Microsoft does declare a disaster and fails over, then your VMs would still work. Perhaps you'd have to create the VM again from the VHD, but the data would be there (minus anything lost since the last sync to storage).