I have 2 web applications in azure on a Standard App Service Plan (S1 Standard).
After I finish a scheduled backup configuration, it returns to the backup blade and show the following message:
"Backup and Restore feature requires your App Service plan to be Standard or higher. Click here to upgrade your App Service plan and access this feature."
Also all the backup options are grey out.
But I have a standard service plan already...
Is there other requirement that I'm missing?
Sometimes if I keep refreshing I can access the backup configuration again, but when I try to configure the backup it never finishes loading the backup options (Storage account/Schedule/Database).
Is there a problem with the backup system?
I just created a Azure Web App in South Central US location and tested its backup feature. It worked fine on my side.
Is there other requirement that I'm missing?
No, what you did is right. The issue maybe a temporary problem of Azure backup service or caused by the cache of your browser. Please clear the cache or history of your browser and try your steps again.
Related
I've been deploying to my cloud service/web role pretty regularly for over a year with no issues. But suddenly, today, my deployment bombed with the following error:
The HTTP request to
'https://management.core.windows.net/*****/services/hostedservices/*****?embed-detail=true'
has exceeded the allotted timeout of 00:01:00. The time allotted to
this operation may have been a portion of a longer timeout.
And when I attempt to view the resource in the Azure portal dashboard, it eventually times out and displays a rain cloud icon. I get the same timeout and rain cloud icon when clicking on "Roles and Instances".
Azure's status page shows my region "West US" doesn't have any issues.
Interestingly, I can still access my application via the browser, so some instance is there and running, I just can't deploy updates to it or manage it in any way via the Azure portal.
What are my options here? I was hoping I could RDP into it and force it to reboot or restart IIS or something, but everything I click on related to the cloud service in the portal times out. I'd hate to have to attempt to delete it and create a new one as it's a pain to get the settings in sync, and often times I can't name it the same, etc.
Any ideas?
So, after going down the rabbit hole for about an hour playing around with the new Cloud Shell feature from the Azure portal to see if I could reboot it via a power shell command, the issue seems to have resolved itself. I guess it was some sort of temporary hiccup with Azure or something, but I can now see my cloud service/web role in the portal and can now deploy to it.
We are evaluating Azure ASR for cloud Backup and Site Recovery.
Started a month ago with Backup services to backup files, folders and SQL servers and everything worked fine, MABS is installed in server A.
We have also added a physical server to Site recovery, installing the Azure site recovery on the same server A. Since then, every dashboard referring to Backup information has not been updated though its clear that GRS Storage is used for backups.
Tried to uninstall/re-install MABS without any success, any ideas? there are no errors in the MABS MMC console.
It is not recommended to install backup (MABS) and site recovery on the same machine since both Services are using similar tasks there will be lot of conflicts.
I am new to Microsoft Azure and working on a MVP for a client. I am able to successfully deploy my ASP.NET MVC web app to a Web Role. The issue I'm facing is that Azure Web Role seems to recycle itself and revert to the deployment package. This leads to rollback of manual changes done (if any) after the deployment (like I allow user to upload profile images and am storing them in file system).
Is this the expected behavior? If not, when can I look from debugging purposes?
Looking for any help possible.
Is this the expected behavior? If not, when can I look from debugging
purposes?
It is expected behavior. Azure Fabric Controller is responsible for managing the Virtual Machines in which your WebRole runs. It takes care of patching the VM and do other maintenance related work on that VM. It is also responsible for taking out faulty VMs and replace them with brand new VMs. When the replacement happens, Fabric Controller will create the new VM based on the last deployment package.
You should not be making any changes manually after VM hosting WebRole has been created, these are Stateless VMs. Any changes you make to VM will be rolled back if Fabric Controller decides to recycle the VM. Please note that these changes do persist if the VM is simply rebooted.
I have not used any Source control mechanism (TFS or GIT) to deploy my Umbraco app to Azure WebSites. Also I don't have any backups of the WebSite(Backups created on Azure Management portal). Also I don't have a previous version of the whole project with me locally. Is there any way I can restore or backup my Azure Website to previous deployment ? Or is it completely impossible ?
Unfortunately, there is no way to restore it the way you have described your situation.
I have a question about Remote Desktop deployment on Azure Cloud Application.
First of all I published my app via visual studio.Everything is working.
Yesterday I connected with remote desktop to my azure app and changed some attributes in my web.config files.
First thing : My cloud app is getting so slowly so I think IIS restart etc. but I don't know why my site is coming slowly ?
Second thing : Today when I enter to my app , I can't see my changes and when I check it via remote desktop all my changed things are roll back. Why ?
Do I have to all my deployment via Visual Studio ?
How is staying my deployment in Azure machines ? This machine is sometimes changing or never change when I delete it ?
Thanks,
This is not the expected way to change the settings. Azure is free to relocate your instance to another VM or restart it in-place and erase all your local changes.
So if you want to do some permanent changes you have to do them locally, build the service package and deploy the new package to Azure. This way Azure will have an updated package and your changes will persist.
If you want to change something frequently you have to use the <ConfigurationSettings> node of the service configuration. Your code will have to query the setting and react accordingly. If you want some activity triggered when the service configuration is changed your code has to handle the RoleEnvironment.Changing event.
You cannot make changes in the VM directly, because these changes are not persisted (as you have already noticed). The VM can be recycled and restored at any moment. So you have to make changes by applying them locally and redeploy the site.