Backing up Azure Files - High cost Read operations
I have found that Azure Files is unusable for large deployments due to the high cost of backups, especially for deployments with lots of small files. Most backup solutions have a changed block tracking mechanism and filter driver that can quickly determine what has changed between the prior backup. If nothing has changed since the last backup, the job quickly makes this determination and the backup job can take seconds to complete. But with Azure Backup backing up Azure Files, it appears to me that each backup has to enumerate every file and blob before making this determination. I first noticed this when I created a 1TB file share and nothing changed with the files from the prior backup and the job took 12 hours to complete. I then looked at my bill and it was $12 in read operations just for that backup where no files have changed. Azure Files is an awesome product, but securing your backups in a vault using Azure Backup just isn't doable from a price perspective. Does anyone know if there are changes on the horizon to Azure Backup in terms of a more robust change block tracking system?
Protecting access to storage account with backups and archived data
Hello experts, I've been trying to understand how to protect backups, and archived data stored in azure blob storage. What is the way to protect those data in case that a global admin rights got compromised? I understand that data are encrypted, etc... but in scenario above, what could be an additional level to make sure that even if global admin account got compromised, it will not be easy to access those critical data?
Can an azure blob with malware infect other blobs in the storage account?
Hi, I need to know whether it can be infected to other blobs or files if I accidently uploaded a malware into azure storage account or all the blobs are isolated from each other. If it can be infected, does it infect the blob/files only within the container or to the entire storage account?
Classic Storage Account with large VM VHDs / Migration to ARM
Hello all. I was tasked with ensuring that all of our Azure VMs were being backed up. Seems easy enough until I went into a subscription that didn't get much attention. There were 5 vms that weren't backed up. I set up an Azure recovery vault, created the backup policy, and tried to add the 5 vms.....Failed. It turns out that these 5 vms had their disks stored in a classic storage account and Azure backup won't back them up. In looking at all of the resources in that subscription, it seems that all of them had been migrated from ASM to ARM except the storage account. Not having migrated anything from ASM to ARM, I read that migrating the classic storage account can be done by clicking on the Migrate to ARM option listed in the storage account. Now the question(s): Each of these 5 vms that are using the classic storage account for disk storage have three or four disks and each of the non-os disks are pretty large; over 500 gigs. Using the 'Migrate to ARM' function, what's going to happen? Do i need to deallocate the VMs? Will it migrate all of the VM vhd disks to a new storage account and update the VMs so that they know where the migrated disks are? Do the migrated vhd files turn into managed disks? I was just looking for some details on how the migration plays out because it would be a monumental task to rebuild those 5 VMs with no backups. Thanks for reading this and any feedback would be much appreciated.
